From owner-ipng@sunroof.eng.sun.com Fri Sep 1 16:05:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e81N3ZW24736 for ipng-dist; Fri, 1 Sep 2000 16:03:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e81N2FH24714; Fri, 1 Sep 2000 16:02:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA09358; Fri, 1 Sep 2000 16:02:15 -0700 (PDT) Received: from ups.cisco.com (ups.cisco.com [171.69.18.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA13778; Fri, 1 Sep 2000 16:02:15 -0700 (PDT) Received: from [10.19.130.190] (deering-office-pb.cisco.com [171.70.84.51]) by ups.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id QAA01889; Fri, 1 Sep 2000 16:02:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: Date: Fri, 1 Sep 2000 16:02:26 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: Fwd: IAB/IESG Recommendations on IPv6 Address Delegation Cc: ngtrans@sunroof.eng.sun.com, Bob Hinden Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Appended below is the message that was sent today to the RIRs from the IAB and IESG, regarding IPv6 address allocation policy. It contains most of the material that was in the draft I forwarded here on Sunday, but reorganized into a more coherent document. Steve -------- >Date: Fri, 01 Sep 2000 12:40:48 -0700 >To: lir-wg@ripe.net (RIPE), policy@arin.net (ARIN), > apnic-talk@apnic.net (APNIC) >From: Fred Baker >Subject: IAB/IESG Recommendations on IPv6 Address Delegation >Cc: ipv6-directorate@sunroof.eng.sun.com, iesg@ietf.org, iab@ISI.EDU, > ipv6-wg@ripe.net (RIPE), sig-ipv6@lists.apnic.net (APNIC) > >Folks: > >The RIR community asked the IETF community for advice regarding the >assignment of IPv6 prefixes to service providers and edge networks, both >with a view to topological address assignment and to multihomed networks. >The IPv6 Directorate prepared a statement, which the IESG and IAB have >reviewed and approved. This is attached. > >I trust that this answers the questions you asked, and serves as a basis for >IPv6 deployment in the near term. If you have questions or issues concerning >it, I would suggest that you address them to the IPv6 Directorate copying >the IESG and IAB. > >We intend to publish an Informational RFC in the near future documenting the >contents of this note. > >Fred Baker > >----------------------------------------------------------------------- > > IAB/IESG Recommendations on IPv6 Address Allocations > September 1, 2000 > >Introduction > >During a discussion between IETF and RIR experts at the Adelaide IETF, >a suggestion was made that it might be appropriate to allocate /56 >prefixes instead of /48 for homes and small businesses. However, >subsequent analysis has revealed significant advantages in using /48 >uniformly. This note is an update following further discussions at >the Pittsburgh IETF. > >This document was developed by the IPv6 Directorate, IAB and IESG, and >is a recommendation from the IAB and IESG to the RIRs. > >Background > >The technical principles that apply to address allocation seek to >balance healthy conservation practices and wisdom with a certain ease >of access. On the one hand, when managing the use of a potentially >limited resource, one must conserve wisely to prevent exhaustion >within an expected lifetime. On the other hand, the IPv6 address >space is in no sense as precious a resource as the IPv4 address space, >and unwarranted conservatism acts as a disincentive in a marketplace >already dampened by other factors. So from a market development >perspective, we would like to see it be very easy for a user or an ISP >to obtain as many IPv6 addresses as they really need without a >prospect of immediate renumbering or of scaling inefficiencies. > >The IETF makes no comment on business issues or relationships. >However, in general, we observe that technical delegation policy can >have strong business impacts. A strong requirement of the address >delegation plan is that it not be predicated on or unduly bias >business relationships or models. > >The IPv6 address, as currently defined, consists of 64 bits of >"network number" and 64 bits of "host number". The technical reasons >for this are several. The requirements for IPv6 agreed to in 1993 >included a plan to be able to address approximately 2^40 networks and >2^50 hosts; the 64/64 split effectively accomplishes this. Procedures >used in host address assignment, such as the router advertisement of a >network's prefix to hosts [RFC 2462], which in turn place a locally >unique number in the host portion, depend on this split. Examples of >obvious choices of host number (IEEE Mac Address, E.164 number, E.214 >IMSI, etc) suggest that no assumption should be made that bits may be >stolen from that range for subnet numbering; current generation MAC >layers and E.164 numbers specify up to 64 bit objects. Therefore, >subnet numbers must be assumed to come from the network part. This is >not to preclude routing protocols such as IS-IS level 1 (intra-area) >routing, which routes individual host addresses, but says that it may >not be depended upon in the world outside that zone. > >The IETF has also gone to a great deal of effort to minimize the >impacts of network renumbering. None-the-less, renumbering of IPv6 >networks is neither invisible nor completely painless. Therefore, >renumbering should be considered an acceptable event, but to be >avoided if reasonably avoidable. > >The IETF's IPNG working group has recommended that the address block >given to a single edge network which may be recursively subnetted be a > >48 bit prefix. This gives each such network 2^16 subnet numbers to >use in routing, and a very large number of unique host numbers within >each network. This is deemed to be large enough for most enterprises, >and to leave plenty of room for delegation of address blocks to >aggregating entities. > >It is not obvious, however, that all edge networks are likely to be >recursively subnetted; an individual PC in a home, or a single cell in >a mobile telephone network, for example, may or may not be further >subnetted (depending whether they are acting as, e.g., gateways to >personal, home, or vehicular networks). When a network number is >delegated to a place that will not require subnetting, therefore, it >might be acceptable for an ISP to give a single 64 bit prefix - >perhaps shared among the dial-in connections to the same ISP router. >However this decision may be taken in the knowledge that there is >objectively no shortage of /48s, and the expectation that personal, >home and vehicle networks will become the norm. Indeed, it is widely >expected that all IPv6 subscribers, whether domestic (homes), mobile >(vehicles or individuals), or enterprises of any size, will eventually >possess multiple always-on hosts, at least one subnet with the >potential for additional subnetting, and therefore some internal >routing capability. Note that in the mobile environment, the device >connecting a mobile site to the network may in fact be a third >generation cellular telephone. In other words the subscriber >allocation unit is not always a host; it is always potentially a site. > >Address Delegation Recommendations > >The RIR communities, with the IAB, have determined that reasonable >address prefixes delegated to service providers for initial >allocations should be on the order of 29 to 35 bits in length, giving >individual delegations support for 2^13 (8K) to 2^19 (512K) subscriber >networks. Allocations are to be given in a manner such that an >initial prefix may be subsumed by subsequent larger allocations >without forcing existing subscriber networks to renumber. We concur >that this meets the technical requirement for manageable and scalable >backbone routing while simultaneously allowing for managed growth of >individual delegations. > >The same type of rule could be used in the allocation of addresses in >edge networks; if there is doubt whether an edge network will in turn >be subnetted, the edge network might be encouraged to allocate the >first 64 bit prefix out of a block of 8..256, preserving room for >growth of that allocation without renumbering up to a point. However, >for the reasons described below, we recommend use of a fixed boundary >at /48 for all subscribers except the very largest (who could receive >multiple /48's), and those clearly transient or otherwise have no >interest in subnetting (who could receive a /64). Note that there >seems to be little benefit in not giving a /48 if future growth is >anticipated. In the following, we give the arguments for a uniform >use of /48 and then demonstrate that it is entirely compatible with >responsible stewardship of the total IPv6 address space. > >The arguments for the fixed boundary are: > > - only by having an ISP-independent boundary can we guarantee that a > change of ISP will not require a costly internal restructuring or > consolidation of subnets. > > - to enable straightforward site renumbering, i.e., when a site > renumbers from one prefix to another, the whole process, including > parallel running of the two prefixes, would be greatly complicated > if the prefixes had different lengths (depending of course on the > size and complexity of the site). > > - there are various possible approaches to multihoming for IPv6 > sites, including the techniques already used for IPv4 multihoming. > The main open issue is finding solutions that scale massively > without unduly damaging route aggregation and/or optimal route > selection. Much more work remains to be done in this area, but it > seems likely that several approaches will be deployed in practice, > each with their own advantages and disadvantages. Some (but not > all) will work better with a fixed prefix boundary. (Multihoming > is discussed in more detail below.) > > - to allow easy growth of the subscribers' networks -- no need to > keep going back to ISPs for more space (except for that relatively > small number of subscribers for which a /48 is not enough). > > - remove the burden from the ISPs and registries of judging sites' > needs for address space, unless the site requests more space than a > /48, with several advantages: > > - ISPs no longer need to ask for details of their customers' > network architecture and growth plans > - ISPs and registries no longer have to judge rates of address > consumption by customer type > - registry operations will be made more efficient by reducing the > need for evaluations and judgements > - address space will no longer be a precious resource for > customers, removing the major incentive for subscribers to > install v6/v6 NATs, which would defeat the ability of IPv6 to > restore address transparency. > > - to allow the site to maintain a single reverse-DNS zone covering > all prefixes. > > - If and only if a site can use the same subnetting structure under > each of its prefixes, then it can use the same zone file for the > address-to-name mapping of all of them. And, using the > conventions of RFC 2874, it can roll the reverse mapping data > into the "forward" (name-keyed) zone. > >Specific advantages of the fixed boundary being at /48 include > > - to leave open the technical option of retro-fitting the GSE > (Global, Site and End-System Designator, a.k.a "8+8") proposal for > separating locators and identifiers, which assumes a fixed boundary > between global and site addressing at /48. Although the GSE > technique was deferred a couple of years ago, it still has strong > proponents. Also, the IRTF Namespace Research Group is actively > looking into topics closely related to GSE. It is still possible > that GSE or a derivative of GSE will be used with IPv6 in the > future. > > - since the site local prefix is fec0::/48, global site prefixes of > /48 will allow sites to easily maintain a simple 1 to 1 mapping > between the global topology and the site local topology in the SLA > field. > > - similarly, if the 6to4 proposal is standardized, migration from a > 6to4 prefix, which is /48 by construction, to a native IPv6 prefix > will be simplified if the native prefix is /48. > >Note that none of these reasons imply an expectation that homes, >vehicles, etc. will intrinsically require 16 bits of subnet space. > >Conservation of Address Space > >The question naturally arises whether giving a /48 to every subscriber >represents a profligate waste of address space. Objective analysis >shows that this is not the case. A /48 prefix under the Aggregatable >Global Unicast Address (TLA) format prefix actually contains 45 >variable bits, i.e., the number of available prefixes is 2**45 or about >35 trillion (35,184,372,088,832). If we take the limiting case of >assigning one prefix per human, then the utilization of the TLA space >appears to be limited to approximately 0.03% on reasonable >assumptions. > >More precisely, > > - RFC 1715 defines an "H ratio" based on experience in address space > assignment in various networks. Applied to a 45 bit address space, > and projecting a world population of 10.7 billion by 2050 (see > http://www.popin.org/pop1998/), the required assignment efficiency > is log_10(1.07*10^10) / 45 = 0.22. This is less than the > efficiencies of telephone numbers and DECnetIV or IPv4 addresses > shown in RFC 1715, i.e., gives no grounds for concern. > > - We are highly confident in the validity of this analysis, based on > experience with IPv4 and several other address spaces, and on > extremely ambitious scaling goals for the Internet amounting to an > 80 bit address space *per person*. Even so, being acutely aware of > the history of under-estimating demand, we have reserved more than > 85% of the address space (i.e., the bulk of the space not under the > Aggregatable Global Unicast Address (TLA) format prefix). > Therefore, if the analysis does one day turn out to be wrong, our > successors will still have the option of imposing much more > restrictive allocation policies on the remaining 85%. > > - For transient use by non-routing hosts (e.g., for stand-alone > dial-up users who prefer transient addresses for privacy reasons), > a prefix of /64 might be OK. But a subscriber who wants "static" > IPv6 address space, or who has or plans to have multiple subnets, > ought to be provided with a /48, for the reasons given above, even > if it is a transiently provided /48. > >To summarize, we argue that although careful stewardship of IPv6 >address space is essential, this is completely compatible with the >convenience and simplicity of a uniform prefix size for IPv6 sites of >any size. The numbers are such that there seems to be no objective >risk of running out of space, giving an unfair amount of space to >early customers, or of getting back into the over-constrained IPv4 >situation where address conservation and route aggregation damage each >other. > >Multihoming Issues > >In the realm of multi-homed networks, the techniques used in IPv4 can >all be applied, but they have known scaling problems. Specifically, >if the same prefix is advertised by multiple ISPs, the routing tables >will grow as a function of the number of multihomed sites. To go >beyond this for IPv6, we only have initial proposals on the table at >this time, and active work is under way in the IETF IPNG working >group. Until existing or new proposals become more fully developed, >existing techniques known to work in IPv4 will continue to be used in >IPv6. > >Key characteristics of an ideal multi-homing proposal include (at >minimum) that it provides routing connectivity to any multi-homed >network globally, conserves address space, produces high quality >routes at least as well as the single-homed host case previously >discussed via any of the network's providers, enables a multi-homed >network to connect to multiple ISPs, does not inherently bias routing >to use any proper subset of those networks, does not unduly damage >route aggregation, and scales to very large numbers of multi-homed >networks. > >One class of solution being considered amounts to permanent parallel >running of two (or more) prefixes per site. In the absence of a fixed >prefix boundary, such a site might be required to have multiple >different internal subnet numbering strategies, (one for each prefix >length) or, if it only wanted one, be forced to use the most >restrictive one as defined by the longest prefix it received from any >of its ISPs. In this approach, a multi-homed network would have an >address block from each of its upstream providers. Each host would >either have exactly one address picked from the set of upstream >providers, or one address per host from each of the upstream >providers. The first case is essentially a variant on RFC 2260, with >known scaling limits. > >In the second case (multiple addresses per host), if two multi-homed >networks communicate, having respectively m and n upstream providers, >then the one initiating the connection will select one address pair >from the n*m potential address pairs to connect from and to, and in so >doing will select the providers, and therefore the applicable route, >for the life of the connection. Given that each path will have a >different ambient bit rate, loss rate, and delay, if neither host is >in possession of any routing or metric information, the initiating >host has only a 1/(m*n) probability of selecting the optimal address >pair. Work on better-than-random address selection is in progress in >the IETF, but is incomplete. > >An existence proof exists in the existing IPv4 Internet that a network >whose address is distinct from and globally advertised to all upstream >providers permits the routing network to select a reasonably good path >within the applicable policy. Present-day routing policies are not >QoS policies but reachability policies, which means that they will not >necessarily select the optimal delay, bit rate, or loss rate, but the >route will be the best within the metrics that are indeed in use. One >may therefore conclude that this would work correctly for IPv6 >networks as well, apart from scaling issues. >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Fred Baker | 519 Lado Drive >IETF Chair | Santa Barbara California 93111 >www.ietf.org | Desk: +1-408-526-4257 > | Mobile: +1-805-886-3873 > | FAX: +1-413-473-2403 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 5 02:19:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e859IHF25997 for ipng-dist; Tue, 5 Sep 2000 02:18:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e859I5H25990 for ; Tue, 5 Sep 2000 02:18:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA24821 for ; Tue, 5 Sep 2000 02:18:03 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA28839 for ; Tue, 5 Sep 2000 02:18:02 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id SAA15198; Tue, 5 Sep 2000 18:17:52 +0900 (JST) To: Keith Moore cc: iesg@ietf.org, ipng@sunroof.eng.sun.com In-reply-to: moore's message of Thu, 31 Aug 2000 14:48:45 -0400. <200008311848.OAA04429@astro.cs.utk.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standard From: itojun@iijlab.net Date: Tue, 05 Sep 2000 18:17:52 +0900 Message-ID: <15196.968145472@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >My biggest concern about this proposal is that it doesn't specify the >purposes for which this service can be used. To put it another way, >what services can rely on this information, and what services are >allowed to break if the result from the ICMPv6 query doesn't correspond >to what can be obtained from DNS (or to what applications running on >that host believe)? at IETF48 zeroconf WG and dnsext WG, I heard some comment on making distinction between full qualified domain name (which is on the DNS database), and hostname (which is configured onto each of the host, and do not necessarily the same as FQDN). Not sure if it has wide concensus, but it made some sense to me. - we look up FQDN through DNS database - we look up hostname through /etc/hosts (i'm not sure if it is really correct) - gethostname(3) returns hostname, not FQDN it is kind of confusing, but this gave me a way to understand the current situation. if we are okay with the distinction, we may be able to state the following: - if we are to lookup some name via ICMPv6 name lookup, it would be hostname, not FQDN. we need to update name-lookup draft again, though. of course, the above distinction could be very wrong. but then, how should we understand the current situation with gethostname(3)? itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 5 03:56:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e85AtBu26077 for ipng-dist; Tue, 5 Sep 2000 03:55:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e85At0H26070 for ; Tue, 5 Sep 2000 03:55:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA02051 for ; Tue, 5 Sep 2000 03:54:59 -0700 (PDT) Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA24956 for ; Tue, 5 Sep 2000 04:54:58 -0600 (MDT) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id GAA16582; Tue, 5 Sep 2000 06:54:47 -0400 (EDT) Message-Id: <200009051054.GAA16582@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net cc: Keith Moore , iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standard In-reply-to: Your message of "Tue, 05 Sep 2000 18:17:52 +0900." <15196.968145472@coconut.itojun.org> Date: Tue, 05 Sep 2000 06:54:46 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >My biggest concern about this proposal is that it doesn't specify the > >purposes for which this service can be used. To put it another way, > >what services can rely on this information, and what services are > >allowed to break if the result from the ICMPv6 query doesn't correspond > >to what can be obtained from DNS (or to what applications running on > >that host believe)? > > at IETF48 zeroconf WG and dnsext WG, I heard some comment on making > distinction between full qualified domain name (which is on the DNS > database), and hostname (which is configured onto each of the host, > and do not necessarily the same as FQDN). Not sure if it has wide > concensus, but it made some sense to me. > - we look up FQDN through DNS database > - we look up hostname through /etc/hosts > (i'm not sure if it is really correct) > - gethostname(3) returns hostname, not FQDN my experience is more like: - hostname is set as part of system configuration (during boot) (you can't look it up in /etc/hosts because you need to know what to look for) - hostname can either be an alias (usually just a label) or an FQDN - you can sometimes look up hostname in local DNS and get back an FQDN - the mapping from hostname to FQDN might or might not involve adding a domain suffix to the hostname. > it is kind of confusing, but this gave me a way to understand the > current situation. if we are okay with the distinction, > we may be able to state the following: > - if we are to lookup some name via ICMPv6 name lookup, it would > be hostname, not FQDN. > we need to update name-lookup draft again, though. okay, but this still doesn't answer the question. what is the purpose of this service, and what things are allowed to depend on it? Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 5 07:32:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e85EUFY26211 for ipng-dist; Tue, 5 Sep 2000 07:30:15 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e85EU4H26204 for ; Tue, 5 Sep 2000 07:30:05 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA17303 for ; Tue, 5 Sep 2000 07:30:04 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06574 for ; Tue, 5 Sep 2000 07:30:03 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id XAA17837; Tue, 5 Sep 2000 23:29:53 +0900 (JST) To: Keith Moore cc: iesg@ietf.org, ipng@sunroof.eng.sun.com In-reply-to: moore's message of Tue, 05 Sep 2000 06:54:46 -0400. <200009051054.GAA16582@astro.cs.utk.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standard From: itojun@iijlab.net Date: Tue, 05 Sep 2000 23:29:53 +0900 Message-ID: <17835.968164193@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> it is kind of confusing, but this gave me a way to understand the >> current situation. if we are okay with the distinction, >> we may be able to state the following: >> - if we are to lookup some name via ICMPv6 name lookup, it would >> be hostname, not FQDN. >> we need to update name-lookup draft again, though. >okay, but this still doesn't answer the question. what is the purpose of >this service, and what things are allowed to depend on it? under zeroconf situation, you may want to lookup: - an address from a hostname, using ICMPv6 name lookup (query type = node addresses) toward ff02::1 (or NI group address) - an address to a hostname, using ICMPv6 name lookup (query type = DNS name/hostname) toward the address the message type can be used just like mDNS proposals (see draft-aboba-dnsext-mdns-01.txt). also, it has been really useful for debugging. not 100% sure if the use of icmp6 is a good idea or not. also, as you noted, icmp6 may seem like a layer violation. if you have better suggestion, please let me know. (NOTE: I understand the security issues by giving away more information to bad guys) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 5 08:25:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e85FOMH26320 for ipng-dist; Tue, 5 Sep 2000 08:24:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e85FNPH26298; Tue, 5 Sep 2000 08:23:25 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA23434; Tue, 5 Sep 2000 08:23:25 -0700 (PDT) Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24797; Tue, 5 Sep 2000 08:23:25 -0700 (PDT) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.9.3/8.9.3) with ESMTP id JAA27104; Tue, 5 Sep 2000 09:23:24 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200009051523.JAA27104@hunkular.glarp.com> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: v4 mapped multicast addresses In-Reply-To: Your message of "Fri, 01 Sep 2000 16:02:26 PDT." Date: Tue, 05 Sep 2000 09:23:24 -0600 From: Brad Huntting Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Forgive me if this has been discussed already, but should applications be able to use v4 mapped multicast addresses the same way they use v6 multicast addresses? I have been working under the assumption that draft-ietf-ipngwg-rfc2553bis-00.txt intends just this, but there is at least one popular implementation that doesnt support this (yet). And if v4 mapped multicast addresses are allowed by the basic API, shouldn't IN6_IS_ADDR_MULTICAST() return !0 for v4 mapped multicast addresses? thanx, brad -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 5 09:23:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e85GMZ026429 for ipng-dist; Tue, 5 Sep 2000 09:22:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e85GLaH26407; Tue, 5 Sep 2000 09:21:36 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA08528; Tue, 5 Sep 2000 09:21:36 -0700 (PDT) Received: from ups.cisco.com (ups.cisco.com [171.69.18.21]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16951; Tue, 5 Sep 2000 09:21:35 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by ups.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id JAA14215; Tue, 5 Sep 2000 09:20:58 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@ups Message-Id: In-Reply-To: <200009051523.JAA27104@hunkular.glarp.com> References: <200009051523.JAA27104@hunkular.glarp.com> Date: Tue, 5 Sep 2000 09:21:21 -0700 To: Brad Huntting From: Steve Deering Subject: Re: v4 mapped multicast addresses Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 9:23 AM -0600 9/5/00, Brad Huntting wrote: >Forgive me if this has been discussed already, but should applications >be able to use v4 mapped multicast addresses the same way they use >v6 multicast addresses? I think we did discuss this is the past and concluded that the v4-mapped v6 addresses were only meaningful when carrying IPv4 non-loopback, unicast addresses. Thus, the IPv6 node should not have to do multiple, different prefix checks to determine if an address is a multicast address or a loopback address. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 5 16:42:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e85Nf6C26784 for ipng-dist; Tue, 5 Sep 2000 16:41:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e85Ne6H26762; Tue, 5 Sep 2000 16:40:06 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA17795; Tue, 5 Sep 2000 16:40:05 -0700 (PDT) Received: from hunkular.glarp.com (hunkular.glarp.com [199.117.25.251]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA03528; Tue, 5 Sep 2000 16:40:05 -0700 (PDT) Received: from hunkular.glarp.com (localhost [127.0.0.1]) by hunkular.glarp.com (8.9.3/8.9.3) with ESMTP id RAA01550; Tue, 5 Sep 2000 17:40:04 -0600 (MDT) (envelope-from huntting@hunkular.glarp.com) Message-Id: <200009052340.RAA01550@hunkular.glarp.com> To: Steve Deering cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: Re: v4 mapped multicast addresses In-Reply-To: Your message of "Tue, 05 Sep 2000 09:21:21 PDT." Date: Tue, 05 Sep 2000 17:40:04 -0600 From: Brad Huntting Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think we did discuss this is the past and concluded that the > v4-mapped v6 addresses were only meaningful when carrying IPv4 > non-loopback, unicast addresses. Thus, the IPv6 node should not > have to do multiple, different prefix checks to determine if an > address is a multicast address or a loopback address. Well, then I would like to beg and plead for a reconsideration. As someone writing a multicast app, I look at the unicast API with envy... Three simple function calls and I'm ready to move data with either v4 or v6 hosts. gethostinfo() socket() [bind()] connect() But with multicast I have to have duplicate code. In fact the same duplicate code that every other multicast app has to have. gethostinfo() socket() if (sa_family==AF_INET6){ setsockopt()'s for v6 [bind()] [connect()] } else if (sa_family==AF_INET){ setsockopt()'s for v4 [bind()] [connect()] } And every time I have to handle an group address (group address, local address, or a remote address) I have to write two sections of code, one for v6 and one for v4. And this same duplication of effort goes into every v6 multicast application (because every one of them will want to be v4 compatible). And all this duplication could be avoided if applications could simply use v4mapped multicast addresses with the basic v6 api. At the very least you should change section 2 paragraph 6 which currently reads: Because of the importance of providing IPv4 compatibility in the API, these extensions are explicitly designed to operate on machines that provide complete support for both IPv4 and IPv6.... If the setsockopt() options IPV6_MULTICAST_IF IPV6_MULTICAST_HOPS IPV6_JOIN_GROUP and IPV6_LEAVE_GROUP cant be used on v4 multicast sockets (whether AF_INET or mapped AF_INET6), then the above paragraph is not being honest and language should be added to indicate that v4 multicast is not in any way supported by this API. If these socket options are to be supported for v4 multicast sockets, then language should be added to make it clear what the basic API should support. brad -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 5 16:59:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e85NwN826850 for ipng-dist; Tue, 5 Sep 2000 16:58:23 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e85NvMH26828; Tue, 5 Sep 2000 16:57:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA13554; Tue, 5 Sep 2000 16:57:22 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA29049; Tue, 5 Sep 2000 17:57:20 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id IAA25173; Wed, 6 Sep 2000 08:57:11 +0900 (JST) To: Brad Huntting cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com In-reply-to: huntting's message of Tue, 05 Sep 2000 17:40:04 CST. <200009052340.RAA01550@hunkular.glarp.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: v4 mapped multicast addresses From: itojun@iijlab.net Date: Wed, 06 Sep 2000 08:57:11 +0900 Message-ID: <25171.968198231@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk i agree with steve, also i admit 2553bis should be more explicit about what is supposed to work (i.e. should tell people that multicast does not work with IPv4 mapped address). >> I think we did discuss this is the past and concluded that the >> v4-mapped v6 addresses were only meaningful when carrying IPv4 >> non-loopback, unicast addresses. Thus, the IPv6 node should not >> have to do multiple, different prefix checks to determine if an >> address is a multicast address or a loopback address. >Well, then I would like to beg and plead for a reconsideration. >As someone writing a multicast app, I look at the unicast API with >envy... Three simple function calls and I'm ready to move data >with either v4 or v6 hosts. > gethostinfo() > socket() > [bind()] > connect() getaddrinfo(3) is the way to go. it will present you with necessary info (address family, whatever) together with the address you have. the following code should do the right thing. if you hardcode AF_INET6 (or AF_INET), you lose in the future. please take a look at the following paper, it gives you a great detail about AF independent programming: .%A Craig Metz .%T Protocol Independence Using the Sockets API .%B "Proceedings of the freenix track: 2000 USENIX annual technical conference" .%D June 2000 itojun --- main() { i = 0; /* initialize hints */ getaddrinfo(mcastaddr, port, &hints, &res0); for (res = res0; res; res = res->ai_next) { switch (res->ai_family) { case AF_INET6: case AF_INET: break; default: exit(1); /* unknown address family */ } s[i] = socket(res->ai_familiy, res->ai_socktype, res->ai_protocol); if (s[i] < 0) continue; /* do it if necessary */ if (bind(s[i], res->ai_addr, res->ai_addrlen) < 0) { close(s[i]); continue; } switch (res->ai_family) { case AF_INET6: /* IPV6_MULTICAST_IF, IPV6_JOIN_GROUP */ break; case AF_INET6: /* IP_MULTICAST_IF */ break; } i++; continue; } if (i == 0); exit(1); /*no listening socket */ /* select loop on s[0] to s[i - 1] */ } -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 6 00:40:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e867dMZ27087 for ipng-dist; Wed, 6 Sep 2000 00:39:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e867cMH27065; Wed, 6 Sep 2000 00:38:23 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA14452; Wed, 6 Sep 2000 00:38:20 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA10692; Wed, 6 Sep 2000 00:38:19 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e867bi616624; Wed, 6 Sep 2000 09:37:44 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA02096; Wed, 6 Sep 2000 09:37:42 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id JAA54271; Wed, 6 Sep 2000 09:37:43 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200009060737.JAA54271@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brad Huntting cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: Re: (ngtrans) v4 mapped multicast addresses In-reply-to: Your message of Tue, 05 Sep 2000 09:23:24 MDT. <200009051523.JAA27104@hunkular.glarp.com> Date: Wed, 06 Sep 2000 09:37:43 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Forgive me if this has been discussed already, but should applications be able to use v4 mapped multicast addresses the same way they use v6 multicast addresses? => this was never specified in API specs but perhaps it is not very reasonable because multicast APIs are too different (no scope in IPv4 for instance). I have been working under the assumption that draft-ietf-ipngwg-rfc2553bis-00.txt intends just this, => obviously it is not the case for everybody. but there is at least one popular implementation that doesnt support this (yet). => in the scope ID usage for multicast discussion one suggested to retrofit IPv6 multicast API goodies into the IPv4 multicast API. I have no strong opinion about this (it is a good idea if it is easy to implement *and* to explain to common programmers) but we have the IPv4 multicast API designer in the list then I'd like to get other's opinion.... And if v4 mapped multicast addresses are allowed by the basic API, shouldn't IN6_IS_ADDR_MULTICAST() return !0 for v4 mapped multicast addresses? => I disagree. IN6_IS_ADDR_MULTICAST() is for real IPv6 addresses only, for IPv4 mapped multicast one should use IN6_IS_ADDR_V4MAPPED() then the common but not standardized macro to extract the IPv4 address and finally IN_MULTICAST() (with the good endian :-). Regards Francis.Dupont@enst-bretagne.fr PS: until a too well known router vender provides IPv6 multicast routing, this discussion has a little interest because IPv6 multicast is not available in the real world (or we'll come back to Mbone nightmares). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 6 05:25:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e86COSO27300 for ipng-dist; Wed, 6 Sep 2000 05:24:28 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e86COJH27293; Wed, 6 Sep 2000 05:24:20 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA15477; Wed, 6 Sep 2000 05:24:18 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29955; Wed, 6 Sep 2000 05:24:16 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.20.151.247) by smtp2.libero.it; 6 Sep 2000 14:24:14 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id 0927C4D25D; Wed, 6 Sep 2000 13:49:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 052964C9B5; Wed, 6 Sep 2000 13:49:27 +0200 (CEST) Date: Wed, 6 Sep 2000 13:49:26 +0200 (CEST) From: Mauro Tortonesi To: itojun@iijlab.net Cc: Brad Huntting , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: Re: (ngtrans) Re: v4 mapped multicast addresses In-Reply-To: <25171.968198231@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 6 Sep 2000 itojun@iijlab.net wrote: > please take a look at the following paper, it gives you a great detail > about AF independent programming: > .%A Craig Metz > .%T Protocol Independence Using the Sockets API > .%B "Proceedings of the freenix track: 2000 USENIX annual technical conference" > .%D June 2000 where can i get this? can you point me to an URL? thanks. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.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 Wed Sep 6 05:27:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e86CQIH27325 for ipng-dist; Wed, 6 Sep 2000 05:26:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e86CPxH27311; Wed, 6 Sep 2000 05:26:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA22043; Wed, 6 Sep 2000 05:25:59 -0700 (PDT) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA02404; Wed, 6 Sep 2000 05:25:59 -0700 (PDT) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 6D9021831; Wed, 6 Sep 2000 08:25:58 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 303A119B5; Wed, 6 Sep 2000 08:25:58 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id IAA0000596392; Wed, 6 Sep 2000 08:23:23 -0400 (EDT) From: Jim Bound Message-Id: <200009061223.IAA0000596392@anw.zk3.dec.com> To: itojun@iijlab.net Cc: Brad Huntting , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: (ngtrans) Re: v4 mapped multicast addresses In-reply-to: Your message of "Wed, 06 Sep 2000 08:57:11 +0900." <25171.968198231@coconut.itojun.org> Date: Wed, 06 Sep 2000 08:23:23 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Itojun, i agree with steve, also i admit 2553bis should be more explicit about what is supposed to work (i.e. should tell people that multicast does not work with IPv4 mapped address). This is simply not true. IPv4-Mapped is a representation of an IPv4 address that is all. If you strip out the leading bits for IPv6 you have left an IPv4 address whether its multicast or not. What does have to be responded to is the mappings for IPv6 Multicast to IPv4 if an applications listens and sends to IPv4-Mapped and that discussion is in process as part of the update to the api now. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 6 06:02:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e86D1bx27506 for ipng-dist; Wed, 6 Sep 2000 06:01:37 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e86D0aH27484; Wed, 6 Sep 2000 06:00:36 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA10613; Wed, 6 Sep 2000 06:00:36 -0700 (PDT) Received: from itojun.org (dialup0.itojun.org [210.160.95.108]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA12083; Wed, 6 Sep 2000 06:00:33 -0700 (PDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e86CujK00754; Wed, 6 Sep 2000 21:56:45 +0900 (JST) Message-Id: <200009061256.e86CujK00754@itojun.org> To: Mauro Tortonesi cc: Brad Huntting , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com In-reply-to: mauro's message of Wed, 06 Sep 2000 13:49:26 +0200. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: (ngtrans) Re: v4 mapped multicast addresses From: Jun-ichiro itojun Hagino Date: Wed, 06 Sep 2000 21:56:45 +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> .%A Craig Metz >> .%T Protocol Independence Using the Sockets API >> .%B "Proceedings of the freenix track: 2000 USENIX annual technical conference" >> .%D June 2000 >where can i get this? can you point me to an URL? thanks. http://www.usenix.org/publications/library/proceedings/usenix2000/freenix/metzprotocol.html you need to be a usenix member to get this, until June 2001. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 6 22:08:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e87578928061 for ipng-dist; Wed, 6 Sep 2000 22:07:08 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e87568H28036; Wed, 6 Sep 2000 22:06:08 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with SMTP id e87566k256866; Wed, 6 Sep 2000 22:06:06 -0700 (PDT) Date: Wed, 6 Sep 2000 22:06:03 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: v4 mapped multicast addresses To: Brad Huntting Cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200009051523.JAA27104@hunkular.glarp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Forgive me if this has been discussed already, but should applications > be able to use v4 mapped multicast addresses the same way they use > v6 multicast addresses? I have been working under the assumption > that draft-ietf-ipngwg-rfc2553bis-00.txt intends just this, but > there is at least one popular implementation that doesnt support > this (yet). I don't think this has been discussed much on the mailing list. We did agree that for IPv4-compatible addresses it didn't make sense at all to allow IPv4 multicast addresses. Initially I didn't see the need for multicast addresses in the IPv4-mapped space, but when folks did an implementation of the java.net classes that transparently did IPv6 and IPv4 it was a real pain to make the multicast class work without being able to always open an AF_INET6 socket issue IPV6_JOINGROUP socket options with either a native IPv6 multicast address or an IPv4-mapped multicast address. The alternative would have been to allow the IP_ADD_MEMBERSHIP socket option on AF_INET6 sockets. I don't think this is necessary for real applications since they presumably know whether they are using to use IPv6 or IPv4 multicast before creating the socket. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 6 22:09:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8758Wb28087 for ipng-dist; Wed, 6 Sep 2000 22:08:32 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8757OH28063; Wed, 6 Sep 2000 22:07:25 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with SMTP id e8757Lk256965; Wed, 6 Sep 2000 22:07:22 -0700 (PDT) Date: Wed, 6 Sep 2000 22:07:18 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: v4 mapped multicast addresses To: Steve Deering Cc: Brad Huntting , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think we did discuss this is the past and concluded that the v4-mapped > v6 addresses were only meaningful when carrying IPv4 non-loopback, unicast > addresses. Thus, the IPv6 node should not have to do multiple, different > prefix checks to determine if an address is a multicast address or a > loopback address. I thought that discussion was for IPv4-compatible addresses. Did we have the discussion for IPv4-mapped addresses as well? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 7 06:47:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e87DguE28379 for ipng-dist; Thu, 7 Sep 2000 06:42:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e87DeLH28357; Thu, 7 Sep 2000 06:40:22 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA18334; Thu, 7 Sep 2000 06:40:20 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13738; Thu, 7 Sep 2000 06:40:21 -0700 (PDT) Received: from [192.87.117.47] (ssh.cisco.com [171.69.10.34]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id GAA04643; Thu, 7 Sep 2000 06:39:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@127.0.0.1 Message-Id: In-Reply-To: References: Date: Thu, 7 Sep 2000 06:40:23 -0700 To: Erik Nordmark From: Steve Deering Subject: Re: v4 mapped multicast addresses Cc: Brad Huntting , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:07 PM -0700 9/6/00, Erik Nordmark wrote: >I thought that discussion was for IPv4-compatible addresses. >Did we have the discussion for IPv4-mapped addresses as well? You are right. I confused one with the other. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 7 09:38:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e87GbCW28511 for ipng-dist; Thu, 7 Sep 2000 09:37:12 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e87Gb3H28504; Thu, 7 Sep 2000 09:37:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA25185; Thu, 7 Sep 2000 09:37:02 -0700 (PDT) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA20319; Thu, 7 Sep 2000 09:37:01 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 7 Sep 2000 09:19:32 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 07 Sep 2000 09:20:04 -0700 (Pacific Daylight Time) Received: from SIT.platinum.corp.microsoft.com ([172.30.236.233]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Thu, 7 Sep 2000 09:20:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C018E7.48F6F9D2" Subject: RE: (ngtrans) Re: v4 mapped multicast addresses Date: Thu, 7 Sep 2000 09:18:40 -0700 Message-ID: <19398D273324D3118A2B0008C7E9A5690C6F7B60@SIT.platinum.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (ngtrans) Re: v4 mapped multicast addresses Thread-Index: AcAYiZM9904zrqI5S1Ko9oYZ3C1E2AAXNa/A From: "Dave Thaler" To: "Erik Nordmark" , "Brad Huntting" Cc: , X-OriginalArrivalTime: 07 Sep 2000 16:20:04.0346 (UTC) FILETIME=[7AD1DDA0:01C018E7] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C018E7.48F6F9D2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Erik Nordmark writes: > I don't think this is necessary for real applications since they > presumably know whether they are using to use IPv6 or IPv4 multicast > before creating the socket. This is only partially true. A protocol-independent application would likely get the address from either getaddrinfo(), or from parsing an SDP description. Both of these methods can generate a sockaddr in either AF_INET or AF_INET6, or in AF_INET6 with v4- mapped addresses. In the getaddrinfo case, the app doesn't "know"=20 unless you add code to check. In the SDP case, there's no standard library that I'm aware of, but some libraries may exist that work similarly to getaddrinfo(). -Dave ------_=_NextPart_001_01C018E7.48F6F9D2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: (ngtrans) Re: v4 mapped multicast addresses

Erik Nordmark writes:
> I don't think this is necessary for real = applications since they
> presumably know whether they are using to use = IPv6 or IPv4 multicast
> before creating the socket.

This is only partially true.  A = protocol-independent application
would likely get the address from either = getaddrinfo(), or from
parsing an SDP description.  Both of these = methods can generate
a sockaddr in either AF_INET or AF_INET6, or in = AF_INET6 with v4-
mapped addresses.  In the getaddrinfo case, the = app doesn't "know"
unless you add code to check.
In the SDP case, there's no standard library that I'm = aware of,
but some libraries may exist that work similarly to = getaddrinfo().

-Dave

------_=_NextPart_001_01C018E7.48F6F9D2-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 8 15:09:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e88M88j29447 for ipng-dist; Fri, 8 Sep 2000 15:08:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e88M7xH29440 for ; Fri, 8 Sep 2000 15:08:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA23354 for ; Fri, 8 Sep 2000 15:08:01 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA27624 for ; Fri, 8 Sep 2000 15:08:00 -0700 (PDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 08 Sep 2000 15:07:47 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Fri, 8 Sep 2000 15:09:25 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA81C9B5E@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "'Powell, Ken'" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-addr-select-01 comments Date: Fri, 8 Sep 2000 15:09:16 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I reviewed your "Default Address Selection for IPv6" draft. > I have some concerns/questions on the algorithms and what > the document requires implementations to support. Details > below. Thanks for your careful reading & great comments!!! [fyi - If a discussion develops... I'll be off email next week.] > Page 2, Section 1 last paragraph: > > "The rules specified in this document MUST NOT be construed > to override an application or upper-layer's explicit choice > of destination or source address." > > Is an implementation allowed to sanity check an application's > source/destination address choices based on criteria like > those defined in section 3 and reject such selections as > invalid? I believe this requirement leaves the option open, > but wanted to be sure. So for example, can an implementation implement a sanity check that prevents an application from choosing an anycast source address? Yes. An implementation can prevent an application from choosing a source address that is not in the candidate set (ie, is completely illegal), but it can't override an application's choice of an address that is in the candidate set. I'll clarify this. > Page 3, Section 2 > > The discussion of where different parts of this spec map > into the API is very helpful. > > If I understand this correctly, destination address > selection is done during the call to getaddrinfo or > getipnodebyname. The destination address selection > algorithm uses the source address selection algorithm. > An important parameter to source address selection is > the interface. Given what invokes destination address > selection, the interface is not known. > > Later on, an implementation is likely to invoke source > address selection again as the result of a connect or sendto > call. This time the interface is known. It was either > specified by the application or determined through a > routing table lookup. The previously chosen destination > address could easily be wrong for the interface. > > This all leads to the concern that destination address > selection goes to great lengths to get the best address > but is hobbled by missing prior knowledge of the interface. Also a good point! I'm trying to allow for flexibility in how this gets implemented. Some implementations of destination address selection might be done entirely in user space and have imprecise or out of date or incomplete information about the source addresses and selection of outgoing interface. Other implementations might use a system call and have better knowledge. Both should be allowed. Another way to say this - suppose you have an user-level destination address selection implementation (used inside getaddrinfo) that uses user-level source address selection as a subroutine. And you have kernel-level source address selection (used inside TCP's connect, for example). The user-level source address selection could use a bigger or less-precise candidate set and not have knowledge of the outgoing interface. I'll try to clarify this issue in the next revision. > Page 5, Section 2.4 > > "IPv6 implementations SHOULD support configurable address > selection via a mechanism at least as powerful as the policy > tables defined here." > > I do not understand why this is a "SHOULD" requirement today. > These tables are very interesting and I can see their power > and use, but they seem to add little practical value without > a management infrastructure capable of downloading a common > set of rules to all nodes in a site. I believe making this > table configurable should be defined as optional. Also, support > for the Label and MatchSrcLabel mechanisms in particular should > be optional. I'd like to hear more feedback from the WG on this point. Should the suggestion of configurability be "SHOULD" or "MAY" or "may" or ??? I certainly agree it should be optional, but I'd like to encourage implementations to be configurable with mechanisms like policy table or equivalent functionality, because those mechanisms can be used in multi-homing situations (both sites connected to multiple ISPs and hosts with multiple interfaces) to control choices of source & destination address. > Page 5, Section 2.4 > > The default policy table treats IPv4 Mapped addresses that > fall within the "autonet" and rfc 1918's private address > ranges as special, with a higher priority than the other > IPv4 mapped addresses. Is there a similar mechanism in > current IPv4 implementations? If not, could this additional > feature possibly change the behavior of applications that > were ported to IPv6 in unexpected ways? I'm not suggesting that v4 stacks change how they do source address selection. If you have a v4-only application, it shouldn't see any changes in source address selection or the address order from gethostbyname as a consequence of my draft. For an application ported to IPv6, the v4-mapped stuff just makes a difference to the order of addresses returned by getaddrinfo, for example whether getaddrinfo returns a v4 address before a v6 address or vice-versa. It would affect whether dual-protocol applications use v4 or v6 in dual-protocol network environments, but by making the correct/expected thing happen. > Page 6, Section 3 > > Should an additional restriction like the following be > added to the candidate set of source addresses? > > "For IPv4 Mapped destination addresses, the set of > candidate source addresses must only include IPv4 Mapped > addresses. For any other destination address, the set > of candidate source addresses MUST NOT include IPv4 > Mapped addresses." Yes. > Should use of the loopback destination restrict the source > address to be loopback also? I don't think so. For example if fe80::1 is assigned to my ethernet interface, why shouldn't I be able to send to destination ::1 using fe80::1 as the source address? (This would be on a weak host model implementation so the mismatch between the loopback interface and the ethernet interface is not considered a problem.) > Page 6, Section 4 > > "Rule 2, Prefer Matching Label" seems to be given too much > weight over other criteria. For example, if the destination > is a 6to4 addresses, this rule will cause a deprecated > 6to4 address to be chosen as the source over a preferred > global address. If your 6to4 address is deprecated, > chances are its time to stop using it. Your site is probably > switching over to global addresses and the 6to4 address is > going away. I agree and my absentee Pittsburgh IETF presentation talked about related policy table issues. In my revision I plan to give "prefer matching label" much lower priority (probably moving it to just above the longest-matching-prefix rule). > Page 7, Section 4 > > "Rule 3, Prefer appropriate scope" is complex and aught > to be broken into two rules with rule 4 in the middle > like: > > Rule 3a: Avoid insufficient scope for destination. > (i.e., avoid Scope Source < Scope Dest) > > Rule 4: Avoid deprecated addresses. > > Rule 3b: Prefer closest scope. > If both SA and SB are of sufficient scope, choose > the one with lower scope. If both SA abd SB are > if insufficient scope, choose the one with higher > scope. One issue with this simplification is that it would change the selection in some instances. For example: global destination with choice of deprecated site-local SA and preferred link-local SB. The current rules pick SA and your proposal would pick SB. If we're going to simplify this, I actually favor just giving appropriate scope absolute priority over preferred/deprecated. The preferred/deprecated parts of the current rule 3 are a response to comments from Erik Nordmark, if I remember correctly. > Page 7, Section 4 > > "Rule 8 MAY be superceded if the implementation has other > means of choosing among source addresses. For example, if > the implementation somehow knows which source address will > result in the "best" communications performance." > > I think limiting implementation specific tests to > supercede only Rule 8 is overly restrictive. We cannot > predict how useful future implementation specific tests > may be for improving efficiency or avoiding connectivity > problems. Implementations should be allowed to inject their > own tests anywhere in the list of rules. > > Page 7, Section 4 > > "The pair-wise comparison consists of eight rules, which > MUST be applied in order." > > Is it mandatory to implement all these rules? I don't > see why every implementation has to implement longest > matching prefix for example. Could you break the list > down and identify which rules MUST, SHOULD, and MAY be > implemented? > > The requirement of order seems overly restrictive too. > A brief list of the source address selection rules > (with my rule 3 suggestion) gives: > > Rule 1: Prefer same address > Rule 2: Prefer matching label > Rule 3a: Avoid insufficient scope > Rule 4: Avoid deprecated addresses > Rule 3b: Prefer lower scope > Rule 5: Prefer home address > Rule 6: Prefer outgoing interface > Rule 7: Prefer anonymous addresses > Rule 8: Use longest matching prefix > Rule X: Implementation defined test > > I tend to divide these rules into the following groups: > > A) Rule 1. This is an important diagnostic feature that > makes sense where it is. > > B) Rules 3a, 4, and 5. There is a good chance > communication will fail if any of these rules > are broken. > > C) Rules 2, 3b, 6, 7, 8, and X seem to exist mostly > for efficiency or privacy enhancements. > > I don't think we know enough to predict which of these > rules will prove more important to customers. For example, > some customers may get annoyed that their system selected > a 6to4 address over a global anonymous address simply > because the destination was a 6to4 address. > > Would it make sense to specify groups of rules, where one > group MUST be applied before the other, then RECOMMEND the > order of rules within each group where order really isn't > important to interoperability? The requirement for applying the rules in order, and only superceding the last rule, is to get some predictability between different implementations. We could argue about your example (sending to 6to4 destination, choice of public 6to4 or anonymous global source address). I think choosing the public 6to4 source address is the right answer (and really, if the implementation is using privacy there will also be an anonymous 6to4 address that will get chosen). But whatever the right answer is, I think customers will be even more annoyed if some implementations do one thing and other implementations do something different. Predictibility in this area is a very good thing for network operations & manageability. Many of the individual rules are collected from other places. For example, avoiding deprecated addresses comes from RFC 2462. Preferring anonymous addresses comes from the privacy draft. The real contribution of this section isn't the rules themselves, it's supplying consistency by giving them an order. I do agree that the higher-priority rules could be MUST, the middle-priority rules could be SHOULD, and the lowest-priority rules (like longest-matching-prefix) could be SHOULD or MAY. > Page 8, Section 5 > > It seems possible that some destination addresses could > end up with no candidate source addresses. Should a rule > be added at the top to avoid destinations with no candidate > source address? Yes. > Page 8, Section 5 > > "The pair-wise comparison of destination addresses consists > of four rules, which MUST be applied in order." > > A summary of the rules is: > > Rule 1: Prefer destination with matching source > Rule 2: Prefer destination with higher precedence > Rule 3: Use longest matching prefix > Rule 4: Use order returned by name service > > Same questions as above for source address selection: > Is it mandatory to implement all these rules? > Is the order really critical for interoperability? > Please be more specific on what MUST, SHOULD, and > MAY be done. Btw: In the forthcoming revision, that greatly reduces the number of entries in the default policy table, these destination address selection rules will expand a bit. For example, because the default policy table won't have separate entries for various address scopes, there will need to be a separate rule here to prefer destination addresses of smaller scope. To answer your question: the prefer smaller scope rule shold be SHOULD or maybe even MUST. The longest-matching-prefix should be SHOULD or maybe MAY. The others can be SHOULD. > Page 8, Section 5 > > "The third and fourth rules MAY be superceded if the > implementation has other means of sorting destination > addresses." > > Same question as above for source address selection. > Why limit this just to the third and fourth rules? For example, consider a name that resolves to both a site-local & global address, and the machine itself both a site-local & global address. I think we agree that for the site-local destination, you should prefer the site-local source, and for the global destination you should prefer the global source. But should getaddrinfo return the two destination addresses in any particular order? I *think* there's consensus that using the smaller-scope addresses is better, so getaddrinfo should return the site-local address before the global address. This is important if the site is trying to use site-local addresses for all intra-site communication. If getaddrinfo returns the global address first, intra-site communication will end up using global addresses. Hence, I think getaddrinfo implementations SHOULD or maybe even MUST return the site-local address before the global address - otherwise site-local addresses will lose one of their important uses. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 8 20:48:03 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e893kRr29590 for ipng-dist; Fri, 8 Sep 2000 20:46:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e893kGH29583 for ; Fri, 8 Sep 2000 20:46:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA21866 for ; Fri, 8 Sep 2000 20:46:16 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA29460 for ; Fri, 8 Sep 2000 20:46:16 -0700 (PDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 08 Sep 2000 20:46:03 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Fri, 8 Sep 2000 20:47:44 -0700 Message-ID: From: Brian Zill To: Richard Draves , "'Powell, Ken'" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-addr-select-01 comments Date: Fri, 8 Sep 2000 20:46:05 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Page 6, Section 3 > > > > Should an additional restriction like the following be > > added to the candidate set of source addresses? > > > > "For IPv4 Mapped destination addresses, the set of > > candidate source addresses must only include IPv4 Mapped > > addresses. For any other destination address, the set > > of candidate source addresses MUST NOT include IPv4 > > Mapped addresses." > > Yes. No :-) In the first quoted sentence, the set of candidate source addresses must also include IPv4 *Translated* addresses, or nodes in a SIIT cloud won't work. And on the other end, translators need to be able to send from IPv4 Mapped addresses to IPv4 Translated addresses. So how about: "For IPv4 Mapped destination addresses, the set of candidate source addresses must only include IPv4 Mapped and IPv4 Translated addresses. For any other destination address, the set of candidate source addresses MUST NOT include IPv4 Mapped addresses." Note I didn't change this to regulate the use of IPv4 translated addresses as destination addresses, since a node inside a SIIT cloud should be able to talk to other local nodes using its translated address even if the other node has a regular (i.e. non-translated IPv4) IPv6 address. Or at least I believe it should. However, I think allowing this means that for source address selection purposes, IPv4 translated addresses should get less preference than global addresses - they're essentially a weird kind of site-local addresses. But if you wanted to restrict the use of translated addresses just to communication with the translator, you could say something like: "For an IPv4 Mapped or IPv4 Translated destination address, the set of candidate source addresses must only include IPv4 Mapped and IPv4 Translated addresses. For any other destination address, the set of candidate source addresses MUST NOT include IPv4 Mapped addresses or IPv4 Translated addresses." But my vote's for my first one. --Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 8 23:20:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e896JAF29662 for ipng-dist; Fri, 8 Sep 2000 23:19:10 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e896IEH29640; Fri, 8 Sep 2000 23:18:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA00121; Fri, 8 Sep 2000 23:18:10 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07933; Fri, 8 Sep 2000 23:18:09 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id PAA11753; Sat, 9 Sep 2000 15:18:08 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA01174; Sat, 9 Sep 2000 15:18:08 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA29168; Sat, 9 Sep 2000 15:18:07 +0900 (JST) Date: Sat, 09 Sep 2000 15:18:53 +0900 (JST) Message-Id: <20000909.151853.74665794.kazu@Mew.org> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@ISI.EDU Subject: The Global IPv6 Summit in Japan From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) Reply-To: cfp@jp.ipv6forum.com X-Mailer: Mew version 1.95b57 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk # This is the third try since the previously posted message have not # delivered. Sorry if you receive duplicated messages. Hello IPv6 folks, "The Global IPv6 Summit in Japan" will be held in the next week of IETF San Diego at Osaka city, Japan. Most presentations/panels are spoken in Japanese but we prepare translators between Japanese and English. So, we would like to call for your participation. Also you have a chance to appeal your IPv6 business in a session. We would also like to call for your presentations. // Steering Group of the Global IPv6 Summit in Japan ---- Call for participation and presentations for "the Global IPv6 Summit in Japan" <> The Global IPv6 Summit, under the organization of the IPv6 Forum, is held regularly around the world to accelerate the deployment of IPv6. We are happy to announce that this conference will be held in Japan, one of the leading countries in the areas of IPv6 development and deployment. The Internet is built on the foundations of the Internet Protocol (IP). The current version of IP is named IPv4 after its version number. The total number of devices that IPv4 can identify is limited to about 4.3 billion. It's hard to see the Internet becoming the foundation of a true, universal communications infrastructure when this number is compared to the human population. In fact, it is expected that the entire address space of IPv4 will be exhausted by around 2008. So, address assignment/allocation is currently being carried out under a very restrictive policy. NAT (Network Address Translator) was introduced as a temporary solution, resulting in the loss of some of the original functionality of the Internet. The principles of the Internet are end-to-end and bidirectional communication. This means every node can communicate with every other freely without any restrictions caused by intermediate nodes. Since NAT broke these principles, it became difficult for unexpected novel applications to appear in the current environment of the Internet. To resolve the exhaustion of IP addresses, extending its address space is a straightforward solution. IPv6, the next generation of IP, provides a huge number of IP addresses and makes NAT obsolete allowing the Internet to recover its original principles. IPv6 is a paradigm recovery for applications. After deploying IPv6 and recovering end-to-end/bidirectional communication, we cannot imagine what kind of applications will appear. This conference will introduce the current deployment status of IPv6 throughout the world. Also, panel discussions are planned, both on "How IPv6 will Change Business" and on "Case Studies: Making the Change to IPv6". Getting Internet people together, including those who are involved in IPv6 activities and IPv4 business and management, we intend to discuss the future of Internet business and the direction of engineering. This conference will be beneficial for everyone including, but not limited to, engineers, researchers, network managers and business people. We would like to invite each of you to participate. <> Steering Group of the Global IPv6 Summit in Japan (Contact: info@jp.ipv6forum.com) <> Date: December 18 - 19, 2000 (As a part of Internet Week 2000) Venue: Grand Cube Osaka (Osaka International Convention Center) 5-3-51, Nakanoshima, Kita-ku, Osaka 530-0005, JAPAN Phone: +81-6-4803-5555 Fax: +81-6-4803-5620 E-mail: soumu@gco.co.jp http://www.gco.co.jp/index.html (The same place as Internet Week 2000) <> Early registration Regular/ discount On-site registration (until Oct 31) Non-student 10,000 JPY 15,000 JPY Student 2,000 JPY 2,000 JPY Non-student 5,000 JPY Student 3,000 JPY <> December 18 (Mon) Keynote Speech 1: Dr. Jun Murai, WIDE Project Session 1: Business report on IPv6 in Japan Session 2: Status report from Asian countries Session 3: Panel on how IPv6 will change business Reception December 19 (Tue) Keynote Speech 2: Dr. Steve Deering, Cisco Systems Session 4: Business report on IPv6 around the world Session 5: Case Studies: Making the Change to IPv6 <> This conference will be held as a part of Internet Week 2000. Please refer to the following page for registration: http://www.jp.ipv6forum.com/ <> The program committee calls for presentation proposal for "Session 4: Business report of IPv6 around the world". Candidates are sTLA holders and IPv6 vendors. Please propose a "10 minutes" presentation on your IPv6 business. If you would like to give a presentation, please send an e-mail message in the following form. Please note that we may not accept all proposals due to the time limitations of the program. Format: See below Deadline: September 30, 2000 Notification date: October 6, 2000 To: cfp@jp.ipv6forum.com Subject: presentation proposal Name : Title : Email : Telephone number: Organization : Department : Your proposal in plain text (no more than 250 words) explaining as concretely as possible your point of view and what kind of presentation can be expected. ---- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 10 10:25:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8AHNnB00380 for ipng-dist; Sun, 10 Sep 2000 10:23:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8AHNeH00373 for ; Sun, 10 Sep 2000 10:23:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA09973 for ; Sun, 10 Sep 2000 10:23:39 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA23829 for ; Sun, 10 Sep 2000 10:23:39 -0700 (PDT) Received: from localhost ([3ffe:501:100f:13ff::e]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA27180; Mon, 11 Sep 2000 02:10:52 +0900 (JST) Date: Mon, 11 Sep 2000 02:19:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: iesg@ietf.org Cc: ipng@sunroof.eng.sun.com Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standard In-Reply-To: In your message of "Thu, 31 Aug 2000 12:36:10 -0400" <200008311636.MAA09234@ietf.org> References: <200008311636.MAA09234@ietf.org> User-Agent: Wanderlust/2.3.0 (Roam) Emacs/20.7 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 55 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 31 Aug 2000 12:36:10 -0400, >>>>> The IESG said: > The IESG has received a request from the IPNG Working Group to consider > IPv6 Node Information Queries > 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 September 13, 2000. I admit that I should've made comments on the draft earlier, but please let me add a final (I hope this is final) comment. The 07 draft defines TTL of an address used in the node information messages as follows: The Responder must fill in the TTL field of the Reply with a meaningful value if possible. That value should be one of the following. The remaining lifetime of a DHCP lease on the Subject Address; The remaining Valid Lifetime of a prefix from which the Subject Address was derived through Stateless Autoconfiguration [2461, 2462]; The TTL of an existing AAAA or A6 record which associates the Subject Address with the DNS Name being returned. (page 8, Section 4.3) Possible range of those TTLs are different: According to draft-ietf-dhc-v6exts-12.txt defines, the Valid (lease) lifetime of an IPv6 address configured by DHCPv6 is a 32bits integer (in seconds). (I'm not sure if the value is signed or not, and if it has some range only by the draft). According to RFC 2461, the Valid lifetime of an IPv6 address through stateless autoconfiguration is an unsigned 32bits integer (in seconds), and the "all-1 value (0xffffffff)" has a special meaning, i.e. infinity. According to RFC 2181, the TTL value for a DNS record is an unsigned integer from 0 to 2^31 - 1. The easiest way to solve the ambiguity would be introduding an additional field for the TTL field to specify the type of TTL. However, this would break backward compatibility (again!)... Currently, I'm not sure the best way, but we'll surely need some clarification here. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Sep 10 23:42:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8B6fdr00664 for ipng-dist; Sun, 10 Sep 2000 23:41:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8B6fUH00657 for ; Sun, 10 Sep 2000 23:41:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA13718 for ; Sun, 10 Sep 2000 23:41:28 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA14606 for ; Sun, 10 Sep 2000 23:41:23 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id GA00800; Mon, 11 Sep 2000 17:40:30 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: iesg@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: Last Call: IPv6 Node Information Queries to Proposed Standard In-Reply-To: Your message of "Mon, 11 Sep 2000 02:19:31 +0900." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 Sep 2000 17:40:28 +1100 Message-Id: <27992.968654428@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 11 Sep 2000 02:19:31 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Message-ID: | The easiest way to solve the ambiguity would be introduding an | additional field for the TTL field to specify the type of | TTL. However, this would break backward compatibility (again!)... | Currently, I'm not sure the best way, but we'll surely need some | clarification here. Actually, the easiest way is just to define it as an unsigned integer (values 0 .. 2^32 - 1) - with 0xffffffff defined specially if needed. A negative TTL has no useful meaning, so even if the dhcpv6exts (the version with the '-' instead of the 'p' in the draft name expired ages ago) draft is intending to allow a negative value for the valid lease lifetime for some reason, sending 0 in the node information query would be reasonable if given negative input (though what a negative value would mean I have no idea .. "you should have returned this address I am just giving you 30 minutes ago" ?). That draft needs a better definition of this field. Then all rational TTL values can be included - the DNS can only handle half of what can be in the node information reply, but that's OK, what matters is that the DNS response can be loaded into the node info field, not the other way. 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 Mon Sep 11 08:27:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8BFQQW00883 for ipng-dist; Mon, 11 Sep 2000 08:26:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8BFQFH00876 for ; Mon, 11 Sep 2000 08:26:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA04274 for ; Mon, 11 Sep 2000 08:26:15 -0700 (PDT) Received: from ulexite.lion-access.net (ulexite.lion-access.net [212.19.217.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00427 for ; Mon, 11 Sep 2000 08:26:15 -0700 (PDT) Received: from joris (1Cust80.tnt8.rtm1.nl.uu.net [213.116.110.80]) by ulexite.lion-access.net (I-Lab) with SMTP id 562BEFAF39; Mon, 11 Sep 2000 14:26:00 -0100 (GMT) From: "Joris Dobbelsteen" To: "IPng WG (E-mail)" , "NAT WG (E-mail)" Subject: IPv6 and NAT Date: Mon, 11 Sep 2000 17:27:21 +0200 Message-ID: <000501c01c04$c94875f0$0d0aa8c0@THUIS.LOCAL> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Maybe an issue for the IPv6 and NAT Workgroups. NAT was proposed as a temporary solution for the shortage of IP address, which is solved with the IPv6 protocol. Currently I don't expect IPv6 to be deployed soon (within 1 or 2 years). My ISP, nor many ISPs, aren't promoting IPv6 yet, nor Microsoft provides IPv6 support for it's OSes. But as finally IPv6 has been deployed world-wide, what will we do with NAT? A disadvantage of NAT is that some protocols don't work good/correctly through NAT. Here NAT broke the principle of the Internet, where every node should be able to have bidirectional and end-to-end communication. FTP and many games require this to operate correctly. However, some scenarios where NAT provides THE solution, are for * private networks that may not be exposed to the Internet and * for networks that have only one IP address available to use on the Internet, while host on the private network are required to make 'direct' connections to the Internet. I don't think NAT should be made obsolete or unneeded after IPv6 has been deployed, but rather to be offered for some purposes on small and home networks. Most companies and bussinesses (even small ones) will be able to afford a dedicated Internet Connection with a couple IP addresses, esspecially after IPv6 has been deployed. However I don't expect my ISP to provide me more than one IP address, because I don't have a dedicated connection (yet) and I even haven't got one static IP address (just DHCP). Also I want to separate 'MY' network from the Internet, and don't install more network adapters into computers and lay networking cable than needed. This requirement without having to make strange configurations to any other computers on the network. That's what's so good about NAT, from my point of view.... - Joris -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 09:06:52 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8BG5Sx00999 for ipng-dist; Mon, 11 Sep 2000 09:05:28 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8BG5KH00992 for ; Mon, 11 Sep 2000 09:05:20 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA12790 for ; Mon, 11 Sep 2000 09:05:19 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA25076 for ; Mon, 11 Sep 2000 09:05:19 -0700 (PDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Sep 2000 09:05:18 -0700 (Pacific Daylight Time) Received: by INET-IMC-02 with Internet Mail Service (5.5.2651.58) id ; Mon, 11 Sep 2000 09:05:16 -0700 Message-ID: From: Christian Huitema To: "'Joris Dobbelsteen'" , "IPng WG (E-mail)" , "NAT WG (E-mail)" Subject: RE: IPv6 and NAT Date: Mon, 11 Sep 2000 09:05:09 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > NAT was proposed as a temporary solution for the shortage of > IP address, > which is solved with the IPv6 protocol. Currently I don't > expect IPv6 to be > deployed soon (within 1 or 2 years). My ISP, nor many ISPs, > aren't promoting > IPv6 yet, nor Microsoft provides IPv6 support for it's OSes. Well, actually, Microsoft's support is documented at: * Microsoft IPv6 Tech Preview News http://www.microsoft.com/PressPass/press/2000/Mar00/IPv6PR.asp * Microsoft IPv6 Tech Preview Kit http://msdn.microsoft.com/downloads/sdks/platform/tpipv6.asp * Microsoft IPv6 white paper http://www.microsoft.com/technet/network/ipvers6.asp but let's go to your actual points: > However, some scenarios where NAT provides THE solution, are for > * private networks that may not be exposed to the Internet and > * for networks that have only one IP address available to use on the > Internet, > while host on the private network are required to make > 'direct' connections > to the Internet. IPv6 supports "private networks that may not be exposed to the Internet" through the use of scoped addresses, i.e. "site-local" and "link-local" addresses. This covers most of the cases in which some dumb hosts are allowed to connect to the network but not to the Internet. For example, if you have a light-switch that should not be activated by remote players, that light-switch should be configued to only use site-local and link-local addresses. It will never receive a packet from outside the network, nor send a packet to the outside. I don't really understand how your hypothesis of "networks that have only one IP address available" fit with the other statement, "for the shortage of IP address, which is solved with the IPv6 protocol..." -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 11 09:56:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8BGtAC01159 for ipng-dist; Mon, 11 Sep 2000 09:55:10 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8BGt5H01152 for ; Mon, 11 Sep 2000 09:55:06 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e8BGsfG02379 for ipng@sunroof.eng.sun.com; Mon, 11 Sep 2000 09:54:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e871kOH27987; Wed, 6 Sep 2000 18:46:25 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA20889; Wed, 6 Sep 2000 18:46:24 -0700 (PDT) From: cfp@jp.ipv6forum.com Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA08805; Wed, 6 Sep 2000 18:46:23 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id KAA17726; Thu, 7 Sep 2000 10:46:21 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA14905; Thu, 7 Sep 2000 10:46:20 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id KAA12382; Thu, 7 Sep 2000 10:46:19 +0900 (JST) Date: Thu, 07 Sep 2000 10:47:01 +0900 (JST) Message-Id: <20000907.104701.71162403.kazu@Mew.org> To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com Subject: The Global IPv6 Summit in Japan X-Mailer: Mew version 1.95b57 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, "The Global IPv6 Summit in Japan" will be held in the next week of IETF San-Diego. Presentations/Panels are spoken in Japanese but we will prepare translators between Japanese and English. We would like to call for your participation. We prepare a session called "Business report on IPv6 around the world". This would be a good chance for your company to appeal your business strategy on IPv6. We would also like to call for your presentation. See you in Osaka. // Global IPv6 Summit in Japan Steering Group ---- Call for participations and presentations for "The Global IPv6 Summit in Japan" <> The Global IPv6 Summit, under the organization of the IPv6 Forum, is held regularly around the world to accelerate the deployment of IPv6. We are happy to announce that this conference will be held in Japan, one of the leading countries in the areas of IPv6 development and deployment. The Internet is built on the foundations of the Internet Protocol (IP). The current version of IP is named IPv4 after its version number. The total number of devices that IPv4 can identify is limited to about 4.3 billion. It's hard to see the Internet becoming the foundation of a true, universal communications infrastructure when this number is compared to the human population. In fact, it is expected that the entire address space of IPv4 will be exhausted by around 2008. So, address assignment/allocation is currently being carried out under a very restrictive policy. NAT (Network Address Translator) was introduced as a temporary solution, resulting in the loss of some of the original functionality of the Internet. The principles of the Internet are end-to-end and bidirectional communication. This means every node can communicate with every other freely without any restrictions caused by intermediate nodes. Since NAT broke these principles, it became difficult for unexpected novel applications to appear in the current environment of the Internet. To resolve the exhaustion of IP addresses, extending its address space is a straightforward solution. IPv6, the next generation of IP, provides a huge number of IP addresses and makes NAT obsolete allowing the Internet to recover its original principles. IPv6 is a paradigm recovery for applications. After deploying IPv6 and recovering end-to-end/bidirectional communication, we cannot imagine what kind of applications will appear. This conference will introduce the current deployment status of IPv6 throughout the world. Also, panel discussions are planned, both on "How IPv6 will Change Business" and on "Case Studies: Making the Change to IPv6". Getting Internet people together, including those who are involved in IPv6 activities and IPv4 business and management, we intend to discuss the future of Internet business and the direction of engineering. This conference will be beneficial for everyone including, but not limited to, engineers, researchers, network managers and business people. We would like to invite each of you to participate. <> Global IPv6 Summit in Japan Steering Group (Contact: info@jp.ipv6forum.com) <> Date: December 18 - 19, 2000 (As a part of Internet Week 2000) Venue: Grand Cube Osaka (Osaka International Convention Center) 5-3-51, Nakanoshima, Kita-ku, Osaka 530-0005, JAPAN Phone: +81-6-4803-5555 Fax: +81-6-4803-5620 E-mail: soumu@gco.co.jp http://www.gco.co.jp/index.html (The same place as Internet Week 2000) <> Early registration Regular/ discount On-site registration (until Oct 31) Non-student 10,000 JPY 15,000 JPY Student 2,000 JPY 2,000 JPY Non-student 5,000 JPY Student 3,000 JPY <> December 18 (Mon) Keynote Speech 1: Dr. Jun Murai, WIDE Project Session 1: Business report on IPv6 in Japan Session 2: Status report from Asian countries Session 3: Panel on how IPv6 will change business Reception December 19 (Tue) Keynote Speech 2: Dr. Steve Deering, Cisco Systems Session 4: Business report on IPv6 around the world Session 5: Case Studies: Making the Change to IPv6 <> This conference will be held as a part of Internet Week 2000. Please refer to the following page for registration: http://www.jp.ipv6forum.com/ <> The program committee calls for presentation proposal for "Session 4: Business report of IPv6 in foreign contrives". Candidates are sTLA holders and IPv6 vendors. Please propose a "10 minutes" presentation on your IPv6 business. If you would like to give a presentation, please send an e-mail message in the following form. Please note that we may not accept all proposal due to the time limitations of the program. Format: See below Deadline: September 30, 2000 Notification date: October 6, 2000 To: cfp@jp.ipv6forum.com Subject: presentation proposal Name : Title : Email : Telephone number: Organization : Department : Your proposal in plain text (no more than 250 words) explaining as concretely as possible your point of view and what kind of presentation can be expected. ---- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 09:57:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8BGtv201177 for ipng-dist; Mon, 11 Sep 2000 09:55:57 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8BGtnH01166 for ; Mon, 11 Sep 2000 09:55:49 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e8BGtPd02408 for ipng@sunroof.eng.sun.com; Mon, 11 Sep 2000 09:55:25 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e879TMH28293 for ; Thu, 7 Sep 2000 02:29:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA23697 for ; Thu, 7 Sep 2000 02:29:21 -0700 (PDT) Received: from ew.mimos.my (ew.mimos.my [192.228.129.34]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA27987 for ; Thu, 7 Sep 2000 02:29:21 -0700 (PDT) Received: from mimos.my (s134175.mimos.my [192.228.134.175]) by ew.mimos.my (8.9.3/8.9.3) with ESMTP id RAA24160; Thu, 7 Sep 2000 17:29:16 +0800 (MYT) Message-ID: <39B7653F.154B44CA@mimos.my> Date: Thu, 07 Sep 2000 17:52:00 +0800 From: Raja Azlina X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: 6bone@isi.edu Subject: HELP: Routing question Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We are a subNLA(::/44) with no downstreams(leaf-sites) connected to us just yet. All these while, we are connected to pTLAs that either advertise for us their own prefix(::/24) or the 6bone prefix(::/16). What I don't understand is the advantages/disadvantages of either advertising only certain perfix or the otherwise. What is the impact of doing so to us as well as the 6bone commnunity? I know one's policy determines its bgp4 configuration, but I wish someone could tell me the best current practice of running bgp4+ these days. Appreciate all the help. Thanks in advance. regards, ~~azlina -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 10:01:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8BH0rB01215 for ipng-dist; Mon, 11 Sep 2000 10:00:53 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8BH0nH01208 for ; Mon, 11 Sep 2000 10:00:49 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e8BH0PY02441 for ipng@sunroof.eng.sun.com; Mon, 11 Sep 2000 10:00:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e88JwaH29372 for ; Fri, 8 Sep 2000 12:58:36 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA19903 for ; Fri, 8 Sep 2000 12:58:35 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23846 for ; Fri, 8 Sep 2000 12:58:35 -0700 (PDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 8194D1E2D; Fri, 8 Sep 2000 15:58:34 -0400 (EDT) Received: from exctay-gh02.tay.cpqcorp.net (exctay-gh02.tay.cpqcorp.net [16.103.129.52]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 6D5621E65 for ; Fri, 8 Sep 2000 15:58:34 -0400 (EDT) Received: by exctay-gh02.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Fri, 8 Sep 2000 15:58:33 -0400 Message-ID: From: "Powell, Ken" To: "'richdr@microsoft.com'" , ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-addr-select-01 comments Date: Fri, 8 Sep 2000 15:58:27 -0400 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, I reviewed your "Default Address Selection for IPv6" draft. I have some concerns/questions on the algorithms and what the document requires implementations to support. Details below. Ken Page 2, Section 1 last paragraph: "The rules specified in this document MUST NOT be construed to override an application or upper-layer's explicit choice of destination or source address." Is an implementation allowed to sanity check an application's source/destination address choices based on criteria like those defined in section 3 and reject such selections as invalid? I believe this requirement leaves the option open, but wanted to be sure. Page 3, Section 2 The discussion of where different parts of this spec map into the API is very helpful. If I understand this correctly, destination address selection is done during the call to getaddrinfo or getipnodebyname. The destination address selection algorithm uses the source address selection algorithm. An important parameter to source address selection is the interface. Given what invokes destination address selection, the interface is not known. Later on, an implementation is likely to invoke source address selection again as the result of a connect or sendto call. This time the interface is known. It was either specified by the application or determined through a routing table lookup. The previously chosen destination address could easily be wrong for the interface. This all leads to the concern that destination address selection goes to great lengths to get the best address but is hobbled by missing prior knowledge of the interface. Page 5, Section 2.4 "IPv6 implementations SHOULD support configurable address selection via a mechanism at least as powerful as the policy tables defined here." I do not understand why this is a "SHOULD" requirement today. These tables are very interesting and I can see their power and use, but they seem to add little practical value without a management infrastructure capable of downloading a common set of rules to all nodes in a site. I believe making this table configurable should be defined as optional. Also, support for the Label and MatchSrcLabel mechanisms in particular should be optional. Page 5, Section 2.4 The default policy table treats IPv4 Mapped addresses that fall within the "autonet" and rfc 1918's private address ranges as special, with a higher priority than the other IPv4 mapped addresses. Is there a similar mechanism in current IPv4 implementations? If not, could this additional feature possibly change the behavior of applications that were ported to IPv6 in unexpected ways? Page 6, Section 3 Should an additional restriction like the following be added to the candidate set of source addresses? "For IPv4 Mapped destination addresses, the set of candidate source addresses must only include IPv4 Mapped addresses. For any other destination address, the set of candidate source addresses MUST NOT include IPv4 Mapped addresses." Should use of the loopback destination restrict the source address to be loopback also? Page 6, Section 4 "Rule 2, Prefer Matching Label" seems to be given too much weight over other criteria. For example, if the destination is a 6to4 addresses, this rule will cause a deprecated 6to4 address to be chosen as the source over a preferred global address. If your 6to4 address is deprecated, chances are its time to stop using it. Your site is probably switching over to global addresses and the 6to4 address is going away. Page 7, Section 4 "Rule 3, Prefer appropriate scope" is complex and aught to be broken into two rules with rule 4 in the middle like: Rule 3a: Avoid insufficient scope for destination. (i.e., avoid Scope Source < Scope Dest) Rule 4: Avoid deprecated addresses. Rule 3b: Prefer closest scope. If both SA and SB are of sufficient scope, choose the one with lower scope. If both SA abd SB are if insufficient scope, choose the one with higher scope. Page 7, Section 4 "Rule 8 MAY be superceded if the implementation has other means of choosing among source addresses. For example, if the implementation somehow knows which source address will result in the "best" communications performance." I think limiting implementation specific tests to supercede only Rule 8 is overly restrictive. We cannot predict how useful future implementation specific tests may be for improving efficiency or avoiding connectivity problems. Implementations should be allowed to inject their own tests anywhere in the list of rules. Page 7, Section 4 "The pair-wise comparison consists of eight rules, which MUST be applied in order." Is it mandatory to implement all these rules? I don't see why every implementation has to implement longest matching prefix for example. Could you break the list down and identify which rules MUST, SHOULD, and MAY be implemented? The requirement of order seems overly restrictive too. A brief list of the source address selection rules (with my rule 3 suggestion) gives: Rule 1: Prefer same address Rule 2: Prefer matching label Rule 3a: Avoid insufficient scope Rule 4: Avoid deprecated addresses Rule 3b: Prefer lower scope Rule 5: Prefer home address Rule 6: Prefer outgoing interface Rule 7: Prefer anonymous addresses Rule 8: Use longest matching prefix Rule X: Implementation defined test I tend to divide these rules into the following groups: A) Rule 1. This is an important diagnostic feature that makes sense where it is. B) Rules 3a, 4, and 5. There is a good chance communication will fail if any of these rules are broken. C) Rules 2, 3b, 6, 7, 8, and X seem to exist mostly for efficiency or privacy enhancements. I don't think we know enough to predict which of these rules will prove more important to customers. For example, some customers may get annoyed that their system selected a 6to4 address over a global anonymous address simply because the destination was a 6to4 address. Would it make sense to specify groups of rules, where one group MUST be applied before the other, then RECOMMEND the order of rules within each group where order really isn't important to interoperability? Page 8, Section 5 It seems possible that some destination addresses could end up with no candidate source addresses. Should a rule be added at the top to avoid destinations with no candidate source address? Page 8, Section 5 "The pair-wise comparison of destination addresses consists of four rules, which MUST be applied in order." A summary of the rules is: Rule 1: Prefer destination with matching source Rule 2: Prefer destination with higher precedence Rule 3: Use longest matching prefix Rule 4: Use order returned by name service Same questions as above for source address selection: Is it mandatory to implement all these rules? Is the order really critical for interoperability? Please be more specific on what MUST, SHOULD, and MAY be done. Page 8, Section 5 "The third and fourth rules MAY be superceded if the implementation has other means of sorting destination addresses." Same question as above for source address selection. Why limit this just to the third and fourth rules? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 10:50:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8BHn1q01412 for ipng-dist; Mon, 11 Sep 2000 10:49:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8BHmqH01405 for ; Mon, 11 Sep 2000 10:48:53 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA07995 for ; Mon, 11 Sep 2000 10:48:51 -0700 (PDT) Received: from rubellite.lion-access.net (rubellite.lion-access.net [212.19.217.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10473 for ; Mon, 11 Sep 2000 10:48:50 -0700 (PDT) Received: from joris (1Cust227.tnt4.rtm1.nl.uu.net [213.116.102.227]) by rubellite.lion-access.net (I-Lab) with SMTP id 051AE283E; Mon, 11 Sep 2000 17:48:30 +0000 (GMT) From: "Joris Dobbelsteen" To: "IPng WG (E-mail)" , "NAT WG (E-mail)" Subject: RE: (NAT) IPv6 and NAT Date: Mon, 11 Sep 2000 19:49:19 +0200 Message-ID: <000801c01c18$9e67ced0$0d0aa8c0@THUIS.LOCAL> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: <006a01c01c10$161715c0$adfb10ac@francislaptop> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Looks like a *dame* stupid question, so I suppose it is.... However I will explain why I actually did ask this: Maybe I don't explain things to good (my english sucks at this point).... Assume i'm just an ordinary home(!) user that dials (with a 50Kbps modem) to an (free) ISP and requests IP addresses using DHCP, you get only ONE, not a subnet (such account I don't have and can't afford: it ain't free, so far I know). So I don't benefit from the 64K (or at least 4 Internet IP addresses).... Now I do have a (little) computer network, that must be connected to the Internet. Installing a HTTP proxy works fine for HTTP, FTP and Gopher. SMTP and POP3 can also be solved (with some more clever software). SOCKS can handle clients that support that (like ICQ, etc). BUT what about my software that does not support this, such as SOCKS??? Things like this are the problem, the - lets call it - 'bad' software... On my current network NAT would solve this problem, what should I do when I have IPv6 deployed? Matt, I will read the docs you given (today, 11th, I'm to busy) Christian, I will look at MS its docs (and downloads)... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 11 10:57:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8BHu1l01447 for ipng-dist; Mon, 11 Sep 2000 10:56:01 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8BHtqH01440 for ; Mon, 11 Sep 2000 10:55:52 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA28955 for ; Mon, 11 Sep 2000 10:55:51 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA08182 for ; Mon, 11 Sep 2000 11:55:49 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e8BHtdu29736; Mon, 11 Sep 2000 19:55:40 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA01208; Mon, 11 Sep 2000 19:55:39 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA80175; Mon, 11 Sep 2000 19:56:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200009111756.TAA80175@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Joris Dobbelsteen" cc: "IPng WG (E-mail)" , "NAT WG (E-mail)" Subject: Re: IPv6 and NAT In-reply-to: Your message of Mon, 11 Sep 2000 17:27:21 +0200. <000501c01c04$c94875f0$0d0aa8c0@THUIS.LOCAL> Date: Mon, 11 Sep 2000 19:56:40 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: nor Microsoft provides IPv6 support for it's OSes. => this is no more true! However, some scenarios where NAT provides THE solution, are for * private networks that may not be exposed to the Internet and => if you don't need a connection to the Internet then you don't even need a NAT: I don't understand your point. * for networks that have only one IP address available to use on the Internet, => with IPv6 you can have near as many addresses as you'd like. The restriction to one dynamic IP address should vanish (even if it is based on not technical reasons). I don't think NAT should be made obsolete or unneeded after IPv6 has been deployed, but rather to be offered for some purposes on small and home networks. => I disagree. IPv6 is here in order to help small and home network users too. In fact this is very important to explain to them (even I don't know how) that IPv6 will help them (in general they know they have a problem but they don't know good (ie. not NAT) solutions). Most companies and bussinesses (even small ones) will be able to afford a dedicated Internet Connection with a couple IP addresses, especially after IPv6 has been deployed. => I still cannot find a technical reason to get only a couple of addresses. However I don't expect my ISP to provide me more than one IP address, because I don't have a dedicated connection (yet) and I even haven't got one static IP address (just DHCP). => IMHO there are two reasons to have dynamic addresses: - the main one (well known but not technical, ie. irrelevant to these lists) - the lack of addresses (ie. use one address per modem, not one address per customer). This one will disappear with IPv6! That's what's so good about NAT, from my point of view.... => we cannot convince everybody that NAT is the devil (:-) but I have noted NATs are not sold to small and home network users as NATs, they are named masquerade devices, smart gateways, ... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 12 07:43:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8CEfsJ02202 for ipng-dist; Tue, 12 Sep 2000 07:41:54 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8CEffH02187 for ; Tue, 12 Sep 2000 07:41:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA29233 for ; Tue, 12 Sep 2000 07:41:35 -0700 (PDT) Received: from lepidachrosite.lion-access.net (lepidachrosite.lion-access.net [212.19.217.3]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19205 for ; Tue, 12 Sep 2000 07:41:34 -0700 (PDT) Received: from joris (1Cust69.tnt16.rtm1.nl.uu.net [213.116.126.69]) by lepidachrosite.lion-access.net (I-Lab) with SMTP id 6A5B1CAEA1 for ; Tue, 12 Sep 2000 14:41:16 +0000 (GMT) From: "Joris Dobbelsteen" To: "IPng WG (E-mail)" Subject: RE: IPv6 and NAT Date: Tue, 12 Sep 2000 16:43:05 +0200 Message-ID: <000d01c01cc7$c64febd0$0d0aa8c0@THUIS.LOCAL> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200009111756.TAA80175@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Francis Dupont > Sent: maandag 11 september 2000 19:57 > To: Joris Dobbelsteen > Cc: IPng WG (E-mail); NAT WG (E-mail) > Subject: Re: IPv6 and NAT > > > In your previous mail you wrote: > > nor Microsoft provides IPv6 support for it's OSes. > > => this is no more true! How whould it be explained that IPv6 (from MS) is only a TECHNICAL PREVIEW for WINDOWS 2000 ONLY??? Without any (GUI) support for configuration, no support for dial-up and VPN connections and lack of support for routing with e.g. RRAS??? With NO SUPPORT I mean, NO official final release of a driver to support IPv6 for ALL Windows Platforms: Windows 95/98/ME/NT/2000... - Joris > > Regards > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 12 09:12:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8CGB7q02336 for ipng-dist; Tue, 12 Sep 2000 09:11:07 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8CGAwH02329 for ; Tue, 12 Sep 2000 09:10:59 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA10035 for ; Tue, 12 Sep 2000 09:10:58 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27920 for ; Tue, 12 Sep 2000 09:10:54 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.20.136.32) by smtp2.libero.it; 12 Sep 2000 18:10:36 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id ED8DB4D6CB; Tue, 12 Sep 2000 11:27:30 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id E8BDD4D6C4; Tue, 12 Sep 2000 11:27:30 +0200 (CEST) Date: Tue, 12 Sep 2000 11:27:30 +0200 (CEST) From: Mauro Tortonesi To: IETF - IPng Working Group Cc: project6-devel@ferrara.linux.it Subject: getaddrinfo Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi, i have a question about the getaddrinfo function. first, suppose that the nodename argument is a numeric host address and the flag AI_NUMERICHOST is not set. will the query to getaddrinfo return ALL addresses of that host? IMHO it should, but draft-...-rfc2553bis-00 is not very clear about this. it only states that AI_NUMERICHOST prevents the DNS from being invoked, so i guess that if AI_NUMERICHOST is not set, then a query to the resolution service MUST be made, even if nodename is a numeric host address. there is also one more problem i'd like to talk about. in order to have a stable and standard api, rfc2553bis and XNET specifications should not be contradictory. i know at least one big implementation that is unwilling to support rfc2553bis because it does not follow XNET specs. this is a serious problem IMO. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.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 Sep 12 10:32:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8CHUhN02430 for ipng-dist; Tue, 12 Sep 2000 10:30:43 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8CHUcH02423 for ; Tue, 12 Sep 2000 10:30:38 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e8CHUCl03019 for ipng@sunroof.eng.sun.com; Tue, 12 Sep 2000 10:30:12 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8BG6NH01001 for ; Mon, 11 Sep 2000 09:06:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA07479 for ; Mon, 11 Sep 2000 09:06:23 -0700 (PDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26175 for ; Mon, 11 Sep 2000 09:06:22 -0700 (PDT) Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA26324; Mon, 11 Sep 2000 09:02:57 -0700 (PDT) Received: from spandex (rtp-dial-2-211.cisco.com [10.83.96.211]) by mira-sjc5-4.cisco.com (Mirapoint) with SMTP id ACN01164; Mon, 11 Sep 2000 09:15:50 -0700 (PDT) Message-ID: <00ce01c01c22$d5a80cc0$11e2130a@spandex> From: "Melinda Shore" To: "Joris Dobbelsteen" , "IPng WG (E-mail)" , "NAT WG (E-mail)" References: <000501c01c04$c94875f0$0d0aa8c0@THUIS.LOCAL> Subject: Re: (NAT) IPv6 and NAT Date: Mon, 11 Sep 2000 12:02:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Joris Dobbelsteen >To: IPng WG (E-mail) ; NAT WG (E-mail) > >Sent: Monday, September 11, 2000 8:27 AM >Subject: (NAT) IPv6 and NAT > I don't think NAT should be made obsolete or unneeded after IPv6 has been > deployed, but rather to be offered for some purposes on small and home > networks. A couple of things: 1) I don't think that anybody is in the position of being able to mandate NAT out of existence - if service providers/network operators feel that there's justification for continuing to translate addresses, they will do just that 2) In voice services there's a requirement to be able to hide calling party addresses on a policy basis. NAT is one way to effect this (although arguably not the best, given the numerous problems it causes). A few people in the voice community are claiming, however, that no terminal should have a public IP address and that there should be "address policy domains." I don't find their arguments for it particularly compelling and I'm not even going to try to represent them, but my guess is that this is going to be an argument we'll be having in a year or so. At any rate, I think that point 1 above is the salient one. Melinda -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 12 10:32:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8CHUKJ02421 for ipng-dist; Tue, 12 Sep 2000 10:30:20 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8CHUGH02414 for ; Tue, 12 Sep 2000 10:30:16 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e8CHTnk02990 for ipng@sunroof.eng.sun.com; Tue, 12 Sep 2000 10:29:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8BG0kH00980 for ; Mon, 11 Sep 2000 09:00:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA11622 for ; Mon, 11 Sep 2000 09:00:46 -0700 (PDT) Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA13113 for ; Mon, 11 Sep 2000 09:00:45 -0700 (PDT) Received: from MATT.ascend.com (ts011d08.lap-ca.concentric.NET [64.1.212.20]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id R9Z2LNT6; Mon, 11 Sep 2000 09:00:44 -0700 Message-Id: <4.3.1.2.20000911085544.00bfacf0@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 11 Sep 2000 09:00:58 -0700 To: "Joris Dobbelsteen" From: Matt Holdrege Subject: Re: (NAT) IPv6 and NAT Cc: "IPng WG (E-mail)" , "NAT WG (E-mail)" In-Reply-To: <000501c01c04$c94875f0$0d0aa8c0@THUIS.LOCAL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joris, Before you post to these groups, it would be a real good idea to read some of the RFC's and Drafts that have been produced on this topic. Specifically, you should read http://www.ietf.org/internet-drafts/draft-iab-nat-implications-09.txt and http://www.ietf.org/internet-drafts/draft-ietf-nat-protocol-complications-04.txt At 05:27 PM 9/11/00 +0200, Joris Dobbelsteen wrote: >Maybe an issue for the IPv6 and NAT Workgroups. > >NAT was proposed as a temporary solution for the shortage of IP address, >which is solved with the IPv6 protocol. Currently I don't expect IPv6 to be >deployed soon (within 1 or 2 years). My ISP, nor many ISPs, aren't promoting >IPv6 yet, nor Microsoft provides IPv6 support for it's OSes. >But as finally IPv6 has been deployed world-wide, what will we do with NAT? > >A disadvantage of NAT is that some protocols don't work good/correctly >through NAT. Here NAT broke the principle of the Internet, where every node >should be able to have bidirectional and end-to-end communication. FTP and >many games require this to operate correctly. > >However, some scenarios where NAT provides THE solution, are for >* private networks that may not be exposed to the Internet and >* for networks that have only one IP address available to use on the >Internet, >while host on the private network are required to make 'direct' connections >to the Internet. > >I don't think NAT should be made obsolete or unneeded after IPv6 has been >deployed, but rather to be offered for some purposes on small and home >networks. Most companies and bussinesses (even small ones) will be able to >afford a dedicated Internet Connection with a couple IP addresses, >esspecially after IPv6 has been deployed. >However I don't expect my ISP to provide me more than one IP address, >because I don't have a dedicated connection (yet) and I even haven't got one >static IP address (just DHCP). Also I want to separate 'MY' network from the >Internet, and don't install more network adapters into computers and lay >networking cable than needed. This requirement without having to make >strange configurations to any other computers on the network. > > >That's what's so good about NAT, from my point of view.... > > > >- Joris > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe nat' in the body of the message. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 12 10:35:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8CHYBC02474 for ipng-dist; Tue, 12 Sep 2000 10:34:11 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8CHY6H02467 for ; Tue, 12 Sep 2000 10:34:07 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e8CHXea03056 for ipng@sunroof.eng.sun.com; Tue, 12 Sep 2000 10:33:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8BGVRH01082 for ; Mon, 11 Sep 2000 09:31:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA21850 for ; Mon, 11 Sep 2000 09:31:27 -0700 (PDT) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA07598 for ; Mon, 11 Sep 2000 09:31:26 -0700 (PDT) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 11 Sep 2000 09:30:32 -0700 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 11 Sep 2000 09:31:05 -0700 (Pacific Daylight Time) Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2023); Mon, 11 Sep 2000 09:30:40 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: (NAT) IPv6 and NAT Date: Mon, 11 Sep 2000 09:27:50 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (NAT) IPv6 and NAT Thread-Index: AcAcBw/npJ3Y0GmVRj6YQLXC7qN+QwAA79sQ From: "Tony Hain" To: "Joris Dobbelsteen" , "IPng WG (E-mail)" , "NAT WG (E-mail)" X-OriginalArrivalTime: 11 Sep 2000 16:30:40.0543 (UTC) FILETIME=[9FACD2F0:01C01C0D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id e8BGVSH01083 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just to clarify, NAT does not provide isolation from the Internet, route filtering does that. The inbound filtering that happens is a function of lack of a route in the NAT, not the fact it is translating addresses. IPv6 has a defined function for this, called Site Local. These addresses are filtered at the site boundary router, providing more security than 'where is this port mapped to now?' functions. It is expected that ISPs will be allocating /48 to customers, and for those that don't support IPv6 the IPv4 address provides a /48 using 6to4. With 64k subnets available there should be no reason to build perverse configurations, and no need for translating the addresses. As you note many things do not work correctly without end-to-end address integrity, so why preclude them by continuing down the NAT path? Each of the items you list as values are solved in a cleaner way by IPv6 so just move to it. Tony While I am the Program Manager for IPv6 at Microsoft, the above comments are mine and should not be construed as related to my employer. -----Original Message----- From: Joris Dobbelsteen [mailto:joris.dobbelsteen@mail.com] Sent: Monday, September 11, 2000 8:27 AM To: IPng WG (E-mail); NAT WG (E-mail) Subject: (NAT) IPv6 and NAT Maybe an issue for the IPv6 and NAT Workgroups. NAT was proposed as a temporary solution for the shortage of IP address, which is solved with the IPv6 protocol. Currently I don't expect IPv6 to be deployed soon (within 1 or 2 years). My ISP, nor many ISPs, aren't promoting IPv6 yet, nor Microsoft provides IPv6 support for it's OSes. But as finally IPv6 has been deployed world-wide, what will we do with NAT? A disadvantage of NAT is that some protocols don't work good/correctly through NAT. Here NAT broke the principle of the Internet, where every node should be able to have bidirectional and end-to-end communication. FTP and many games require this to operate correctly. However, some scenarios where NAT provides THE solution, are for * private networks that may not be exposed to the Internet and * for networks that have only one IP address available to use on the Internet, while host on the private network are required to make 'direct' connections to the Internet. I don't think NAT should be made obsolete or unneeded after IPv6 has been deployed, but rather to be offered for some purposes on small and home networks. Most companies and bussinesses (even small ones) will be able to afford a dedicated Internet Connection with a couple IP addresses, esspecially after IPv6 has been deployed. However I don't expect my ISP to provide me more than one IP address, because I don't have a dedicated connection (yet) and I even haven't got one static IP address (just DHCP). Also I want to separate 'MY' network from the Internet, and don't install more network adapters into computers and lay networking cable than needed. This requirement without having to make strange configurations to any other computers on the network. That's what's so good about NAT, from my point of view.... - Joris - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe nat' in the body of the message. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 12 10:38:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8CHZLx02489 for ipng-dist; Tue, 12 Sep 2000 10:35:21 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8CHZDH02482 for ; Tue, 12 Sep 2000 10:35:14 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e8CHYkD03085 for ipng@sunroof.eng.sun.com; Tue, 12 Sep 2000 10:34:46 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8BGq4H01108 for ; Mon, 11 Sep 2000 09:52:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA27802 for ; Mon, 11 Sep 2000 09:52:03 -0700 (PDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA00249 for ; Mon, 11 Sep 2000 10:52:02 -0600 (MDT) Received: from francislaptop ([208.176.6.221]) by mta5.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0G0Q00LBLEMX3R@mta5.snfc21.pbi.net> for ipng@sunroof.eng.sun.com; Mon, 11 Sep 2000 09:47:22 -0700 (PDT) Date: Mon, 11 Sep 2000 09:48:17 -0700 From: Paul Francis Subject: Re: (NAT) IPv6 and NAT To: Melinda Shore , Joris Dobbelsteen , "IPng WG (E-mail)" , "NAT WG (E-mail)" Reply-to: Paul Francis Message-id: <006a01c01c10$161715c0$adfb10ac@francislaptop> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 References: <000501c01c04$c94875f0$0d0aa8c0@THUIS.LOCAL> <00ce01c01c22$d5a80cc0$11e2130a@spandex> X-Priority: 3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > I don't think NAT should be made obsolete or unneeded after > IPv6 has been > > deployed, but rather to be offered for some purposes on small > and home > > networks. > I predict that the use of IPv6-IPv6 NAT will be widespread, for the reason that most net admins will prefer NAT to renumbering. (Noting here that site-local addresses doesn't eliminate renumbering...you still will have to merge sites from time to time.) PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 12 10:49:07 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8CHlf302552 for ipng-dist; Tue, 12 Sep 2000 10:47:41 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8CHlaH02545 for ; Tue, 12 Sep 2000 10:47:36 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e8CHlAg03131 for ipng@sunroof.eng.sun.com; Tue, 12 Sep 2000 10:47:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8BI04H01470 for ; Mon, 11 Sep 2000 11:00:05 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA17393 for ; Mon, 11 Sep 2000 11:00:04 -0700 (PDT) Received: from lint.cisco.com (lint.cisco.com [171.68.224.209]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00857 for ; Mon, 11 Sep 2000 11:00:03 -0700 (PDT) Received: from cisco.com ([10.16.192.138] (may be forged)) by lint.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA20053; Mon, 11 Sep 2000 10:59:58 -0700 (PDT) Message-ID: <39BD1D8F.18BE3BA8@cisco.com> Date: Mon, 11 Sep 2000 10:59:43 -0700 From: Eliot Lear Reply-To: lear@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Joris Dobbelsteen CC: "IPng WG (E-mail)" , "NAT WG (E-mail)" Subject: Re: (NAT) IPv6 and NAT References: <000801c01c18$9e67ced0$0d0aa8c0@THUIS.LOCAL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk First, you probably don't realize what a storm you are treading into, and so let me suggest that this NOT become a flame fest. Technically speaking there is nothing that stops you from using NAT with IPv6. The issue remains the limitations it could cause you, should you choose to offer services from one of your workstations. Please read Tony Hain's document carefully. -- Eliot Lear lear@cisco.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 Sep 12 11:12:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8CIApF02609 for ipng-dist; Tue, 12 Sep 2000 11:10:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8CIAgH02602 for ; Tue, 12 Sep 2000 11:10:43 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA28093 for ; Tue, 12 Sep 2000 11:10:41 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA05560 for ; Tue, 12 Sep 2000 11:10:38 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id SA25205; Wed, 13 Sep 2000 05:10:29 +1100 (from kre@munnari.OZ.AU) From: Robert Elz To: Paul Francis Cc: ipng@sunroof.eng.sun.com Subject: Re: (NAT) IPv6 and NAT In-Reply-To: Your message of "Mon, 11 Sep 2000 09:48:17 PDT." <006a01c01c10$161715c0$adfb10ac@francislaptop> Date: Wed, 13 Sep 2000 05:10:28 +1100 Message-Id: <24275.968782228@mundamutti.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 11 Sep 2000 09:48:17 -0700 From: Paul Francis Message-ID: <006a01c01c10$161715c0$adfb10ac@francislaptop> | (Noting here that site-local addresses doesn't eliminate | renumbering...you still will have to merge sites from time to | time.) In that case, NAT doesn't help either - if the address spaces are to be merged, then there can't be any NAT between them. If the address spaces aren't being merged, then they can be considered to be two separate sites, each with their own site local. Nothing is ever going to eliminate the need for renumbering (not even very agressive NAT) - the best that can be done is to make it as painless as possible when it is needed. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 12 12:40:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8CJcvL02695 for ipng-dist; Tue, 12 Sep 2000 12:38:57 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8CJcrH02688 for ; Tue, 12 Sep 2000 12:38:53 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e8CJcPn03273 for ipng@sunroof.eng.sun.com; Tue, 12 Sep 2000 12:38:25 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8CJXjH02676 for ; Tue, 12 Sep 2000 12:33:46 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA23462 for ; Tue, 12 Sep 2000 12:33:41 -0700 (PDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26024 for ; Tue, 12 Sep 2000 12:33:41 -0700 (PDT) Received: from francislaptop ([208.176.6.221]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0G0S009XPE4MF7@mta6.snfc21.pbi.net> for ipng@sunroof.eng.sun.com; Tue, 12 Sep 2000 11:31:40 -0700 (PDT) Date: Tue, 12 Sep 2000 11:33:03 -0700 From: Paul Francis Subject: Re: (NAT) IPv6 and NAT To: Robert Elz Cc: ipng@sunroof.eng.sun.com Reply-to: Paul Francis Message-id: <005301c01ce7$e620b460$adfb10ac@francislaptop> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 References: <24275.968782228@mundamutti.cs.mu.OZ.AU> X-Priority: 3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > | (Noting here that site-local addresses doesn't eliminate > | renumbering...you still will have to merge sites from time to > | time.) > > In that case, NAT doesn't help either - if the address spaces are to > be merged, then there can't be any NAT between them. > No...what will happen is that the site internally uses some globally unique address space, but shields that space from renumbering by using NAT between it and its ISP(s). When two such numbered sites merge, there is no renumbering because each already uses a globally unique address space. I've sometimes wondered why IPv6 doesn't have some number space that is "globally unique but not globally routable" that could be used for packets internal to a site. PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 12 12:52:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8CJpRK02718 for ipng-dist; Tue, 12 Sep 2000 12:51:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8CJpGH02711 for ; Tue, 12 Sep 2000 12:51:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA12375 for ; Tue, 12 Sep 2000 12:51:11 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA03727 for ; Tue, 12 Sep 2000 12:51:11 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id OAA19497; Tue, 12 Sep 2000 14:51:05 -0500 (CDT) Message-Id: <200009121951.OAA19497@gungnir.fnal.gov> To: Paul Francis Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: (NAT) IPv6 and NAT In-reply-to: Your message of Tue, 12 Sep 2000 11:33:03 PDT. <005301c01ce7$e620b460$adfb10ac@francislaptop> Date: Tue, 12 Sep 2000 14:51:05 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I've sometimes wondered why IPv6 doesn't have some number space that is > "globally unique but not globally routable" that could be used for packets > internal to a site. How do you get people to do even epsilon paperwork to request such space? How do you deter them from just picking something in the block? (Or not in the block!) As long as you have an IPv4 address to call your own, you can do the 6to4 thing. But since you are likely not to "own" any IPv4 space, you can to the "pick and pray" thing with a random RFC 1918 address. Until your mergers and backdoor connections lump you in together with sqrt(2^24 + 2^20 + 2^16) ~= 4230 like-mindless organizations, you can expect to probably get away with it. Ugh. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 12 13:58:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8CKudv02756 for ipng-dist; Tue, 12 Sep 2000 13:56:39 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8CKuZH02749 for ; Tue, 12 Sep 2000 13:56:35 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e8CKu8N03316 for ipng@sunroof.eng.sun.com; Tue, 12 Sep 2000 13:56:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8CKcwH02735 for ; Tue, 12 Sep 2000 13:38:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA24871 for ; Tue, 12 Sep 2000 13:38:56 -0700 (PDT) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA11706 for ; Tue, 12 Sep 2000 14:38:54 -0600 (MDT) Received: from francislaptop ([208.176.6.221]) by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0G0S00KJMJRDTY@mta6.snfc21.pbi.net> for ipng@sunroof.eng.sun.com; Tue, 12 Sep 2000 13:34:08 -0700 (PDT) Date: Tue, 12 Sep 2000 13:34:43 -0700 From: Paul Francis Subject: Re: (NAT) IPv6 and NAT To: Matt Crawford Cc: ipng@sunroof.eng.sun.com Reply-to: Paul Francis Message-id: <007f01c01cf9$02230da0$adfb10ac@francislaptop> MIME-version: 1.0 X-Mailer: Microsoft Outlook Express 5.50.4133.2400 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 References: <200009121951.OAA19497@gungnir.fnal.gov> X-Priority: 3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > How do you get people to do even epsilon paperwork to request such > space? How do you deter them from just picking something in the > block? (Or not in the block!) The only way to deter (not prevent, of course, but deter) would be to make the space easy to come by...which in theory shouldn't be too hard because you wouldn't have to worry about making it aggregatable. You can hand out huge chunks of it to the good folks who today will gladly sell you your domain name, or to your friendly ISP... I guess my point, ultimately, is that the user community is going to pick their own poison. They don't find NAT to be very objectionable, so if you offer something that is *to them* worse than NAT (i.e. renumbering), you will have effectively promoted a NAT solution. PF -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 12 21:18:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8D432k02954 for ipng-dist; Tue, 12 Sep 2000 21:03:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8D42hH02947 for ; Tue, 12 Sep 2000 21:02:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA03316 for ; Tue, 12 Sep 2000 21:02:42 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA16685 for ; Tue, 12 Sep 2000 21:02:42 -0700 (PDT) Received: from endor.deas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id AAA29353 for ; Wed, 13 Sep 2000 00:02:36 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.deas.harvard.edu (8.8.8/8.8.8) id AAA13380 for ipng@sunroof.eng.sun.com; Wed, 13 Sep 2000 00:02:35 -0400 (EDT) Date: Wed, 13 Sep 2000 00:02:35 -0400 (EDT) Message-Id: <200009130402.AAA13380@endor.deas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: (NAT) IPv6 and NAT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk |> I've sometimes wondered why IPv6 doesn't have some number space that is |> "globally unique but not globally routable" that could be used for packets |> internal to a site. | |How do you get people to do even epsilon paperwork to request such |space? People seemed so willing to do such paperwork for non-routable v4 address space that is was supposedly necessary to make the process hard/expensive to discourage them from consuming it all. Offer the v6 space on the terms that v4 space was once available (i.e., free with nominal justification documentation) and I'm sure people will use it. Try to make these allocations another cash cow with yearly fees and, naturally, people will pick (poorly) random addresses that will later hurt them. The same argument applies to NAT. If ISPs make it expensive to get extra v6 addresses (based on the justification that addresses used to be scarce?) then people will use NAT with IPv6. If ISPs make "stable" v6 addresses (i.e., ones that they do not deliberately renumber frequently) a premium service then people will use NAT. Although the standard claim is that NAT breaks the end- to-end model we all like (and note that I have personally never liked NAT), NAT shines at preserving the stable-address model that is deeply embedded in many protocols and applications. NAT has already proved itself: many useful applications work just fine in spite of the loss of the end-to-end model. The renumbering model has yet to be proven, let alone retrofitted to many existing applications. I happen to think that ISPs will charge a premium for multiple and/or stable v6 addresses because that is the status quo and because the market will bear it. Thus, I suspect that NAT will remain quite active if/when IPv6 is deployed. I think this is unfortunate--again, I'm no fan of NAT--but it's probably too late to do anything. While it certainly would have been possible to structure IPv6 in such a way that end users could allocate identity addresses independent of their providers (I even made a hand-waving proposal to allow for this with relatively minor protocol modifications) there never seemed to be much interest. So the market pressures will continue to operate in an IPv6 environment just as they have in the IPv4 one. All IMHO, of course... Dan Lanciani ddl@harvard.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 Wed Sep 13 09:52:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8DGp4l03355 for ipng-dist; Wed, 13 Sep 2000 09:51:04 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8DGp0H03348 for ; Wed, 13 Sep 2000 09:51:00 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e8DGoWE03835 for ipng@sunroof.eng.sun.com; Wed, 13 Sep 2000 09:50:32 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8DCKEH03244 for ; Wed, 13 Sep 2000 05:20:14 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA15996 for ; Wed, 13 Sep 2000 05:20:13 -0700 (PDT) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20753 for ; Wed, 13 Sep 2000 05:20:13 -0700 (PDT) Received: by mail.kebne.se with Internet Mail Service (5.5.2448.0) id ; Wed, 13 Sep 2000 14:20:14 +0200 Message-ID: <31A473DBB655D21180850008C71E251A020B5F76@mail.kebne.se> From: Thomas Eklund To: Paul Francis , Matt Crawford Cc: ipng@sunroof.eng.sun.com Subject: RE: (NAT) IPv6 and NAT Date: Wed, 13 Sep 2000 14:20:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A few comments: ; Wed, 13 Sep 2000 13:59:32 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA01844 for ; Wed, 13 Sep 2000 13:59:30 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05227 for ; Wed, 13 Sep 2000 13:59:28 -0700 (PDT) Received: (from root@localhost) by mail.wrs.com (8.9.3/8.9.1) id NAA12322; Wed, 13 Sep 2000 13:59:27 -0700 (PDT) Received: from mail01-oak.pilot.net (mail-oak-1.pilot.net [198.232.147.16]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id VAA09785 for ; Tue, 12 Sep 2000 21:20:15 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by mail01-oak.pilot.net with ESMTP id VAA21116 for ; Tue, 12 Sep 2000 21:20:28 -0700 (PDT) Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA01045; Tue, 12 Sep 2000 22:20:00 -0600 (MDT) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA08388; Tue, 12 Sep 2000 21:19:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8D432k02954 for ipng-dist; Tue, 12 Sep 2000 21:03:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8D42hH02947 for ; Tue, 12 Sep 2000 21:02:48 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA03316 for ; Tue, 12 Sep 2000 21:02:42 -0700 (PDT) Received: from minuet.das.harvard.edu (minuet.das.harvard.edu [140.247.50.251]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA16685 for ; Tue, 12 Sep 2000 21:02:42 -0700 (PDT) Received: from endor.deas.harvard.edu (endor.harvard.edu [128.103.50.55]) by minuet.das.harvard.edu (8.9.1/8.9.1) with ESMTP id AAA29353 for ; Wed, 13 Sep 2000 00:02:36 -0400 (EDT) From: Dan Lanciani Received: (from ddl@localhost) by endor.deas.harvard.edu (8.8.8/8.8.8) id AAA13380 for ipng@sunroof.eng.sun.com; Wed, 13 Sep 2000 00:02:35 -0400 (EDT) Date: Wed, 13 Sep 2000 00:02:35 -0400 (EDT) Message-Id: <200009130402.AAA13380@endor.deas.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: (NAT) IPv6 and NAT Content-Type: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk |> I've sometimes wondered why IPv6 doesn't have some number space that is |> "globally unique but not globally routable" that could be used for packets |> internal to a site. | |How do you get people to do even epsilon paperwork to request such |space? People seemed so willing to do such paperwork for non-routable v4 address space that is was supposedly necessary to make the process hard/expensive to discourage them from consuming it all. Offer the v6 space on the terms that v4 space was once available (i.e., free with nominal justification documentation) and I'm sure people will use it. Try to make these allocations another cash cow with yearly fees and, naturally, people will pick (poorly) random addresses that will later hurt them. The same argument applies to NAT. If ISPs make it expensive to get extra v6 addresses (based on the justification that addresses used to be scarce?) then people will use NAT with IPv6. If ISPs make "stable" v6 addresses (i.e., ones that they do not deliberately renumber frequently) a premium service then people will use NAT. Although the standard claim is that NAT breaks the end- to-end model we all like (and note that I have personally never liked NAT), NAT shines at preserving the stable-address model that is deeply embedded in many protocols and applications. NAT has already proved itself: many useful applications work just fine in spite of the loss of the end-to-end model. The renumbering model has yet to be proven, let alone retrofitted to many existing applications. I happen to think that ISPs will charge a premium for multiple and/or stable v6 addresses because that is the status quo and because the market will bear it. Thus, I suspect that NAT will remain quite active if/when IPv6 is deployed. I think this is unfortunate--again, I'm no fan of NAT--but it's probably too late to do anything. While it certainly would have been possible to structure IPv6 in such a way that end users could allocate identity addresses independent of their providers (I even made a hand-waving proposal to allow for this with relatively minor protocol modifications) there never seemed to be much interest. So the market pressures will continue to operate in an IPv6 environment just as they have in the IPv4 one. All IMHO, of course... Dan Lanciani ddl@harvard.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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 13 14:46:48 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8DLj9K04172 for ipng-dist; Wed, 13 Sep 2000 14:45:09 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8DLj5H04165 for ; Wed, 13 Sep 2000 14:45:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.10.2+Sun/8.10.2) id e8DLicx03942 for ipng@sunroof.eng.sun.com; Wed, 13 Sep 2000 14:44:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8DLeHH04153 for ; Wed, 13 Sep 2000 14:40:17 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA14556 for ; Wed, 13 Sep 2000 14:40:17 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA10007 for ; Wed, 13 Sep 2000 14:40:16 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id 3286FB8C; Wed, 13 Sep 2000 17:40:16 -0400 (EDT) Received: from exctay-gh01.tay.cpqcorp.net (exctay-gh01.tay.cpqcorp.net [16.103.129.42]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 2A6DEA95 for ; Wed, 13 Sep 2000 17:40:16 -0400 (EDT) Received: by exctay-gh01bk.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Wed, 13 Sep 2000 17:40:15 -0400 Message-ID: From: "Powell, Ken" To: "'Richard Draves'" , ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-addr-select-01 comments Date: Wed, 13 Sep 2000 17:40:14 -0400 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Page 5, Section 2.4 > > > > "IPv6 implementations SHOULD support configurable address > > selection via a mechanism at least as powerful as the policy > > tables defined here." > > > > I do not understand why this is a "SHOULD" requirement today. > > These tables are very interesting and I can see their power > > and use, but they seem to add little practical value without > > a management infrastructure capable of downloading a common > > set of rules to all nodes in a site. I believe making this > > table configurable should be defined as optional. Also, support > > for the Label and MatchSrcLabel mechanisms in particular should > > be optional. > > I'd like to hear more feedback from the WG on this point. > Should the suggestion of configurability be "SHOULD" or "MAY" > or "may" or ??? > > I certainly agree it should be optional, but I'd like to > encourage implementations to be configurable with mechanisms > like policy table or equivalent functionality, because those > mechanisms can be used in multi-homing situations (both sites > connected to multiple ISPs and hosts with multiple > interfaces) to control choices of source & destination address. > I agree that this feature could be very useful in multi-homing situations, but would it be used much? If each vendor implements the management hooks their own way, network administrators would quickly find the hassle of defining this information on every node in a site out-weighs the benefits. I think it would be reasonable for vendors to postpone implementation of this mechanism until additional configuration tools are well defined. > > Page 5, Section 2.4 > > > > The default policy table treats IPv4 Mapped addresses that > > fall within the "autonet" and rfc 1918's private address > > ranges as special, with a higher priority than the other > > IPv4 mapped addresses. Is there a similar mechanism in > > current IPv4 implementations? If not, could this additional > > feature possibly change the behavior of applications that > > were ported to IPv6 in unexpected ways? > > I'm not suggesting that v4 stacks change how they do source > address selection. If you have a v4-only application, it > shouldn't see any changes in source address selection or the > address order from gethostbyname as a consequence of my draft. > > For an application ported to IPv6, the v4-mapped stuff just > makes a difference to the order of addresses returned by > getaddrinfo, for example whether getaddrinfo returns a v4 > address before a v6 address or vice-versa. It would affect > whether dual-protocol applications use v4 or v6 in > dual-protocol network environments, but by making the > correct/expected thing happen. I think you may have missed the point of my question. The default policy table contains the following lines: ::ffff:169.254.0.0/112 30 7 7 ::ffff:10.0.0.0/104 20 8 8 ::ffff:172.16.0.0/108 20 9 9 ::ffff:192.168.0.0/112 20 10 10 ::ffff:0:0/96 10 11 11 Instead of just: ::ffff:0:0/96 10 11 11 I was questioning if subdividing the V4-mapped addresses in the table is a good thing. > > Page 7, Section 4 > > > > "Rule 3, Prefer appropriate scope" is complex and aught > > to be broken into two rules with rule 4 in the middle > > like: > > > > Rule 3a: Avoid insufficient scope for destination. > > (i.e., avoid Scope Source < Scope Dest) > > > > Rule 4: Avoid deprecated addresses. > > > > Rule 3b: Prefer closest scope. > > If both SA and SB are of sufficient scope, choose > > the one with lower scope. If both SA abd SB are > > if insufficient scope, choose the one with higher > > scope. > > One issue with this simplification is that it would change > the selection in some instances. For example: global > destination with choice of deprecated site-local SA and > preferred link-local SB. The current rules pick SA and your > proposal would pick SB. I see your point. I'm not terribly concerned what happens when both addresses are of insufficient scope. The network configuration is clearly broken if it comes down to this choice anyhow. How about something like: Rule 3a: Avoid insufficient scope for destination. (i.e., avoid Scope Source < Scope Dest) If both addresses have insufficient scope, prefer the one with higher scope. Rule 4: Avoid deprecated addresses. Rule 3b: Prefer lower scope. > If we're going to simplify this, I actually favor just giving > appropriate scope absolute priority over > preferred/deprecated. The preferred/deprecated parts of the > current rule 3 are a response to comments from Erik Nordmark, > if I remember correctly. I wouldn't do that. We should support graceful renumbering of a network from site-local addresses to global addresses. In this situation, one would intentionally configure a router to advertise a deprecated site-local prefix. > > > Page 7, Section 4 > > > > "Rule 8 MAY be superceded if the implementation has other > > means of choosing among source addresses. For example, if > > the implementation somehow knows which source address will > > result in the "best" communications performance." > > > > I think limiting implementation specific tests to > > supercede only Rule 8 is overly restrictive. We cannot > > predict how useful future implementation specific tests > > may be for improving efficiency or avoiding connectivity > > problems. Implementations should be allowed to inject their > > own tests anywhere in the list of rules. > > > > Page 7, Section 4 > > > > "The pair-wise comparison consists of eight rules, which > > MUST be applied in order." > > > > Is it mandatory to implement all these rules? I don't > > see why every implementation has to implement longest > > matching prefix for example. Could you break the list > > down and identify which rules MUST, SHOULD, and MAY be > > implemented? > > > > The requirement of order seems overly restrictive too. > > A brief list of the source address selection rules > > (with my rule 3 suggestion) gives: > > > > Rule 1: Prefer same address > > Rule 2: Prefer matching label > > Rule 3a: Avoid insufficient scope > > Rule 4: Avoid deprecated addresses > > Rule 3b: Prefer lower scope > > Rule 5: Prefer home address > > Rule 6: Prefer outgoing interface > > Rule 7: Prefer anonymous addresses > > Rule 8: Use longest matching prefix > > Rule X: Implementation defined test > > > > I tend to divide these rules into the following groups: > > > > A) Rule 1. This is an important diagnostic feature that > > makes sense where it is. > > > > B) Rules 3a, 4, and 5. There is a good chance > > communication will fail if any of these rules > > are broken. > > > > C) Rules 2, 3b, 6, 7, 8, and X seem to exist mostly > > for efficiency or privacy enhancements. > > > > I don't think we know enough to predict which of these > > rules will prove more important to customers. For example, > > some customers may get annoyed that their system selected > > a 6to4 address over a global anonymous address simply > > because the destination was a 6to4 address. > > > > Would it make sense to specify groups of rules, where one > > group MUST be applied before the other, then RECOMMEND the > > order of rules within each group where order really isn't > > important to interoperability? > > The requirement for applying the rules in order, and only > superceding the last rule, is to get some predictability > between different implementations. We could argue about your > example (sending to 6to4 destination, choice of public 6to4 > or anonymous global source address). I think choosing the > public 6to4 source address is the right answer (and really, > if the implementation is using privacy there will also be an > anonymous 6to4 address that will get chosen). But whatever > the right answer is, I think customers will be even more > annoyed if some implementations do one thing and other > implementations do something different. > > Predictibility in this area is a very good thing for network > operations & manageability. I don't think we should use MUST unless violating a rule breaks interoperability. I agree with you that inconsistency between implementations is not good. Still, we need to allow implementations the freedom to deal with issues not foreseen by us today. That's why I prefer words like RECOMMEND and SHOULD on the order of the rules. > Many of the individual rules are collected from other places. > For example, avoiding deprecated addresses comes from RFC > 2462. Preferring anonymous addresses comes from the privacy > draft. The real contribution of this section isn't the rules > themselves, it's supplying consistency by giving them an order. Agreed. Is there any other spec that specifies "avoid insufficient scope"? > > > A summary of the rules is: > > > > Rule 1: Prefer destination with matching source > > Rule 2: Prefer destination with higher precedence > > Rule 3: Use longest matching prefix > > Rule 4: Use order returned by name service > > Page 8, Section 5 > > > > "The third and fourth rules MAY be superceded if the > > implementation has other means of sorting destination > > addresses." > > > > Same question as above for source address selection. > > Why limit this just to the third and fourth rules? > > > For example, consider a name that resolves to both a > site-local & global address, and the machine itself both a > site-local & global address. > > I think we agree that for the site-local destination, you > should prefer the site-local source, and for the global > destination you should prefer the global source. > > But should getaddrinfo return the two destination addresses > in any particular order? I *think* there's consensus that > using the smaller-scope addresses is better, so getaddrinfo > should return the site-local address before the global address. > > This is important if the site is trying to use site-local > addresses for all intra-site communication. If getaddrinfo > returns the global address first, intra-site communication > will end up using global addresses. I agree, this all makes sense as a default mode of operation given what we know today, but I'm not sure you caught the concern here. I was thinking cost, QoS, performance, or even political/ contractual considerations may become important factors in address selection in the future. I can't say how, but I can see why an implementer may need have such considerations override most other rules. > > Hence, I think getaddrinfo implementations SHOULD or maybe > even MUST return the site-local address before the global > address - otherwise site-local addresses will lose one of > their important uses. As stated before, given the lack of interface information in getaddrinfo, the source addresses selected for the destination address comparisons could be incorrect. Implementations may need to provide some way to compensate for this problem, even if its as ugly as a management knob to force use of global addresses when all else fails. That said, I have no problem with SHOULD. Ken -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 13 15:34:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8DMXO104225 for ipng-dist; Wed, 13 Sep 2000 15:33:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8DMXFH04218 for ; Wed, 13 Sep 2000 15:33:15 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA10340 for ; Wed, 13 Sep 2000 15:33:15 -0700 (PDT) Received: from mochila.martin.fl.us (mochila.martin.fl.us [198.136.32.118]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA16970 for ; Wed, 13 Sep 2000 15:33:15 -0700 (PDT) Received: from da1server.martin.fl.us (nis01 [10.10.6.103]) by mochila.martin.fl.us (8.9.3+Sun/8.9.3) with ESMTP id SAA22427; Wed, 13 Sep 2000 18:32:54 -0400 (EDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with SMTP id SAA13670; Wed, 13 Sep 2000 18:31:50 -0400 (EDT) Date: Wed, 13 Sep 2000 18:31:49 -0400 (EDT) From: Greg Maxwell X-Sender: gmaxwell@da1server To: Dan Lanciani cc: ipng@sunroof.eng.sun.com Subject: Re: (NAT) IPv6 and NAT In-Reply-To: <200009130402.AAA13380@endor.deas.harvard.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 13 Sep 2000, Dan Lanciani wrote: [snip] > discourage them from consuming it all. Offer the v6 space on the terms that v4 > space was once available (i.e., free with nominal justification documentation) > and I'm sure people will use it. [snip] > The same argument applies to NAT. If ISPs make it expensive to get extra v6 > addresses (based on the justification that addresses used to be scarce?) then > people will use NAT with IPv6. If ISPs make "stable" v6 addresses (i.e., ones > that they do not deliberately renumber frequently) a premium service then > people will use NAT. Simple. Require that any group providing packet transport services (an ISP) to provide address space to their users under the same set of qualifications required for the provider to obtain address space at a maximum. This would be enforced by making compliance mandatory for address space allocations (thus making the requirement recursive (i.e users of user of users). This would not effect a providers ability to otherwise sell transport services under whatever contract their customers and they agree opon. It would also simplify justification documentation for providers, just concatenate their user's justification documents with their own to form their application. I believe this is the only way to break the idea that network addresses are a valuable commodity and to prevent NAT. > Although the standard claim is that NAT breaks the end- > to-end model we all like (and note that I have personally never liked NAT), > NAT shines at preserving the stable-address model that is deeply embedded in > many protocols and applications. NAT has already proved itself: many useful > applications work just fine in spite of the loss of the end-to-end model. NAT is abominable. It subtlety breaks things and hides the cause. It is full of exceptions and gotchas. One layer of NAT can be manageable when the network is small and has only a single outside path. However, as networks become large and better innerconnected, peering address conflicts on NATed networks necessitate multiple layers of NAT causing a complicated 'WHO's on first?' situation. Furthermore, the statefulness required by many->one NAT (and one-one for some protocols) makes many types of highly-available configuration virtually impossible to achieve. Indeed, virtually all NAT solutions force there to be a single point of failure or a single site of failure. NAT is a descent into madness. > I happen to think that ISPs will charge a premium for multiple and/or stable > v6 addresses because that is the status quo and because the market will bear > it. I agree unless they are required not to practice this harmful activity. The legally required goal of a corporation is to maxmize shareholder profits. This goal may at times conflict with the goal of providing a global, scalable, available, and optimally useful network infrastructure. Indeed, a heavily NATed internet enviroment would create many additional network contracting and consulting jobs. > Thus, I suspect that NAT will remain quite active if/when IPv6 is deployed. If it does IPv6 will fail. An IPv6 NATatopia would offer no benifit to consumers or providers over an IPv4 NATatopia. > I think this is unfortunate--again, I'm no fan of NAT--but it's probably too > late to do anything. While it certainly would have been possible to structure > IPv6 in such a way that end users could allocate identity addresses independent [snip] > So the market pressures will continue to operate in an IPv6 environment just as > they have in the IPv4 one. All IMHO, of course... I think the solution is obvious: If a detrimental behavior is expected then simply forbid it. There is no point to being wishey-washey. Progress is not made by the mediocre. Gregory Maxwell -- The comments and opinions expressed herein are those of the author of this message and may not reflect the policies of the Martin County Board of County Commissioners. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 14 12:06:51 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8EJ5T605352 for ipng-dist; Thu, 14 Sep 2000 12:05:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8EJ5JH05345 for ; Thu, 14 Sep 2000 12:05:20 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA18769 for ; Thu, 14 Sep 2000 12:05:18 -0700 (PDT) Received: from lepidachrosite.lion-access.net (lepidachrosite.lion-access.net [212.19.217.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22538 for ; Thu, 14 Sep 2000 12:05:18 -0700 (PDT) Received: from joris (1Cust99.tnt6.rtm1.nl.uu.net [213.116.106.99]) by lepidachrosite.lion-access.net (I-Lab) with SMTP id CD753CAFF3; Thu, 14 Sep 2000 19:04:57 +0000 (GMT) From: "Joris Dobbelsteen" To: "IPng WG (E-mail)" , "NAT WG (E-mail)" Subject: RE: (NAT) IPv6 and NAT Date: Thu, 14 Sep 2000 20:56:19 +0200 Message-ID: <001101c01e7e$f23a6640$0d0aa8c0@THUIS.LOCAL> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've read the drafts about NAT (finally), As Dan said, NAT will be used, what is not a problem if it's only - AND ONLY - used by home users that want to route there network to the Internet and have a simple (free) Internet account, that only provides one public/Internet IP address to them. Let's assume MOST (not all) home users won't make much use from all the security services that are provides, like IPSec (SSL, etc. with e.g. HTTPS is not a problem). They also don't have complex networks and only want to be able to use a web browser, send/receive e-mail and play a game on the Internet. Most of these services can be done over NAT, usually home users have only one network link, and a quite simple network. Actually, I like it on a home LAN, even with it's limitations.... For better explanation, I mean with a Home LAN a network consisting of a single link with no routers, and (maybe) only one NAT router to the Internet. Businesses usually have more complex networks, require security services and things that don't work with NAT. For them NAT should be highly discouraged. However now the problem that arises, most computers will not be equipped with two network cards, where one is for the private network, and the other one for the Internet. Hope you understand what I mean???? Let me explain a bit better before you give comment (most likely needed)... Let's take the Microsoft Windows platform for example (e.g. Windows 98). This is the only platform where I have experience with IPv4 transports. Your computer is connected to a private network and has a private IP address. So why not add the public IP address to the same adapter to be used for the Internet connection? Well, Windows doesn't assign services (like file and printer sharing) to IP address, but to the Network adapter itself, regardless of any network protocol and it's configuration. This will mean everybody on the private network AND the Internet will access your computer using the MS File and Printer Sharing! This is only one service where the problem arises... And why can't we install an additional Network Adapter? This solution is not cost-efficient: It will require around $100 for every computer that needs a connection to the Internet, and not counting the cost for the UTP hubs needed. The solution to this problem is probably VPN, (IP-over-IP) tunneling or something similar. Maybe there are other solutions, but I'm not familiar with them or don't know of there existence. Maybe that software implementers can provide a virtual device driver that simulates a network adapter connected to the Internet and has IP tunneling. But I leave this discussion to the software implementers. Before I forget, some of you talked about Interface-local, link-local and site-local IPv6 address, but these cannot be used on the Internet, nor routed to the Internet without the translation that is subjected to retire after IPv6 (just like the private IPv4 addresses). - Joris > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Greg Maxwell > Sent: donderdag 14 september 2000 0:32 > To: Dan Lanciani > Cc: ipng@sunroof.eng.sun.com > Subject: Re: (NAT) IPv6 and NAT > > > On Wed, 13 Sep 2000, Dan Lanciani wrote: > > [snip] > > discourage them from consuming it all. Offer the v6 space > on the terms that v4 > > space was once available (i.e., free with nominal > justification documentation) > > and I'm sure people will use it. > [snip] > > The same argument applies to NAT. If ISPs make it > expensive to get extra v6 > > addresses (based on the justification that addresses used > to be scarce?) then > > people will use NAT with IPv6. If ISPs make "stable" v6 > addresses (i.e., ones > > that they do not deliberately renumber frequently) a > premium service then > > people will use NAT. > > Simple. Require that any group providing packet transport services (an > ISP) to provide address space to their users under the same set of > qualifications required for the provider to obtain address space at a > maximum. > > This would be enforced by making compliance mandatory for > address space > allocations (thus making the requirement recursive (i.e users > of user of > users). > > This would not effect a providers ability to otherwise sell transport > services under whatever contract their customers and they agree opon. > > It would also simplify justification documentation for providers, just > concatenate their user's justification documents with their > own to form > their application. > > I believe this is the only way to break the idea that network > addresses > are a valuable commodity and to prevent NAT. > > > Although the standard claim is that NAT breaks the end- > > to-end model we all like (and note that I have personally > never liked NAT), > > NAT shines at preserving the stable-address model that is > deeply embedded in > > many protocols and applications. NAT has already proved > itself: many useful > > applications work just fine in spite of the loss of the > end-to-end model. > > NAT is abominable. It subtlety breaks things and hides the > cause. It is > full of exceptions and gotchas. > > One layer of NAT can be manageable when the network is small > and has only > a single outside path. > > However, as networks become large and better innerconnected, peering > address conflicts on NATed networks necessitate multiple layers of NAT > causing a complicated 'WHO's on first?' situation. Furthermore, the > statefulness required by many->one NAT (and one-one for some > protocols) > makes many types of highly-available configuration virtually > impossible to > achieve. Indeed, virtually all NAT solutions force there to > be a single > point of failure or a single site of failure. > > NAT is a descent into madness. > > > I happen to think that ISPs will charge a premium for > multiple and/or stable > > v6 addresses because that is the status quo and because the > market will bear > > it. > > I agree unless they are required not to practice this harmful > activity. > > The legally required goal of a corporation is to maxmize shareholder > profits. This goal may at times conflict with the goal of providing a > global, scalable, available, and optimally useful network > infrastructure. > > Indeed, a heavily NATed internet enviroment would create many > additional > network contracting and consulting jobs. > > > Thus, I suspect that NAT will remain quite active if/when > IPv6 is deployed. > > If it does IPv6 will fail. > An IPv6 NATatopia would offer no benifit to consumers or > providers over an > IPv4 NATatopia. > > > I think this is unfortunate--again, I'm no fan of NAT--but > it's probably too > > late to do anything. While it certainly would have been > possible to structure > > IPv6 in such a way that end users could allocate identity > addresses independent > [snip] > > > So the market pressures will continue to operate in an IPv6 > environment just as > > they have in the IPv4 one. All IMHO, of course... > > I think the solution is obvious: If a detrimental behavior is expected > then simply forbid it. > > There is no point to being wishey-washey. Progress is not made by > the mediocre. > > Gregory Maxwell > > -- > The comments and opinions expressed herein are those of the > author of this > message and may not reflect the policies of the Martin County Board of > County Commissioners. > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sep 14 13:31:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) id e8EKRuT05462 for ipng-dist; Thu, 14 Sep 2000 13:27:56 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8EKRbH05455 for ; Thu, 14 Sep 2000 13:27:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA06420 for ; Thu, 14 Sep 2000 13:27:35 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22204 for ; Thu, 14 Sep 2000 13:27:34 -0700 (PDT) Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id VAA08947; Thu, 14 Sep 2000 21:23:51 +0100 (BST) Received: from penelope (penelope [152.78.68.135]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id VAA19665; Thu, 14 Sep 2000 21:23:50 +0100 (BST) Date: Thu, 14 Sep 2000 21:23:50 +0100 (BST) From: Tim Chown To: Joris Dobbelsteen cc: "IPng WG (E-mail)" , "NAT WG (E-mail)" Subject: RE: (NAT) IPv6 and NAT In-Reply-To: <001101c01e7e$f23a6640$0d0aa8c0@THUIS.LOCAL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 14 Sep 2000, Joris Dobbelsteen wrote: > I've read the drafts about NAT (finally), Also have a read of the IPv6 Home Networking white paper by Brian Haberman and George Tsirtsis at http://www.ipv6forum.com. I think this may answer some more of your questions. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 15 00:45:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8F7iS105820 for ipng-dist; Fri, 15 Sep 2000 00:44:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8F7iJr05813 for ; Fri, 15 Sep 2000 00:44:19 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA07231 for ; Fri, 15 Sep 2000 00:44:20 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17716 for ; Fri, 15 Sep 2000 00:44:18 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id JAA08142; Fri, 15 Sep 2000 09:44:03 +0200 (MET DST) Date: Fri, 15 Sep 2000 09:44:02 +0200 From: Ignatios Souvatzis To: Joris Dobbelsteen Cc: "IPng WG (E-mail)" , "NAT WG (E-mail)" Subject: Re: (NAT) IPv6 and NAT Message-ID: <20000915094402.A8111@theory.cs.uni-bonn.de> References: <001101c01e7e$f23a6640$0d0aa8c0@THUIS.LOCAL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <001101c01e7e$f23a6640$0d0aa8c0@THUIS.LOCAL>; from joris.dobbelsteen@mail.com on Thu, Sep 14, 2000 at 08:56:19PM +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Sep 14, 2000 at 08:56:19PM +0200, Joris Dobbelsteen wrote: > I've read the drafts about NAT (finally), > > As Dan said, NAT will be used, what is not a problem if it's only - AND > ONLY - used by home users that want to route there network to the Internet > and have a simple (free) Internet account, that only provides one > public/Internet IP address to them. > > Let's assume MOST (not all) home users won't make much use from all the > security services that are provides, like IPSec (SSL, etc. with e.g. HTTPS > is not a problem). They also don't have complex networks and only want to be > able to use a web browser, send/receive e-mail and play a game on the AH, play a game on the Internet.... but you can't develop new types of games using some advanced protocol when it doesn't work because NAT would require an application level gateway... Regards, -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 09:12:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8FGBc906165 for ipng-dist; Fri, 15 Sep 2000 09:11:38 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8FGBTr06158 for ; Fri, 15 Sep 2000 09:11:29 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA00330 for ; Fri, 15 Sep 2000 09:11:29 -0700 (PDT) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26322 for ; Fri, 15 Sep 2000 09:11:28 -0700 (PDT) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id CCA042975; Fri, 15 Sep 2000 11:11:27 -0500 (CDT) Received: from yquarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 63E4C1023; Fri, 15 Sep 2000 11:11:27 -0500 (CDT) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id MAA0000008975; Fri, 15 Sep 2000 12:11:25 -0400 (EDT) From: Jim Bound Message-Id: <200009151611.MAA0000008975@yquarry.zk3.dec.com> X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Richard Draves Cc: "'Powell, Ken'" , ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipngwg-addr-select-01 comments In-reply-to: Your message of "Fri, 08 Sep 2000 15:09:16 PDT." <7695E2F6903F7A41961F8CF888D87EA81C9B5E@red-msg-06.redmond.corp.microsoft.com> Date: Fri, 15 Sep 2000 12:11:25 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >This is important if the site is trying to use site-local addresses for all >intra-site communication. If getaddrinfo returns the global address first, >intra-site communication will end up using global addresses. > >Hence, I think getaddrinfo implementations SHOULD or maybe even MUST return >the site-local address before the global address - otherwise site-local >addresses will lose one of their important uses. I don't agree we can declare this in the spec. How we word it I am not sure yet. But mobile nodes will use global addresses not site-local if they are roaming across routing realms. Site-local simply won't work. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 15 10:06:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8FH4dV06234 for ipng-dist; Fri, 15 Sep 2000 10:04:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8FH4Ur06227 for ; Fri, 15 Sep 2000 10:04:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA19461 for ; Fri, 15 Sep 2000 10:04:28 -0700 (PDT) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18204 for ; Fri, 15 Sep 2000 10:04:28 -0700 (PDT) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id 3612B11F4; Fri, 15 Sep 2000 12:04:28 -0500 (CDT) Received: from yquarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id C2BD62AB0; Fri, 15 Sep 2000 12:04:27 -0500 (CDT) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id NAA0000018559; Fri, 15 Sep 2000 13:04:26 -0400 (EDT) From: Jim Bound Message-Id: <200009151704.NAA0000018559@yquarry.zk3.dec.com> X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Mauro Tortonesi Cc: IETF - IPng Working Group , project6-devel@ferrara.linux.it Subject: Re: getaddrinfo In-reply-to: Your message of "Tue, 12 Sep 2000 11:27:30 +0200." Date: Fri, 15 Sep 2000 13:04:26 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Maruo, >i have a question about the getaddrinfo function. > >first, suppose that the nodename argument is a numeric host address and >the flag AI_NUMERICHOST is not set. will the query to getaddrinfo return >ALL addresses of that host? No. That is an error and you will get EAI_AGAIN is my view. >IMHO it should, but draft-...-rfc2553bis-00 is not very clear about this. >it only states that AI_NUMERICHOST prevents the DNS from being invoked, so >i guess that if AI_NUMERICHOST is not set, then a query to the resolution >service MUST be made, even if nodename is a numeric host address. Correct. >there is also one more problem i'd like to talk about. in order to have a >stable and standard api, rfc2553bis and XNET specifications should not be >contradictory. i know at least one big implementation that is unwilling >to support rfc2553bis because it does not follow XNET specs. this is a >serious problem IMO. I agree. We have an offline design team of folks who are talking and we are about ready to report our findings. A bit of history here. The only purpose of the base API since the beginning was to add the basic syntax and semantics to add IPv6 to the BSD sockets programming model. But two things happened. Creeping featurism and we need to support scopes for addresses. This lead us to add the getaddrinfo and friends API and now we have deprecated getipnodebyname and friends. The next revision of 2553bis will fix some base IPv6 issues and provide one new feature to tell an implementation to not process IPv4 Mapped addresses which came into the implementation as native IPv4 addresses at the Stevens and BSD ip_input.c module. Also provide additional clarity. The getaddrinfo and friends API has numerous combinations and a complex matrice of choices for the variant parameters to these new APIs. All we are specifying in the Base API (2553bis) are when specific IPv6 datums created by the Base API are used in these new APIs. For example what happens when AI_V4MAPPED is set, or what is in the sin6_scope_id field. But the many questions like yours above really are generic to these new APIs and not specific for IPv6. To that end the Base API will not specify or try to annotate all behaviors of these new APIs (new in the sense of adoption by 2553bis). We will point this work to the XNET group to the IEEE POSIX 1003 committee who will own this API. This is not the job of the IPng WG as our job is to get the IPv6 parameters defined. After the next release of 2553bis (and in the next release) the WG and community will be given a pointer to how to participate with XNET to work on the issues as you have just presented. I will work with Andrew Gollan from Sun to make this as clear as possible for you all. So to answer your question the next version of 2553bis for getaddrinfo and friends will duplicate the present wording of XNET except where we need to add any new features from IPng WG discussion. But we will not try to solve or specify all the needed behavior of getaddrinfo and friends thats XNET's job. This is one of the reasons I wish we had been able to keep the simple getipnodebyname and friends working with scopes, but we can't and need to move on. regards, /jim -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 15 11:05:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8FI4BJ06366 for ipng-dist; Fri, 15 Sep 2000 11:04:11 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8FI46r06359 for ; Fri, 15 Sep 2000 11:04:07 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e8FI42J01571 for ipng@sunroof.eng.sun.com; Fri, 15 Sep 2000 11:04:02 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta0+Sun/8.11.1.Beta0) with ESMTP id e8F4pGH05636 for ; Thu, 14 Sep 2000 21:51:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id VAA14089 for ; Thu, 14 Sep 2000 21:51:15 -0700 (PDT) Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA26018 for ; Thu, 14 Sep 2000 22:51:14 -0600 (MDT) Received: from MATT.ascend.com (ts007d27.lap-ca.concentric.NET [64.1.209.87]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id R9Z2L36A; Thu, 14 Sep 2000 21:51:09 -0700 Message-Id: <4.3.1.2.20000914211753.00c5a7c0@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 14 Sep 2000 21:27:12 -0700 To: "Joris Dobbelsteen" From: Matt Holdrege Subject: RE: (NAT) IPv6 and NAT Cc: "IPng WG (E-mail)" , "NAT WG (E-mail)" In-Reply-To: <001101c01e7e$f23a6640$0d0aa8c0@THUIS.LOCAL> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Joris, I'm not sure what your point is, but these email lists are solely for the purpose of progressing the drafts of the NAT and IPNG working groups respectively. If you have a comment on how you would change any outstanding Internet Drafts, please let us know what those changes might be. Specifically, it isn't (IMHO) useful to have discussions here about how you assume people use NAT at home. I'm sure there is a better place outside the IETF for such discussions. At 08:56 PM 9/14/00 +0200, Joris Dobbelsteen wrote: >I've read the drafts about NAT (finally), > >As Dan said, NAT will be used, what is not a problem if it's only - AND >ONLY - used by home users that want to route there network to the Internet >and have a simple (free) Internet account, that only provides one >public/Internet IP address to them. > >Let's assume MOST (not all) home users won't make much use from all the >security services that are provides, like IPSec (SSL, etc. with e.g. HTTPS >is not a problem). They also don't have complex networks and only want to be >able to use a web browser, send/receive e-mail and play a game on the >Internet. Most of these services can be done over NAT, usually home users >have only one network link, and a quite simple network. >Actually, I like it on a home LAN, even with it's limitations.... > >For better explanation, I mean with a Home LAN a network consisting of a >single link with no routers, and (maybe) only one NAT router to the >Internet. > >Businesses usually have more complex networks, require security services and >things that don't work with NAT. For them NAT should be highly discouraged. > >However now the problem that arises, most computers will not be equipped >with two network cards, where one is for the private network, and the other >one for the Internet. >Hope you understand what I mean???? Let me explain a bit better before you >give comment (most likely needed)... > > >Let's take the Microsoft Windows platform for example (e.g. Windows 98). >This is the only platform where I have experience with IPv4 transports. > >Your computer is connected to a private network and has a private IP >address. So why not add the public IP address to the same adapter to be used >for the Internet connection? >Well, Windows doesn't assign services (like file and printer sharing) to IP >address, but to the Network adapter itself, regardless of any network >protocol and it's configuration. This will mean everybody on the private >network AND the Internet will access your computer using the MS File and >Printer Sharing! This is only one service where the problem arises... > >And why can't we install an additional Network Adapter? >This solution is not cost-efficient: It will require around $100 for every >computer that needs a connection to the Internet, and not counting the cost >for the UTP hubs needed. > > >The solution to this problem is probably VPN, (IP-over-IP) tunneling or >something similar. Maybe there are other solutions, but I'm not familiar >with them or don't know of there existence. >Maybe that software implementers can provide a virtual device driver that >simulates a network adapter connected to the Internet and has IP tunneling. >But I leave this discussion to the software implementers. > > >Before I forget, some of you talked about Interface-local, link-local and >site-local IPv6 address, but these cannot be used on the Internet, nor >routed to the Internet without the translation that is subjected to retire >after IPv6 (just like the private IPv4 addresses). > > > > >- Joris > > > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Greg Maxwell > > Sent: donderdag 14 september 2000 0:32 > > To: Dan Lanciani > > Cc: ipng@sunroof.eng.sun.com > > Subject: Re: (NAT) IPv6 and NAT > > > > > > On Wed, 13 Sep 2000, Dan Lanciani wrote: > > > > [snip] > > > discourage them from consuming it all. Offer the v6 space > > on the terms that v4 > > > space was once available (i.e., free with nominal > > justification documentation) > > > and I'm sure people will use it. > > [snip] > > > The same argument applies to NAT. If ISPs make it > > expensive to get extra v6 > > > addresses (based on the justification that addresses used > > to be scarce?) then > > > people will use NAT with IPv6. If ISPs make "stable" v6 > > addresses (i.e., ones > > > that they do not deliberately renumber frequently) a > > premium service then > > > people will use NAT. > > > > Simple. Require that any group providing packet transport services (an > > ISP) to provide address space to their users under the same set of > > qualifications required for the provider to obtain address space at a > > maximum. > > > > This would be enforced by making compliance mandatory for > > address space > > allocations (thus making the requirement recursive (i.e users > > of user of > > users). > > > > This would not effect a providers ability to otherwise sell transport > > services under whatever contract their customers and they agree opon. > > > > It would also simplify justification documentation for providers, just > > concatenate their user's justification documents with their > > own to form > > their application. > > > > I believe this is the only way to break the idea that network > > addresses > > are a valuable commodity and to prevent NAT. > > > > > Although the standard claim is that NAT breaks the end- > > > to-end model we all like (and note that I have personally > > never liked NAT), > > > NAT shines at preserving the stable-address model that is > > deeply embedded in > > > many protocols and applications. NAT has already proved > > itself: many useful > > > applications work just fine in spite of the loss of the > > end-to-end model. > > > > NAT is abominable. It subtlety breaks things and hides the > > cause. It is > > full of exceptions and gotchas. > > > > One layer of NAT can be manageable when the network is small > > and has only > > a single outside path. > > > > However, as networks become large and better innerconnected, peering > > address conflicts on NATed networks necessitate multiple layers of NAT > > causing a complicated 'WHO's on first?' situation. Furthermore, the > > statefulness required by many->one NAT (and one-one for some > > protocols) > > makes many types of highly-available configuration virtually > > impossible to > > achieve. Indeed, virtually all NAT solutions force there to > > be a single > > point of failure or a single site of failure. > > > > NAT is a descent into madness. > > > > > I happen to think that ISPs will charge a premium for > > multiple and/or stable > > > v6 addresses because that is the status quo and because the > > market will bear > > > it. > > > > I agree unless they are required not to practice this harmful > > activity. > > > > The legally required goal of a corporation is to maxmize shareholder > > profits. This goal may at times conflict with the goal of providing a > > global, scalable, available, and optimally useful network > > infrastructure. > > > > Indeed, a heavily NATed internet enviroment would create many > > additional > > network contracting and consulting jobs. > > > > > Thus, I suspect that NAT will remain quite active if/when > > IPv6 is deployed. > > > > If it does IPv6 will fail. > > An IPv6 NATatopia would offer no benifit to consumers or > > providers over an > > IPv4 NATatopia. > > > > > I think this is unfortunate--again, I'm no fan of NAT--but > > it's probably too > > > late to do anything. While it certainly would have been > > possible to structure > > > IPv6 in such a way that end users could allocate identity > > addresses independent > > [snip] > > > > > So the market pressures will continue to operate in an IPv6 > > environment just as > > > they have in the IPv4 one. All IMHO, of course... > > > > I think the solution is obvious: If a detrimental behavior is expected > > then simply forbid it. > > > > There is no point to being wishey-washey. Progress is not made by > > the mediocre. > > > > Gregory Maxwell > > > > -- > > The comments and opinions expressed herein are those of the > > author of this > > message and may not reflect the policies of the Martin County Board of > > County Commissioners. > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe nat' in the body of the message. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Sep 16 01:35:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8G8Xn906816 for ipng-dist; Sat, 16 Sep 2000 01:33:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8G8Xar06809 for ; Sat, 16 Sep 2000 01:33:37 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA06320 for ; Sat, 16 Sep 2000 01:33:05 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA26468 for ; Sat, 16 Sep 2000 02:33:03 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id RAA11107; Sat, 16 Sep 2000 17:32:56 +0900 (JST) To: "Powell, Ken" cc: "'Richard Draves'" , ipng@sunroof.eng.sun.com In-reply-to: Ken.Powell's message of Wed, 13 Sep 2000 17:40:14 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: draft-ietf-ipngwg-addr-select-01 comments From: itojun@iijlab.net Date: Sat, 16 Sep 2000 17:32:56 +0900 Message-ID: <11105.969093176@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Hence, I think getaddrinfo implementations SHOULD or maybe >> even MUST return the site-local address before the global >> address - otherwise site-local addresses will lose one of >> their important uses. >As stated before, given the lack of interface information in >getaddrinfo, the source addresses selected for the destination >address comparisons could be incorrect. Implementations may need >to provide some way to compensate for this problem, even if its >as ugly as a management knob to force use of global addresses >when all else fails. That said, I have no problem with SHOULD. my take was that, if the node/library obeys ipngwg-addr-select-01, getaddrinfo/gethostbyname will (or should) return the addrsses ordered appropriately. for a normal UNIX implementation, ipngwg-addr-select-01 defines the behavior of the kernel (source address selection) and the name resolver library in libc (destination address seletion). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 18 01:53:27 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8I8qAI07589 for ipng-dist; Mon, 18 Sep 2000 01:52:10 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8I8pxr07582 for ; Mon, 18 Sep 2000 01:52:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA08369 for ; Mon, 18 Sep 2000 01:51:46 -0700 (PDT) Received: from smtp3.libero.it (smtp3.libero.it [193.70.192.53]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA00953 for ; Mon, 18 Sep 2000 01:51:44 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.20.137.181) by smtp3.libero.it; 18 Sep 2000 10:51:35 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id 57B3F4D594; Mon, 18 Sep 2000 10:43:57 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 53B774D51A; Mon, 18 Sep 2000 10:43:57 +0200 (CEST) Date: Mon, 18 Sep 2000 10:43:57 +0200 (CEST) From: Mauro Tortonesi To: Jim Bound Cc: IETF - IPng Working Group , project6-devel@ferrara.linux.it Subject: Re: getaddrinfo In-Reply-To: <200009151704.NAA0000018559@yquarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 15 Sep 2000, Jim Bound wrote: > Hi Mauro, > > >i have a question about the getaddrinfo function. > > > >first, suppose that the nodename argument is a numeric host address and > >the flag AI_NUMERICHOST is not set. will the query to getaddrinfo return > >ALL addresses of that host? > > No. That is an error and you will get EAI_AGAIN is my view. maybe i have not explained the situation very well. the call: getaddrinfo("xxx:xxx::xxx", NULL, &res) should return the full results of a query to the DNS for address "xxx...", and not only a struct sockaddr_in6 filled with the address "xxx...", imo. is this correct? > >IMHO it should, but draft-...-rfc2553bis-00 is not very clear about this. > >it only states that AI_NUMERICHOST prevents the DNS from being invoked, so > >i guess that if AI_NUMERICHOST is not set, then a query to the resolution > >service MUST be made, even if nodename is a numeric host address. > > Correct. thank you for your answers. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.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 Mon Sep 18 17:18:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8J0FtK09534 for ipng-dist; Mon, 18 Sep 2000 17:15:55 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8J0Fkr09527 for ; Mon, 18 Sep 2000 17:15:47 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA14895 for ; Mon, 18 Sep 2000 17:15:30 -0700 (PDT) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07406 for ; Mon, 18 Sep 2000 17:15:30 -0700 (PDT) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id CB9E01059; Mon, 18 Sep 2000 19:15:29 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id 349D21369; Mon, 18 Sep 2000 19:15:29 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id UAA0000766427; Mon, 18 Sep 2000 20:14:41 -0400 (EDT) From: Jim Bound Message-Id: <200009190014.UAA0000766427@anw.zk3.dec.com> To: Mauro Tortonesi Cc: Jim Bound , IETF - IPng Working Group , project6-devel@ferrara.linux.it, bound@zk3.dec.com Subject: Re: getaddrinfo In-reply-to: Your message of "Mon, 18 Sep 2000 10:43:57 +0200." Date: Mon, 18 Sep 2000 20:14:40 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mauro, >> >i have a question about the getaddrinfo function. >> > >> >first, suppose that the nodename argument is a numeric host address and >> >the flag AI_NUMERICHOST is not set. will the query to getaddrinfo return >> >ALL addresses of that host? >> >> No. That is an error and you will get EAI_AGAIN is my view. > >maybe i have not explained the situation very well. the call: > >getaddrinfo("xxx:xxx::xxx", NULL, &res) > >should return the full results of a query to the DNS for address "xxx...", >and not only a struct sockaddr_in6 filled with the address "xxx...", imo. >is this correct? Yes. regards, /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 Sep 18 17:35:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8J0Y1k09768 for ipng-dist; Mon, 18 Sep 2000 17:34:01 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8J0Xpr09761 for ; Mon, 18 Sep 2000 17:33:52 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA23640 for ; Mon, 18 Sep 2000 17:33:38 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA10934 for ; Mon, 18 Sep 2000 17:33:36 -0700 (PDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id JAA30082; Tue, 19 Sep 2000 09:33:08 +0900 To: bound@zk3.dec.com Cc: mauro@ferrara.linux.it, ipng@sunroof.eng.sun.com, project6-devel@ferrara.linux.it Subject: Re: getaddrinfo In-Reply-To: <200009190014.UAA0000766427@anw.zk3.dec.com> References: <200009190014.UAA0000766427@anw.zk3.dec.com> X-Mailer: Mew version 1.94 on XEmacs 21.1 (Capitol Reef) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000919093306V.yoshfuji@ecei.tohoku.ac.jp> Date: Tue, 19 Sep 2000 09:33:06 +0900 From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) X-Dispatcher: imput version 990905(IM130) Lines: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article <200009190014.UAA0000766427@anw.zk3.dec.com> (at Mon, 18 Sep 2000 20:14:40 -0400), Jim Bound says: > >getaddrinfo("xxx:xxx::xxx", NULL, &res) > > > >should return the full results of a query to the DNS for address "xxx...", > >and not only a struct sockaddr_in6 filled with the address "xxx...", imo. > >is this correct? What do you mean by "full results," Mauro? > Yes. Really? -- Hideaki YOSHIFUJI @ USAGI Project Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 18 21:36:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8J4Yth10143 for ipng-dist; Mon, 18 Sep 2000 21:34:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8J4Ycr10132 for ; Mon, 18 Sep 2000 21:34:39 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA25215 for ; Mon, 18 Sep 2000 20:30:36 -0700 (PDT) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA11905 for ; Mon, 18 Sep 2000 20:30:31 -0700 (PDT) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id EE82F2DB1; Mon, 18 Sep 2000 23:30:30 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id A6D234E79; Mon, 18 Sep 2000 23:30:30 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0000783352; Mon, 18 Sep 2000 23:29:14 -0400 (EDT) From: Jim Bound Message-Id: <200009190329.XAA0000783352@anw.zk3.dec.com> To: Brian Zill Cc: "'Hideaki YOSHIFUJI'" , bound@zk3.dec.com, mauro@ferrara.linux.it, ipng@sunroof.eng.sun.com, project6-devel@ferrara.linux.it, bound@zk3.dec.com Subject: Re: getaddrinfo In-reply-to: Your message of "Mon, 18 Sep 2000 20:07:00 PDT." <9B9A5456AFE99E4181416B252F63BDA2212450@red-msg-05.redmond.corp.microsoft.com> Date: Mon, 18 Sep 2000 23:29:12 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Let me clarify. I think its crazy too. But what I was beaten in to believe and I think XNET was too is that implementors want this? /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 Sep 18 21:36:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8J4Ub110098 for ipng-dist; Mon, 18 Sep 2000 21:30:37 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8J4UFr10091 for ; Mon, 18 Sep 2000 21:30:16 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA20096 for ; Mon, 18 Sep 2000 20:07:17 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA08391 for ; Mon, 18 Sep 2000 20:07:17 -0700 (PDT) Received: from 157.54.9.108 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Sep 2000 20:07:14 -0700 (Pacific Daylight Time) Received: by INET-IMC-05 with Internet Mail Service (5.5.2651.58) id ; Mon, 18 Sep 2000 20:07:14 -0700 Message-ID: <9B9A5456AFE99E4181416B252F63BDA2212450@red-msg-05.redmond.corp.microsoft.com> From: Brian Zill To: "'Hideaki YOSHIFUJI'" , bound@zk3.dec.com, mauro@ferrara.linux.it Cc: ipng@sunroof.eng.sun.com, project6-devel@ferrara.linux.it Subject: RE: getaddrinfo Date: Mon, 18 Sep 2000 20:07:00 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Hideaki YOSHIFUJI [mailto:yoshfuji@ecei.tohoku.ac.jp] > > In article <200009190014.UAA0000766427@anw.zk3.dec.com> (at > Mon, 18 Sep 2000 20:14:40 -0400), Jim Bound says: > > > >getaddrinfo("xxx:xxx::xxx", NULL, &res) > > > > > >should return the full results of a query to the DNS for > address "xxx...", > > >and not only a struct sockaddr_in6 filled with the address > "xxx...", imo. > > >is this correct? > > What do you mean by "full results," Mauro? Yes, what are you asking? In your earlier message you asked: > first, suppose that the nodename argument is a numeric host > address and the flag AI_NUMERICHOST is not set. will the > query to getaddrinfo return ALL addresses of that host? Are you saying that if one gives it a literal address, it should do a reverse lookup to figure out what name that corresponds to and then do a forward lookup to find all the addresses for that host? Personally, I think that's crazy! If you want that behavior, you should use getnameinfo to get the name, and then feed the name into getaddrinfo. getaddrinfo shouldn't be doing reverse lookups, that's what getnameinfo is for. The AI_NUMERICHOST flag should have no effect if you give getaddrinfo an address literal. It's purpose is to prevent DNS lookups in the case where you don't give getaddrinfo an address literal. > > Yes. > > Really? I sure hope not. I vote No. --Brian > -- > Hideaki YOSHIFUJI @ USAGI Project > Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ > PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sep 18 23:14:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8J6D6H10227 for ipng-dist; Mon, 18 Sep 2000 23:13:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8J6Cvr10220 for ; Mon, 18 Sep 2000 23:12:57 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA18668 for ; Mon, 18 Sep 2000 23:12:41 -0700 (PDT) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA17180 for ; Mon, 18 Sep 2000 23:12:41 -0700 (PDT) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id A725C12A9; Tue, 19 Sep 2000 01:12:40 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id DCCA712FB; Tue, 19 Sep 2000 01:12:39 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id CAA0000802090; Tue, 19 Sep 2000 02:11:53 -0400 (EDT) From: Jim Bound Message-Id: <200009190611.CAA0000802090@anw.zk3.dec.com> To: Stig Venaas Cc: Jim Bound , Brian Zill , "'Hideaki YOSHIFUJI'" , mauro@ferrara.linux.it, ipng@sunroof.eng.sun.com, project6-devel@ferrara.linux.it, bound@zk3.dec.com Subject: Re: [Project6-devel] Re: getaddrinfo In-reply-to: Your message of "Tue, 19 Sep 2000 07:59:28 +0200." <20000919075928.A6790@sverresborg.uninett.no> Date: Tue, 19 Sep 2000 02:11:52 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk the problem is there is nothing that says you can't do it. thats why my long winded mail about these are classic API issues not network issues. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 19 07:17:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8JEEmC10436 for ipng-dist; Tue, 19 Sep 2000 07:14:48 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8JEEcr10429 for ; Tue, 19 Sep 2000 07:14:38 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA29732 for ; Tue, 19 Sep 2000 07:14:35 -0700 (PDT) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA04819 for ; Tue, 19 Sep 2000 07:14:34 -0700 (PDT) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 38C5A2A4D; Tue, 19 Sep 2000 10:14:34 -0400 (EDT) Received: from yquarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 05CD82BD5; Tue, 19 Sep 2000 10:14:33 -0400 (EDT) Received: from whitestar.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id KAA0000003417; Tue, 19 Sep 2000 10:14:29 -0400 (EDT) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA03707; Tue, 19 Sep 2000 10:14:28 -0400 Message-Id: <39C774C3.C1161092@zk3.dec.com> Date: Tue, 19 Sep 2000 10:14:28 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: ru, en Mime-Version: 1.0 To: Jim Bound Cc: Brian Zill , "'Hideaki YOSHIFUJI'" , mauro@ferrara.linux.it, ipng@sunroof.eng.sun.com, project6-devel@ferrara.linux.it Subject: Re: getaddrinfo References: <200009190329.XAA0000783352@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound wrote: > > Brian, > > Let me clarify. I think its crazy too. But what I was beaten in to > believe and I think XNET was too is that implementors want this? > > /jim Jim Really? Every implementation I know of (the ones I've seen the code to) do exacatly what Brian described, that is just translate the address to binary and return it. I agree with Brian that getaddrinfo() should not do reverse lookups. That is what getnameinfo() is for. Adding this would makes this function even more bloated then it already is and add more state information to keep track of. I vote "no" to this. -vlad ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 19 07:35:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8JEXNT10467 for ipng-dist; Tue, 19 Sep 2000 07:33:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8JEXFr10460 for ; Tue, 19 Sep 2000 07:33:15 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA26992 for ; Tue, 19 Sep 2000 07:33:15 -0700 (PDT) Received: from hermes.research.kpn.com (hermes.research.kpn.com [139.63.192.8]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10214 for ; Tue, 19 Sep 2000 07:33:15 -0700 (PDT) Received: from l04.research.kpn.com (l04.research.kpn.com [139.63.192.204]) by research.kpn.com (PMDF V5.2-31 #42699) with ESMTP id <01JUD3WTIT1A0000MQ@research.kpn.com> for ipng@sunroof.eng.sun.com; Tue, 19 Sep 2000 16:33:06 +0200 Received: by l04.research.kpn.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Sep 2000 16:33:05 +0100 Content-return: allowed Date: Tue, 19 Sep 2000 16:33:03 +0100 From: "Neuijen, S.M.J.G." Subject: RE: (NAT) IPv6 and NAT To: ipng@sunroof.eng.sun.com Message-id: <59063B5B4D98D311BC0D0001FA7E4522033B082C@l04.research.kpn.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I happen to think that ISPs will charge a premium for multiple and/or stable > v6 addresses because that is the status quo and because the market will bear > it. Thus, I suspect that NAT will remain quite active if/when IPv6 is > deployed. Maybe they wan't do that anymore when their competitors offer the same service for free, and why wouldn't they? IPv6 addresses, as opposed to ipv4 addresses, are NOT a scarse resource! So only one "FREE ISP" has to make the move..... Saskia -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 19 08:52:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8JFonS10777 for ipng-dist; Tue, 19 Sep 2000 08:50:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8JFoer10770 for ; Tue, 19 Sep 2000 08:50:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA19101 for ; Tue, 19 Sep 2000 08:50:40 -0700 (PDT) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA08743 for ; Tue, 19 Sep 2000 08:50:39 -0700 (PDT) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 73621A8D; Tue, 19 Sep 2000 11:50:39 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 11C522B3A; Tue, 19 Sep 2000 11:50:39 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id LAA0000540712; Tue, 19 Sep 2000 11:50:02 -0400 (EDT) From: Jim Bound Message-Id: <200009191550.LAA0000540712@anw.zk3.dec.com> To: Vladislav Yasevich Cc: Jim Bound , Brian Zill , "'Hideaki YOSHIFUJI'" , mauro@ferrara.linux.it, ipng@sunroof.eng.sun.com, project6-devel@ferrara.linux.it, bound@zk3.dec.com Subject: Re: getaddrinfo In-reply-to: Your message of "Tue, 19 Sep 2000 10:14:28 EDT." <39C774C3.C1161092@zk3.dec.com> Date: Tue, 19 Sep 2000 11:50:02 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vlad, You miss the point completely. I agree with you but nothing in the curent wording in the spec "prevents" it from being interrupted that way. The getnameinfo() is the best argument thus far. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 19 10:31:25 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8JHTY210869 for ipng-dist; Tue, 19 Sep 2000 10:29:34 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8JHTSr10862 for ; Tue, 19 Sep 2000 10:29:29 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e8JHTL402603 for ipng@sunroof.eng.sun.com; Tue, 19 Sep 2000 10:29:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8J5uAr10195 for ; Mon, 18 Sep 2000 22:56:10 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA16494 for ; Mon, 18 Sep 2000 22:55:56 -0700 (PDT) Received: from tyholt.uninett.no (tyholt.uninett.no [158.38.60.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA06316 for ; Mon, 18 Sep 2000 22:55:55 -0700 (PDT) Received: from sverresborg.uninett.no (IDENT:root@sverresborg.uninett.no [158.38.60.92]) by tyholt.uninett.no (8.9.3/8.8.8) with ESMTP id HAA01072; Tue, 19 Sep 2000 07:55:51 +0200 (METDST) Received: (from venaas@localhost) by sverresborg.uninett.no (8.10.1/8.10.1) id e8J5xSO06796; Tue, 19 Sep 2000 07:59:28 +0200 Date: Tue, 19 Sep 2000 07:59:28 +0200 From: Stig Venaas To: Jim Bound Cc: Brian Zill , "'Hideaki YOSHIFUJI'" , mauro@ferrara.linux.it, ipng@sunroof.eng.sun.com, project6-devel@ferrara.linux.it Subject: Re: [Project6-devel] Re: getaddrinfo Message-ID: <20000919075928.A6790@sverresborg.uninett.no> References: <9B9A5456AFE99E4181416B252F63BDA2212450@red-msg-05.redmond.corp.microsoft.com> <200009190329.XAA0000783352@anw.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200009190329.XAA0000783352@anw.zk3.dec.com>; from bound@zk3.dec.com on Mon, Sep 18, 2000 at 11:29:12PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Sep 18, 2000 at 11:29:12PM -0400, Jim Bound wrote: > Brian, > > Let me clarify. I think its crazy too. But what I was beaten in to > believe and I think XNET was too is that implementors want this? Yes, this sounds crazy to me as well. I can't see why someone wants this, I've also carefully checked the specs (also XNET) and I can't find anything saying this should be possible. Stig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 19 10:37:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8JHahQ10930 for ipng-dist; Tue, 19 Sep 2000 10:36:43 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8JHaYr10923 for ; Tue, 19 Sep 2000 10:36:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA17719 for ; Tue, 19 Sep 2000 10:36:35 -0700 (PDT) Received: from smtp3.libero.it (smtp3.libero.it [193.70.192.53]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05069 for ; Tue, 19 Sep 2000 11:36:33 -0600 (MDT) Received: from trantor.ferrara.linux.it (151.20.139.10) by smtp3.libero.it; 19 Sep 2000 19:36:28 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id 5766A4D89B; Tue, 19 Sep 2000 18:59:29 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 550794D89A; Tue, 19 Sep 2000 18:59:29 +0200 (CEST) Date: Tue, 19 Sep 2000 18:59:29 +0200 (CEST) From: Mauro Tortonesi To: Hideaki YOSHIFUJI Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, project6-devel@ferrara.linux.it Subject: Re: getaddrinfo In-Reply-To: <20000919093306V.yoshfuji@ecei.tohoku.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 19 Sep 2000, Hideaki YOSHIFUJI wrote: > In article <200009190014.UAA0000766427@anw.zk3.dec.com> (at Mon, 18 Sep 2000 20:14:40 -0400), Jim Bound says: > > > >getaddrinfo("xxx:xxx::xxx", NULL, &res) > > > > > >should return the full results of a query to the DNS for address "xxx...", > > >and not only a struct sockaddr_in6 filled with the address "xxx...", imo. > > >is this correct? > > What do you mean by "full results," Mauro? simply the result of a query to the dns ;) -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.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 Sep 19 10:38:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8JHbEE10942 for ipng-dist; Tue, 19 Sep 2000 10:37:14 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8JHb0r10935 for ; Tue, 19 Sep 2000 10:37:00 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA20565 for ; Tue, 19 Sep 2000 10:36:59 -0700 (PDT) Received: from smtp1.libero.it (smtp1.libero.it [193.70.192.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09673 for ; Tue, 19 Sep 2000 10:36:42 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.20.139.10) by smtp1.libero.it; 19 Sep 2000 19:36:32 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id 759634D7A4; Tue, 19 Sep 2000 19:06:56 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 6EE814D7A0; Tue, 19 Sep 2000 19:06:56 +0200 (CEST) Date: Tue, 19 Sep 2000 19:06:56 +0200 (CEST) From: Mauro Tortonesi To: Brian Zill Cc: "'Hideaki YOSHIFUJI'" , bound@zk3.dec.com, IETF - IPng Working Group , project6-devel@ferrara.linux.it Subject: RE: getaddrinfo In-Reply-To: <9B9A5456AFE99E4181416B252F63BDA2212450@red-msg-05.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 18 Sep 2000, Brian Zill wrote: > > From: Hideaki YOSHIFUJI [mailto:yoshfuji@ecei.tohoku.ac.jp] > > > > In article <200009190014.UAA0000766427@anw.zk3.dec.com> (at > > Mon, 18 Sep 2000 20:14:40 -0400), Jim Bound says: > > > > > >getaddrinfo("xxx:xxx::xxx", NULL, &res) > > > > > > > >should return the full results of a query to the DNS for > > address "xxx...", > > > >and not only a struct sockaddr_in6 filled with the address > > "xxx...", imo. > > > >is this correct? > > > > What do you mean by "full results," Mauro? > > Yes, what are you asking? In your earlier message you asked: > > > first, suppose that the nodename argument is a numeric host > > address and the flag AI_NUMERICHOST is not set. will the > > query to getaddrinfo return ALL addresses of that host? > > Are you saying that if one gives it a literal address, it should do a > reverse lookup to figure out what name that corresponds to and then do a > forward lookup to find all the addresses for that host? Personally, I think > that's crazy! If you want that behavior, you should use getnameinfo to get > the name, and then feed the name into getaddrinfo. getaddrinfo shouldn't be > doing reverse lookups, that's what getnameinfo is for. The AI_NUMERICHOST > flag should have no effect if you give getaddrinfo an address literal. It's > purpose is to prevent DNS lookups in the case where you don't give > getaddrinfo an address literal. i am not as expert as you are, but if you read the latest draft-rfc2553bis with a bit of logic, you will find that my interpretation of the text is not wrong ;) please, would you tell me why you consider this a bad behaviour? thank you. -- Aequam memento rebus in arduis servare mentem... Mauro Tortonesi mauro@ferrara.linux.it Ferrara Linux User Group http://www.ferrara.linux.it Project6 - IPv6 for Linux http://project6.ferrara.linux.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 Sep 19 10:43:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8JHfeL10977 for ipng-dist; Tue, 19 Sep 2000 10:41:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8JHfVr10970 for ; Tue, 19 Sep 2000 10:41:31 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA21844 for ; Tue, 19 Sep 2000 10:41:31 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11218 for ; Tue, 19 Sep 2000 10:41:30 -0700 (PDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id CAA03692; Wed, 20 Sep 2000 02:41:20 +0900 To: mauro@ferrara.linux.it Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, project6-devel@ferrara.linux.it Subject: Re: getaddrinfo In-Reply-To: References: <20000919093306V.yoshfuji@ecei.tohoku.ac.jp> X-Mailer: Mew version 1.94 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000920024120S.yoshfuji@ecei.tohoku.ac.jp> Date: Wed, 20 Sep 2000 02:41:20 +0900 From: Hideaki YOSHIFUJI (=?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) X-Dispatcher: imput version 990905(IM130) Lines: 13 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article (at Tue, 19 Sep 2000 18:59:29 +0200 (CEST)), Mauro Tortonesi says: > > What do you mean by "full results," Mauro? > > simply the result of a query to the dns ;) For what? You should show us FULL example code and result; don't try to describe. -- Hideaki YOSHIFUJI @ USAGI Project Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 19 10:56:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8JHtaA11049 for ipng-dist; Tue, 19 Sep 2000 10:55:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8JHtQr11042 for ; Tue, 19 Sep 2000 10:55:27 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA23085 for ; Tue, 19 Sep 2000 10:55:27 -0700 (PDT) Received: from zmamail01.zma.compaq.com (zmamail01.zma.compaq.com [161.114.64.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05896 for ; Tue, 19 Sep 2000 10:55:16 -0700 (PDT) Received: by zmamail01.zma.compaq.com (Postfix, from userid 12345) id 489296B99; Tue, 19 Sep 2000 13:55:16 -0400 (EDT) Received: from oflume.zk3.dec.com (bryflume.zk3.dec.com [16.141.40.17]) by zmamail01.zma.compaq.com (Postfix) with ESMTP id 1375A4EC5; Tue, 19 Sep 2000 13:55:16 -0400 (EDT) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id NAA0000028638; Tue, 19 Sep 2000 13:55:15 -0400 (EDT) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA04416; Tue, 19 Sep 2000 13:55:14 -0400 Message-Id: <39C7A882.4CCDCEF@zk3.dec.com> Date: Tue, 19 Sep 2000 13:55:14 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: ru, en Mime-Version: 1.0 To: Stig Venaas Cc: Jim Bound , Brian Zill , "'Hideaki YOSHIFUJI'" , mauro@ferrara.linux.it, ipng@sunroof.eng.sun.com, project6-devel@ferrara.linux.it Subject: Re: [Project6-devel] Re: getaddrinfo References: <9B9A5456AFE99E4181416B252F63BDA2212450@red-msg-05.redmond.corp.microsoft.com> <200009190329.XAA0000783352@anw.zk3.dec.com> <20000919075928.A6790@sverresborg.uninett.no> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Stig After Jim told me that I missed his point, I went back through XNET 5.2 and 2553-bis and they are both very vague on the issue (not the fault of 2553-bis since it tryes to use the same wording as XNET 5.2). There is nothing there that says it should be possible. There is nothing there that says that this should NOT be possible either. IMHO, this is yet another one of those ambiguities that needs to be clarified by XNET (not the api draft). -vlad Stig Venaas wrote: > > On Mon, Sep 18, 2000 at 11:29:12PM -0400, Jim Bound wrote: > > Brian, > > > > Let me clarify. I think its crazy too. But what I was beaten in to > > believe and I think XNET was too is that implementors want this? > > Yes, this sounds crazy to me as well. I can't see why someone wants > this, I've also carefully checked the specs (also XNET) and I can't > find anything saying this should be possible. > > Stig > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 02:17:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8K9F1Y11544 for ipng-dist; Wed, 20 Sep 2000 02:15:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8K9Epr11537 for ; Wed, 20 Sep 2000 02:14:51 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA06121 for ; Wed, 20 Sep 2000 02:14:49 -0700 (PDT) Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA23199 for ; Wed, 20 Sep 2000 02:14:48 -0700 (PDT) Received: from trantor.ferrara.linux.it (151.20.132.251) by smtp2.libero.it; 20 Sep 2000 11:14:39 +0200 Received: by trantor.ferrara.linux.it (Postfix, from userid 501) id 090574D8E8; Wed, 20 Sep 2000 10:59:09 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by trantor.ferrara.linux.it (Postfix) with ESMTP id 070994D8E1; Wed, 20 Sep 2000 10:59:09 +0200 (CEST) Date: Wed, 20 Sep 2000 10:59:08 +0200 (CEST) From: Mauro Tortonesi To: Hideaki YOSHIFUJI Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, project6-devel@ferrara.linux.it Subject: Re: getaddrinfo In-Reply-To: <20000920024120S.yoshfuji@ecei.tohoku.ac.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 20 Sep 2000, Hideaki YOSHIFUJI wrote: > In article (at Tue, 19 Sep 2000 18:59:29 +0200 (CEST)), Mauro Tortonesi says: > > > > What do you mean by "full results," Mauro? > > > > simply the result of a query to the dns ;) > > For what? > You should show us FULL example code and result; don't try to describe. source code is not very significant. it simply contains the call: memset(&ai, 0, sizeof(ai)); ai.ai_family = AF_UNSPEC; ai.ai_protocol = IPPROTO_TCP; ai.ai_flags = AI_CANONNAME; if ((err = getaddrinfo(host,"finger", &ai, &res)) != 0 || !res) { eprintf("finger: getaddrinfo failure: %s\n", gai_strerror(err)); return; } where host is "fe80::248:54ff:fe4b:1c6f". the results are: res dumped: flags: AI_CANONNAME AI_ALL family: AF_INET6 socket type: SOCK_STREAM protocol: 6 ip address length: 24 canonic name: trantorv6 res->ai_addr dumped: family: AF_INET6 port: 79 address: fe80::248:54ff:fe4b:1c6f no query to the dns is done. -- Mauro Tortonesi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 20 09:53:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8KGpbb11830 for ipng-dist; Wed, 20 Sep 2000 09:51:37 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8KGpWr11823 for ; Wed, 20 Sep 2000 09:51:33 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e8KGpPr03755 for ipng@sunroof.eng.sun.com; Wed, 20 Sep 2000 09:51:25 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8KEO1r11743 for ; Wed, 20 Sep 2000 07:24:01 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA27780 for ; Wed, 20 Sep 2000 07:24:01 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18918 for ; Wed, 20 Sep 2000 07:24:00 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id A07CC2F1; Wed, 20 Sep 2000 10:24:00 -0400 (EDT) Received: from exctay-gh02.tay.cpqcorp.net (exctay-gh02.tay.cpqcorp.net [16.103.129.52]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 9732D8B4 for ; Wed, 20 Sep 2000 10:24:00 -0400 (EDT) Received: by exctay-gh02.tay.cpqcorp.net with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Sep 2000 10:23:59 -0400 Message-ID: From: "Powell, Ken" To: "'richdr@microsoft.com'" , "'ipng@sunroof.eng.sun.com'" Cc: "Yasevich, Vladislav" Subject: draft-ietf-ipngwg-addr-select-01: destination selection comments Date: Wed, 20 Sep 2000 10:23:56 -0400 X-Mailer: Internet Mail Service (5.5.2650.21) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Richard, I was talking to Vlad Yasevich here at Compaq about your spec. Vlad has detailed knowledge about how getaddrinfo is implemented and understands Xnet issues far better than I. After discussing how the implementation works and what the likely impacts of your spec are, we decided to make the following additional comments. 1) We believe use of source address selection results during destination address selection is probably going to cause more trouble than its worth for the following reasons: o Under the socket API, destination address selection is performed by getaddrinfo. getaddrinfo does not have sufficient information to perform source address selection accurately every time, particularly on multi-interface nodes. o getaddrinfo is already a very complex function with its requirement to handle all sorts of address family and protocol combinations. It will be difficult to specify these additional requirements in the context of all the other getaddrinfo requirements. The likelihood Xnet would accept such a change is questionable. o In IPv4, getaddrinfo is capable of sorting destination addresses according to a list of address prefixes stored in /etc/resolv.conf. This is similar to the prefixes in your precedence table. There should be no problem selecting the correct destination address if this table is defined correctly (more on that later). We ask that you remove rules 1 and 3 from destination address selection. 2) We believe implementations should default to prefer higher scope destination addresses over lower scope destination addresses. Global scope destination addresses are most likely to be reachable when given the limited information getaddrinfo has available. As for the desire to allow some sites to avoid renumbering problems through the use of site-local destinations, we believe other methods make just as much sense: o Use a separate namespace for an organization's key site-local addresses. o Define the destination address precedence table on each node in the site to prefer site- locals. Yes, there is no way to easily do this now, but it is something that could be added through a future tool. 3) You mentioned in a previous message that you were going to remove scoped addresses from your default precedence table. This sounds like a good idea. It would allow us to "prefer lower scope source addresses" and "prefer higher scope destination addresses" at the same time. If you do this, I think the precedence table should take priority over the "prefer higher scoped destination addresses" rule. Ken Powell Compaq Computer Corporation -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 20 17:38:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8L0a8q12740 for ipng-dist; Wed, 20 Sep 2000 17:36:08 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8L0Zvr12733 for ; Wed, 20 Sep 2000 17:35:57 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8L0Zra318175; Wed, 20 Sep 2000 17:35:53 -0700 (PDT) Date: Wed, 20 Sep 2000 17:35:15 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-addr-select-01: destination selection comments To: "Powell, Ken" Cc: "'richdr@microsoft.com'" , "'ipng@sunroof.eng.sun.com'" , "Yasevich, Vladislav" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ken, I'm offering some alternative opinions here. > 1) We believe use of source address selection results > during destination address selection is probably > going to cause more trouble than its worth for > the following reasons: > > o Under the socket API, destination address > selection is performed by getaddrinfo. > getaddrinfo does not have sufficient > information to perform source address > selection accurately every time, particularly > on multi-interface nodes. I agree that getaddrinfo needs to consult the kernel (or IP stack) in many/most cases when it has more than one IP address to return. In Solaris we've done this for IPv4 addresses in gethostbyname for about 10 years unless I'm mistaken. It is true that with IPv6 it is likely that there be more FQDNs returning more than one IP address than for IPv4, but I'm still not concerned with the overhead of an extra ioctl (or whatever an implementation chooses to use) since this is small compared to the cost of doing the actual DNS query. > o getaddrinfo is already a very complex function > with its requirement to handle all sorts of > address family and protocol combinations. It > will be difficult to specify these additional > requirements in the context of all the other > getaddrinfo requirements. The likelihood Xnet > would accept such a change is questionable. I think it is relatively easy to find the place in a getaddrinfo implementation that deals with the IP address and insert if (more than one IP address) ask kernel to order them > 2) We believe implementations should default to prefer > higher scope destination addresses over lower scope > destination addresses. Global scope destination > addresses are most likely to be reachable when given > the limited information getaddrinfo has available. > > As for the desire to allow some sites to avoid > renumbering problems through the use of site-local > destinations, we believe other methods make just as > much sense: > > o Use a separate namespace for an organization's > key site-local addresses. Do you have a concrete proposal? The only way I can think of doing this involves - ICANN allocating a special tld for the local addresses, and - applications like web servers know do on the fly use different URLs in the HTML depending on who is asking for the page (e.g. http://foo.local/xyz vs. http://foo.example.com/xyz) This is problematic both at the political level and at the technical level. And the foo.local URLs are sure to "leak" outside the site e.g. by being included in email messages. Thus it would be good to have a bit more detail on your proposal before we take it for given that it is the best way to proceed. Thanks, Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 21 02:52:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8L9ohs13532 for ipng-dist; Thu, 21 Sep 2000 02:50:43 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8L9oYr13525 for ; Thu, 21 Sep 2000 02:50:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA02487 for ; Thu, 21 Sep 2000 02:50:33 -0700 (PDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA28631 for ; Thu, 21 Sep 2000 03:50:30 -0600 (MDT) Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id e8L9p2X29382 for ; Thu, 21 Sep 2000 11:51:07 +0200 (MET DST) Received: from alcatel.be ([138.203.65.10]) by bemail04.net.alcatel.be (Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) with SMTP id C1256961.00360516; Thu, 21 Sep 2000 11:50:02 +0200 Message-ID: <39C9D9A3.3E1E2A60@alcatel.be> Date: Thu, 21 Sep 2000 11:49:23 +0200 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: link/site local prefixes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Probably this is something that is asked many times before, but I am completely new to the subject and there is no flat mailing list archive to do a search. As far as I understand the two below extracts of RFC2373 contain a contradiction. So is the prefix of link-local 1111111010/10 (fraction is 1/1024) or 111111101000::/64 (fraction is 1/2**64)? Same question for site-local. dirk Allocation Prefix Fraction of (binary) Address Space ----------------------------------- -------- ------------- Link-Local Unicast Addresses 1111 1110 10 1/1024 ... 2.5.8 Local-Use IPv6 Unicast Addresses There are two types of local-use unicast addresses defined. These are Link-Local and Site-Local. The Link-Local is for use on a single link and the Site-Local is for use in a single site. Link-Local addresses have the following format: | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 21 03:34:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8LAWvq13587 for ipng-dist; Thu, 21 Sep 2000 03:32:57 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8LAWmr13580 for ; Thu, 21 Sep 2000 03:32:48 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA11418 for ; Thu, 21 Sep 2000 03:32:47 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA09947 for ; Thu, 21 Sep 2000 04:32:45 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e8LAWBu18578; Thu, 21 Sep 2000 12:32:11 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA22445; Thu, 21 Sep 2000 12:32:10 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id MAA31869; Thu, 21 Sep 2000 12:34:06 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200009211034.MAA31869@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Dirk Ooms cc: ipng@sunroof.eng.sun.com Subject: Re: link/site local prefixes In-reply-to: Your message of Thu, 21 Sep 2000 11:49:23 +0200. <39C9D9A3.3E1E2A60@alcatel.be> Date: Thu, 21 Sep 2000 12:34:06 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Probably this is something that is asked many times before, but I am completely new to the subject and there is no flat mailing list archive to do a search. As far as I understand the two below extracts of RFC2373 contain a contradiction. So is the prefix of link-local 1111111010/10 (fraction is 1/1024) or 111111101000::/64 (fraction is 1/2**64)? => it is fe80::/64 for all the links using a 64 bit interface ID (ie. all the links where IPv6 transport is currently defined). For site-locals the prefix is fec0::/48 because of the 16 bits for routing inside the site. Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 21 03:40:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8LAdn813610 for ipng-dist; Thu, 21 Sep 2000 03:39:49 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8LAdNr13603 for ; Thu, 21 Sep 2000 03:39:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA19292 for ; Thu, 21 Sep 2000 03:39:22 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA11837 for ; Thu, 21 Sep 2000 04:39:21 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02124; Thu, 21 Sep 2000 06:39:20 -0400 (EDT) Message-Id: <200009211039.GAA02124@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-addrconf-privacy-03.txt Date: Thu, 21 Sep 2000 06:39:20 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Author(s) : T. Narten, R. Draves Filename : draft-ietf-ipngwg-addrconf-privacy-03.txt Pages : 16 Date : 20-Sep-00 Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a DHCP server. Addresses are formed by combining network prefixes with an interface identifier. On interfaces that contain embedded IEEE Identifiers, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global-scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-03.txt Internet-Drafts are also 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-privacy-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-addrconf-privacy-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000920142251.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addrconf-privacy-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addrconf-privacy-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000920142251.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 Sep 21 06:35:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8LDY5S13682 for ipng-dist; Thu, 21 Sep 2000 06:34:05 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8LDXsr13675 for ; Thu, 21 Sep 2000 06:33:54 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA03809 for ; Thu, 21 Sep 2000 06:33:49 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA09303 for ; Thu, 21 Sep 2000 06:33:49 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA16966; Thu, 21 Sep 2000 08:33:44 -0500 (CDT) Message-Id: <200009211333.IAA16966@gungnir.fnal.gov> To: Dirk Ooms Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: link/site local prefixes In-reply-to: Your message of Thu, 21 Sep 2000 11:49:23 +0200. <39C9D9A3.3E1E2A60@alcatel.be> Date: Thu, 21 Sep 2000 08:33:44 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It's not quite a contradiction. The first excerpt says that every address matching fe80::/10 is reserved for link-local use. The second says that actual link-local addresses will use only the tiny fraction of that space which matches fe80::/64. You could consider the space in which the 54 bits just after the first 10 are not all zero to be either "wasted" or "reserved for future link-local variants". -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 21 06:55:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8LDqsW13706 for ipng-dist; Thu, 21 Sep 2000 06:52:54 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8LDqkr13699 for ; Thu, 21 Sep 2000 06:52:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA00725 for ; Thu, 21 Sep 2000 06:52:46 -0700 (PDT) Received: from rubellite.lion-access.net (rubellite.lion-access.net [212.19.217.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13836 for ; Thu, 21 Sep 2000 06:52:45 -0700 (PDT) Received: from joris (1Cust98.tnt21.rtm1.nl.uu.net [213.116.136.98]) by rubellite.lion-access.net (I-Lab) with SMTP id C6D242903 for ; Thu, 21 Sep 2000 13:52:20 +0000 (GMT) From: "Joris Dobbelsteen" To: "IPng WG (E-mail)" Subject: RE: (NAT) IPv6 and NAT Date: Thu, 21 Sep 2000 15:54:23 +0200 Message-ID: <000e01c023d3$736563b0$0d0aa8c0@THUIS.LOCAL> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <59063B5B4D98D311BC0D0001FA7E4522033B082C@l04.research.kpn.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Neuijen, S.M.J.G. > Sent: dinsdag 19 september 2000 17:33 > To: ipng@sunroof.eng.sun.com > Subject: RE: (NAT) IPv6 and NAT > > > > I happen to think that ISPs will charge a premium for > multiple and/or > stable > > v6 addresses because that is the status quo and because the > market will > bear > > it. Thus, I suspect that NAT will remain quite active > if/when IPv6 is > > deployed. > > Maybe they wan't do that anymore when their competitors offer the same > service for free, and why wouldn't they? IPv6 addresses, as > opposed to ipv4 > addresses, are NOT a scarse resource! > > So only one "FREE ISP" has to make the move..... > Agree, but /48 IPv6 subnets can be allocated many times more than IPv4 address are currently available. However /48 subnets for my home network would allow me to even connect all the bricks to the Internet (by matter of speaking), I think Free ISPs don't have to complain about someone allocating a /48 subnet or maybe smaller ones. Some simple calculations indicate ISPs can allocate many more clients if they only have /72 or /80 subnet. And give clients /48 subnets. So ISPs should actually not complain about giving you no subnet.... At least this is my opinion. Also this ensure end-to-end communication for even my refrigerator (not that it will that soon). Also it's more likely people get dedicted Internet connections, I think, like ADSL and Cable. We have seen that NAT was a mistake on the Internet. (I'm convinced about it now). I think the implementation of this over phone lines is not likely to happen suddenly (you don't have your modem online for 24 hours). > Saskia - Joris -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 21 07:41:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8LEeJ613796 for ipng-dist; Thu, 21 Sep 2000 07:40:19 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8LEeAr13789 for ; Thu, 21 Sep 2000 07:40:10 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA13113 for ; Thu, 21 Sep 2000 07:40:10 -0700 (PDT) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16191 for ; Thu, 21 Sep 2000 07:40:08 -0700 (PDT) Received: from bemail04.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with SMTP id e8LEeTP04016; Thu, 21 Sep 2000 16:40:29 +0200 (MET DST) Received: from alcatel.be ([138.203.65.10]) by bemail04.net.alcatel.be (Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) with SMTP id C1256961.0050544C; Thu, 21 Sep 2000 16:37:24 +0200 Message-ID: <39CA1CFB.56BFF456@alcatel.be> Date: Thu, 21 Sep 2000 16:36:43 +0200 From: Dirk Ooms X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Matt Crawford CC: ipng@sunroof.eng.sun.com Subject: Re: link/site local prefixes References: <200009211333.IAA16966@gungnir.fnal.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, The second excerpt says Link-Local addresses have the format fe80::/64, the first excerpt says 1/1024 of the address space is available for Link-Local addresses. To me this is a contradiction. It wouldn't have been a contradiction if the second excerpt would mention something like 'Link-Local of type x'. Anyway, I understand what is meant. Thanks, dirk Matt Crawford wrote: > > It's not quite a contradiction. The first excerpt says that every > address matching fe80::/10 is reserved for link-local use. The > second says that actual link-local addresses will use only the tiny > fraction of that space which matches fe80::/64. You could consider > the space in which the 54 bits just after the first 10 are not all > zero to be either "wasted" or "reserved for future link-local > variants". -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 21 11:58:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8LIv7X14074 for ipng-dist; Thu, 21 Sep 2000 11:57:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8LIuwr14067 for ; Thu, 21 Sep 2000 11:56:58 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA27388 for ; Thu, 21 Sep 2000 11:56:57 -0700 (PDT) Received: from ztxmail02.ztx.compaq.com (ztxmail02.ztx.compaq.com [161.114.1.206]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12348 for ; Thu, 21 Sep 2000 11:56:56 -0700 (PDT) Received: by ztxmail02.ztx.compaq.com (Postfix, from userid 12345) id 49A6E2933; Thu, 21 Sep 2000 13:56:56 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail02.ztx.compaq.com (Postfix) with ESMTP id AA656289B; Thu, 21 Sep 2000 13:56:55 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id OAA0000588780; Thu, 21 Sep 2000 14:56:46 -0400 (EDT) From: Jim Bound Message-Id: <200009211856.OAA0000588780@anw.zk3.dec.com> To: Erik Nordmark Cc: "Powell, Ken" , "'richdr@microsoft.com'" , "'ipng@sunroof.eng.sun.com'" , "Yasevich, Vladislav" , bound@zk3.dec.com Subject: Re: draft-ietf-ipngwg-addr-select-01: destination selection comments In-reply-to: Your message of "Wed, 20 Sep 2000 17:35:15 PDT." Date: Thu, 21 Sep 2000 14:56:46 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, >The only way I can think of doing this involves > - ICANN allocating a special tld for the local addresses, and > - applications like web servers know do on the fly use different URLs > in the HTML depending on who is asking for the page > (e.g. http://foo.local/xyz vs. http://foo.example.com/xyz) > >This is problematic both at the political level and at the technical level. >>And the foo.local URLs are sure to "leak" outside the site e.g. by being >included in email messages. But maybe we need to do this or we are not done with the site-local (or other non-global scope addresses in the IPng)??? >Thus it would be good to have a bit more detail on your proposal before >we take it for given that it is the best way to proceed. But there is a core architectural assumption here being proposed regardless if non-global scopes work. By axiom global scopes do work, can exist in the DNS, and will work end-to-end, so from common sense type engineering (I know an art being lost) prefer them. But I do see your point. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 21 19:08:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8M26a114550 for ipng-dist; Thu, 21 Sep 2000 19:06:36 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8M26Rr14543 for ; Thu, 21 Sep 2000 19:06:27 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA15124 for ; Thu, 21 Sep 2000 19:06:26 -0700 (PDT) Received: from hygro.adsl.duke.edu (hygro.adsl.duke.edu [152.16.64.159]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26266 for ; Thu, 21 Sep 2000 19:06:25 -0700 (PDT) Received: from hygro.adsl.duke.edu (IDENT:narten@localhost.localdomain [127.0.0.1]) by hygro.adsl.duke.edu (8.9.3/8.9.3) with ESMTP id RAA02123; Thu, 21 Sep 2000 17:22:20 -0400 Message-Id: <200009212122.RAA02123@hygro.adsl.duke.edu> To: ipng@sunroof.eng.sun.com cc: Richard Draves Subject: Re: I-D ACTION:draft-ietf-ipngwg-addrconf-privacy-03.txt In-Reply-To: Message from Internet-Drafts@ietf.org of "Thu, 21 Sep 2000 06:39:20 EDT." <200009211039.GAA02124@ietf.org> Date: Thu, 21 Sep 2000 17:22:20 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There are three changes in this new version relative to -02. 1) remove normative dependency on address selection draft. I.e., added text saying anonymous addresses would need to be given priority over public addresses when selecting source addresses. 2) In response to Matt Crawford's comment on DNS issues, removed the following sentence: [-One alternative is that DNS servers (for client machines) may need to fabricate "dummy" answers so that all addresses, whether used or not, appear to have DNS names associated with them.-] 3) removed the word "optional" in two places where the wording explicitely indicated that this spec is an optional part of IPv6. This is no change in practice, as the document is an elective standard with no requirement that it be implemented. However, removing the wording smooths the path for a possible follow-up applicability statement that could specify in more detail when anonymous addresses should be used without needing to update the current document. These updates address all the comments received during WG last call. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 22 10:23:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8MHLmg15136 for ipng-dist; Fri, 22 Sep 2000 10:21:48 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8MHLdr15129 for ; Fri, 22 Sep 2000 10:21:39 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA18553 for ; Fri, 22 Sep 2000 10:21:38 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10680 for ; Fri, 22 Sep 2000 10:21:37 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e8MHLYu33575 for ; Fri, 22 Sep 2000 19:21:35 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA07436 for ; Fri, 22 Sep 2000 19:21:33 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA38309 for ; Fri, 22 Sep 2000 19:23:36 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200009221723.TAA38309@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Subject: RFC 2460 4.1 notes 1 & 3 again Date: Fri, 22 Sep 2000 19:23:36 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One more time some people in the mobile IPv6 are doing a strange confusion between RFC 2460 4.1 notes 1 & 3 (about destination option headers) and mobile IPv6 draft. Then I propose: - we state the rationate for notes 1 & 3 (they seem not clear enough???) - we note to fix this for the RFC 2460 revision (in some years? :-) - we ask mobile IPv6 draft authors to state that the draft amends the RFC 2460. Perhaps this is already in the modifications asked by IESG? Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 22 12:11:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8MJ9Qv15321 for ipng-dist; Fri, 22 Sep 2000 12:09:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8MJ9Hr15314 for ; Fri, 22 Sep 2000 12:09:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA08488; Fri, 22 Sep 2000 12:09:15 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21277; Fri, 22 Sep 2000 12:09:15 -0700 (PDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA28420; Fri, 22 Sep 2000 12:08:43 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id e8MJ8ek04313; Fri, 22 Sep 2000 12:08:40 -0700 X-Virus-Scanned: Fri, 22 Sep 2000 12:08:40 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(WTS.12.69) smtpdjRjmP2; Fri, 22 Sep 2000 12:08:33 PDT Message-Id: <4.3.2.7.2.20000922115556.0210b5b8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Sep 2000 12:06:14 -0700 To: Erik.Nordmark@eng.sun.com From: Bob Hinden Subject: Request to Advance "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" Cc: scoya@ietf.org, deering@cisco.com, ipng@sunroof.eng.sun.com, narten@raleigh.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as an Proposed Standard: Title : Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Author(s) : T. Narten, R. Draves Filename : draft-ietf-ipngwg-addrconf-privacy-03.txt Pages : 16 Date : 20-Sep-00 A working group last call for this document was completed on August 17, 2000. The -03 version of the draft resolves issues raised during the working group last call. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Sep 22 13:47:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8MKg7915458 for ipng-dist; Fri, 22 Sep 2000 13:42:07 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8MKg2r15451 for ; Fri, 22 Sep 2000 13:42:03 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.0+Sun/8.11.0) id e8MKfph05406 for ipng@sunroof.eng.sun.com; Fri, 22 Sep 2000 13:41:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8LLWtr14256 for ; Thu, 21 Sep 2000 14:32:55 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA06190 for ; Thu, 21 Sep 2000 14:32:55 -0700 (PDT) Received: from southpass.baynetworks.com (ns2.BayNetworks.COM [134.177.3.16]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14886 for ; Thu, 21 Sep 2000 15:32:54 -0600 (MDT) Received: from mailhost.BayNetworks.COM (h8754.s84f5.BayNetworks.COM [132.245.135.84]) by southpass.baynetworks.com (8.9.1/8.9.1) with ESMTP id OAA29956 for ; Thu, 21 Sep 2000 14:24:14 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id RAA26227 for ; Thu, 21 Sep 2000 17:32:31 -0400 (EDT) Received: from kozi.engeast (kozi [192.32.150.115]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id RAA27438; Thu, 21 Sep 2000 17:32:30 -0400 for Received: from baynetworks.com by kozi.engeast (SMI-8.6/SMI-SVR4) id RAA10482; Thu, 21 Sep 2000 17:32:30 -0400 Message-ID: <39CA7E6E.C6498224@baynetworks.com> Date: Thu, 21 Sep 2000 17:32:30 -0400 From: Okoziem Allen X-Mailer: Mozilla 4.5 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: oallen@BayNetworks.COM Subject: Applications over IPv6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi , I am curious to know if there is any work currently being done with applications (TFTP, Telnet, FTP, Ping, Traceroute, etc ) with regards IPv6? Are there any white papers available? I found some information in RFC 1545 - FTP Over Big Address. And so far I have been told about RFC 2428 which is also on FTP. Any other information will be greatly appreciated! Thanks, ---Kozi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 23 08:46:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8NFjTP15962 for ipng-dist; Sat, 23 Sep 2000 08:45:29 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8NFjJr15955 for ; Sat, 23 Sep 2000 08:45:19 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA12894 for ; Sat, 23 Sep 2000 08:45:18 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26277 for ; Sat, 23 Sep 2000 08:45:17 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id RAA10275 for ipng@sunroof.eng.sun.com; Sat, 23 Sep 2000 17:45:15 +0200 (MET DST) Date: Sat, 23 Sep 2000 17:45:15 +0200 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: Applications over IPv6 Message-ID: <20000923174515.A10226@theory.cs.uni-bonn.de> References: <39CA7E6E.C6498224@baynetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <39CA7E6E.C6498224@baynetworks.com>; from okallen@nortelnetworks.com on Thu, Sep 21, 2000 at 05:32:30PM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Sep 21, 2000 at 05:32:30PM -0400, Okoziem Allen wrote: > I am curious to know if there is any work currently being done with > applications (TFTP, Telnet, FTP, Ping, Traceroute, etc ) On my favourite OS, telnet, ftp, ping and traceroute work. I never tried tftp... > with regards IPv6? Are there any white papers available? > I found some information in RFC 1545 - FTP Over Big Address. And > so far I have been told about RFC 2428 which is also on FTP. Any > other information will be greatly appreciated! Applications that do NOT transfer addresses over some data channel, but just use TCP or UDP, are just fine. For ping and traceroute, there are special version in some OSes, as the calling interface for v6 allows them to be written differently. Regards, -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 25 11:27:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8PIPQR17201 for ipng-dist; Mon, 25 Sep 2000 11:25:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8PIPCr17194 for ; Mon, 25 Sep 2000 11:25:13 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA25750 for ; Mon, 25 Sep 2000 11:25:11 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07319 for ; Mon, 25 Sep 2000 11:25:11 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10127; Mon, 25 Sep 2000 14:25:08 -0400 (EDT) Message-Id: <200009251825.OAA10127@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: Privacy Extensions for Stateless Address Autoconfiguration in IPv6 to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 25 Sep 2000 14:25:08 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider Privacy Extensions for Stateless Address Autoconfiguration in IPv6 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 October 9, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-03.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 25 12:27:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8PJPJk17284 for ipng-dist; Mon, 25 Sep 2000 12:25:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8PJP9r17277 for ; Mon, 25 Sep 2000 12:25:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA12974 for ; Mon, 25 Sep 2000 12:25:08 -0700 (PDT) Received: from firstclass.rit.edu (firstclass.isc.rit.edu [129.21.7.41]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA19054 for ; Mon, 25 Sep 2000 13:25:06 -0600 (MDT) Message-id: Date: Mon, 25 Sep 2000 15:31:20 -0400 Subject: VoIP and IPv6 To: ipng@sunroof.eng.sun.com From: "Amit Datta" MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! I am working on a thesis on Voice over IP with possible implementations of the same in a educational institution. All the available articles point out to the QoS problem IP has (basically lag>250ms) rendering it a wee bit untolerable. I know that VoIP works great in a controlled environment (LAN/WAN) and VoFR and VoATM is even better. I am looking at any article that might explain or clarify if IPv6 or IPnG will address this QoS issue and the voice packets prioritisation problem. Also, if any one can point me to Case Studies of busines corporations (cisco, lucent, any F500 company) that has sucessfully implemented VoIP over their private Intranets? Thanks! Any help would be a life saver. I have pretty much ran into a cul-de-sac here with my research. Cheers! Amit Datta Rochester Institute of Technology, Rochester, NY 14623 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 25 13:29:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8PKF4U17375 for ipng-dist; Mon, 25 Sep 2000 13:15:04 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8PKERr17340 for ; Mon, 25 Sep 2000 13:14:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA18071 for ; Mon, 25 Sep 2000 13:14:26 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA06618 for ; Mon, 25 Sep 2000 13:14:25 -0700 (PDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Sep 2000 13:13:55 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Mon, 25 Sep 2000 13:04:35 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8A0E037@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: "Powell, Ken" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-addr-select-01 comments Date: Mon, 25 Sep 2000 13:03:31 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I'd like to hear more feedback from the WG on this point. > > Should the suggestion of configurability be "SHOULD" or "MAY" > > or "may" or ??? > > > > I certainly agree it should be optional, but I'd like to > > encourage implementations to be configurable with mechanisms > > like policy table or equivalent functionality, because those > > mechanisms can be used in multi-homing situations (both sites > > connected to multiple ISPs and hosts with multiple > > interfaces) to control choices of source & destination address. > > > > I agree that this feature could be very useful in multi-homing > situations, but would it be used much? If each vendor implements > the management hooks their own way, network administrators would > quickly find the hassle of defining this information on every > node in a site out-weighs the benefits. I think it would be > reasonable for vendors to postpone implementation of this > mechanism until additional configuration tools are well defined. Hmm. This argument could apply reductio ad absurdum to every aspect of an implementation's configurability. For example, router's are configurable and there's no IETF standard for configuring them (maybe I'm just ignorant) but network administrators still find it useful to configure routers. In particular, RFC 2461 section 6.2.1 defines conceptual variables that MUST be configurable, but it does not specify a standard protocol or mechanism for configuring them. How is this any different from my draft specifying a conceptual policy table that SHOULD be configurable, but not having a standard protocol or mechanism for configuring it? > I think you may have missed the point of my question. The > default policy table contains the following lines: > > ::ffff:169.254.0.0/112 30 7 7 > ::ffff:10.0.0.0/104 20 8 8 > ::ffff:172.16.0.0/108 20 9 9 > ::ffff:192.168.0.0/112 20 10 10 > ::ffff:0:0/96 10 11 11 > > Instead of just: > > ::ffff:0:0/96 10 11 11 > > I was questioning if subdividing the V4-mapped addresses > in the table is a good thing. I've concluded that having policy entries for different scopes is not a good thing, it's getting in the way of the rules that deal with scoping. And see my reply to Brian - looks like we can't have v4-mapped addresses in the policy table at all. > I see your point. I'm not terribly concerned what happens > when both addresses are of insufficient scope. The network > configuration is clearly broken if it comes down to this > choice anyhow. How about something like: > > Rule 3a: Avoid insufficient scope for destination. > (i.e., avoid Scope Source < Scope Dest) If both > addresses have insufficient scope, prefer the one > with higher scope. > > Rule 4: Avoid deprecated addresses. > > Rule 3b: Prefer lower scope. > > > If we're going to simplify this, I actually favor just giving > > appropriate scope absolute priority over > > preferred/deprecated. The preferred/deprecated parts of the > > current rule 3 are a response to comments from Erik Nordmark, > > if I remember correctly. > > I wouldn't do that. We should support graceful renumbering > of a network from site-local addresses to global addresses. > In this situation, one would intentionally configure a router > to advertise a deprecated site-local prefix. You are describing a scenario where a site transitions from using both site-local & global addresses to only using global addresses? So a node A has global address Ag and site-local address As. And node B, that is trying to connect to A, has addresses Bg and Bs. Now the network administrator deprecates site-local addresses across the site. I think this would also result in the site-local addresses being removed from DNS. You don't want to have deprecated addresses in the DNS. So when node B looks up node A, it only finds Ag. And source address selection on node B will pick source address Bg. Maybe the point you are making applies to destination address selection. Would you want to see a destination address selection rule like this: when comparing destination addresses DA and DB, if Source(DA) is not deprecated and Source(DB) is deprecated, then sort DA before DB? > I don't think we should use MUST unless violating a rule breaks > interoperability. I agree with you that inconsistency between > implementations is not good. Still, we need to allow > implementations the freedom to deal with issues not foreseen > by us today. That's why I prefer words like RECOMMEND and > SHOULD on the order of the rules. OK, I think I buy this. Off hand, this means that candidate set definition and the source address selection rule(s) relating to scope would be MUST, and everything else would be SHOULD. For example, the source address selection rule saying that deprecated addresses should be avoided, would be SHOULD instead of MUST because it does not affect interoperability. Is everyone OK with this? > > Many of the individual rules are collected from other places. > > For example, avoiding deprecated addresses comes from RFC > > 2462. Preferring anonymous addresses comes from the privacy > > draft. The real contribution of this section isn't the rules > > themselves, it's supplying consistency by giving them an order. > > Agreed. Is there any other spec that specifies "avoid > insufficient scope"? Not in so many words, but draft-ietf-ipngwg-scoped-routing-03.txt can be construed that way. > I was thinking cost, QoS, performance, or even political/ > contractual considerations may become important factors > in address selection in the future. I can't say how, but > I can see why an implementer may need have such > considerations override most other rules. If Congress passes a law, I think that will supercede an IETF standard. :-) More seriously, see the MUST/SHOULD discussion above. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 25 13:29:49 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8PKF0B17373 for ipng-dist; Mon, 25 Sep 2000 13:15:00 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8PKEPr17338 for ; Mon, 25 Sep 2000 13:14:27 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA26132 for ; Mon, 25 Sep 2000 13:14:24 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA06606 for ; Mon, 25 Sep 2000 13:14:23 -0700 (PDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Sep 2000 13:13:53 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Mon, 25 Sep 2000 13:04:35 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8A0E038@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: Erik Nordmark , "Powell, Ken" Cc: "'ipng@sunroof.eng.sun.com'" , "Yasevich, Vladislav" Subject: RE: draft-ietf-ipngwg-addr-select-01: destination selection comme nts Date: Mon, 25 Sep 2000 13:03:31 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Erik below. There are many examples where the destination address selection really needs to know about the available source addresses. For example, suppose a DNS name resolves to two addresses, a 6to4 address A and a native global address B. If the node only has a 6to4 address itself, then it should sort A before B; if the node only has a native global address itself, it should sort B before A. Our getaddrinfo implementation uses an ioctl as Erik describes. This interacts well with our implementation of draft-ietf-ipngwg-site-prefixes-04.txt. The draft allows implementations that prefer not to use an ioctl, but instead do everything in user space, by caching in user space information about the node's source addresses. It's an implementation choice. I don't see the need for any XNET coordination or acceptance. The destination address selection is orthogonal to and independent of XNET's getaddrinfo specification. Rich > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Wednesday, September 20, 2000 5:35 PM > To: Powell, Ken > Cc: Richard Draves; 'ipng@sunroof.eng.sun.com'; Yasevich, Vladislav > Subject: Re: draft-ietf-ipngwg-addr-select-01: destination selection > comments > > > > Ken, > I'm offering some alternative opinions here. > > > 1) We believe use of source address selection results > > during destination address selection is probably > > going to cause more trouble than its worth for > > the following reasons: > > > > o Under the socket API, destination address > > selection is performed by getaddrinfo. > > getaddrinfo does not have sufficient > > information to perform source address > > selection accurately every time, particularly > > on multi-interface nodes. > > I agree that getaddrinfo needs to consult the kernel (or IP > stack) in many/most > cases when it has more than one IP address to return. In > Solaris we've done > this for IPv4 addresses in gethostbyname for about 10 years unless I'm > mistaken. It is true that with IPv6 it is likely that there > be more FQDNs > returning more than one IP address than for IPv4, but I'm > still not concerned > with the overhead of an extra ioctl (or whatever an > implementation chooses to > use) since this is small compared to the cost of doing the > actual DNS query. > > > o getaddrinfo is already a very complex function > > with its requirement to handle all sorts of > > address family and protocol combinations. It > > will be difficult to specify these additional > > requirements in the context of all the other > > getaddrinfo requirements. The likelihood Xnet > > would accept such a change is questionable. > > I think it is relatively easy to find the place in a getaddrinfo > implementation that deals with the IP address and insert > if (more than one IP address) > ask kernel to order them > > > > 2) We believe implementations should default to prefer > > higher scope destination addresses over lower scope > > destination addresses. Global scope destination > > addresses are most likely to be reachable when given > > the limited information getaddrinfo has available. > > > > As for the desire to allow some sites to avoid > > renumbering problems through the use of site-local > > destinations, we believe other methods make just as > > much sense: > > > > o Use a separate namespace for an organization's > > key site-local addresses. > > Do you have a concrete proposal? > The only way I can think of doing this involves > - ICANN allocating a special tld for the local addresses, and > - applications like web servers know do on the fly use different URLs > in the HTML depending on who is asking for the page > (e.g. http://foo.local/xyz vs. http://foo.example.com/xyz) > > This is problematic both at the political level and at the > technical level. > And the foo.local URLs are sure to "leak" outside the site > e.g. by being > included in email messages. > > Thus it would be good to have a bit more detail on your > proposal before > we take it for given that it is the best way to proceed. > > Thanks, > Erik > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 25 13:29:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8PKF6D17376 for ipng-dist; Mon, 25 Sep 2000 13:15:06 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8PKEar17358 for ; Mon, 25 Sep 2000 13:14:37 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA18116 for ; Mon, 25 Sep 2000 13:14:35 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA06645 for ; Mon, 25 Sep 2000 13:14:33 -0700 (PDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Sep 2000 13:14:03 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Mon, 25 Sep 2000 13:04:24 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8A0E036@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: Jim Bound Cc: "'Powell, Ken'" , ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipngwg-addr-select-01 comments Date: Mon, 25 Sep 2000 13:03:31 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't agree we can declare this in the spec. How we word > it I am not > sure yet. But mobile nodes will use global addresses not > site-local if > they are roaming across routing realms. Site-local simply won't work. You are getting at the interaction between site-local addresses and mobility. Can a mobile node have a site-local home address as well as a global home address? If the implementation does not support mobility for scoped addresses, then the destination address selection will need to be modified. How about a rule like this: if you are comparing two destination addresses DA and DB, and Source(DA) is a home address and Source(DB) is not a home address, then sort DA before DB. In this example, DA would be a global address and Source(DA) would be a global home address. DB would be a site-local address and Source(DB) would be a site-local address, but not a home address. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 25 13:29:56 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8PKF2217374 for ipng-dist; Mon, 25 Sep 2000 13:15:02 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8PKEXr17347 for ; Mon, 25 Sep 2000 13:14:33 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA29260 for ; Mon, 25 Sep 2000 13:14:30 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA06604 for ; Mon, 25 Sep 2000 13:14:22 -0700 (PDT) Received: from 157.54.9.100 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 25 Sep 2000 13:13:51 -0700 (Pacific Daylight Time) Received: by INET-IMC-03 with Internet Mail Service (5.5.2651.58) id ; Mon, 25 Sep 2000 13:04:24 -0700 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8A0E034@red-msg-06.redmond.corp.microsoft.com> From: Richard Draves To: Brian Zill , "'Powell, Ken'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: draft-ietf-ipngwg-addr-select-01 comments Date: Mon, 25 Sep 2000 13:03:30 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think the point Ken was making, which I agreed with, is that when you are sending to an IPv4 destination address, you have to use an IPv4 source address. And when you are sending to an IPv6 destination address, you have to use an IPv6 source address. I think the point you are making is that according to draft-ietf-ngtrans-siit-07.txt, there will be cases where an IPv6 node will be sending an IPv6 packet to an IPv4-mapped IPv6 destination address. In other words, IPv4-mapped IPv6 addresses can appear on the wire in IPv6 packets. This means that my draft can not unambiguously use IPv4-mapped addresses as a convenient representation for IPv4 addresses. Sigh. [Btw, won't this be a big source of confusion for applications? I can forsee an app that supports both IPv6 & IPv4 doing a getpeername on an IPv6 socket and getting back an IPv4-mapped address - might this lead to problems, like the app thinking the socket is sending IPv4 packets???] Here is one possible fix (maybe an improvement, actually) that occurs to me: a) the policy table only contains policies for IPv6 addresses, not IPv4 addresses b) so remove all the IPv4-mapped policies from the policy table c) the source address selection algorithm only applies to IPv6 addresses. candidate set definition does not need to say anything about IPv4-mapped addresses. d) the destination address selection algorithm (which is dealing with both IPv4 and IPv6 destination addresses) still has a need to know what IPv4 source address will be used for an IPv4 destination address e) but this IPv4 source address selection is left unspecified in my draft Comments? Rich > -----Original Message----- > From: Brian Zill > Sent: Friday, September 08, 2000 8:46 PM > To: Richard Draves; 'Powell, Ken' > Cc: ipng@sunroof.eng.sun.com > Subject: RE: draft-ietf-ipngwg-addr-select-01 comments > > > > > Page 6, Section 3 > > > > > > Should an additional restriction like the following be > > > added to the candidate set of source addresses? > > > > > > "For IPv4 Mapped destination addresses, the set of > > > candidate source addresses must only include IPv4 Mapped > > > addresses. For any other destination address, the set > > > of candidate source addresses MUST NOT include IPv4 > > > Mapped addresses." > > > > Yes. > > No :-) > > In the first quoted sentence, the set of candidate source > addresses must also include IPv4 *Translated* addresses, or > nodes in a SIIT cloud won't work. And on the other end, > translators need to be able to send from IPv4 Mapped > addresses to IPv4 Translated addresses. > > So how about: > > "For IPv4 Mapped destination addresses, the set of > candidate source addresses must only include IPv4 > Mapped and IPv4 Translated addresses. For any other > destination address, the set of candidate source > addresses MUST NOT include IPv4 Mapped addresses." > > Note I didn't change this to regulate the use of IPv4 > translated addresses as destination addresses, since a node > inside a SIIT cloud should be able to talk to other local > nodes using its translated address even if the other node has > a regular (i.e. non-translated IPv4) IPv6 address. Or at > least I believe it should. However, I think allowing this > means that for source address selection purposes, IPv4 > translated addresses should get less preference than global > addresses - they're essentially a weird kind of site-local addresses. > > But if you wanted to restrict the use of translated addresses > just to communication with the translator, you could say > something like: > > "For an IPv4 Mapped or IPv4 Translated destination > address, the set of candidate source addresses must > only include IPv4 Mapped and IPv4 Translated addresses. > For any other destination address, the set of candidate > source addresses MUST NOT include IPv4 Mapped addresses > or IPv4 Translated addresses." > > But my vote's for my first one. > > --Brian > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 25 14:29:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8PLSAK17534 for ipng-dist; Mon, 25 Sep 2000 14:28:10 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8PLRxr17527 for ; Mon, 25 Sep 2000 14:28:00 -0700 (PDT) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8PLRZe915453; Mon, 25 Sep 2000 14:27:36 -0700 (PDT) Date: Mon, 25 Sep 2000 14:27:33 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: draft-ietf-ipngwg-addr-select-01 comments To: Richard Draves Cc: Brian Zill , "'Powell, Ken'" , "'ipng@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <7695E2F6903F7A41961F8CF888D87EA8A0E034@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think the point you are making is that according to > draft-ietf-ngtrans-siit-07.txt, there will be cases where an IPv6 node will > be sending an IPv6 packet to an IPv4-mapped IPv6 destination address. In > other words, IPv4-mapped IPv6 addresses can appear on the wire in IPv6 > packets. > > This means that my draft can not unambiguously use IPv4-mapped addresses as > a convenient representation for IPv4 addresses. Sigh. Why not? I fail to see an actual problem caused by the intersection of SIIT and the default address selection rules. The (perhaps unstated) assumtion in SIIT is that SIIT doesn't make sense on a dual stack node configured with both IPv4 and IPv6 addresses. Thus the only choice for an IPv6-only node supporting SIIT when phased with an IPv4 destination or an IPv4-mapped IPv6 destination is to send IPv6 packets to the IPv4-mapped address. The thing the default address draft might not cover (I haven't read it carefully yet) is the need for such a node to use an IPv4-translatable source address when sending to an IPv4-mapped destination. If we fix this then are there other problems? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Sep 25 23:19:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8Q6Hd917807 for ipng-dist; Mon, 25 Sep 2000 23:17:39 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8Q6HUr17800 for ; Mon, 25 Sep 2000 23:17:30 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA18620 for ; Mon, 25 Sep 2000 23:17:30 -0700 (PDT) Received: from zmamail02.zma.compaq.com (zmamail02.zma.compaq.com [161.114.64.102]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07185 for ; Mon, 25 Sep 2000 23:17:30 -0700 (PDT) Received: by zmamail02.zma.compaq.com (Postfix, from userid 12345) id F283424D; Tue, 26 Sep 2000 02:17:29 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail02.zma.compaq.com (Postfix) with ESMTP id AEFCD1A7; Tue, 26 Sep 2000 02:17:29 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id CAA0000811735; Tue, 26 Sep 2000 02:17:10 -0400 (EDT) From: Jim Bound Message-Id: <200009260617.CAA0000811735@anw.zk3.dec.com> To: Richard Draves Cc: Jim Bound , "'Powell, Ken'" , ipng@sunroof.eng.sun.com, bound@zk3.dec.com Subject: Re: draft-ietf-ipngwg-addr-select-01 comments In-reply-to: Your message of "Mon, 25 Sep 2000 13:03:31 PDT." <7695E2F6903F7A41961F8CF888D87EA8A0E036@red-msg-06.redmond.corp.microsoft.com> Date: Tue, 26 Sep 2000 02:17:09 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, >> I don't agree we can declare this in the spec. How we word >> it I am not >> sure yet. But mobile nodes will use global addresses not >> site-local if >> they are roaming across routing realms. Site-local simply won't work. >You are getting at the interaction between site-local addresses and >mobility. Can a mobile node have a site-local home address as well as a >global home address? If the implementation does not support mobility for >scoped addresses, then the destination address selection will need to be >modified. I see that too. But I am coming from a much stronger issue. I do not think the src addr selection work should prefer less scope over greater scope or equal scope ever as a default. >How about a rule like this: if you are comparing two destination addresses >DA and DB, and Source(DA) is a home address and Source(DB) is not a home >address, then sort DA before DB. Thats fine but this is getting out of control now we have this to check. But this sounds right. But I really think if this causes any performance issues for servers that handle 50,000 requests and many simultaneously this entire source address selection algorithm/config will get shut off and rely on DNS ordering which can be done too at least with BIND DNS. I strongly suggest we have a common set of sorts that are basic and to what we have deployed today plus 6t04 and leave the others in the spec as TBD. No one has shipped a base OS product or router supporting scoping to the degree we are discussing hear and it has not been tested at any bakeoffs. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Sep 26 09:43:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8QGfXa18264 for ipng-dist; Tue, 26 Sep 2000 09:41:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8QGfNr18257 for ; Tue, 26 Sep 2000 09:41:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA25084; Tue, 26 Sep 2000 09:41:23 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01430; Tue, 26 Sep 2000 10:41:18 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw1.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id RAA12946; Tue, 26 Sep 2000 17:41:10 +0100 Received: from hursley.ibm.com (gsine03.us.sine.ibm.com [9.14.6.43]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA28348; Tue, 26 Sep 2000 17:41:05 +0100 (BST) Message-ID: <39D0D1A3.B6FA8D8B@hursley.ibm.com> Date: Tue, 26 Sep 2000 11:41:07 -0500 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Richard Draves CC: Erik Nordmark , "Powell, Ken" , "'ipng@sunroof.eng.sun.com'" , "Yasevich, Vladislav" Subject: Re: draft-ietf-ipngwg-addr-select-01: destination selection comments References: <7695E2F6903F7A41961F8CF888D87EA8A0E038@red-msg-06.redmond.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sure. If you don't have this algorithm, you have to put in a special case for 6to4 - which I really think would be a kludge. Brian Richard Draves wrote: > > I agree with Erik below. > > There are many examples where the destination address selection really needs > to know about the available source addresses. For example, suppose a DNS > name resolves to two addresses, a 6to4 address A and a native global address > B. If the node only has a 6to4 address itself, then it should sort A before > B; if the node only has a native global address itself, it should sort B > before A. > > Our getaddrinfo implementation uses an ioctl as Erik describes. This > interacts well with our implementation of > draft-ietf-ipngwg-site-prefixes-04.txt. > > The draft allows implementations that prefer not to use an ioctl, but > instead do everything in user space, by caching in user space information > about the node's source addresses. It's an implementation choice. > > I don't see the need for any XNET coordination or acceptance. The > destination address selection is orthogonal to and independent of XNET's > getaddrinfo specification. > > Rich > > > -----Original Message----- > > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > > Sent: Wednesday, September 20, 2000 5:35 PM > > To: Powell, Ken > > Cc: Richard Draves; 'ipng@sunroof.eng.sun.com'; Yasevich, Vladislav > > Subject: Re: draft-ietf-ipngwg-addr-select-01: destination selection > > comments > > > > > > > > Ken, > > I'm offering some alternative opinions here. > > > > > 1) We believe use of source address selection results > > > during destination address selection is probably > > > going to cause more trouble than its worth for > > > the following reasons: > > > > > > o Under the socket API, destination address > > > selection is performed by getaddrinfo. > > > getaddrinfo does not have sufficient > > > information to perform source address > > > selection accurately every time, particularly > > > on multi-interface nodes. > > > > I agree that getaddrinfo needs to consult the kernel (or IP > > stack) in many/most > > cases when it has more than one IP address to return. In > > Solaris we've done > > this for IPv4 addresses in gethostbyname for about 10 years unless I'm > > mistaken. It is true that with IPv6 it is likely that there > > be more FQDNs > > returning more than one IP address than for IPv4, but I'm > > still not concerned > > with the overhead of an extra ioctl (or whatever an > > implementation chooses to > > use) since this is small compared to the cost of doing the > > actual DNS query. > > > > > o getaddrinfo is already a very complex function > > > with its requirement to handle all sorts of > > > address family and protocol combinations. It > > > will be difficult to specify these additional > > > requirements in the context of all the other > > > getaddrinfo requirements. The likelihood Xnet > > > would accept such a change is questionable. > > > > I think it is relatively easy to find the place in a getaddrinfo > > implementation that deals with the IP address and insert > > if (more than one IP address) > > ask kernel to order them > > > > > > > 2) We believe implementations should default to prefer > > > higher scope destination addresses over lower scope > > > destination addresses. Global scope destination > > > addresses are most likely to be reachable when given > > > the limited information getaddrinfo has available. > > > > > > As for the desire to allow some sites to avoid > > > renumbering problems through the use of site-local > > > destinations, we believe other methods make just as > > > much sense: > > > > > > o Use a separate namespace for an organization's > > > key site-local addresses. > > > > Do you have a concrete proposal? > > The only way I can think of doing this involves > > - ICANN allocating a special tld for the local addresses, and > > - applications like web servers know do on the fly use different URLs > > in the HTML depending on who is asking for the page > > (e.g. http://foo.local/xyz vs. http://foo.example.com/xyz) > > > > This is problematic both at the political level and at the > > technical level. > > And the foo.local URLs are sure to "leak" outside the site > > e.g. by being > > included in email messages. > > > > Thus it would be good to have a bit more detail on your > > proposal before > > we take it for given that it is the best way to proceed. > > > > Thanks, > > Erik > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 09:51:38 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8RGo2D19097 for ipng-dist; Wed, 27 Sep 2000 09:50:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8RGnrr19090 for ; Wed, 27 Sep 2000 09:49:53 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA19844 for ; Wed, 27 Sep 2000 09:49:52 -0700 (PDT) Received: from firstclass.rit.edu (firstclass.isc.rit.edu [129.21.7.41]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06436 for ; Wed, 27 Sep 2000 09:49:52 -0700 (PDT) Message-id: Date: Wed, 27 Sep 2000 12:51:40 -0400 Subject: Re: RE: (NAT) IPv6 and NAT To: joris.dobbelsteen@mail.com Cc: ipng@sunroof.eng.sun.com From: "Amit Datta" References: <000e01c023d3$736563b0$0d0aa8c0@THUIS.LOCAL> In-Reply-To: <000e01c023d3$736563b0$0d0aa8c0@THUIS.LOCAL> MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! I am working on a thesis on Voice over IP with possible implementations of the same in a educational institution. All the available articles point out to the QoS problem IP has (basically lag>250ms) rendering it a wee bit untolerable. I know that VoIP works great in a controlled environment (LAN/WAN) and VoFR and VoATM is even better. I am looking at any article that might explain or clarify if IPv6 or IPnG will address this QoS issue and the voice packets prioritisation problem. Also, if any one can point me to Case Studies of busines corporations (cisco, lucent, any F500 company) that has sucessfully implemented VoIP over their private Intranets? Thanks! Any help would be a life saver. I have pretty much ran into a cul-de-sac here with my research. Cheers! Amit Datta Rochester Institute of Technology, Rochester, NY 14623 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 27 13:21:36 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8RKJU619233 for ipng-dist; Wed, 27 Sep 2000 13:19:30 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8RKJBr19226 for ; Wed, 27 Sep 2000 13:19:17 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA15550 for ; Wed, 27 Sep 2000 13:19:10 -0700 (PDT) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09151 for ; Wed, 27 Sep 2000 13:19:10 -0700 (PDT) Received: from zed.isi.edu (root@zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id NAA21139; Wed, 27 Sep 2000 13:19:09 -0700 (PDT) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.9.3/8.8.6) id NAA06938; Wed, 27 Sep 2000 13:19:09 -0700 Message-Id: <200009272019.NAA06938@zed.isi.edu> Subject: forms of loopback To: ipng@sunroof.eng.sun.com Date: Wed, 27 Sep 2000 13:19:09 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What are the possible forms for representing the "loopback" interface? Which are prefered and why? --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Sep 27 20:54:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8S3r7c19846 for ipng-dist; Wed, 27 Sep 2000 20:53:07 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8S3qor19839 for ; Wed, 27 Sep 2000 20:52:51 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with SMTP id e8S3qle397774; Wed, 27 Sep 2000 20:52:47 -0700 (PDT) Date: Tue, 26 Sep 2000 21:26:52 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: draft-ietf-ipngwg-addr-select-01: destination selection comme nts To: "Powell, Ken" Cc: "'Erik Nordmark'" , "'richdr@microsoft.com'" , "'ipng@sunroof.eng.sun.com'" , "Yasevich, Vladislav" In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I still don't understand why it should be mandatory for all > nodes to implement consulting the kernel. I look at it as a > terrific value-added feature that Solaris put in for IPv4 and > definitely believe it should be allowed in IPv6. I wasn't claiming that it was mandatory to consult a kernel - it isn't mandatory for an implementation to have a kernel. The general point is 1) the address selection rules are useful 2) I know how to implement them in one implementation without creating a noticable performance hit and without adding much complexity. You were arguing that for implementation performance and complexity reasons certain parts of the rules should not be mandatory. Seems like we are coming to different conclusions on the cost/benefit tradeoffs for those particular rules. > As for the performance aspect, I thought about that too. I > agree you, its probably not significant. > > The problem is defining everything else getaddrinfo can handle > to the level of detail needed to support this destination address > selection algorithm. For example, what order do addresses get > returned when family, socktype, and/or protocol are unspecified? That issues is completely orthogonal to the subject of default address selection. > I was thinking something much simpler and confused things with > the term "namespace". The suggestion was intended to be "use > separate names for an organization's key site-local addresses": > > servername.mysite.com ; node's global addresses > servername-loc.mysite.com ; node's site-local address That avoids the TLD allocation problem, but it doesn't address the issue of the -loc names leaking outside the site. For instance, if I send a email to alice@example.com and cc bob@blah-loc.mysite.com alice can't reply to bob unless the mail system does rewriting between the two above types of names for email that leaves the site. Same thing for URLs etc. > This is what we do now in our lab (not in a production > namespace). It doesn't matter where the names are defined. > The point is, many organizations will probably only need to > define the site local addresses of a few nodes for the few > specific applications that would otherwise break during a > renumbering event. Let all other applications that will > work fine with global addresses use global addresses. draft-ietf-ipngwg-site-prefixes-* shows a different way to approach the same problem. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Sep 28 03:47:30 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) id e8SAjug20108 for ipng-dist; Thu, 28 Sep 2000 03:45:56 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1.Beta1+Sun/8.11.1.Beta1) with ESMTP id e8SAjir20097 for ; Thu, 28 Sep 2000 03:45:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA21438 for ; Thu, 28 Sep 2000 03:45:43 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA16012 for ; Thu, 28 Sep 2000 04:45:42 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16234; Thu, 28 Sep 2000 06:45:41 -0400 (EDT) Message-Id: <200009281045.GAA16234@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-uni-based-mcast-00.txt Date: Thu, 28 Sep 2000 06:45:41 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Unicast-Prefix-based IPv6 Multicast Addresses Author(s) : B. Haberman, D. Thaler Filename : draft-ietf-ipngwg-uni-based-mcast-00.txt Pages : 5 Date : 27-Sep-00 This specification defines an extension to the multicast addressing architecture of the IP Version 6 protocol. The extension presented in this document allows for unicast-prefix-based allocation of multicast addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-uni-based-mcast-00.txt Internet-Drafts are also 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-uni-based-mcast-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-uni-based-mcast-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000927135844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-uni-based-mcast-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-uni-based-mcast-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000927135844.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 Sep 28 19:14:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e8T280S20663 for ipng-dist; Thu, 28 Sep 2000 19:08:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e8T27f320656 for ; Thu, 28 Sep 2000 19:07:43 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA02199 for ; Thu, 28 Sep 2000 19:07:21 -0700 (PDT) Received: from ish7.ericsson.com.au ([203.61.155.111]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07196 for ; Thu, 28 Sep 2000 19:07:19 -0700 (PDT) Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA10267; Fri, 29 Sep 2000 12:04:20 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA08270; Fri, 29 Sep 2000 13:06:30 +1100 (EST) Received: by eaubrnt019.epa.ericsson.se with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Sep 2000 13:06:35 +1100 Message-ID: <4B6BC00CD15FD2119E5F0008C7A419A5089EB2C5@eaubrnt018.epa.ericsson.se> From: "Hesham Soliman (EPA)" To: "'Francis Dupont'" , ipng@sunroof.eng.sun.com Subject: RE: RFC 2460 4.1 notes 1 & 3 again Date: Fri, 29 Sep 2000 13:06:31 +1100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > One more time some people in the mobile IPv6 are doing a strange confusion > between RFC 2460 4.1 notes 1 & 3 (about destination option headers) and > mobile IPv6 draft. Then I propose: > - we state the rationate for notes 1 & 3 (they seem not clear enough???) > - we note to fix this for the RFC 2460 revision (in some years? :-) > - we ask mobile IPv6 draft authors to state that the draft amends the > RFC 2460. Perhaps this is already in the modifications asked by IESG? > => I fully agree. The DO positioning in MIPv6 is not clear to many readers, especially people are reading the draft.for the first time. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 29 00:32:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e8T7V7X20776 for ipng-dist; Fri, 29 Sep 2000 00:31:07 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e8T7Uw320769; Fri, 29 Sep 2000 00:30:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA20113; Fri, 29 Sep 2000 00:30:58 -0700 (PDT) Received: from mgo.iij.ad.jp (mgo.iij.ad.jp [202.232.15.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA00092; Fri, 29 Sep 2000 00:30:57 -0700 (PDT) Received: from ns.iij.ad.jp (root@ns.iij.ad.jp [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id QAA28155; Fri, 29 Sep 2000 16:30:56 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id QAA20973; Fri, 29 Sep 2000 16:30:55 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id QAA04846; Fri, 29 Sep 2000 16:30:55 +0900 (JST) Date: Fri, 29 Sep 2000 16:29:11 +0900 (JST) Message-Id: <20000929.162911.18619584.kazu@Mew.org> To: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Cc: pc@jp.ipv6forum.com Subject: Global IPv6 Summit in Japan From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.95b64 on Emacs 20.7 / Mule 4.1 (AOI) 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 all, I would like to remind you that the deadline of Call For Presentation for the Summit is tomorrow. If you have not applied yet, please fill the following application form and post it to cfp@jp.ipv6forum.com. --Kazu Call for participation and presentations for "the Global IPv6 Summit in Japan" <> The Global IPv6 Summit, under the organization of the IPv6 Forum, is held regularly around the world to accelerate the deployment of IPv6. We are happy to announce that this conference will be held in Japan, one of the leading countries in the areas of IPv6 development and deployment. The Internet is built on the foundations of the Internet Protocol (IP). The current version of IP is named IPv4 after its version number. The total number of devices that IPv4 can identify is limited to about 4.3 billion. It's hard to see the Internet becoming the foundation of a true, universal communications infrastructure when this number is compared to the human population. In fact, it is expected that the entire address space of IPv4 will be exhausted by around 2008. So, address assignment/allocation is currently being carried out under a very restrictive policy. NAT (Network Address Translator) was introduced as a temporary solution, resulting in the loss of some of the original functionality of the Internet. The principles of the Internet are end-to-end and bidirectional communication. This means every node can communicate with every other freely without any restrictions caused by intermediate nodes. Since NAT broke these principles, it became difficult for unexpected novel applications to appear in the current environment of the Internet. To resolve the exhaustion of IP addresses, extending its address space is a straightforward solution. IPv6, the next generation of IP, provides a huge number of IP addresses and makes NAT obsolete allowing the Internet to recover its original principles. IPv6 is a paradigm recovery for applications. After deploying IPv6 and recovering end-to-end/bidirectional communication, we cannot imagine what kind of applications will appear. This conference will introduce the current deployment status of IPv6 throughout the world. Also, panel discussions are planned, both on "How IPv6 will Change Business" and on "Case Studies: Making the Change to IPv6". Getting Internet people together, including those who are involved in IPv6 activities and IPv4 business and management, we intend to discuss the future of Internet business and the direction of engineering. This conference will be beneficial for everyone including, but not limited to, engineers, researchers, network managers and business people. We would like to invite each of you to participate. <> Steering Group of the Global IPv6 Summit in Japan (Contact: info@jp.ipv6forum.com) <> Date: December 18 - 19, 2000 (As a part of Internet Week 2000) Venue: Grand Cube Osaka (Osaka International Convention Center) 5-3-51, Nakanoshima, Kita-ku, Osaka 530-0005, JAPAN Phone: +81-6-4803-5555 Fax: +81-6-4803-5620 E-mail: soumu@gco.co.jp http://www.gco.co.jp/index.html (The same place as Internet Week 2000) <> Early registration Regular/ discount On-site registration (until Oct 31) Non-student 10,000 JPY 15,000 JPY Student 2,000 JPY 2,000 JPY Non-student 5,000 JPY Student 3,000 JPY <> December 18 (Mon) Keynote Speech 1: Dr. Jun Murai, WIDE Project Session 1: Business report on IPv6 in Japan Session 2: Status report from Asian countries Session 3: Panel on how IPv6 will change business Reception December 19 (Tue) Keynote Speech 2: Dr. Steve Deering, Cisco Systems Session 4: Business report on IPv6 around the world Session 5: Case Studies: Making the Change to IPv6 <> This conference will be held as a part of Internet Week 2000. Please refer to the following page for registration: http://www.jp.ipv6forum.com/ <> The program committee calls for presentation proposal for "Session 4: Business report of IPv6 around the world". Candidates are sTLA holders and IPv6 vendors. Please propose a "10 minutes" presentation on your IPv6 business. If you would like to give a presentation, please send an e-mail message in the following form. Please note that we may not accept all proposals due to the time limitations of the program. Format: See below Deadline: September 30, 2000 Notification date: October 6, 2000 To: cfp@jp.ipv6forum.com Subject: presentation proposal Name : Title : Email : Telephone number: Organization : Department : Your proposal in plain text (no more than 250 words) explaining as concretely as possible your point of view and what kind of presentation can be expected. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 29 04:05:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e8TB45821115 for ipng-dist; Fri, 29 Sep 2000 04:04:05 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e8TB3t321108 for ; Fri, 29 Sep 2000 04:03:55 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA07094 for ; Fri, 29 Sep 2000 04:03:54 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA22262 for ; Fri, 29 Sep 2000 04:03:53 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26191; Fri, 29 Sep 2000 07:01:07 -0400 (EDT) Message-Id: <200009291101.HAA26191@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dnsext-message-size-01.txt Date: Fri, 29 Sep 2000 07:01:07 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : DNSSEC and IPv6 A6 aware server/resolver message size requirements Author(s) : O. Gudmundsson Filename : draft-ietf-dnsext-message-size-01.txt Pages : 6 Date : 28-Sep-00 This document mandates support for EDNS0 in DNS entities claiming to support DNS Security Extensions and A6 records. This requirement is necessary because these new features increase the size of DNS messages. If EDNS0 is not supported fallback to TCP will happen, having a detrimental impact on query latency and DNS server load. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-01.txt Internet-Drafts are also 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-dnsext-message-size-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-message-size-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000928115159.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dnsext-message-size-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dnsext-message-size-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000928115159.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 Sep 29 07:44:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e8TEgnx21229 for ipng-dist; Fri, 29 Sep 2000 07:42:49 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e8TEge321222 for ; Fri, 29 Sep 2000 07:42:40 -0700 (PDT) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA14356 for ; Fri, 29 Sep 2000 07:42:40 -0700 (PDT) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01696 for ; Fri, 29 Sep 2000 07:42:39 -0700 (PDT) Received: by sentry.gw.tislabs.com; id KAA12915; Fri, 29 Sep 2000 10:45:14 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma012904; Fri, 29 Sep 00 10:44:58 -0400 Received: from english.tislabs.com (clipper.gw.tislabs.com [10.33.1.2]) by clipper.gw.tislabs.com (8.9.3/8.9.1) with ESMTP id KAA13640; Fri, 29 Sep 2000 10:41:35 -0400 (EDT) Message-Id: <4.3.2.7.2.20000929103717.00b2ee20@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 29 Sep 2000 10:45:45 -0400 To: namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com From: Olafur Gudmundsson Subject: Re: I-D ACTION:draft-ietf-dnsext-message-size-01.txt In-Reply-To: <200009291101.HAA26191@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Summary off changes: More explicit rationale in introduction, including why we want to start fragmenting DNS answers. Larger sizes required than in old version, different sizes required for DNSSEC and IPv6 but larger size required for support of both. I put in a requirement there that hosts supporting EDNS0 MUST be able to deal with fragmented UDP messages. Please send comments. Olafur PS: -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Sep 29 17:14:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) id e8U0CsJ21715 for ipng-dist; Fri, 29 Sep 2000 17:12:54 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.11.1+Sun/8.11.1) with ESMTP id e8U0Ch321708 for ; Fri, 29 Sep 2000 17:12:43 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA22319 for ; Fri, 29 Sep 2000 17:12:43 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA28003 for ; Fri, 29 Sep 2000 17:12:43 -0700 (PDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by boreas.isi.edu (8.9.3/8.9.3) with ESMTP id RAA23733; Fri, 29 Sep 2000 17:11:36 -0700 (PDT) Message-Id: <200009300011.RAA23733@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2928 on Initial IPv6 Sub-TLA ID Assignments Cc: rfc-ed@ISI.EDU, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 29 Sep 2000 17:11:36 -0700 From: RFC Editor Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2928 Title: Initial IPv6 Sub-TLA ID Assignments Author(s): R. Hinden, S. Deering, R. Fink, T. Hain Status: Informational Date: September 2000 Mailbox: hinden@iprg.nokia.com, deering@cisco.com, rlfink@lbl.gov, tonyhain@microsoft.com Pages: 7 Characters: 11882 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipngwg-iana-tlal-03.txt URL: ftp://ftp.isi.edu/in-notes/rfc2928.txt This document defines initial assignments of IPv6 Sub-Top-Level Aggregation Identifiers (Sub-TLA ID) to the Address Registries. It is intended as technical input to the Internet Assigned Numbers Authority (IANA) from the Internet Engineering Task Force (IETF) Internet Protocol Next Generation (IPNG) and Next Generation Transition (NGTRANS) working groups, as an input to the process of developing guidelines for the allocation of IPv6 addresses. This document was originally developed to provide advice to IANA in the fall of 1998 and is being published at this time for the historical record. The Internet Architecture Board (IAB) subsequently requested that the IANA delegate these assignments to the Address Registries. The IANA did this and the Address Registries are now using them to assign IPv6 addresses. 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@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG 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 RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza 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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000929171005.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2928 --OtherAccess Content-Type: Message/External-body; name="rfc2928.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000929171005.RFC@RFC-EDITOR.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 --------------------------------------------------------------------