From owner-ipng@sunroof.eng.sun.com Mon Feb 2 10:21:39 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA21649 for ipng-dist; Mon, 2 Feb 1998 10:14:50 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA21642 for ; Mon, 2 Feb 1998 10:14:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA04972 for ; Mon, 2 Feb 1998 10:14:35 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id KAA25918 for ; Mon, 2 Feb 1998 10:14:27 -0800 (PST) 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 KAA13641; Mon, 2 Feb 1998 10:14:23 -0800 Message-Id: <3.0.3.32.19980202101736.009a75a0@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 02 Feb 1998 10:17:36 -0800 To: burgan@home.net From: Bob Hinden Subject: (IPng 5163) Updated IPv6 Addressing Drafts Cc: ipng@sunroof.eng.sun.com, scoya@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff, Updates to the "An IPv6 Aggregatable Global Unicast Address Format" and "IP Version 6 Addressing Architecture" are now out. They are: Title : An IPv6 Aggregatable Global Unicast Address Format Author(s) : B. Hinden, M. O'Dell, S. Deering Filename : draft-ietf-ipngwg-unicast-aggr-03.txt Pages : 11 Date : 27-Jan-98 Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v2-06.txt Pages : 25 Date : 28-Jan-98 The changes to "An IPv6 Aggregatable Global Unicast Address Format" are in response to the comments received during the IETF last call. Specifically, it adds an 8-bit reserved field between the TLA and NLA fields to allow for future growth in the number of TLA's and a new technical motivation section that explains the design choices. The change to "IP Version 6 Addressing Architecture" is to update the section on the aggregatable address format to show the new reserved field. I belive that both of these documents can now go forward to proposed standard. 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 Feb 4 05:29:12 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA24302 for ipng-dist; Wed, 4 Feb 1998 05:24:07 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA24295 for ; Wed, 4 Feb 1998 05:23:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA00535 for ; Wed, 4 Feb 1998 05:23:52 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id FAA00694 for ; Wed, 4 Feb 1998 05:23:50 -0800 (PST) Received: from dashub2.das.dec.com (dashub2.das.dec.com [16.136.64.63]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with ESMTP id IAA02041 for ; Wed, 4 Feb 1998 08:22:52 -0500 (EST) Message-Id: <199802041322.IAA02041@mail13.digital.com> Received: by dashub2.das.dec.com with Internet Mail Service (5.0.1458.49) id ; Wed, 4 Feb 1998 08:23:50 -0500 From: Ken Powell To: "'set@bellcore.com'" , "'huitema@bellcore.com'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 5164) RE: I-D ACTION:draft-ietf-ipngwg-aaaa-02.txt Date: Wed, 4 Feb 1998 08:23:47 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, Susan, I like the general approach taken in your draft. It defines an excellent mechanism to reduce the aggravation of network renumbering on the namespace. I am concerned about the potential performance impacts, particularly when combining the mechanisms defined here with additional section processing, multi-homing, and dnssec. DNS resolvers could face long strings of queries where a single query was used before. The functional gains from all these mechanisms are significant, but will the performance hit be too much? Does anybody have an idea what the impacts are likely to be? Section 2 >> When the number of significant bits is lower than 128, >> the record also contains the domain name of another >> IPv6 system, which typically describes a complete subnet, >> or a complete site. The term "subnet" is not used consistently in this document. I read "subnet" in this statement to mean "link". The term "subnet" takes on a much broader role later in the document. For example, "domain name of subnet" uses "subnet" to be any portion of the world-wide IPv6 network that happens to share the same prefix. The "IP Version 6 Addressing Architecture" (draft-ietf-ipngwg-addr-arch-v2-05) section 2.1 defines "subnet" to be associated with a single link. Perhaps "prefix" should replace "subnet" wherever the latter meaning is intended. Section 2.1 >> Old systems, however, will only be capable of using >> the new records if they decide to use the first 128 >> bits and ignore the remainder. Yes, this is possible, but do we really want to mention this? Any old system that is implemented this way will encounter increasing numbers of communication failures as databases are loaded to use the prefixes. Section 2.2 >> +------------------+--------------+-----------------------+ >> | Ipv6 address | Pre. length | Domain name of subnet | >> | (128 bits) | (1 octet) | (variable, 0..256) | >> +------------------+--------------+-----------------------+ Domain name length range should be 0..255. See RFC 1035 section 3.1: "To simplify implementations, the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less." >> o a prefix length, encoded as one single octet. This should specify the encoding more accurately. Perhaps: "...encoded as an eight bit unsigned integer number, valid range 0 to 128." Should this section provide special rules on prefix length to support transition? For example: "Prefix length MUST be provided on transmitted messages. The receiver may accept a message without a prefix length to support backward compatibility. In this case, the receiver treats the message as having a prefix length of zero." This specification should cover the case where a AAAA record with a non-zero prefix length defines a non-zero value for the prefix. For example: S.XXX.COM AAAA 2CCC:00CA:001A:1:1234:5678:90AB:CDEF 48 IP6.XXX.COM Is this valid? If so, how is it interpreted by the resolver?" Should this specification restrict address prefixes to be used only with Global Aggregate Unicast Addresses? If so, then the valid range for prefix length should be 0 to 64. If not, then are there any special rules that apply to their use with other types of addresses? Where should such rules be defined? Section 2.3 >> A type AAAA query does perform additional section >> processing, by returning the AAAA records associated to >> the domain names mentioned in the domain's AAAA records. It looks as if additional section processing will become recursive. For example, a query for a mail exchange (MX) record could return a AAAA domain name. The AAAA domain name lookup during additional section processing could specify another AAAA domain name for the prefix. This leads to a second level of additional section processing. What happens if the record for this second AAAA domain name is also in the same zone? Should the server continue following the path in additional section processing until it hits a domain name that is not locally defined? Section 4 >> These new definitions mean that a name server must add >> any relevant IPv4 addresses and any relevant IPv6 addresses >> available locally to the additional section of a response >> when processing any one of the above queries. Is this really intended to be a "MUST"? RFC 1034 section 3.7.1 indicates additional section processing is optional: "In addition to relevant records, the name server may return RRs that point toward a name server that has the desired information or RRs that are expected to be useful in interpreting the relevant RRs." Section 5.1 >> Lets suppose that S is a station in the site X, that it is >> connected to the link number 1 in this site, and that it uses >> the station identifier (UID) '1234:5678:90AB:CDEF'. Change "station identifier" to "interface identifier". This is the term used in "IP Version 6 Addressing Architecture" (draft-ietf-ipngwg-addr-arch-v2-05) section 2.5.1. Remove "(UID)". The identifier does not need to be globally unique for this to work. >> As a result, the site X inherits three address prefixes: >> >> o 2CCC:00AA:001A/48 from A, for routes through C, >> o 2DDD:00AA:001A/48 from A, for routes through D, >> o 2EEE:00BB:034B/48 from B, for routes through E, The next level aggregates should be "00CA", "00DA", and "00EB" instead of "00AA", "00AA", and "00BB" in this table. >> S.XXX.COM AAAA ::1:1234:5678:90AB:CDEF 48 IP6.XXX.COM >> >> IP6.XXX.COM AAAA 0:0:001A:: 28 IP6.A.NET >> IP6.XXX.COM AAAA 0:0:034B:: 28 IP6.B.NET >> >> IP6.A.NET AAAA 0:00CA:: 16 IP6.C.NET >> IP6.A.NET AAAA 0:00DA:: 16 IP6.D.NET >> >> IP6.B.NET AAAA 0:00EB:: 16 IP6.E.NET Does each successive level of AAAA records in the tree require a reduced prefix length? In your example, XXX.COM zone contains the site prefix. Instead, the ISP's may wish to store prefix allocations for their subscribers within their own DNS zone. You could end up with the following: S.XXX.COM AAAA ::1:1234:5678:90AB:CDEF 48 IP6.XXX.COM IP6.XXX.COM AAAA 0::0 48 XXX.A.NET IP6.XXX.COM AAAA 0::0 48 XXX.B.NET XXX.A.NET AAAA 0:0:001A:: 28 IP6.A.NET IP6.A.NET AAAA 0:00CA:: 16 IP6.C.NET IP6.A.NET AAAA 0:00DA:: 16 IP6.D.NET XXX.B.NET AAAA 0:0:034B:: 28 IP6.B.NET IP6.B.NET AAAA 0:00EB:: 16 IP6.E.NET Notice that IP6.XXX.COM does not define any additional bits of the address, but it does define the multi-homed nature of the site. Should this be allowed? Section 5.2 >> Obviously, the DNS updates will have to be synchronized >> with the address configuration and router renumbering >> procedures. This should be specified in a separate memo. Agreed. This needs to be clearly understood. How will all this work with dynamic updates to DNS? I assume we want a host or it's DHCP server to automatically set its Site Level Aggregation Identifier and Interface Identifier in it's DNS resource record. The host will need some way to determine that a prefix domain name exists so that it won't also attempt to change the site prefix when the site gets renumbered. Section 6 >> 5. SECURITY CONSIDERATIONS nit: this should be section 6. >> The AAAA and DBIT records can be secured by using the DNS >> security procedures. True. However, verification will become more costly. Each resource record returned in the queries to resolve a AAAA address will have an associated signature record. The resolver will need to track down the public keys for every zone that the signature records came from in order to authenticate the query. This could result in more AAAA queries to additional zones, which in turn could trigger the need to retrieve more public keys. Site security considerations may rule out the use of domain names of prefixes. For example, Site A and Site B require highly secure communications with each other. They trust the integrity of each other's DNS zones and rely on dnssec procedures to verify the information. Their security policies may not allow the same level of trust in their internet service provider's DNS zones. Does a statement like this belong in the draft? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 4 06:24:21 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA24363 for ipng-dist; Wed, 4 Feb 1998 06:12:28 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA24356 for ; Wed, 4 Feb 1998 06:12:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA04618 for ; Wed, 4 Feb 1998 06:12:13 -0800 Received: from wentzl.cdg.chalmers.se (wentzl.cdg.chalmers.se [129.16.12.9]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA19464 for ; Wed, 4 Feb 1998 06:12:10 -0800 (PST) Received: from wilfer1.cdg.chalmers.se (wilfer1.cdg.chalmers.se [129.16.12.11]) by wentzl.cdg.chalmers.se (8.8.8/8.8.8) with ESMTP id PAA05245; Wed, 4 Feb 1998 15:12:07 +0100 (MET) From: Gunnar Lindberg Received: (from lindberg@localhost) by wilfer1.cdg.chalmers.se (8.8.8/8.8.8) id PAA15231; Wed, 4 Feb 1998 15:12:06 +0100 (MET) Date: Wed, 4 Feb 1998 15:12:06 +0100 (MET) Message-Id: <199802041412.PAA15231@wilfer1.cdg.chalmers.se> To: ipng@sunroof.eng.sun.com Subject: (IPng 5165) IPv6 addr in URL & X X-Mailer: UCB Mail 5.3.9 97-10-01 (MIME) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I know this was brought up in DC and was discussed on the list afterwards, but was it ever resolved - except for "keep it as is"? Someone even mentioned he had a parser that could handle all cases, but I actually doubt it will. Please ignore that the example is somewhat silly and look at http://3FFE:200:3::80:80 Is this an address ending with ":80:80" (assuming the default port) or is port ":80" actually there? I'm unable to see how any parser could ever handle that. But, I actually think we can get around this ambiguity or at least reduce it: Simply require that IPv6 addresses used in URL:s, X etc may not use "::" and must instead give the entire row of ":0:", e.g. http://3FFE:200:3:0:0:0:0:80:80 People will still screw up and use "::", but a parser would then be able to find out and issue an error message rather then make the wrong guess. It's possible that an ordinary URL parser will still barf, but at least we now have no ambiguity in the URL/addr format. Gunnar Lindberg -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 4 08:34:50 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id IAA24543 for ipng-dist; Wed, 4 Feb 1998 08:28:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id IAA24536 for ; Wed, 4 Feb 1998 08:27:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA08130 for ; Wed, 4 Feb 1998 08:27:48 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id IAA27037 for ; Wed, 4 Feb 1998 08:27:05 -0800 (PST) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA28270; Wed, 4 Feb 1998 16:27:01 GMT Received: from brianh.hursley.ibm.com (carpenterb.hursley.ibm.com [9.20.22.153]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) with SMTP id QAA106290; Wed, 4 Feb 1998 16:27:00 GMT Message-Id: <34D889E7.524D@hursley.ibm.com> Date: Wed, 04 Feb 1998 15:31:51 +0000 From: Brian E Carpenter Reply-To: brian@hursley.ibm.com Organization: IBM Internet Division X-Mailer: Mozilla 3.01 (Win95; I) Mime-Version: 1.0 To: Gunnar Lindberg Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5166) Re: IPv6 addr in URL & X References: <199802041412.PAA15231@wilfer1.cdg.chalmers.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gunnar, Two problems with your proposal. 1. URL parsers take the first colon after // as defining the end of hostname - in your example 3FFE is sent off to gethostbyname. Expanding the :: doesn't fix this. Try it at home, kids: I get > Fatal Error 500 > > Can't Access Document: http://3ffe.hursley.ibm.com:200:3::80:80/. > > Reason: Can't locate remote host: 3ffe.hursley.ibm.com:200:3::80:80. where you can see that the default domain was inserted before the first colon. 2. The objective was to allow cut-and-paste of arbitrary IPv6 addresses. Expanding the :: requires brainwork and typing. As of today, we don't have a solution. Brian Carpenter >-- Gunnar Lindberg wrote: > > I know this was brought up in DC and was discussed on the list > afterwards, but was it ever resolved - except for "keep it as is"? > Someone even mentioned he had a parser that could handle all cases, > but I actually doubt it will. > > Please ignore that the example is somewhat silly and look at > > http://3FFE:200:3::80:80 > > Is this an address ending with ":80:80" (assuming the default port) > or is port ":80" actually there? I'm unable to see how any parser > could ever handle that. > > But, I actually think we can get around this ambiguity or at least > reduce it: Simply require that IPv6 addresses used in URL:s, X etc > may not use "::" and must instead give the entire row of ":0:", e.g. > > http://3FFE:200:3:0:0:0:0:80:80 > > People will still screw up and use "::", but a parser would then be > able to find out and issue an error message rather then make the > wrong guess. It's possible that an ordinary URL parser will still > barf, but at least we now have no ambiguity in the URL/addr format. > > Gunnar Lindberg > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 4 09:38:08 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA24654 for ipng-dist; Wed, 4 Feb 1998 09:29:07 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id JAA24647 for ; Wed, 4 Feb 1998 09:28:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA21355 for ; Wed, 4 Feb 1998 09:28:56 -0800 Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id JAA03209 for ; Wed, 4 Feb 1998 09:28:09 -0800 (PST) Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id QA05458; Thu, 5 Feb 1998 03:06:23 +1100 (from kre@munnari.OZ.AU) To: Ken Powell Cc: "'set@bellcore.com'" , "'huitema@bellcore.com'" , "'ipng@sunroof.eng.sun.com'" Subject: (IPng 5167) Re: I-D ACTION:draft-ietf-ipngwg-aaaa-02.txt In-Reply-To: Ken Powell's message of "Wed, 04 Feb 1998 08:23:47 -0500." References: <199802041322.IAA02041@mail13.digital.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 05 Feb 1998 03:06:22 +1100 Message-Id: <14637.886608382@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 4 Feb 1998 08:23:47 -0500 From: Ken Powell Message-ID: <199802041322.IAA02041@mail13.digital.com> | Does anybody have an idea what the impacts are likely to be? Not yet I don't think. I agree with most of your comments and fixes, but some of them are probably of the kind that could wait until the basic mechanisms are more agreed. They should be fixed before this is done, but aren't all that important for the immediate future. Just one point... | Site security considerations may rule out the use of domain names | of prefixes. For example, Site A and Site B require highly secure | communications with each other. They trust the integrity | of each other's DNS zones and rely on dnssec procedures to | verify the information. Their security policies may not allow | the same level of trust in their internet service provider's DNS | zones. Does a statement like this belong in the draft? Probably. However, what the draft should make clear (perhaps just by the use of another example) is that it is not required that the higher level prefix domain name be in the ISP's name space. It (they) can just as easily be in the end user organisation's domain. That means that the end user has to take the responsibility of changing its value when renumbering occurs, but also means that they keep total control over their name space. Which to use will be up to the actual users to decide. As currently written there's kind of an implicit assumption that control of the upper level bits of the organisation's addresses will automatically be handed off to the ISP which assigned them - while that likely will be common, it is by no means required for the mechanisms to work, and won't always be what is done. 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 Feb 4 09:56:16 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA24793 for ipng-dist; Wed, 4 Feb 1998 09:47:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id JAA24786 for ; Wed, 4 Feb 1998 09:47:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA25699 for ; Wed, 4 Feb 1998 09:47:19 -0800 Received: from wentzl.cdg.chalmers.se (wentzl.cdg.chalmers.se [129.16.12.9]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA14608 for ; Wed, 4 Feb 1998 09:47:15 -0800 (PST) Received: from wilfer1.cdg.chalmers.se (wilfer1.cdg.chalmers.se [129.16.12.11]) by wentzl.cdg.chalmers.se (8.8.8/8.8.8) with ESMTP id SAA06984; Wed, 4 Feb 1998 18:47:13 +0100 (MET) From: Gunnar Lindberg Received: (from lindberg@localhost) by wilfer1.cdg.chalmers.se (8.8.8/8.8.8) id SAA15871; Wed, 4 Feb 1998 18:47:12 +0100 (MET) Date: Wed, 4 Feb 1998 18:47:12 +0100 (MET) Message-Id: <199802041747.SAA15871@wilfer1.cdg.chalmers.se> To: brian@hursley.ibm.com Subject: (IPng 5168) Re: IPv6 addr in URL & X Cc: ipng@sunroof.eng.sun.com X-Mailer: UCB Mail 5.3.9 97-10-01 (MIME) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Frankly speaking, I would have been surprised if that change would have solved the IPv6 addr in "URL + X + what-more-to-come" problem. But even if the URL parser people came up front and agreed to change their code, my fear is that we would have little to say to them; as defined today the "::" makes it impossible to parse a numerical IPv6 address in the URL style (unless *they* give up *their* use of ":"). Now, we can speculate about probabilities for either event... If I'm wrong, i.e. it is possible to parse my silly little example without ambiguity, then we're done for now and can stop here. But otherwise, perhaps we should try to find a notation for this case. I guess it's not an extreme hurry but in the long run, saying "we don't have a solution" is a no-no. It is not going to be used often (and I would almost say that making it hard to type in numerical addresses by hand is a Good Thing :-) but as has been pointed out there are some cases where you desperately need to be able to do this, e.g. the DNS docs are on the Web 1/2 :-). My 1c, Gunnar Lindberg >Date: Wed, 04 Feb 1998 15:31:51 +0000 >From: Brian E Carpenter >Message-Id: <34D889E7.524D@hursley.ibm.com> >To: Gunnar Lindberg >Cc: ipng@sunroof.Eng.Sun.COM >Subject: Re: (IPng 5165) IPv6 addr in URL & X >Gunnar, >Two problems with your proposal. >1. URL parsers take the first colon after // as >defining the end of hostname - in your example 3FFE is >sent off to gethostbyname. Expanding the :: doesn't >fix this. Try it at home, kids: I get >> Fatal Error 500 >> >> Can't Access Document: http://3ffe.hursley.ibm.com:200:3::80:80/. >> >> Reason: Can't locate remote host: 3ffe.hursley.ibm.com:200:3::80:80. >where you can see that the default domain was inserted before the >first colon. >2. The objective was to allow cut-and-paste of arbitrary IPv6 >addresses. Expanding the :: requires brainwork and typing. >As of today, we don't have a solution. > Brian Carpenter >>-- Gunnar Lindberg wrote: >> >> I know this was brought up in DC and was discussed on the list >> afterwards, but was it ever resolved - except for "keep it as is"? >> Someone even mentioned he had a parser that could handle all cases, >> but I actually doubt it will. >> >> Please ignore that the example is somewhat silly and look at >> >> http://3FFE:200:3::80:80 >> >> Is this an address ending with ":80:80" (assuming the default port) >> or is port ":80" actually there? I'm unable to see how any parser >> could ever handle that. >> >> But, I actually think we can get around this ambiguity or at least >> reduce it: Simply require that IPv6 addresses used in URL:s, X etc >> may not use "::" and must instead give the entire row of ":0:", e.g. >> >> http://3FFE:200:3:0:0:0:0:80:80 >> >> People will still screw up and use "::", but a parser would then be >> able to find out and issue an error message rather then make the >> wrong guess. It's possible that an ordinary URL parser will still >> barf, but at least we now have no ambiguity in the URL/addr format. >> >> Gunnar Lindberg >> -------------------------------------------------------------------- >> IETF IPng Working Group Mailing List >> IPng Home Page: http://playground.sun.com/ipng >> FTP archive: ftp://playground.sun.com/pub/ipng >> Direct all administrative requests to majordomo@sunroof.eng.sun.com >> -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 4 13:32:55 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id NAA25143 for ipng-dist; Wed, 4 Feb 1998 13:25:29 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id NAA25136 for ; Wed, 4 Feb 1998 13:25:20 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA03443 for ; Wed, 4 Feb 1998 13:25:18 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA23343 for ; Wed, 4 Feb 1998 13:24:10 -0800 (PST) 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 NAA25197; Wed, 4 Feb 1998 13:23:13 -0800 Message-Id: <3.0.3.32.19980204132621.007b1500@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Wed, 04 Feb 1998 13:26:21 -0800 To: Gunnar Lindberg From: Bob Hinden Subject: (IPng 5169) Re: IPv6 addr in URL & X Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199802041747.SAA15871@wilfer1.cdg.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Gunnar, >But even if the URL parser people came up front and agreed to change >their code, my fear is that we would have little to say to them; as >defined today the "::" makes it impossible to parse a numerical IPv6 >address in the URL style (unless *they* give up *their* use of ":"). >Now, we can speculate about probabilities for either event... I think what was actually proposed was of the form: http://[3FFE:200:3::80]:80 where the "[ ]" would delineate the numerical IPv6 address. I think this should be parsable and meet the goal of "pasting" IPv6 addresses into URL's. The issue seemed to be whether parser software could be modified to handle this extension. 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 Fri Feb 6 08:35:51 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id IAA27387 for ipng-dist; Fri, 6 Feb 1998 08:30:08 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id IAA27380 for ; Fri, 6 Feb 1998 08:30:03 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id IAA12418 for ; Fri, 6 Feb 1998 08:30:02 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA06613; Fri, 6 Feb 1998 08:29:12 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA27176 for ; Fri, 6 Feb 1998 06:34:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA14119 for ; Fri, 6 Feb 1998 06:34:04 -0800 Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA19900 for ; Fri, 6 Feb 1998 06:34:02 -0800 (PST) Received: from coke.east.isi.edu by east.isi.edu (8.8.5/5.61+local-24) id ; Fri, 6 Feb 1998 14:34:01 GMT Date: Fri, 6 Feb 1998 09:28:25 -0500 (Eastern Standard Time) From: Suzanne Burgess Reply-To: Suzanne Burgess To: ipng@sunroof.eng.sun.com cc: mankin@east.isi.edu Subject: (IPng 5174) Announcement: 2nd TRAIL Workshop Message-ID: X-X-Sender: sburgess@east.isi.edu MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The National Science Foundation and USC/ISI East will present the second TRAIL Workshop, IPng Research, on 12-13 February 1998, at the NSF, in Arlington, Virginia. The workshop agenda will include presentations and discussions of submitted short papers, along with special sessions on recent developments, mobility, and the TRAIL (Testbed Routers for Advanced Internet Labs) packages. It will be posted soon. For those interested in participating, some space is available. If you are interested, please send an e-mail to Suzanne Burgess at sburgess@east.isi.edu with your name, organization, and interest in IPng. Also if you have any questions, send an e-mail to the same address. Additional information on the Workshop is available at its web site http://trail.isi.edu/Workshop2-ann.html and general information is available at the TRAIL web site (http://trail.isi.edu) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 6 09:28:00 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA27489 for ipng-dist; Fri, 6 Feb 1998 09:20:45 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id JAA27482 for ; Fri, 6 Feb 1998 09:20:33 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA24710 for ; Fri, 6 Feb 1998 09:20:32 -0800 Received: from innergate.sni.co.uk (gatekeeper2.sni.co.uk [194.42.250.67]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA06820 for ; Fri, 6 Feb 1998 09:20:22 -0800 Received: from manpost001.sni.co.uk (manpost001.sni.co.uk [137.223.63.12]) by innergate.sni.co.uk (8.6.11/8.6.7) with ESMTP id RAA00369 for ; Fri, 6 Feb 1998 17:06:34 GMT Received: by manpost001.sni.co.uk with Internet Mail Service (5.0.1458.49) id <1N1PRZZN>; Fri, 6 Feb 1998 17:20:58 -0000 Message-ID: From: "Mosthav, Marc (IT Man.)" To: "'ipng@sunroof.Eng.Sun.COM'" Subject: (IPng 5175) Re: IPv6 addr in URL & X Date: Fri, 6 Feb 1998 17:20:57 -0000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think what was actually proposed was of the form: > > http://[3FFE:200:3::80]:80 > > where the "[ ]" would delineate the numerical IPv6 address. I think > this > should be parsable and meet the goal of "pasting" IPv6 addresses into > URL's. I'm just a stupid user ;-), but I agree. > The issue seemed to be whether parser software could be modified to > handle > this extension. Well, I guess browsers will just have to be updated as every other pice of software too. Marc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 6 09:48:18 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA27570 for ipng-dist; Fri, 6 Feb 1998 09:40:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id JAA27563 for ; Fri, 6 Feb 1998 09:40:43 -0800 (PST) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA29101 for ; Fri, 6 Feb 1998 09:40:40 -0800 Received: from innergate.sni.co.uk (gatekeeper2.sni.co.uk [194.42.250.67]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA08029 for ; Fri, 6 Feb 1998 09:40:33 -0800 Received: from manpost001.sni.co.uk (manpost001.sni.co.uk [137.223.63.12]) by innergate.sni.co.uk (8.6.11/8.6.7) with ESMTP id RAA00648 for ; Fri, 6 Feb 1998 17:26:43 GMT Received: by manpost001.sni.co.uk with Internet Mail Service (5.0.1458.49) id <1N1PRZ5D>; Fri, 6 Feb 1998 17:41:07 -0000 Message-ID: From: "Mosthav, Marc (IT Man.)" To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 5176) Re: IPv6 addr in URL & X Date: Fri, 6 Feb 1998 17:41:04 -0000 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think what was actually proposed was of the form: > > http://[3FFE:200:3::80]:80 > > where the "[ ]" would delineate the numerical IPv6 address. I think > this > should be parsable and meet the goal of "pasting" IPv6 addresses into > URL's. I'm just a stupid user ;-), but I agree. > The issue seemed to be whether parser software could be modified to > handle > this extension. Well, I guess browsers will just have to be updated as every other pice of software too. Marc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 6 12:42:46 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id MAA27874 for ipng-dist; Fri, 6 Feb 1998 12:30:58 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id MAA27867 for ; Fri, 6 Feb 1998 12:30:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA15714 for ; Fri, 6 Feb 1998 12:30:42 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA28457 for ; Fri, 6 Feb 1998 12:30:38 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA14162; Fri, 6 Feb 1998 15:30:31 -0500 (EST) Message-Id: <199802062030.PAA14162@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5177) I-D ACTION:draft-ietf-ipngwg-ipv6-tcp-mib-01.txt Date: Fri, 06 Feb 1998 15:30:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Management Information Base for the Transmission Control Protocol Author(s) : M. Daniele Filename : draft-ietf-ipngwg-ipv6-tcp-mib-01.txt Pages : 6 Date : 04-Feb-98 This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the Transmission Control Protocol (TCP) over IP Version 6 (IPv6). This document also recommends a specific policy with respect to the applicability of RFC 2012 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2012 are independent of which IP versions underlie TCP, and only the TCP connection information is IP version-specific. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. 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-ipv6-tcp-mib-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-tcp-mib-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-ipv6-tcp-mib-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: <19980204141434.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tcp-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-tcp-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980204141434.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 Fri Feb 6 12:43:41 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id MAA27883 for ipng-dist; Fri, 6 Feb 1998 12:33:52 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id MAA27876 for ; Fri, 6 Feb 1998 12:33:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA16321 for ; Fri, 6 Feb 1998 12:33:33 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA29844 for ; Fri, 6 Feb 1998 12:33:18 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id PAA14255; Fri, 6 Feb 1998 15:33:12 -0500 (EST) Message-Id: <199802062033.PAA14255@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5178) I-D ACTION:draft-ietf-ipngwg-ipv6-udp-mib-01.txt Date: Fri, 06 Feb 1998 15:33:11 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Management Information Base for the User Datagram Protocol Author(s) : M. Daniele Filename : draft-ietf-ipngwg-ipv6-udp-mib-01.txt Pages : 5 Date : 04-Feb-98 This document is one in the series of documents that define various MIB objects for IPv6. Specifically, this document is the MIB module which defines managed objects for implementations of the User Datagram Protocol (UDP) over IP Version 6 (IPv6). This document also recommends a specific policy with respect to the applicability of RFC 2013 for implementations of IPv6. Namely, that most of managed objects defined in RFC 2013 are independent of which IP versions underlie UDP, and only the UDP listener information is IP version-specific. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in IPv6-based internets. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-udp-mib-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-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-ipv6-udp-mib-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: <19980204141912.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-udp-mib-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980204141912.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 Feb 9 05:27:54 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA00042 for ipng-dist; Mon, 9 Feb 1998 05:21:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA00035 for ; Mon, 9 Feb 1998 05:21:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA12873 for ; Mon, 9 Feb 1998 05:21:13 -0800 Received: from inetfw.sonycsl.co.jp (inetfw.sonycsl.co.jp [203.137.129.4]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id FAA18924 for ; Mon, 9 Feb 1998 05:20:40 -0800 (PST) Received: from gear.csl.sony.co.jp (gear.csl.sony.co.jp [43.27.98.87]) by inetfw.sonycsl.co.jp (8.8.5/3.5W) with ESMTP id WAA13053 for ; Mon, 9 Feb 1998 22:19:55 +0900 (JST) Received: from localhost by gear.csl.sony.co.jp (8.8.7/2.8Wb) id NAA00922; Mon, 9 Feb 1998 13:19:29 GMT From: Noritoshi Demizu To: ipng@sunroof.eng.sun.com Subject: (IPng 5180) Re: IPv6 addr in URL & X In-Reply-To: Your message of "Wed, 04 Feb 1998 13:26:21 -0800" References: <3.0.3.32.19980204132621.007b1500@mailhost.ipsilon.com> X-Mailer: Mew version 1.69 on Emacs 19.28.1 / Mule 2.3 X-URL: http://www.csl.sony.co.jp/person/demizu/ Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19980209221927B.demizu@gear.csl.sony.co.jp> Date: Mon, 09 Feb 1998 22:19:27 +0900 X-Dispatcher: impost version 0.99i (Apr. 6, 1997) Lines: 41 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think what was actually proposed was of the form: > > http://[3FFE:200:3::80]:80 > > where the "[ ]" would delineate the numerical IPv6 address. I think this > should be parsable and meet the goal of "pasting" IPv6 addresses into URL's. > > The issue seemed to be whether parser software could be modified to handle > this extension. Some people of web community seem to worry that this proposal would break a large number of web tools for HTML, XML, etc. One possible way would be to determine: - The notation above MUST NOT be used in HTML, XML, and other documents. - The notation above MUST NOT be appeared even in HTTP session. - The notation above is defined only for a convention for web clients. That is, browsers and web tools MUST treat the notation as illegal if it is written in web documents. (But relative URLs should be legal.) (I've heard it is already illegal because '[' and ']' are illegal in URLs.) Web clients are allowd to connect to the web server directly (i.e. not via web proxies) only when the notation was specified interactively or by a administration configuration file. This would allow to use the notation in "Open dialog" on emergency operations, and would discourage to use raw IPv6 addresses in documents. URL parsers that should be modified are limited to ones for browsers and administration tools that speak IPv6. I'm sorry if this is already assumed. FYI: There were discussions on this issue in http-wg mailing list and www-talk mailing list. Goto the following URLs and click on "Next in thread". - http-wg http://www.ics.uci.edu/pub/ietf/http/hypermail/1998q1/0129.html - www-talk http://lists.w3.org/Archives/Public/www-talk/1996JulAug/0093.html Noritoshi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 9 07:08:35 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id HAA00130 for ipng-dist; Mon, 9 Feb 1998 07:03:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id HAA00122 for ; Mon, 9 Feb 1998 07:03:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA29490 for ; Mon, 9 Feb 1998 07:03:25 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA03043 for ; Mon, 9 Feb 1998 07:02:59 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA19509; Mon, 9 Feb 1998 10:02:52 -0500 (EST) Message-Id: <199802091502.KAA19509@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5181) I-D ACTION:draft-ietf-ipngwg-ipv6-tunnel-08.txt Date: Mon, 09 Feb 1998 10:02:52 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Generic Packet Tunneling in IPv6 Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-ipv6-tunnel-08.txt Pages : 37 Date : 06-Feb-98 This document defines the model and generic mechanisms for IPv6 encapsulation of Internet packets, such as IPv6 and IPv4. The model and mechanisms can be applied to other protocol packets as well, such as AppleTalk, IPX, CLNP, or others. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-ipv6-tunnel-08.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-08.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-ipv6-tunnel-08.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: <19980206150722.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-tunnel-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-tunnel-08.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980206150722.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 Feb 9 11:45:09 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA00556 for ipng-dist; Mon, 9 Feb 1998 11:39:13 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id LAA00549; Mon, 9 Feb 1998 11:39:02 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA14926; Mon, 9 Feb 1998 11:38:56 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id LAA00737; Mon, 9 Feb 1998 11:38:17 -0800 (PST) Received: from wasted.zk3.dec.com (abelia.zk3.dec.com [16.140.64.63]) by mail13.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id OAA25408; Mon, 9 Feb 1998 14:36:16 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA27020; Mon, 9 Feb 1998 14:37:11 -0500 Message-Id: <199802091937.AA27020@wasted.zk3.dec.com> To: nat@livingston.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@isi.edu, dhcp-v4@bucknell.edu, dhcp-v6@bucknell.edu, mobile-ip@SmallWorks.com, ipsec@tis.com Subject: (IPng 5182) AATN (alternatives to NAT) Mail List Set up........................ Date: Mon, 09 Feb 1998 14:37:11 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk DO NOT RESPOND TO THIS MAIL IT IS INFORMATION per a new Mail List. If you have comment please send to me privately or get on the aatn list and send it to aatn... I have submitted a request and description for a BOF to the IETF Internet ADs to discuss alternatives to NAT. But I set up a mail list as interim place to discuss this technology. My mail is attached to the ADs....Comments on description and agenda welcome the more we do before L.A. the better we can determine if this work should move forward. send mail to - majordomo@alpha.zk3.dec.com subscribe aatn your-email-addr THose of you who sent me mail to be on this are already subscribed if you sent me mail before Noon today everyone else please subscribe directly yourself. Apology for this interruption but folks on these mail lists have expresssed an interest in alternatives to NAT and I wanted to let them know, we have a place to discuss it. /jim -------------- Return-Path: bound Received: from bywasted.zk3.dec.com by mailhub2.zk3.dec.com (5.65v3.2/1.1.10.5/24Sep96-0323PM) id AA12327; Mon, 9 Feb 1998 13:14:29 -0500 Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA16538; Mon, 9 Feb 1998 13:14:12 -0500 Message-Id: <199802091814.AA16538@wasted.zk3.dec.com> To: narten@vnet.ibm.com, burgan@home.net Cc: agenda@ietf.org, bound@zk3.dec.com, Erik.Nordmark@eng.sun.com, gabriel.montenergo@eng.sun.com, vipul.gupta@eng.sun.com, george@gideon.bt.co.uk, alan.oneill@bt-sys.bt.co.uk Subject: Request for AATN BOF at L.A. IETF Meeting Date: Mon, 09 Feb 1998 13:14:12 -0500 From: bound X-Mts: smtp Thomas and Jeff, I would like to request a 2 hour BOF for the subject "Avoidance of Address Translation in Networks" (AATN), for the L.A. Meeting. I have to request this BOF not happen during the following events so I may lead it. IPng, NGTRANS, DHCPv6, or NAT BOF meetings. Evening is fine too, but day is better. I feel this BOF should be sponsored by the Internet Area as it affects the Internet Layer of the IP model. If it should become a WG then that is up to the IESG to decide clearly where that should be located. I enlist your leadership and support to get this discussed. I am already setting up an initial mail list now. It could take two BOFs to determine what this work would entail and if it should be a working group, I just don't know right now. Description of BOF: To address the limitations of the IPv4 address space the Internet community needs to adopt variant technologies until IPv6 can be deployed giving the Internet a new address space. Three such technologies are Network Address Translation (NAT), Link Tunnel Protocols like L2TP, and the use of address translation in Firwall products. This BOF would like to investigate and discover if there is valid work to do, which can be used to assist this IPv4 problem thru the Avoidance of Network Address Translation on Networks (AATN). This work would address todays need for IPv4 and some of the needs for IPv6 which are not addressed by the existing NGTRANS WG. Because this work includes work specific just to IPv4 it should not be part of NGTRANS, but there will be some overlap clearly. Engineers in our community have begun to work on AATN in various manners and from several IETF WG mail lists this work appears to have a growing interest. This is also not part of the NAT work on going as that function is to define and specifiy parts to do NAT. One objective of this work is to provide and insure that end-to-end host connectivity is supported for mobility and IPSEC, without network address translation. Examples of work in our community to support AATN exist today: draft-tsirtisi-nat-bypass-00.txt George Tsirtisi and ALan O'Neill (British Telecom Labs) draft-montenegro-firewall-sup-03.txt G. Montenegro and V. Gupta (Sun Microsystems) draft-ngtrans-header-trans-01.txt Erik Nordmark (Sun Microsystems) draft-ngtrans-nnat-00.txt Jim Bound (Digital Equipment Corporation) A tentative agenda would look as follows: - What is the taxonomy AATN and what are some examples. - Specific Overviews of AATN (the above draft examples possibly) - What would be the objectives and charter of such a WG - What would be the deliverables of such a WG - Do we want to start a working group for AATN Sincerely, /jim Jim Bound IPv6 Technical Director Consulting Engineer UNIX Internet Group Digital Equipment Corporation 1+(603) 884-0400 bound@zk3.dec.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 Feb 10 01:46:35 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id BAA01294 for ipng-dist; Tue, 10 Feb 1998 01:42:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id BAA01287 for ; Tue, 10 Feb 1998 01:42:03 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA18561 for ; Tue, 10 Feb 1998 01:42:03 -0800 Received: from dxcnaf.cnaf.infn.it (dxcnaf.cnaf.infn.it [131.154.3.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id BAA01244 for ; Tue, 10 Feb 1998 01:41:57 -0800 (PST) Received: from dxcnaf.cnaf.infn.it (fenice.cnaf.infn.it [192.135.23.3]) by dxcnaf.cnaf.infn.it (8.8.8/8.8.8) with ESMTP id KAA26208 for ; Tue, 10 Feb 1998 10:41:55 +0100 (MET) Message-ID: <34E020E2.4BCE12F2@dxcnaf.cnaf.infn.it> Date: Tue, 10 Feb 1998 10:41:54 +0100 From: Andrea Chierici X-Mailer: Mozilla 4.03 [en] (X11; I; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 5183) IOS with IPv6 and RSVP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, we are beta test site for ipv6. We have installed the ipv6 IOS image in a 7505 router. Now, we have to use the same router both for ipv6 (6-bone connectivity) and RVSP international tests. We need an IOS image that includes both ipv6 and latest RSVP functionality. Is the current ipv6 version suitable? If not, could be possible to have a new image with these characteristics? Thank you for your collaboration, Andrea -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Andrea Chierici Computer Science Graduate Bologna ITALY e-mail: chierici@cnaf.infn.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 Tue Feb 10 07:07:54 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id HAA01492 for ipng-dist; Tue, 10 Feb 1998 07:04:27 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id HAA01479 for ; Tue, 10 Feb 1998 07:04:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA14067 for ; Tue, 10 Feb 1998 07:04:05 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA06108 for ; Tue, 10 Feb 1998 07:03:44 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA19761; Tue, 10 Feb 1998 10:03:39 -0500 (EST) Message-Id: <199802101503.KAA19761@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5185) I-D ACTION:draft-ietf-ipngwg-aaaa-03.txt Date: Tue, 10 Feb 1998 10:03:38 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : DNS Extensions to support IP version 6 Author(s) : C. Huitema, S. Thomson Filename : draft-ietf-ipngwg-aaaa-03.txt Pages : 9 Date : 09-Feb-98 This document defines the changes that need to be made to the Domain Name System to support hosts running IP version 6 (IPv6). The changes include a new resource record type to store an IPv6 address, a new domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. 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-aaaa-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-aaaa-03.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-aaaa-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19980209102648.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-aaaa-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-aaaa-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980209102648.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 Feb 10 13:57:21 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id NAA02141 for ipng-dist; Tue, 10 Feb 1998 13:50:11 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id NAA02134 for ; Tue, 10 Feb 1998 13:50:04 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id NAA29852 for ; Tue, 10 Feb 1998 13:50:03 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13397; Tue, 10 Feb 1998 13:49:11 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id MAA01997 for ; Tue, 10 Feb 1998 12:16:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA06239 for ; Tue, 10 Feb 1998 12:16:49 -0800 Received: from sunsrv5.lrz-muenchen.de (sunsrv5.lrz-muenchen.de [129.187.13.15]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id MAA14613 for ; Tue, 10 Feb 1998 12:16:48 -0800 (PST) Received: from sunsrv7.lrz-muenchen.de by sunsrv5.lrz-muenchen.de; Tue, 10 Feb 98 21:16:46 +0100 Received: from gate.muc.bieringer.de (dial0114.lrz-muenchen.de) by sunsrv7.lrz-muenchen.de (5.x/SMI-SVR4) id AA09471; Tue, 10 Feb 1998 21:16:44 +0100 Message-Id: <3.0.5.32.19980210211620.007ec730@mail.bieringer.de> X-Sender: peter@mail.bieringer.de X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 10 Feb 1998 21:16:20 +0100 To: ipng@sunroof.eng.sun.com From: Peter Bieringer Subject: (IPng 5187) Re: I-D ACTION:draft-ietf-ipngwg-aaaa-03.txt In-Reply-To: <199802101503.KAA19761@ns.ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-aaaa-03.txt Like described in section 5.1 i.e. three addresses are assigned to a hosts interface because three TLAs are in use. But is there any mechanism at the host to decide, which address should be used for outgoing packets? I know that this is not originally a problem of DNS, but this draft has opened my eyes for that kind of problem and caused this question. TIA for helpful answers, Peter --- *************************************************************** * Peter Bieringer Diplom-Physiker (Univ.) * * e-mail: mailto:peter@bieringer.de * * WWW: http://www.bieringer.de/pb (Contains PGP Public Keys) * *************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 11 07:08:29 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA02702 for ipng-dist; Wed, 11 Feb 1998 06:55:18 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA02695 for ; Wed, 11 Feb 1998 06:55:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA21158 for ; Wed, 11 Feb 1998 06:55:01 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA02791 for ; Wed, 11 Feb 1998 06:55:02 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id JAA09738; Wed, 11 Feb 1998 09:54:53 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id JAA16584; Wed, 11 Feb 1998 09:54:53 -0500 (EST) Date: Wed, 11 Feb 1998 09:54:53 -0500 (EST) From: Christian Huitema Message-Id: <980211095452.ZM16582@seawind.bellcore.com> In-Reply-To: Peter Bieringer "(IPng 5187) Re: I-D ACTION:draft-ietf-ipngwg-aaaa-03.txt" (Feb 10, 9:16pm) References: <3.0.5.32.19980210211620.007ec730@mail.bieringer.de> X-Mailer: Z-Mail (5.0.0 30July97) To: Peter Bieringer , ipng@sunroof.eng.sun.com Subject: (IPng 5188) Re: I-D ACTION:draft-ietf-ipngwg-aaaa-03.txt MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, Chosing between addresses of multi-homed hosts is an open problem, already present in IPv4. The aggregatable address format makes it slightly easier to solve than the IPv4 case, because addresses have a closer relation to topology. When looking at a set of addresses, you can prioritize those that are "on the same link", then "in the same site", then "in the same NLA", then "in the same TLA." This gives you a rather gross rule of thumb. It does not help you, however, when you need to choose between addresses that are at the same "organizational distance." Paul Francis recently presented work on that subject, involving a specialized server. -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 11 14:59:04 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id OAA03297 for ipng-dist; Wed, 11 Feb 1998 14:54:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id OAA03290 for ; Wed, 11 Feb 1998 14:54:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA10973 for ; Wed, 11 Feb 1998 14:54:38 -0800 Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id OAA27969 for ; Wed, 11 Feb 1998 14:54:38 -0800 (PST) Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.12/8.6.5) with SMTP id OAA04830; Wed, 11 Feb 1998 14:53:32 -0800 Message-Id: <199802112253.OAA04830@puli.cisco.com> To: Christian Huitema cc: Peter Bieringer , ipng@sunroof.eng.sun.com Subject: (IPng 5191) Re: I-D ACTION:draft-ietf-ipngwg-aaaa-03.txt In-reply-to: Your message of "Wed, 11 Feb 98 09:54:53 EST." <980211095452.ZM16582@seawind.bellcore.com> Date: Wed, 11 Feb 98 14:53:32 PST From: Yakov Rekhter Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, > Peter, > > Chosing between addresses of multi-homed hosts is an open problem, > already present in IPv4. For a solution to this problem with IPv4 read RFC2260 (by the way the solutions described in RFC2260 could be equally applicable to IPv6 as well). Yakov. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 12 05:12:18 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA03768 for ipng-dist; Thu, 12 Feb 1998 05:08:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA03761 for ; Thu, 12 Feb 1998 05:08:26 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA29563 for ; Thu, 12 Feb 1998 05:08:24 -0800 Received: from samar.sasi.com (sasi.com [164.164.56.2]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id FAA07732 for ; Thu, 12 Feb 1998 05:08:14 -0800 (PST) Received: from sunc2.sasi.com (sunc2.sasi.com [10.0.32.2]) by samar.sasi.com (8.8.7/8.8.7) with ESMTP id SAA11084 for ; Thu, 12 Feb 1998 18:40:57 +0530 Received: from lnxc37.sasi.com (lnxc37.sasi.com [10.0.32.37]) by sunc2.sasi.com (8.8.7/8.8.7) with ESMTP id SAA26179 for ; Thu, 12 Feb 1998 18:39:32 +0530 (IST) From: Jayesh Shah Received: (from jvs@localhost) by lnxc37.sasi.com (8.8.7/8.8.5) id SAA03776 for ipng@sunroof.eng.sun.com; Thu, 12 Feb 1998 18:46:48 +0530 Message-Id: <199802121316.SAA03776@lnxc37.sasi.com> Subject: (IPng 5192) Mobile IPv6 query To: ipng@sunroof.eng.sun.com (IPng Mailing List) Date: Thu, 12 Feb 1998 18:46:47 +0530 (IST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Is it possible for a mobile node to send binding updates to the home agents, with the home registration bit not set ? I mean to say that is the following sequence of events possible ? time event t mobile node sending BU to its home agent with H set, lifetime = 100 sec t+50 mobile node sending BU to its home agent with H off t+90 mobile node refreshing its registration with home agent by sending BU with H set Any ideas are appreciated at jvs@sasi.com Best Regards Jayesh -- Jayesh V. Shah, Networking Group, SAS, Bangalore Phone - +91-80-5281229/5281461 EXTN : 4202 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 12 07:51:18 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id HAA03854 for ipng-dist; Thu, 12 Feb 1998 07:47:10 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id HAA03847 for ; Thu, 12 Feb 1998 07:46:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA19453 for ; Thu, 12 Feb 1998 07:46:57 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id HAA15801 for ; Thu, 12 Feb 1998 07:46:56 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id KAA14498; Thu, 12 Feb 1998 10:46:51 -0500 (EST) Message-Id: <199802121546.KAA14498@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5194) I-D ACTION:draft-ietf-ipngwg-ipv6-mib-04.txt Date: Thu, 12 Feb 1998 10:46:51 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Management Information Base for IP Version 6: Textual Conventions and General Group Author(s) : D. Haskin, S. Onishi Filename : draft-ietf-ipngwg-ipv6-mib-04.txt Pages : 43 Date : 11-Feb-98 This document is one in the series of documents that provide MIB definitions for for IP Version 6. Specifically, the IPv6 MIB textual conventions as well as the IPv6 MIB General group is defined in this document. This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the IPv6-based internets. This document specifies a MIB module in a manner that is both compliant to the SNMPv2 SMI, and semantically identical to the peer SNMPv1 definitions. Internet-Drafts are available by anonymous FTP. Login 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-ipv6-mib-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-ipv6-mib-04.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: 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-ipv6-mib-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: <19980211144214.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6-mib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6-mib-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980211144214.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 Feb 12 09:09:54 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA03936 for ipng-dist; Thu, 12 Feb 1998 09:05:30 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id JAA03929 for ; Thu, 12 Feb 1998 09:05:22 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id JAA17856 for ; Thu, 12 Feb 1998 09:05:21 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01593; Thu, 12 Feb 1998 09:04:27 -0800 Received: from hsmpka.eng.sun.com (phys-hsmpka-101 [129.146.101.37]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id HAA03834 for ; Thu, 12 Feb 1998 07:40:07 -0800 (PST) Received: from finesse by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA25581; Thu, 12 Feb 1998 07:40:05 -0800 Message-Id: <199802121540.HAA25581@hsmpka.eng.sun.com> Date: Thu, 12 Feb 1998 07:38:36 -0800 (PST) From: Charles Perkins Reply-To: Charles Perkins Subject: (IPng 5195) Re: Mobile IPv6 query To: jvs@sasi.com Cc: ipng@sunroof.eng.sun.com, dbj@cs.cmu.edu MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ALfe0eO/KQIhk0mONzlAIA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jayesh, > Is it possible for a mobile node to send binding updates to the home > agents, with the home registration bit not set ? It is possible, of course. The question is whether it is meaningful or useful to do so. > I mean to say that is the following sequence of events possible ? > > time event > t mobile node sending BU to its home agent with H set, > lifetime = 100 sec > t+50 mobile node sending BU to its home agent with H off > t+90 mobile node refreshing its registration with home agent by > sending BU with H set This could be interpreted to mean that the mobile node is asking its home agent to interrupt proxy services during the interval [t+50,t+90). We did not spell out any such thing in the protocol specification. Is it useful to specify this behavior? If so, does the home agent have to explicitly notify nodes on the home network that it is not currently the home agent for the mobile node? Regards, 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 Fri Feb 13 08:08:32 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id IAA04866 for ipng-dist; Fri, 13 Feb 1998 08:04:40 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id IAA04859 for ; Fri, 13 Feb 1998 08:04:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA07789 for ; Fri, 13 Feb 1998 08:04:29 -0800 Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id IAA12598 for ; Fri, 13 Feb 1998 08:04:26 -0800 (PST) Received: (from richier@localhost) by horus.imag.fr (8.8.5/8.8.5) id RAA02938 for ipng@sunroof.Eng.Sun.COM; Fri, 13 Feb 1998 17:04:19 +0100 (MET) Date: Fri, 13 Feb 1998 17:04:19 +0100 (MET) From: Jean-Luc Richier Message-Id: <199802131604.RAA02938@horus.imag.fr> Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 5198) draft-ietf-ipngwg-addr-arch-v2-06.txt and draft-ietf-ipngwg-bsd-api-new-00.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think that there is an ambiguity in the definition of "IPv4-compatible IPv6 address" in both drafts : IP Version 6 Addressing Architecture and Basic Socket Interface Extensions for IPv6 and I suggest that the text should be clarified. 1/ ``IP Version 6 Addressing Architecture'' defines in paragraph 5.4 a type of address is termed an "IPv4-compatible IPv6 address" with the format: 0:0:0:0:0:0:XXXX:YYYY (XXXX and YYY are any value, if the 32 bit value XXXXYYYY is an ``IPv4 address'' : > > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|0000| IPv4 address | > +--------------------------------------+----+---------------------+ but in the two previous paragraphs two conflicting values are defined: >2.5.2 The Unspecified Address > The address 0:0:0:0:0:0:0:0 is called the unspecified address. >2.5.3 The Loopback Address > The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. This ambiguity cause problems for the reverse DNS lookups (see below). I suggest that the wording of paragraph 2.5.4 should be corrected, by explicitely suppressing some values form the domain of "IPv4-compatible IPv6 address". One can note that 0.0.0.1 is not a used IPv4 address, and that 0.0.0.0 is the unspecified IPv4 adress, for which the corresponding "IPv4-compatible IPv6 address" is of no interest. Therefore I suggest to explicitly reject :: and ::1, or, perheaps better, to specify that ::x.y.z.t is a "IPv4-compatible IPv6 address" only if x is not zero. This leave room for other special IPv6 addresses, if needed. 2/ Basic Socket Interface Extensions for IPv6 declares : >6.2. Address To Hostname Translation > One possible source of confusion is the handling of IPv4-mapped IPv6 > addresses and IPv4-compatible IPv6 addresses. This is addressed in > [7] and involves the following logic: > > 1. If af is AF_INET6, and if len equals 16, and if the IPv6 address > is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 > address, then skip over the first 12 bytes of the IPv6 address, > set af to AF_INET, and set len to 4. > > 2. If af is AF_INET, then query for a PTR record in the in- > addr.arpa domain. > > 3. If af is AF_INET6, then query for a PTR record in the ip6.int > domain. > > 4. If the function is returning success, then the single address > that is returned in the hostent structure is a copy of the first > argument to the function with with the same address family that > was passed as an argument to this function. > > All four steps listed are performed, in order. The reference [7] is : [7] P. Vixie, "Reverse Name Lookups of Encapsulated IPv4 Addresses in IPv6", Internet-Draft, , May 1996. but it has expired, and no replacing draft is available. The problem is where to declare the PTR entry for the IPv6 loopback address ::1 ? In the in-addr.arpa. tree, or in the ip6.int. tree ? Today most of the implementations based on bind4.9.x look in the in-addr.arpa. tree, which means that we must define in all our DNS the zone 0.0.0.in-addr.arpa, and the record: 1.0.0.0.in-addr.arpa. PRT localhost. This is hardly intuitive, and this has the unwanted side effect to define a name for the incorrect addresses 0.0.0.1 and ::ffff:0.0.0.1. Also in many codes which control the DNS by making a reverse and then a direct DNS lookup, we have to explicitely seperate IPv4 and IPv6 addresses in the same way as for DNS reverse lookup: address is correct in DNS == a. If address is IPv4, make a lookup for PTR in in-addr.arpa, then a lookup for A. The initial address is correct iff it is equal to one of the address returned. b. If address is IPv6, if the address is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6 address, then skip over the first 12 bytes of the IPv6 address, and do as (a) above. c. Othervise If address is IPv6, make a lookup for PTR in ip6.int. then a lookup for AAAA. The initial address is correct iff it is equal to one of the address returned. Again this fails for ::1 if one considers ::1 as an IPv4-compatible IPv6: ::1 => 0.0.0.1 -> PTR == localhost -> A = 127.0.0.1 DIFFERENT Therefore it should be better to correct the case 1 above, by explicitly giving the applicable rule for ::1, or by making an explicit reference to an (amended) IP Version 6 Addressing Architecture draft. The problem is the same for ::, but this address is seldom in the DNS. As it is clear, considering the new AAAA drafts, that the DNS code will have to be modified soon, a timely clarification should be welcome. Best regards -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 72, F-38402 St Martin d'Heres Cedex Tel : (33) 4 76 82 72 32 Fax : (33) 4 76 82 72 87 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 18 04:55:33 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id EAA09835 for ipng-dist; Wed, 18 Feb 1998 04:50:46 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id EAA09820 for ; Wed, 18 Feb 1998 04:50:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA20529 for ; Wed, 18 Feb 1998 04:50:24 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id EAA06542 for ; Wed, 18 Feb 1998 04:50:25 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id HAA26505; Wed, 18 Feb 1998 07:50:06 -0500 (EST) Message-Id: <199802181250.HAA26505@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5200) I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt Date: Wed, 18 Feb 1998 07:50:05 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Stateless Address Autoconfiguration Author(s) : S. Thomson, T. Narten Filename : draft-ietf-ipngwg-addrconf-v2-02.txt Pages : 25 Date : 17-Feb-98 This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes creating a link-local address and verifying its uniqueness on a link, determining what information should be autoconfigured (addresses, other information, or both), and in the case of addresses, whether they should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for generating a link-local address, the process for generating site-local and global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure. The details of autoconfiguration using the stateful protocol are specified elsewhere. 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-addrconf-v2-02.txt". A URL for the Internet-Draft is: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-v2-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: 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-addrconf-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. --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: <19980217174408.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addrconf-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addrconf-v2-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980217174408.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 Feb 18 07:01:28 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA10005 for ipng-dist; Wed, 18 Feb 1998 06:51:08 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA09998 for ; Wed, 18 Feb 1998 06:50:56 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA07022 for ; Wed, 18 Feb 1998 06:50:53 -0800 Received: from ns.ietf.org ([132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA26205 for ; Wed, 18 Feb 1998 06:50:54 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA00731; Wed, 18 Feb 1998 09:50:48 -0500 (EST) Message-Id: <199802181450.JAA00731@ns.ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 5201) Document Action: Advanced Sockets API for IPv6 to Informational Date: Wed, 18 Feb 1998 09:50:48 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Advanced Sockets API for IPv6' as a Informational. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 18 09:36:31 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id JAA10268 for ipng-dist; Wed, 18 Feb 1998 09:30:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id JAA10261 for ; Wed, 18 Feb 1998 09:30:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA24164 for ; Wed, 18 Feb 1998 09:30:43 -0800 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id JAA29646 for ; Wed, 18 Feb 1998 09:30:40 -0800 (PST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id MAA39188 for ; Wed, 18 Feb 1998 12:30:38 -0500 (EST) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA06518 for ; Wed, 18 Feb 1998 12:30:38 -0500 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id MAA19704 for ; Wed, 18 Feb 1998 12:30:38 -0500 (EST) Message-Id: <199802181730.MAA19704@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: (IPng 5202) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt In-reply-to: Your message of "Wed, 18 Feb 1998 07:50:05 EST." <199802181250.HAA26505@ns.ietf.org> Date: Wed, 18 Feb 1998 12:30:37 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, The updated draft includes the changes agreed to in DC. It also addresses all the comments I've received. If I've missed anything, please let me know. Unless there are additional comments, I think this document is ready to ship. 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 Feb 18 18:21:13 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id SAA11072 for ipng-dist; Wed, 18 Feb 1998 18:14:54 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id SAA11065 for ; Wed, 18 Feb 1998 18:14:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA23621 for ; Wed, 18 Feb 1998 18:14:41 -0800 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id SAA20428 for ; Wed, 18 Feb 1998 18:14:42 -0800 (PST) Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/970507) via ESMTP id SAA25662 for <@sgi.engr.sgi.com:ipng@sunroof.Eng.Sun.COM>; Wed, 18 Feb 1998 18:14:41 -0800 env-from (ms@newt.engr.sgi.com) Received: from newt.engr.sgi.com (newt.engr.sgi.com [150.166.75.47]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA00661 for <@cthulhu.engr.sgi.com:ipng@sunroof.Eng.Sun.COM>; Wed, 18 Feb 1998 18:14:40 -0800 Received: (from ms@localhost) by newt.engr.sgi.com (971110.SGI.8.8.8/970903.SGI.AUTOCF) id SAA05384 for ipng@sunroof.Eng.Sun.COM; Wed, 18 Feb 1998 18:14:40 -0800 (PST) Date: Wed, 18 Feb 1998 18:14:40 -0800 (PST) From: ms@newt.engr.sgi.com (Mark Smith..) Message-Id: <199802190214.SAA05384@newt.engr.sgi.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 5203) Re: Document Action: Advanced Sockets API for IPv6 to Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Last October a couple of issues were brought up about the Advanced API that received little comment on the mailing list. One of them was the API for the routing header. Since the current draft describing the routing header has changed the TYPE_0 routing header from what is described in the Advanced API, I thought I would take this opportunity to remail my comments. I feel that the API is too closely tied to the TYPE_0 routing header. I have included my original mail below. In light of the recent draft, the struct rt_type_0 would need to be changed to be as follows: struct rt_type_0 { int rt0_reserved; in6_addr rt0_addrs[1]; /* Could be longer */ } Even if we do not change the API, the examples will need to be changed to reflect the latest draft. > The description of inet6_rthdr_segments seems overly restrictive to me. > It states: > "On success the return value is between 1 and 23, inclusive." > > This is true for a Type 0 Routing header but may not be for others. > I would prefer the statement read as follows: > > For an IPv6 Type 0 Routing header, on success the return value is > between 1 and 23, inclusive. > > > This brings me to a related topic. It appears to me that the interface > is tied rather closely to the current implementation of Type 0 Routing > headers. For example Type 0 has a reserved byte which can not be accessed > with this interface. There is no need now but it might be useful > to conveniently get at it in the future. Also, the interface assumes > pairs of (int, in6_addr) where the case of Type 0 the 'int' is a single > bit. I have no idea what someone might do in the future with the > Routing header. Maybe Type 1 will have 64 bits associated with each address. > > Would it be better to follow the style used with the hop-by-hop and > destination headers? Basically we supply a structure, that the user > fills in, and an init function which initializes the 'system' part > (ie. the part that is the same for all options). > > The API would the consist of 3 things: > struct rt_type_0 { > int rt0_reserved:8; > rt0_slflags:24; > in6_addr rt0_addrs[1]; /* Could be longer */ > } > > inet6_rthdr_space() > in6_rthdr_init(); > > The user fills in the struct rt_type_0 just like they have to fill in the > options that get passed to inet6_option_append(). That way the API handles > the parts that are always the same (cmsg and the 4 byte routing header). > The user handles the type-specific data. > > Basically, what I am suggesting is that the API should not initialize the > type specific portions of the option. Leave that to the user. We do that now > with hop-by-hop and destination options. Lets also do that with Routing > options. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 19 03:36:12 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id DAA11478 for ipng-dist; Thu, 19 Feb 1998 03:18:06 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id DAA11471 for ; Thu, 19 Feb 1998 03:17:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA18492 for ; Thu, 19 Feb 1998 03:17:54 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id DAA23173 for ; Thu, 19 Feb 1998 03:05:07 -0800 (PST) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id LAA13003; Thu, 19 Feb 1998 11:01:11 GMT Message-Id: <199802191101.LAA13003@gate.ticl.co.uk> X-Sender: peter@gate (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Thu, 19 Feb 1998 11:07:04 +0000 To: Thomas Narten From: Peter Curran Subject: (IPng 5205) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199802181730.MAA19704@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 Thomas Sorry to raise an old chestnut once again, but... I have re-read your draft and the appropriate sections of [ADDR-ARCH]. I can find no circumstance in the latter where the interface ID will be, or could be, less than 64 bits. I therefore question the need for the addr-conf-v2 to suggest that the interface ID length is a variable, when it clearly is not. I did raise this question before Christmas and from your reply I inferred that you may be reading the ADDR-ARCH stuff in an ambiguous way. I did actually make this comment, but received no reply and it dropped down my priority list. Could you clarify the position in this area? Thanks Peter Curran At 12:30 18/02/98 -0500, Thomas Narten wrote: >Folks, > >The updated draft includes the changes agreed to in DC. > >It also addresses all the comments I've received. If I've missed >anything, please let me know. > >Unless there are additional comments, I think this document is ready >to ship. > >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 Thu Feb 19 05:18:07 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id EAA11649 for ipng-dist; Thu, 19 Feb 1998 04:52:23 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id EAA11642 for ; Thu, 19 Feb 1998 04:51:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA24076 for ; Thu, 19 Feb 1998 04:50:44 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id EAA17953 for ; Thu, 19 Feb 1998 04:38:11 -0800 (PST) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA14440; Thu, 19 Feb 1998 12:37:46 GMT Received: from hursley.ibm.com (carpenterb.hursley.ibm.com [9.20.22.153]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) with ESMTP id MAA125348 for ; Thu, 19 Feb 1998 12:37:46 GMT Message-Id: <34EC2818.4D55A8BD@hursley.ibm.com> Date: Thu, 19 Feb 1998 12:39:52 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 5206) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt References: <199802191101.LAA13003@gate.ticl.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [ADDR-ARCH] actually says: > In a number of the format prefixes (see section 2.4) Interface IDs > are required to be 64 bits long and to be constructed in IEEE EUI-64 > format [EUI64]. It emphatically does not say "In all format prefixes..." We must keep this bit of flexibility for the future, in case some future format prefix needs some other kind of Interface ID. Brian Carpenter Peter Curran wrote: > > Thomas > > Sorry to raise an old chestnut once again, but... > > I have re-read your draft and the appropriate sections of [ADDR-ARCH]. I > can find no circumstance in the latter where the interface ID will be, or > could be, less than 64 bits. I therefore question the need for the > addr-conf-v2 to suggest that the interface ID length is a variable, when it > clearly is not. ... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 19 07:20:48 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA11844 for ipng-dist; Thu, 19 Feb 1998 06:55:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA11837 for ; Thu, 19 Feb 1998 06:55:31 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA04153 for ; Thu, 19 Feb 1998 06:55:28 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA03179 for ; Thu, 19 Feb 1998 06:44:32 -0800 (PST) Received: from wasted.zk3.dec.com (abelia.zk3.dec.com [16.140.64.63]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id JAA00136; Thu, 19 Feb 1998 09:44:16 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA01366; Thu, 19 Feb 1998 09:44:05 -0500 Message-Id: <199802191444.AA01366@wasted.zk3.dec.com> To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5207) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt In-Reply-To: Your message of "Thu, 19 Feb 1998 12:39:52 GMT." <34EC2818.4D55A8BD@hursley.ibm.com> Date: Thu, 19 Feb 1998 09:44:05 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, But Peter is right for when we use EUI 64. All our code and sys mgmt is going to be much more efficient for FP=001 and Unicast Aggr address if we assume no prefix is greater than 64bits. I really think Peter has a good point. I think its worth us putting checks in implementations for FP=XXX and if XXX means on 64bit prefix we can get really good fastpath mechanisms built for that case that are highly optimized. If the future changes and XXX means variable then that can be handled too. Variable always is bad in the context of computer science and should always be avoided if possible IMO. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 19 08:53:13 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id IAA12079 for ipng-dist; Thu, 19 Feb 1998 08:36:52 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id IAA12072 for ; Thu, 19 Feb 1998 08:36:42 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA26070 for ; Thu, 19 Feb 1998 08:36:40 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id IAA28576 for ; Thu, 19 Feb 1998 08:36:06 -0800 (PST) Received: from wasted.zk3.dec.com (abelia.zk3.dec.com [16.140.64.63]) by mail11.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id LAA22653; Thu, 19 Feb 1998 11:33:37 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA08592; Thu, 19 Feb 1998 11:33:11 -0500 Message-Id: <199802191633.AA08592@wasted.zk3.dec.com> To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5208) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt In-Reply-To: Your message of "Thu, 19 Feb 1998 16:22:20 GMT." <34EC5C3C.4F751ACE@hursley.ibm.com> Date: Thu, 19 Feb 1998 11:33:11 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >Of course I agree with optimising for the common case; >what I don't want is to close off unknown options ten years >into the future. 100% agree with you and sorry if I made it seem I would not. As an example. At the point the packet enters my comm adapter and is processed upto the Internet Layer I would not look at the prefix vs the EUI or some other link-only ID for the future. Neither would I base access to any statistical data structures or MIBs on an fixed anything but use the IPv6 address. Nor would I do anything to assume "routability" as a host (as I hope all figured this out with IPv6 and addressing in general). Nor would any assumption be put in any APIs. Where it could be differentiated now and support the future is where we do lookups for src or dst addresses, NUD, onlink vs offlink decisions, and multihoming. Strictlty as optimizations. Also I think some sys mgmt optimizations could be made for users but that I can't state emphatically without more thought and not a code base I keep track of either, so that is purely a "guess" on my part. I am not clear we need to change any specs though? But I do see Peter's point about the word "variable" in addr conf. So I am more concerned about the syntax we use as opposed to the actual semantics for addr conf. I think implementors will build all kinds of added value for IPv6 completely missed by the standardizations process especially for host "server" computing. /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 Feb 19 10:20:21 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA12384 for ipng-dist; Thu, 19 Feb 1998 10:12:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA12377 for ; Thu, 19 Feb 1998 10:11:59 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA19411 for ; Thu, 19 Feb 1998 10:11:49 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id IAA20407 for ; Thu, 19 Feb 1998 08:20:38 -0800 (PST) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA24345; Thu, 19 Feb 1998 16:20:13 GMT Received: from hursley.ibm.com (carpenterb.hursley.ibm.com [9.20.22.153]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) with ESMTP id QAA100876; Thu, 19 Feb 1998 16:20:13 GMT Message-Id: <34EC5C3C.4F751ACE@hursley.ibm.com> Date: Thu, 19 Feb 1998 16:22:20 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5209) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt References: <199802191444.AA01366@wasted.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Of course I agree with optimising for the common case; what I don't want is to close off unknown options ten years into the future. BTW > Variable always is bad in the context of computer science and should > always be avoided if possible IMO. I was taught that all numbers in Computer Science are 0, 1 or infinity. Brian bound@zk3.dec.com wrote: > > Brian, > > But Peter is right for when we use EUI 64. > > All our code and sys mgmt is going to be much more efficient for > FP=001 and Unicast Aggr address if we assume no prefix is greater than > 64bits. I really think Peter has a good point. > > I think its worth us putting checks in implementations for FP=XXX and if > XXX means on 64bit prefix we can get really good fastpath mechanisms > built for that case that are highly optimized. If the future changes > and XXX means variable then that can be handled too. > > Variable always is bad in the context of computer science and should > always be avoided if possible IMO. > > /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 19 11:15:47 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA12585 for ipng-dist; Thu, 19 Feb 1998 11:10:49 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id LAA12560 for ; Thu, 19 Feb 1998 11:10:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA10069 for ; Thu, 19 Feb 1998 11:10:30 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id GAA07120 for ; Thu, 19 Feb 1998 06:54:03 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id IAA14556; Thu, 19 Feb 1998 08:53:57 -0600 Message-Id: <199802191453.IAA14556@gungnir.fnal.gov> To: Peter Curran Cc: Thomas Narten , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5210) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt In-reply-to: Your message of Thu, 19 Feb 1998 11:07:04 GMT. <199802191101.LAA13003@gate.ticl.co.uk> Date: Thu, 19 Feb 1998 08:53:57 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have re-read your draft and the appropriate sections of [ADDR-ARCH]. I > can find no circumstance in the latter where the interface ID will be, or > could be, less than 64 bits. I therefore question the need for the > addr-conf-v2 to suggest that the interface ID length is a variable, when it > clearly is not. Remember that the format of addresses beginning with the three bits 010 through 110 have not been defined, and likewise for some of those beginning with 000 and 111. ___________________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 19 13:40:45 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id NAA12986 for ipng-dist; Thu, 19 Feb 1998 13:31:15 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id NAA12979 for ; Thu, 19 Feb 1998 13:31:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA18834 for ; Thu, 19 Feb 1998 13:31:04 -0800 Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA09270 for ; Thu, 19 Feb 1998 13:31:03 -0800 (PST) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns1.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id QAA37700; Thu, 19 Feb 1998 16:30:52 -0500 (EST) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id QAA28048; Thu, 19 Feb 1998 16:30:54 -0500 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id QAA04218; Thu, 19 Feb 1998 16:30:53 -0500 (EST) Message-Id: <199802192130.QAA04218@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Peter Curran cc: ipng@sunroof.eng.sun.com Subject: (IPng 5211) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt In-reply-to: Your message of "Thu, 19 Feb 1998 11:07:04 GMT." <199802191101.LAA13003@gate.ticl.co.uk> Date: Thu, 19 Feb 1998 16:30:53 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter, > I have re-read your draft and the appropriate sections of [ADDR-ARCH]. I > can find no circumstance in the latter where the interface ID will be, or > could be, less than 64 bits. I therefore question the need for the > addr-conf-v2 to suggest that the interface ID length is a variable, when it > clearly is not. I did add some words to the addrconf document suggesting the EUI-64 identifier would be the common case. But you are right, I still left things flexible by explicitly allowing other identifier sizes. And the more I think about it, the less I am able to argue for not changing the text as you suggest. One could make the argument that the current text is more flexible for the future. In practice, I find that difficult to argue. The reality now is that the size of the interface identifier is defined by the IP-over-foo documents, and they all specify EUI-64s. Thus, for it to be possible for a router to actually advertise a prefix of length other than 64 bits, you'd have to rewrite the v6-over-foo spec and change existing host implementations (since they'd have to generate their interface identifers in a different way). This is a very high bar and we're probably past the point of being able to do that. Plus transition issues would not be pretty. The argument that only some format prefixes specify the use of EUI-64s is probably irrelevent. At present, the addrconf spec specifies a single way to form addresses and doesn't even care what the prefix format bits are. If we we were to imagine having some format prefixes use one interface identifier type, while other format prefixes use a different one, addrconf can't handle that case today. The spec would need to be changed and code would need to be changed in hosts (the real killer). Again, a very high bar. That is, the bar is already high enough for such a change that the impact on implementations that had assumed only 64-bit identifiers would ever be used is probably not significant. So, although I'd argue that the current text isn't incorrect, if it's confusing, it should be changed, in the absence of compelling benefit in leaving it as is. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 19 15:29:49 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id PAA13096 for ipng-dist; Thu, 19 Feb 1998 15:22:17 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id PAA13089 for ; Thu, 19 Feb 1998 15:22:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA18242 for ; Thu, 19 Feb 1998 15:22:04 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA05358 for ; Thu, 19 Feb 1998 15:22:04 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id SAA27394; Thu, 19 Feb 1998 18:22:02 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id SAA21141; Thu, 19 Feb 1998 18:22:02 -0500 (EST) Date: Thu, 19 Feb 1998 18:22:02 -0500 (EST) From: Christian Huitema Message-Id: <980219182201.ZM21139@seawind.bellcore.com> In-Reply-To: Thomas Narten "(IPng 5211) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt" (Feb 19, 4:30pm) References: <199802192130.QAA04218@cichlid.raleigh.ibm.com> X-Mailer: Z-Mail (5.0.0 30July97) To: Thomas Narten , Peter Curran Subject: (IPng 5212) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.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 Don't forget that there is a rationale behind the EUI 64 choice. If the address contains a unique identifier, then that identifier can be used to identify connections, and maybe to assure that they survive a change of prefix. Come to think of it -- is anyone working on how this feature could be used in conjunction with IPSEC ? For example, check that the security association is identified by the EUI 64 pair and the security context identifier ? -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 19 15:58:08 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id PAA13161 for ipng-dist; Thu, 19 Feb 1998 15:49:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id PAA13154 for ; Thu, 19 Feb 1998 15:48:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA25048 for ; Thu, 19 Feb 1998 15:48:46 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA17931 for ; Thu, 19 Feb 1998 15:48:47 -0800 (PST) From: Masataka Ohta Message-Id: <199802192341.IAA10923@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id IAA10923; Fri, 20 Feb 1998 08:40:54 +0859 Subject: (IPng 5213) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt To: huitema@bellcore.com (Christian Huitema) Date: Fri, 20 Feb 98 8:40:53 JST Cc: narten@raleigh.ibm.com, pcurran@ticl.co.uk, ipng@sunroof.eng.sun.com In-Reply-To: <980219182201.ZM21139@seawind.bellcore.com>; from "Christian Huitema" at Feb 19, 98 6:22 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian > Don't forget that there is a rationale behind the EUI 64 choice. If the > address contains a unique identifier, then that identifier can be used to > identify connections, and maybe to assure that they survive a change of > prefix. Sure. > Come to think of it -- is anyone working on how this feature could be used > in conjunction with IPSEC ? For example, check that the security > association is identified by the EUI 64 pair and the security context > identifier ? It can be identified. However, to make the identification scale, we need local part (w.r.t. IEEE point of view) of EUI 64 has a global (w.r.t. Internet point of view) tree structure like in-addr.arpa. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 19 16:21:07 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id QAA13295 for ipng-dist; Thu, 19 Feb 1998 16:12:24 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id QAA13288 for ; Thu, 19 Feb 1998 16:12:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA00980 for ; Thu, 19 Feb 1998 16:12:08 -0800 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id QAA28447 for ; Thu, 19 Feb 1998 16:12:08 -0800 (PST) Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id SAA16223; Thu, 19 Feb 1998 18:11:57 -0600 Message-Id: <199802200011.SAA16223@gungnir.fnal.gov> To: Masataka Ohta Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 5214) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt In-reply-to: Your message of Fri, 20 Feb 1998 08:40:53 +0200. <199802192341.IAA10923@necom830.hpcl.titech.ac.jp> Date: Thu, 19 Feb 1998 18:11:57 -0600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Come to think of it -- is anyone working on how this feature could be used > > in conjunction with IPSEC ? For example, check that the security > > association is identified by the EUI 64 pair and the security context > > identifier ? > > It can be identified. However, to make the identification scale, > we need local part (w.r.t. IEEE point of view) of EUI 64 has > a global (w.r.t. Internet point of view) tree structure like in-addr.arpa. I do not think security associations have such a scaling requirement. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 19 16:38:00 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id QAA13329 for ipng-dist; Thu, 19 Feb 1998 16:30:41 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id QAA13322 for ; Thu, 19 Feb 1998 16:30:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id QAA05251 for ; Thu, 19 Feb 1998 16:30:05 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id QAA06384 for ; Thu, 19 Feb 1998 16:30:06 -0800 (PST) From: Masataka Ohta Message-Id: <199802200022.JAA11235@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA11235; Fri, 20 Feb 1998 09:22:34 +0900 Subject: (IPng 5215) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt To: crawdad@fnal.gov (Matt Crawford) Date: Fri, 20 Feb 98 9:22:32 JST Cc: mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <199802200011.SAA16223@gungnir.fnal.gov>; from "Matt Crawford" at Feb 19, 98 6:11 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt; > > > > Come to think of it -- is anyone working on how this feature could be used > > > in conjunction with IPSEC ? For example, check that the security > > > association is identified by the EUI 64 pair and the security context > > > identifier ? > > > > It can be identified. However, to make the identification scale, > > we need local part (w.r.t. IEEE point of view) of EUI 64 has > > a global (w.r.t. Internet point of view) tree structure like in-addr.arpa. > > I do not think security associations have such a scaling > requirement. Electric commerce to general public, for example, needs scalabile identification. You may locate the hierarchical structure somewhere else, of course, with new identification fields role of which is somewhat duplicated with that of IP addresses. IP header format issue is just a design beauty and efficiency issue that there always are less ellegant alternatives. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 20 03:44:01 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id DAA13939 for ipng-dist; Fri, 20 Feb 1998 03:40:25 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id DAA13932 for ; Fri, 20 Feb 1998 03:40:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id DAA22631 for ; Fri, 20 Feb 1998 03:40:14 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id DAA24239 for ; Fri, 20 Feb 1998 03:40:13 -0800 (PST) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA26812; Fri, 20 Feb 1998 11:40:10 GMT Received: from hursley.ibm.com (carpenterb.hursley.ibm.com [9.20.22.153]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA94844 for ; Fri, 20 Feb 1998 11:40:10 GMT Message-Id: <34ED6C14.3E66A470@hursley.ibm.com> Date: Fri, 20 Feb 1998 11:42:12 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 5216) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt References: <199802192130.QAA04218@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If anybody cares, making this change would break RFC 1888. Brian Thomas Narten wrote: > > Peter, > > > I have re-read your draft and the appropriate sections of [ADDR-ARCH]. I > > can find no circumstance in the latter where the interface ID will be, or > > could be, less than 64 bits. I therefore question the need for the > > addr-conf-v2 to suggest that the interface ID length is a variable, when it > > clearly is not. > > I did add some words to the addrconf document suggesting the EUI-64 > identifier would be the common case. But you are right, I still left > things flexible by explicitly allowing other identifier sizes. And the > more I think about it, the less I am able to argue for not changing > the text as you suggest. > > One could make the argument that the current text is more flexible for > the future. In practice, I find that difficult to argue. The reality > now is that the size of the interface identifier is defined by the > IP-over-foo documents, and they all specify EUI-64s. Thus, for it to > be possible for a router to actually advertise a prefix of length > other than 64 bits, you'd have to rewrite the v6-over-foo spec and > change existing host implementations (since they'd have to generate > their interface identifers in a different way). This is a very high > bar and we're probably past the point of being able to do that. Plus > transition issues would not be pretty. > > The argument that only some format prefixes specify the use of EUI-64s > is probably irrelevent. At present, the addrconf spec specifies a > single way to form addresses and doesn't even care what the prefix > format bits are. If we we were to imagine having some format prefixes > use one interface identifier type, while other format prefixes use a > different one, addrconf can't handle that case today. The spec would > need to be changed and code would need to be changed in hosts (the > real killer). Again, a very high bar. That is, the bar is already high > enough for such a change that the impact on implementations that had > assumed only 64-bit identifiers would ever be used is probably not > significant. > > So, although I'd argue that the current text isn't incorrect, if it's > confusing, it should be changed, in the absence of compelling benefit > in leaving it as is. > > 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 Fri Feb 20 11:53:56 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA14915 for ipng-dist; Fri, 20 Feb 1998 11:47:13 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id LAA14908 for ; Fri, 20 Feb 1998 11:47:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA27767 for ; Fri, 20 Feb 1998 11:46:58 -0800 Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id LAA00601 for ; Fri, 20 Feb 1998 11:46:58 -0800 (PST) Received: from research.att.com ([135.207.30.100]) by rumor; Fri Feb 20 14:42:10 EST 1998 Received: from postal.research.att.com ([135.207.23.30]) by research-clone; Fri Feb 20 14:43:24 EST 1998 Received: from smb.research.att.com (postal.research.att.com [135.207.23.30]) by postal.research.att.com (8.8.7/8.8.7) with SMTP id OAA06201; Fri, 20 Feb 1998 14:43:09 -0500 (EST) Message-Id: <3.0.3.32.19980220191415.0091c740@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 20 Feb 1998 19:14:15 +0000 To: "Matt Crawford" From: "Steven M. Bellovin" Subject: (IPng 5218) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt Cc: Masataka Ohta , ipng@sunroof.eng.sun.com In-Reply-To: <199802200011.SAA16223@gungnir.fnal.gov> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 06:11 PM 2/19/98 -0600, Matt Crawford wrote: >> > Come to think of it -- is anyone working on how this feature could be used >> > in conjunction with IPSEC ? For example, check that the security >> > association is identified by the EUI 64 pair and the security context >> > identifier ? >> >> It can be identified. However, to make the identification scale, >> we need local part (w.r.t. IEEE point of view) of EUI 64 has >> a global (w.r.t. Internet point of view) tree structure like in-addr.arpa. > >I do not think security associations have such a scaling >requirement. I haven't read the draft lately, but I believe you're right -- with IPSEC, the real -- and scalable and hierarchical -- identity of the machine is in the certificate. Anything else is good for TCP circuit identification, for example, and need not be mapped into 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 Fri Feb 20 12:53:50 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id MAA14949 for ipng-dist; Fri, 20 Feb 1998 12:47:31 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id MAA14942 for ; Fri, 20 Feb 1998 12:47:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA11206 for ; Fri, 20 Feb 1998 12:47:17 -0800 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id MAA00346 for ; Fri, 20 Feb 1998 12:47:19 -0800 (PST) Received: from desktop (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id UAA15497; Fri, 20 Feb 1998 20:43:31 GMT Message-Id: <199802202043.UAA15497@gate.ticl.co.uk> X-Sender: peter@gate (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Fri, 20 Feb 1998 20:49:15 +0000 To: Brian E Carpenter From: Peter Curran Subject: (IPng 5219) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <34ED6C14.3E66A470@hursley.ibm.com> References: <199802192130.QAA04218@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:42 AM 2/20/98 +0000, Brian E Carpenter wrote: >If anybody cares, making this change would break RFC 1888. > > Brian > Actually, I think RFC1888 needs revisiting in light of EUI-64. My reading of the document (and of course Brian is one of the authors, so I bow to his greater wisdom) is that there is an implicit assumption that as most NSAP addressing schemes use a 6-byte identifier (normally the MAC address) then this would map well onto the then current IPv6 addressing scheme. This is no longer true - does that mean that RFC1888 needs changing? In terms of defining a CLNP address space that can be mapped onto IPv6 for transition purposes I think there is a problem with mapping Area-No + ID (64-bits) onto an IPv6 interface ID (unless the G/L bit can be set to Local). Peter TICL PS. I don't want to open **another** can of worms here :-) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 20 15:29:24 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id PAA15333 for ipng-dist; Fri, 20 Feb 1998 15:25:35 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id PAA15326 for ; Fri, 20 Feb 1998 15:25:24 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA19831 for ; Fri, 20 Feb 1998 15:25:21 -0800 Received: from thumper.bellcore.com (thumper.bellcore.com [128.96.41.1]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id PAA17857 for ; Fri, 20 Feb 1998 15:25:22 -0800 (PST) Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by thumper.bellcore.com (8.8.8/8.8.8) with ESMTP id SAA10849; Fri, 20 Feb 1998 18:25:20 -0500 (EST) Received: (from huitema@localhost) by seawind.bellcore.com (8.8.8/8.8.8) id SAA21770; Fri, 20 Feb 1998 18:25:19 -0500 (EST) Date: Fri, 20 Feb 1998 18:25:19 -0500 (EST) From: Christian Huitema Message-Id: <980220182519.ZM21768@seawind.bellcore.com> In-Reply-To: "Steven M. Bellovin" "(IPng 5218) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt" (Feb 20, 7:14pm) References: <3.0.3.32.19980220191415.0091c740@127.0.0.1> X-Mailer: Z-Mail (5.0.0 30July97) To: "Steven M. Bellovin" Subject: (IPng 5220) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.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 On Feb 20, 7:14pm, Steven M. Bellovin wrote: > I haven't read the draft lately, but I believe you're right -- with IPSEC, > the real -- and scalable and hierarchical -- identity of the machine is > in the certificate. Anything else is good for TCP circuit identification, > for example, and need not be mapped into the DNS. Steve, The question relates to the possibility to change the "address" during the life of the security association. Suppose that you had negotiated an association between A, whose address was initially the tuple (PA1, UA) (first prefix of A, 64 bit ID), and B, whose address was initially the tuple (PB1, UB). A, for some reason, needs to use the new prefix PA2, so B receives now packets from (PA2, UA), with payload type "IPSEC" and the same security assciation identifier as previously negotiated. If we do that: 1) will the packet be somehow accepted, or summarily rejected ? 2) could the next packets on the IPSEC association be send to the new address? -- Christian Huitema ---------- See you at INET'98, Geneva 21-24,July 98 http://www.isoc.org/inet98/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 20 15:47:40 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id PAA15366 for ipng-dist; Fri, 20 Feb 1998 15:43:16 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id PAA15359 for ; Fri, 20 Feb 1998 15:43:10 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id PAA11679 for ; Fri, 20 Feb 1998 15:43:09 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA15755; Fri, 20 Feb 1998 15:42:11 -0800 Received: from kebe.eng.sun.com (kebe [129.146.86.51]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id PAA15347 for ; Fri, 20 Feb 1998 15:41:08 -0800 (PST) Received: (from danmcd@localhost) by kebe.eng.sun.com (8.8.8+Sun/8.8.8) id PAA05275; Fri, 20 Feb 1998 15:40:29 -0800 (PST) From: Dan McDonald Message-Id: <199802202340.PAA05275@kebe.eng.sun.com> Subject: (IPng 5222) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt To: huitema@bellcore.com (Christian Huitema) Date: Fri, 20 Feb 1998 15:40:28 -0800 (PST) Cc: smb@research.att.com, ipng@sunroof.eng.sun.com In-Reply-To: <980220182519.ZM21768@seawind.bellcore.com> from "Christian Huitema" at Feb 20, 98 06:25:19 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 Christian (& Steve), > > I haven't read the draft lately, but I believe you're right -- with > IPSEC, > > the real -- and scalable and hierarchical -- identity of the machine is > > in the certificate. Anything else is good for TCP circuit > identification, > > for example, and need not be mapped into the DNS. > > The question relates to the possibility to change the "address" during the > life of the security association. Suppose that you had negotiated an > association between A, whose address was initially the tuple (PA1, UA) > (first prefix of A, 64 bit ID), and B, whose address was initially the > tuple (PB1, UB). A, for some reason, needs to use the new prefix PA2, so > B receives now packets from (PA2, UA), with payload type "IPSEC" and the > same security assciation identifier as previously negotiated. > > If we do that: > > 1) will the packet be somehow accepted, or summarily rejected ? > > 2) could the next packets on the IPSEC association be send to the new > address? To solve this, remember what IPsec requires for SPI identification: To Christian's point, if the address changes, it technically wouldn't be the same SA. BUT (and stay with me on this one), if I understand the addressing proposal on the table, the SA identification component "dest. address" can be reduced to "dest. 64-bit unique ID" without any loss of security. If we go with these sorts of IPv6 addresses, the IPsec over IPv6 implementors MUST be made aware that the only part of "dest. address" that matters is the unique (UA or UB) part. That's the simplest approach which doesn't break IPsec. Now there are some that feel that "dest. address" isn't at all necessary, but that's (IMHO) a hairier problem. Just my $0.02 worth. -- Daniel L. McDonald - Solaris Internet Engineering || MY OPINIONS ARE NOT Mail: danmcd@eng.sun.com, danmcd@kebe.com <*> || NOT NECESSARILY SUN'S! Phone: (650) 786-6815 |"rising falling at force ten WWW: http://www.kebe.com/~danmcd | we twist the world and ride the wind" - Rush -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 21 18:14:53 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id SAA16415 for ipng-dist; Sat, 21 Feb 1998 18:11:18 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id SAA16408 for ; Sat, 21 Feb 1998 18:11:05 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA01479 for ; Sat, 21 Feb 1998 18:10:57 -0800 Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id SAA04070 for ; Sat, 21 Feb 1998 18:10:59 -0800 (PST) Received: from research.att.com ([135.207.30.100]) by rumor; Sat Feb 21 21:06:10 EST 1998 Received: from postal.research.att.com ([135.207.23.30]) by research-clone; Sat Feb 21 21:07:23 EST 1998 Received: from smb.research.att.com (raptor.research.att.com [135.207.23.32]) by postal.research.att.com (8.8.7/8.8.7) with SMTP id VAA06046; Sat, 21 Feb 1998 21:07:18 -0500 (EST) Message-Id: <3.0.3.32.19980222014310.0090f380@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 22 Feb 1998 01:43:10 +0000 To: Dan McDonald From: "Steven M. Bellovin" Subject: (IPng 5223) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt Cc: huitema@bellcore.com (Christian Huitema), ipng@sunroof.eng.sun.com In-Reply-To: <199802202340.PAA05275@kebe.eng.sun.com> References: <980220182519.ZM21768@seawind.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 03:40 PM 2/20/98 -0800, Dan McDonald wrote: >BUT (and stay with me on this one), if I understand the addressing proposal >on the table, the SA identification component "dest. address" can be reduced >to "dest. 64-bit unique ID" without any loss of security. > >If we go with these sorts of IPv6 addresses, the IPsec over IPv6 implementors >MUST be made aware that the only part of "dest. address" that matters is the >unique (UA or UB) part. That's the simplest approach which doesn't break >IPsec. > >Now there are some that feel that "dest. address" isn't at all necessary, but >that's (IMHO) a hairier problem. > Yup, I'm one of them -- with IPsec, addresses are irrelevant. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 22 11:23:31 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA16713 for ipng-dist; Sun, 22 Feb 1998 11:19:19 -0800 (PST) Received: from kebe.eng.sun.com (kebe [129.146.86.51]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id LAA16706 for ; Sun, 22 Feb 1998 11:19:11 -0800 (PST) Received: (from danmcd@localhost) by kebe.eng.sun.com (8.8.8+Sun/8.8.8) id LAA21513 for ipng@sunroof; Sun, 22 Feb 1998 11:18:32 -0800 (PST) From: Dan McDonald Message-Id: <199802221918.LAA21513@kebe.eng.sun.com> Subject: (IPng 5224) IPsec docs are in last call! To: ipng@sunroof.eng.sun.com Date: Sun, 22 Feb 1998 11:18:31 -0800 (PST) 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 Sorry for the delay on letting you folks know this, but the following I-Ds... Last Modified Draft Name Jul 25 1997 draft-ietf-ipsec-oakley-02.txt Jul 28 1997 draft-ietf-ipsec-isakmp-08.txt Feb 13 1998 draft-ietf-ipsec-isakmp-oakley-06.txt Feb 16 1998 draft-ietf-ipsec-ipsec-doi-07.txt Feb 13 1998 draft-ietf-ipsec-auth-header-04.txt Feb 13 1998 draft-ietf-ipsec-esp-v2-03.txt Feb 18 1998 draft-ietf-ipsec-auth-hmac-md5-96-03.txt Feb 18 1998 draft-ietf-ipsec-auth-hmac-sha196-03.txt Feb 14 1998 draft-ietf-ipsec-ciph-des-expiv-02.txt are in _WORKING GROUP_ last call until the 25th. After that, they will go to IETF last call. I _believe_ that there are no IPv6-related oversights, but if I'm wrong, this is where anyone in IPng-land can help. 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 Sun Feb 22 13:53:34 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id NAA16797 for ipng-dist; Sun, 22 Feb 1998 13:49:42 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id NAA16790 for ; Sun, 22 Feb 1998 13:49:33 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA09922 for ; Sun, 22 Feb 1998 13:49:31 -0800 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id NAA24383 for ; Sun, 22 Feb 1998 13:49:31 -0800 (PST) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id QAA39658 for ; Sun, 22 Feb 1998 16:49:29 -0500 (EST) 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 ESMTP id QAA33584; Sun, 22 Feb 1998 16:49:28 -0500 Received: from hygro.raleigh.ibm.com (lig32-224-57-160.us.lig-dial.ibm.com [32.224.57.160]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with ESMTP id PAA02696; Sat, 21 Feb 1998 15:26:09 -0500 (EST) 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 PAA00883; Sat, 21 Feb 1998 15:22:22 -0500 Message-Id: <199802212022.PAA00883@hygro.raleigh.ibm.com> To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: (IPng 5225) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt In-reply-to: Your message of "Fri, 20 Feb 1998 11:42:12 GMT." <34ED6C14.3E66A470@hursley.ibm.com> Date: Sat, 21 Feb 1998 15:22:22 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If anybody cares, making this change would break RFC 1888. Is the problem the suggested change to addrconf or is it actually the fact that all interface identifiers are now 64 bits in length? I suspect that latter. (Don't blame the messenger!) 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 Feb 23 02:29:09 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id CAA17124 for ipng-dist; Mon, 23 Feb 1998 02:23:27 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id CAA17117 for ; Mon, 23 Feb 1998 02:23:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA03848 for ; Mon, 23 Feb 1998 02:23:16 -0800 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id CAA18292 for ; Mon, 23 Feb 1998 02:23:15 -0800 (PST) Received: from sp3at21.hursley.ibm.com by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA23206; Mon, 23 Feb 1998 10:23:13 GMT Received: from hursley.ibm.com (carpenterb.hursley.ibm.com [9.20.22.153]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7) with ESMTP id KAA73906; Mon, 23 Feb 1998 10:23:12 GMT Message-Id: <34F14E93.65F058F3@hursley.ibm.com> Date: Mon, 23 Feb 1998 10:25:23 +0000 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) Mime-Version: 1.0 To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 5226) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt References: <199802212022.PAA00883@hygro.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't track what SC6 is up to in detail. If SC6 reopens the NSAP format as a result of EUI-64 then it's the latter. If not it's only the former. RFC 1888 is an experimental RFC. We have no obligation to worry about it unless anybody actually cares. Up to now I am aware of no implementations of RFC 1888 so I deduce that nobody cares. (Peter Curran, this is also my response to your note.) Brian Carpenter Thomas Narten wrote: > > > If anybody cares, making this change would break RFC 1888. > > Is the problem the suggested change to addrconf or is it actually the > fact that all interface identifiers are now 64 bits in length? I > suspect that latter. (Don't blame the messenger!) > > 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 Mon Feb 23 05:14:07 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id FAA17227 for ipng-dist; Mon, 23 Feb 1998 05:10:34 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id FAA17220 for ; Mon, 23 Feb 1998 05:10:25 -0800 (PST) From: bound@zk3.dec.com Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA12681 for ; Mon, 23 Feb 1998 05:10:22 -0800 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id FAA29005 for ; Mon, 23 Feb 1998 05:10:21 -0800 (PST) Received: from wasted.zk3.dec.com (abelia.zk3.dec.com [16.140.64.63]) by mail12.digital.com (8.8.8/8.8.8/WV1.0c) with SMTP id IAA08676; Mon, 23 Feb 1998 08:10:20 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA15058; Mon, 23 Feb 1998 08:10:14 -0500 Message-Id: <199802231310.AA15058@wasted.zk3.dec.com> To: Brian E Carpenter Cc: Thomas Narten , ipng@sunroof.eng.sun.com Subject: (IPng 5227) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt In-Reply-To: Your message of "Mon, 23 Feb 1998 10:25:23 GMT." <34F14E93.65F058F3@hursley.ibm.com> Date: Mon, 23 Feb 1998 08:10:14 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As Brian pointed out I no of no implementation of RFC 1888 and no plans for one. Basically no one cares IMHO. I think it far wiser to assume a 64bit prefix for all addresses rather than not as I can't see any address FP not using the EUI. In addition the EUI is far closer to defining for the future a means to truly trust a global manufactured address in a site, than any thing invented in SC6 ever, hence if SC6 were alive for this topic they would be moving towards it too and would most likely alter NSAP to fit it. IMO everything but TCP/IP and SNA is a dead end protocol and users are moving legacy protocols to TCP/IP as quick as possible. I see no business or market for NSAPs at all. It appears Bill Simpson was right. We are wasting bits for NSAP address space in the IPv6 addr arch, but we can always take them back later. DISCLAIMER "The above opinion is not representative of Digital Equipment Corporation". /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 Feb 23 22:36:09 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id WAA18680 for ipng-dist; Mon, 23 Feb 1998 22:32:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id WAA18673 for ; Mon, 23 Feb 1998 22:32:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id WAA12295 for ; Mon, 23 Feb 1998 22:32:05 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id WAA28642 for ; Mon, 23 Feb 1998 22:32:05 -0800 (PST) From: Masataka Ohta Message-Id: <199802240620.PAA05765@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA05765; Tue, 24 Feb 1998 15:20:41 +0900 Subject: (IPng 5228) Re: I-D To: smb@research.att.com (Steven M. Bellovin) Date: Tue, 24 Feb 98 15:20:39 JST Cc: crawdad@fnal.gov, mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <3.0.3.32.19980220191415.0091c740@127.0.0.1>; from "Steven M. Bellovin" at Feb 20, 98 7:14 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve; > >> It can be identified. However, to make the identification scale, > >> we need local part (w.r.t. IEEE point of view) of EUI 64 has > >> a global (w.r.t. Internet point of view) tree structure like in-addr.arpa. > > > >I do not think security associations have such a scaling > >requirement. > > I haven't read the draft lately, but I believe you're right -- with IPSEC, > the real -- and scalable and hierarchical -- identity of the machine is > in the certificate. It, of course, is possible as long as you provide yet another layers of protocols to transfer the certificates of machines. > Anything else is good for TCP circuit identification, > for example, and need not be mapped into the DNS. Sure. It is merely an inellegance and inefficiency. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 24 10:16:04 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA19481 for ipng-dist; Tue, 24 Feb 1998 10:09:21 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA19474 for ; Tue, 24 Feb 1998 10:09:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA17707 for ; Tue, 24 Feb 1998 10:08:59 -0800 Received: from rumor.research.att.com (rumor.research.att.com [192.20.225.9]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id KAA16671 for ; Tue, 24 Feb 1998 10:09:00 -0800 (PST) Received: from research.att.com ([135.207.30.100]) by rumor; Tue Feb 24 13:04:08 EST 1998 Received: from postal.research.att.com ([135.207.23.30]) by research-clone; Tue Feb 24 13:05:29 EST 1998 Received: from smb.research.att.com (volvo.research.att.com [135.207.23.62]) by postal.research.att.com (8.8.7/8.8.7) with SMTP id NAA02975; Tue, 24 Feb 1998 13:05:16 -0500 (EST) Message-Id: <3.0.3.32.19980224122704.0091fb00@127.0.0.1> X-Sender: smb@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 24 Feb 1998 12:27:04 +0000 To: Masataka Ohta From: "Steven M. Bellovin" Subject: (IPng 5229) Re: I-D Cc: crawdad@fnal.gov, mohta@necom830.hpcl.titech.ac.jp, ipng@sunroof.eng.sun.com In-Reply-To: <199802240620.PAA05765@necom830.hpcl.titech.ac.jp> References: <3.0.3.32.19980220191415.0091c740@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 03:20 PM 2/24/98 JST, Masataka Ohta wrote: >Steve; > >> >> It can be identified. However, to make the identification scale, >> >> we need local part (w.r.t. IEEE point of view) of EUI 64 has >> >> a global (w.r.t. Internet point of view) tree structure like in-addr.arpa. >> > >> >I do not think security associations have such a scaling >> >requirement. >> >> I haven't read the draft lately, but I believe you're right -- with IPSEC, >> the real -- and scalable and hierarchical -- identity of the machine is >> in the certificate. > >It, of course, is possible as long as you provide yet another layers of >protocols to transfer the certificates of machines. IPsec requires that regardless. The question is whether or not we can make other use of it. > >> Anything else is good for TCP circuit identification, >> for example, and need not be mapped into the DNS. > >Sure. It is merely an inellegance and inefficiency. I think we'll have to agree to disagree here. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 24 18:15:01 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id SAA20318 for ipng-dist; Tue, 24 Feb 1998 18:07:12 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id SAA20311 for ; Tue, 24 Feb 1998 18:07:01 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id SAA02676 for ; Tue, 24 Feb 1998 18:06:54 -0800 Received: from necom830.hpcl.titech.ac.jp (necom830.hpcl.titech.ac.jp [131.112.32.132]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id SAA04548 for ; Tue, 24 Feb 1998 18:06:54 -0800 (PST) From: Masataka Ohta Message-Id: <199802250159.KAA08513@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA08513; Wed, 25 Feb 1998 10:59:09 +0900 Subject: (IPng 5230) Re: I-D To: smb@research.att.com (Steven M. Bellovin) Date: Wed, 25 Feb 98 10:59:08 JST Cc: mohta@necom830.hpcl.titech.ac.jp, crawdad@fnal.gov, ipng@sunroof.eng.sun.com In-Reply-To: <3.0.3.32.19980224122704.0091fb00@127.0.0.1>; from "Steven M. Bellovin" at Feb 24, 98 12:27 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve; > >> I haven't read the draft lately, but I believe you're right -- with IPSEC, > >> the real -- and scalable and hierarchical -- identity of the machine is > >> in the certificate. > > > >It, of course, is possible as long as you provide yet another layers of > >protocols to transfer the certificates of machines. > > IPsec requires that regardless. No objection. The difference is whether we satisfy the requirement ellegantly and efficiently through a existing protocol of DNS and IP header or create yet another layers of protocols with extra amount of data role of which is duplicated with those already in IP headers. Internet secutiry (not IPsec anymore) still requires some protocol to traverse the authentication chains of certificates, for which DNSSEC may or may not be useful. But, it is a separate issue. > The question is whether or not we > can make other use of it. The question is whether we should do it ellegantly and efficiently or not. Masataka Ohta -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 25 01:07:25 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id BAA20687 for ipng-dist; Wed, 25 Feb 1998 01:03:44 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id BAA20680 for ; Wed, 25 Feb 1998 01:03:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA22122 for ; Wed, 25 Feb 1998 01:03:33 -0800 Received: from cookson.iclweb.com (cookson.iclnet.co.uk [194.176.194.192]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id BAA17244 for ; Wed, 25 Feb 1998 01:03:31 -0800 (PST) Received: from DEFAULT ([194.176.201.68]) by cookson.iclweb.com (Netscape Mail Server v2.0) with ESMTP id AAA7719; Wed, 25 Feb 1998 09:03:20 +0000 From: jack@iclweb.com (Jack Holdsworth) To: "sc6wg7" , "ipngwg send" Subject: (IPng 5231) Fw: NSAP addresses in IPv6 Date: Wed, 25 Feb 1998 09:12:59 -0800 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <19980225090319.AAA7719@DEFAULT> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian Carpenter - in particular I have been reading the attached discussion on interface ID length and its impact on the use of NSAP's within the IPv6 addressing scheme, which is very worrying to me. One of the reasons why we did this in the first place was because many current NSAP users with large intranets may wish to embrace their addressing schemes as a part of a planned migration to IPv6 and RFC1888 throws them a lifeline. I have forwarded this correspondence to SC6 members to obtain their views. Please do not do anything precipitate until they have had a chance to consider it. Jack Houldsworth ISO Liaison +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > To: Peter Curran > Subject: (IPng 5211) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt > Date: Thu, 19 Feb 1998 16:30:53 -0500 > From: Thomas Narten > > > Peter, > > > I have re-read your draft and the appropriate sections of [ADDR-ARCH]. I > > can find no circumstance in the latter where the interface ID will be, or > > could be, less than 64 bits. I therefore question the need for the > > addr-conf-v2 to suggest that the interface ID length is a variable, when it > > clearly is not. > > I did add some words to the addrconf document suggesting the EUI-64 > identifier would be the common case. But you are right, I still left > things flexible by explicitly allowing other identifier sizes. And the > more I think about it, the less I am able to argue for not changing > the text as you suggest. > > One could make the argument that the current text is more flexible for > the future. In practice, I find that difficult to argue. The reality > now is that the size of the interface identifier is defined by the > IP-over-foo documents, and they all specify EUI-64s. Thus, for it to > be possible for a router to actually advertise a prefix of length > other than 64 bits, you'd have to rewrite the v6-over-foo spec and > change existing host implementations (since they'd have to generate > their interface identifers in a different way). This is a very high > bar and we're probably past the point of being able to do that. Plus > transition issues would not be pretty. > > The argument that only some format prefixes specify the use of EUI-64s > is probably irrelevent. At present, the addrconf spec specifies a > single way to form addresses and doesn't even care what the prefix > format bits are. If we we were to imagine having some format prefixes > use one interface identifier type, while other format prefixes use a > different one, addrconf can't handle that case today. The spec would > need to be changed and code would need to be changed in hosts (the > real killer). Again, a very high bar. That is, the bar is already high > enough for such a change that the impact on implementations that had > assumed only 64-bit identifiers would ever be used is probably not > significant. > > So, although I'd argue that the current text isn't incorrect, if it's > confusing, it should be changed, in the absence of compelling benefit > in leaving it as is. > > Thomas > > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > Date: Fri, 20 Feb 1998 20:49:15 +0000 > To: Brian E Carpenter > From: Peter Curran > Subject: (IPng 5219) Re: I-D > ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt > > At 11:42 AM 2/20/98 +0000, Brian E Carpenter wrote: > >If anybody cares, making this change would break RFC 1888. > > > > Brian > > > > Actually, I think RFC1888 needs revisiting in light of EUI-64. > > My reading of the document (and of course Brian is one of the authors, so I > bow to his greater wisdom) is that there is an implicit assumption that as > most NSAP addressing schemes use a 6-byte identifier (normally the MAC > address) then this would map well onto the then current IPv6 addressing > scheme. > > This is no longer true - does that mean that RFC1888 needs changing? > > In terms of defining a CLNP address space that can be mapped onto IPv6 for > transition purposes I think there is a problem with mapping Area-No + ID > (64-bits) onto an IPv6 interface ID (unless the G/L bit can be set to Local). > > Peter > TICL > > PS. I don't want to open **another** can of worms here :-) > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + > > To: Brian E Carpenter > cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 5225) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt > > > If anybody cares, making this change would break RFC 1888. > > Is the problem the suggested change to addrconf or is it actually the > fact that all interface identifiers are now 64 bits in length? I > suspect that latter. (Don't blame the messenger!) > > Thomas > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > Date: Mon, 23 Feb 1998 10:25:23 +0000 > From: Brian E Carpenter > Subject: (IPng 5226) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt > > I don't track what SC6 is up to in detail. If SC6 reopens the > NSAP format as a result of EUI-64 then it's the latter. If not > it's only the former. > > RFC 1888 is an experimental RFC. We have no obligation to worry > about it unless anybody actually cares. Up to now I am aware of > no implementations of RFC 1888 so I deduce that nobody cares. > (Peter Curran, this is also my response to your note.) > > Brian Carpenter > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > From: bound@zk3.dec.com > To: Brian E Carpenter > Subject: (IPng 5227) Re: I-D ACTION:draft-ietf-ipngwg-addrconf-v2-02.txt > Date: Mon, 23 Feb 1998 08:10:14 -0500 > > As Brian pointed out I no of no implementation of RFC 1888 and no plans > for one. Basically no one cares IMHO. I think it far wiser to assume a > 64bit prefix for all addresses rather than not as I can't see any > address FP not using the EUI. > > In addition the EUI is far closer to defining for the future a means to > truly trust a global manufactured address in a site, than any thing > invented in SC6 ever, hence if SC6 were alive for this topic they would > be moving towards it too and would most likely alter NSAP to fit it. > > IMO everything but TCP/IP and SNA is a dead end protocol and users > are moving legacy protocols to TCP/IP as quick as possible. I see no business > or market for NSAPs at all. > > It appears Bill Simpson was right. We are wasting bits for NSAP address > space in the IPv6 addr arch, but we can always take them back later. > > DISCLAIMER > "The above opinion is not representative of Digital Equipment Corporation". > > /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 Feb 26 06:33:51 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id GAA23038 for ipng-dist; Thu, 26 Feb 1998 06:25:58 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id GAA23030 for ; Thu, 26 Feb 1998 06:25:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA08952 for ; Thu, 26 Feb 1998 06:25:41 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id GAA05852 for ; Thu, 26 Feb 1998 06:25:42 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id JAA02046; Thu, 26 Feb 1998 09:25:37 -0500 (EST) Message-Id: <199802261425.JAA02046@ns.ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce@ns.ietf.org Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ns.ietf.org Reply-to: Internet-Drafts@ns.ietf.org Subject: (IPng 5232) I-D ACTION:draft-ietf-ipngwg-discovery-v2-02.txt Date: Thu, 26 Feb 1998 09:25:36 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Neighbor Discovery for IP Version 6 (IPv6) Author(s) : W. Simpson, T. Narten, E. Nordmark Filename : draft-ietf-ipngwg-discovery-v2-02.txt Pages : 92 Date : 25-Feb-98 This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers and to maintain reachability information about the paths to active neighbors. 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-discovery-v2-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-discovery-v2-02.txt Internet-Drafts directories are located at: Africa: ftp.is.co.za Europe: ftp.nordu.net ftp.nis.garr.it Pacific Rim: munnari.oz.au US East Coast: 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-discovery-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. --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: <19980225120040.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-discovery-v2-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-discovery-v2-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19980225120040.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 Fri Feb 27 10:42:39 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id KAA27877 for ipng-dist; Fri, 27 Feb 1998 10:35:23 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id KAA27870 for ; Fri, 27 Feb 1998 10:35:10 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA17914 for ; Fri, 27 Feb 1998 10:35:05 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id KAA20934 for ; Fri, 27 Feb 1998 10:34:56 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id NAA16302; Fri, 27 Feb 1998 13:34:50 -0500 (EST) Message-Id: <199802271834.NAA16302@ns.ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 5237) Last Call: IP Version 6 Management Information Base for the Transmission Control Protocol to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Fri, 27 Feb 1998 13:34:50 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider IP Version 6 Management Information Base for the Transmission Control Protocol as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 13, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-tcp-mib-01.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 Feb 27 11:10:55 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id LAA28068 for ipng-dist; Fri, 27 Feb 1998 11:05:34 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id LAA28061 for ; Fri, 27 Feb 1998 11:05:20 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA27691 for ; Fri, 27 Feb 1998 11:05:16 -0800 Received: from ns.ietf.org (ietf.org [132.151.1.19]) by saturn.sun.com (8.8.8/8.8.8) with ESMTP id LAA09835 for ; Fri, 27 Feb 1998 11:04:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ns.ietf.org (8.8.7/8.8.7a) with ESMTP id OAA17687; Fri, 27 Feb 1998 14:04:10 -0500 (EST) Message-Id: <199802271904.OAA17687@ns.ietf.org> To: IETF-Announce:;;;@cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 5238) Last Call: IP Version 6 Management Information Base for the User Datagram Protocol to Proposed Standard Reply-to: iesg@ns.ietf.org Date: Fri, 27 Feb 1998 14:04:10 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider IP Version 6 Management Information Base for the User Datagram Protocol as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 13, 1998. Files can be obtained via ftp://ftp.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6-udp-mib-01.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 Feb 27 13:43:54 1998 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) id NAA28342 for ipng-dist; Fri, 27 Feb 1998 13:35:49 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with ESMTP id NAA28335 for ; Fri, 27 Feb 1998 13:35:44 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.8+Sun+sa+re+hr/8.8.8) with SMTP id NAA27551 for ; Fri, 27 Feb 1998 13:35:43 -0800 (PST) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA02271; Fri, 27 Feb 1998 13:34:43 -0800 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.8.8+Sun/8.8.8) with SMTP id NAA28280 for ; Fri, 27 Feb 1998 13:09:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA01842 for ; Fri, 27 Feb 1998 13:08:58 -0800 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.sun.com (8.8.8/8.8.8) with SMTP id NAA22122 for ; Fri, 27 Feb 1998 13:08:58 -0800 (PST) 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 NAA28348 for ; Fri, 27 Feb 1998 13:08:56 -0800 Message-Id: <3.0.3.32.19980227130837.007b2320@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 27 Feb 1998 13:08:37 -0800 To: ipng@sunroof.eng.sun.com From: RFC Editor (by way of Bob Hinden ) Subject: (IPng 5240) RFC 2292 on Advanced Sockets API for IPv6 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A new Request for Comments is now available in online RFC libraries. RFC 2292: Title: Advanced Sockets API for IPv6 Author(s): W. Stevens, M. Thomas Status: Informational Date: February 1998 Mailbox: rstevens@kohala.com, matt.thomas@altavista-software.com Pages: 67 Characters: 152077 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2292.txt 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. This document is a product of the IPNG Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. Content-Type: text/plain Content-ID: <980226122443.RFC@ISI.EDU> SEND /rfc/rfc2292.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 --------------------------------------------------------------------