From owner-ipng Wed May 1 09:38:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07441; Wed, 1 May 96 09:38:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA07430; Wed, 1 May 96 09:37:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20858; Wed, 1 May 1996 09:35:07 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA22323; Wed, 1 May 1996 09:34:48 -0700 Received: from thumper (localhost [127.0.0.1]) by thumper.bellcore.com (8.6.12/8.6.11) with ESMTP id MAA01570; Wed, 1 May 1996 12:31:58 -0400 Message-Id: <199605011631.MAA01570@thumper.bellcore.com> To: rolc@nexen.com, ipng@sunroof.eng.sun.com Subject: (IPng 1700) FYI: draft-ietf-ipatm-ipv6nd-02.txt Date: Wed, 01 May 1996 12:31:45 -0400 From: Grenville Armitage Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------- Forwarded Message A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Over Asynchronous Transfer Mode Working Group of the IETF. Title : IPv6 and Neighbour Discovery over ATM Author(s) : G. Armitage Filename : draft-ietf-ipatm-ipv6nd-02.txt Pages : 15 Date : 04/29/1996 This document attempts to describe and summarize some current proposals for running IPv6 over ATM, and identifies open issues that require resolution by one or more IETF working groups. The frame formats for unicast and multicast transmission of IPv6 packets in a UNI3.1 based ATM environment are specified. Some issues regarding the construction of IPv6 link-local addresses are identified, and a proposal made. A format for source and target link-layer address options in Neighbor Discovery messages is suggested, and the interactions between IPv6 Neighbor Discovery and existing IP over ATM models are outlined. This revision is looks at the three models that were presented at the Los Angeles IETF in March 1996, in a joint session of the IPATM, IPNG, and ROLC working groups. No firm decisions were made at this joint meeting. Readers are encouraged to locate and review the Internet Drafts describing each model in greater detail. Further discussion of the issues raised in this document is requested, as not all questions are currently answered satisfactorily. ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 2 09:34:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08303; Thu, 2 May 96 09:34:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08297; Thu, 2 May 96 09:34:04 PDT Received: from venus.Sun.COM (venus.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19234; Thu, 2 May 1996 09:31:22 -0700 Received: by venus.Sun.COM (Sun.COM) id JAA07924; Thu, 2 May 1996 09:31:22 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with SMTP id JAA17384; Thu, 2 May 1996 09:31:05 -0700 (MST) Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA17850; Thu, 2 May 96 09:31:04 MST; for ipng@sunroof.eng.sun.com Message-Id: <9605021631.AA17850@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Thu, 2 May 1996 09:31:04 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Paul Vixie , ipng@sunroof.eng.sun.com Subject: (IPng 1701) Re: I hope we don't go back to the ascii2addr() and addr2ascii() names Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 2. Using "2" to mean "to" is not something we ought to do in public, and > and that's the nicest thing I could think to say about it. I just took a quick look at the libc.a files on BSD/OS and Solaris 2.5 and found 15 uses of "to" in a function name (atof, atoi, atol, dtoa, htonl, htons, ntohl, ntohs, strtod, strtol, strtoq, strtoul, strtouq, tolower, toupper) and only two uses of "2" (Solaris-only: str2sig and sig2str). But the real question I have, after working with inet_ntop and inet_pton is why the third argument exists for inet_ntop? It is the length of the binary address (4 or 16) but this is known from the first argument (AF_INET or AF_INET6). Is the intent to handle (future?) addresses that might have a variable-length binary format? Is that also why inet_pton returns -1, 4, or 16, instead of just -1 or 0? Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 2 15:04:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08718; Thu, 2 May 96 15:04:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08712; Thu, 2 May 96 15:04:23 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08202; Thu, 2 May 1996 15:01:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA26263; Thu, 2 May 1996 15:01:39 -0700 Received: (from sklower@localhost) by vangogh.CS.Berkeley.EDU (8.7.Beta.2/8.7.Beta.2) id PAA27933 for ipng@sunroof.Eng.Sun.COM; Thu, 2 May 1996 15:00:33 -0700 (PDT) Date: Thu, 2 May 1996 15:00:33 -0700 (PDT) From: Keith Sklower Message-Id: <199605022200.PAA27933@vangogh.CS.Berkeley.EDU> To: ipng@sunroof.eng.sun.com Subject: (IPng 1702) re: variable length sockaddrs Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich Stevens writes: But the real question I have, after working with inet_ntop and inet_pton is why the third argument exists for inet_ntop? It is the length of the binary address (4 or 16) but this is known from the first argument (AF_INET or AF_INET6). Is the intent to handle (future?) addresses that might have a variable-length binary format? Certainly unix domain sockaddrs are variable length. At the risk of being plastered with tomatoes for bringing them up, so are AF_ISO sockaddrs when the transport and presentation selectors are in use. The sockaddr_iso was a minimum size, and was enough if you did GOSIP version 1 with 2 byte - only TSELS and SSELS. This is getting off topic, but I thought I better pipe up. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 2 15:47:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08793; Thu, 2 May 96 15:47:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08774; Thu, 2 May 96 15:43:10 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15450; Thu, 2 May 1996 15:40:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA07790; Thu, 2 May 1996 15:40:28 -0700 From: Barney Wolff To: ipng@sunroof.eng.sun.com Date: Thu, 2 May 1996 18:37 EDT Subject: (IPng 1703) Re: I hope we don't go back to the ascii2addr() and addr2ascii() names Content-Type: text/plain Message-Id: <318939d70.194@databus.databus.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: rstevens@noao.edu (Richard Stevens) > Date: Thu, 2 May 1996 09:31:04 -0700 > > I just took a quick look at the libc.a files on BSD/OS and Solaris 2.5 > and found 15 uses of "to" in a function name (atof, atoi, atol, dtoa, > htonl, htons, ntohl, ntohs, strtod, strtol, strtoq, strtoul, strtouq, > tolower, toupper) and only two uses of "2" (Solaris-only: str2sig and > sig2str). >From the Unixware man pages, host2netname, netname2host, netname2user, taddr2uaddr, uaddr2taddr, user2netname, all in 3n. Just 4 info; I'm not expressing an opinion either way :-) Barney Wolff ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 3 08:21:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09216; Fri, 3 May 96 08:21:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09210; Fri, 3 May 96 08:21:03 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00686; Fri, 3 May 1996 08:18:21 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA01080; Fri, 3 May 1996 08:18:21 -0700 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA22031; Fri, 3 May 1996 08:17:27 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="============_-1380985786==_============" Date: Fri, 3 May 1996 08:18:30 -0700 To: minutes@cnri.reston.va.us From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1704) Revised March IPng Minutes Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --============_-1380985786==_============ Content-Type: text/plain; charset="us-ascii" Attached are the revised meeting minutes for the IPng working group March IETF Meeting. Bob --============_-1380985786==_============ Content-Type: text/plain; name="IPng-Meeting.March96"; charset="us-ascii" Content-Disposition: attachment; filename="IPng-Meeting.March96" IPng Working Group Meeting March 1996 Los Angles IETF Steve Deering / Xerox PARC, Co-Chair Robert Hinden / Ipsilon Networks, Co-Chair Meeting Minutes were taken and produced by Robert Hinden. ------------------------------------------------- Steve Deering opened the meeting. Bob Hinden agreed to take the minutes. The agenda was reviewed and the following items were agreed to be discussed: Introductions / Steve Deering W.G. Document Status / Bob Hinden University of New Hampshire Bakeoff Report / Jim Bound Spec. changes from UNH Experience / Steve Deering DHCPv6 Issues / Ralph Droms Host Anycasting Support / Jim Bound Multihomed Hosts / Mike Shand Link Local Address and Interface ID's / KRE Payload Header / KRE Header Compression for IPv6 / Mikael Degermark Tunneling Spec / Alex Conta Unicast address Formats / Bob Hinden Swap Source & Destination Address in IPv6 Header / Mike Carlton PMTU Spec / Jim McCanne BSD API Issues / Bob Gilligan UDP + TCP/MSS vs. JumboGrams / Dave Borman Host Handling of Router Header Max Autoconfig Token size? Correct ::127.0.0.1 in Transition Mechanism Specification IPv6 over PPP / Dimitry Haskin =================================================================== Monday =================================================================== Document Status / Bob Hinden Since the last IETF meeting the following IPv6 RFC's were published as Proposed Standards: o Internet Protocol, Version 6 (IPv6) Specification IP Version 6 Addressing Architecture o Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification o DNS Extensions to support IP version 6 The following document was published as an Informational RFC: o An Architecture for IPv6 Unicast Address Allocation The following documents was published as an experimental RFC: o IPv6 Testing Address Allocation The following document was approved by the IESG to be published as an experimental RFC: o OSI NSAPs and IPv6 This document was rejected by the IANA because of the usage of the complete portion of the NSAP address space assigned to the IANA. To resolve this an AFI number is being assigned to the IANA which will give the IANA additional address space. A new draft is being prepared. The following documents have completed IETF last call and the IESG is considering for evaluation to Proposed Standard: o Neighbor Discovery for IP Version 6 (IPv6) o A Method for the Transmission of IPv6 Packets over Ethernet Networks o A Method for the Transmission of IPv6 Packets over FDDI Networks The IESG returned the following document to the working group: o An IPv6 Provider-Based Unicast Address Format [Editors Note: This document was discussed later in this meeting] The following documents are ready to be sent to the IESG: o A Method for the Transmission of IPv6 Packets over Token Ring Networks The following documents are almost ready for IPng working group last call: o Path MTU Discovery for IP version 6 o Generic Packet Tunneling in IPv6 Specification o IPv6 Program Interfaces for BSD Systems ------------- UNH Bakeoff / Jim Bound Jim Bound gave a report on the UNH IPv6 Bakeoff. Router implementations were tested from Digital, Ipsilon Networks and Bay Networks. Host implementations were tested from Sun Microsystems, Mentat, FTP Software, WIDE Consortia, HP, Digital, and INRIA. Most of the base spec was tested as well as Neighbor Discovery and Auto Address Configuration. The testing went well. The group is planning another test in late June. ------------- Specification Changes/Issues arising from UNH Bakeoff / Steve Deering o When processing routing header, If packet too big for next hop MTU, send ICMP packet "Pkt too big" to source Do NOT Fragment o On reception of option with wrong alignment, send ICMP parameter problem. Discussion about how to move changes forward. Scott Bradner (AD) said a new ID should be published, then ask IESG to publish an informational RFC. o In ND specifcation, clarify purpose and effect of the on-line flag. This is a mechanism which requires that all hosts send to routers to reach all destinations. Erik Nordmark noted that the text describing this topic was clarified in the current version of the ND Internet Draft. o Does a redirect for a packet with non-zero flow ID apply to only that flow or for all packets to same destination? Deering suggested that it should apply to all packets to that destination. Redirection of flows should be done with flow setup protocol (e.g., RSVP). Group agreed to make the IPv6 redirect flow insensitive. Dennis Fergusion noted that a flow redirect would also need to redirect source, destination, flow ID, not just destination. o Discussion on should a host accept new connections on a "depreciated" address. Group concluded that a host should accept new connections on a "depreciated" address. The AddrConf spec should be clarified. ------------ DHCPv6 Issues / Ralph Droms Authentication/Verification in DHCPv6 Background Want to authenticate clients and servers and verify contents unmodified. DHCP uses "relay agents" that retransmit messages between client and off-link server. DHCPv4 uses "giaddr' and "hops" fields, which are changed by the relay agent. Proposed Solutions Uses IPSEC and tunnels between relay agents and servers. Client discovers relay agents, inserts "giaddr" and uses IPSEC Skip "giaddr" and "hops" in verification computations with IPSEC or DHCP specific mechanism. Use IPSEC with separate associations between client/relay agent and relay agent/server. Defer authentication; encrypt response. Discussion about preferences of each proposed solutions. No clear preference from working group. Multiple Addresses and DCHCPv6 in IPv6 Are multiple addresses per interface a good idea for IPv6: Yes Should multiple addresses be delivered "on demand"? Service want its own address, doesn't know it until server starts. Long varied discussion about pro's/cons. Straw poll leaning that this is a good idea. Will applications want to specify the characteristics of the addresses they request? Site Local / Global Life Time Multi-homed Discussion....... No concensus on this. How will applications specify these addresses? Should DHCP be charged with specificaton and delivery of multiple addresses? DHCPv6 will be discussed tomorrow evening DHCP session. -------------- Bob Gilligan, NGTrans co-chair offered to let the IPng working group use the second half its session on Tuesday to complete more action items. The chairs accepted his offer. An additional session was scheduled Tuesday at 4:30pm at the end of the NGTRANS session. =================================================================== Tuesday =================================================================== Multihomed Hosts Draft tries to enumerate what multihoming means. Are there issues not described. Lists issues. Author wants people to read draft and have discussion on list and discuss at next IETF meeting. Suggestion to change title to "Multihomed Hosts". ---------- Payload Header KRE's proposal to support multipayload fields in single packet. Proposal to require implementation of this options. Three advantages: Put a number of small packets in one large one, 2) Makes better use of jumbograms, could be useful for better alignment in supercomputers. 3) Align TCP header on 8 byte boundary. Choice to to require it or to throw out the option. Meeting in Washington, DC concluded this was not worth doing. Discussion on pros/cons. Would put burden on receiver. Not at all clear how sender would like this to be used. Also, large issue for implementations of firewalls. Firewall would need to look inside to see if there were other headers. Group decided to not pursue. ------ IPv6 over PPP / Dimitry Haskin Draft proposal for a new PPP network control protocol to negotiate IP version 6 datagram transmission and configureation options. Current draft is draft-ietf-ipngwg-pppext-ipv6cp-01.txt. Draft was developed because IPv6 datagram use different protocol ID another data links and has different options than IPv4. Options are interface token used to form IPv6 link-local address as well as in global address autoconfiguration. Generated similar to Magic Number procedure. Also includes an option for IPv6 compression protocol. Draft was reviewed by PPP group. IPng needs to approve to move forward. Interface token 8 8 32 bits +------+--------+-----------------------------------------+ | Type | Length| Interface-Token | +------+--------+-----------------------------------------+ Link local address of PPP interfaces 8 70 bits 48 bits +------------+---------------------+----------------------+ | 1111111010 | 0 | Interface-Token | +------------+---------------------+----------------------+ Discussion about necessity of special PPP compression for IPv6 because there is already a general PPP compression algorithm which is not protocol specific. Discussion about reducing the size of the interface token. Would make compressions better if there was more zeros in the address. Suggestion for 8 bit interface token. Also, would allow more subnet space to create local address hierarchy in dialup service providers Suggestion for 32bits. Discussion about using smaller token. Group agreed to use 32bit tokens. Document will be revised. Chairs will do a working group last call when new ID is published. =================================================================== Wednesday =================================================================== Unicast Address Formats / Bob Hinden The IESG returned the "An IPv6 Provider-Based Unicast Address Format" to the working group. The issues dealt with the use of fixed length fields in the middle of the address. A new draft has been issued with attempts to resolve this issue. It defines the format for this address type to be: 3 5 n 56-n 64 bits +---+------------+------------+--------------+------------------+ |010| RegistryID | ProviderID | SubscriberID | Intra-Subscriber | +---+------------+------------+--------------+------------------+ In this version of the document the RegistryID uses a 5 bits and the Provider ID and Subscriber ID fields together use 56 bits. Individual subscribers are always guaranteed 64 bits of local address independent of which provider they use to insure operation with addr conf and to allow renumbering. The working group agreed to do a working group last call on this document and then to advance it to the IESG for proposed standard at the completion of the working group last call. --------- PMTU Specification Author reviewed changes from previous version. These included: o Add terminology section o Clarify definition of path o Local representation of path (implementation specific) o Applies to Multicast o Processing routing header o PMTU for directly connected node o Note about PTB message with MTU < 576 bytes o Appendix on changes from RFC-1191 o Add Jeff Mogul as an author o Remove references to "routes" Working group agreed to do a working group last call on this document. ----------------- Header Compression for IPv6 / Mikael Degermark Why Header Compressions: On low speed links want good interactive response time. Want to be able to support realtime audio. Goals to compress IPv6 (and IPv4), TCP, and UDP Headers. No setup is required in this proposal and it works over simplex links. The goal to support realtime audio for low speed links. Results: Reduces IPv6/UDP headers to 8.7% of size, 48 bytes to 4 bytes. Swedish Institute of Computer Science (SICS) has a prototype implementation running. Compressor is about 400 lines of C code. Decompressor is 300 lines of C code. Basic idea is to send a full header with a CID (compression ID) occasionally. Subsequent compressed headers carry the CID and fields that are different from the fields in the full header. TCP uses RFC1144 header. New formats for non-TCP flows. Adds generation field to identify when compression state is obsolete. Supports different formats depending on how much information is carried. Goal is to use the smallest possible. Handles compression of IPv6 subheaders. Includes rules for how to handle extension headers. Includes four different ways to classify how an individual field will change. Includes NOCHANGE: Never changes. DELTA: Changes in predictable way. Send difference. RANDOM: Can not predict, must be included INFERRED: Can deduce from other fields. Example of link level field. Showed examples of different cases are extended. Full Headers: Don't want to increase the size of a full header when maximum MTU is being used. Utilizes fact that header length field can be inferred. Uses the length field in IPv6 [and transport] header. Assumes that link layer provides the length of the packet. Also assumes that link layer delivers packets in the order that they are sent. Interesting issue of how to deal with packet loss. What happens if full header (which would have changed compresisons state) is lost. Must be able to detect this incorrect decompression and reestablish compressions state. For TCP many fields use delta encoding (tcp segements, etc.). If lost, then TCP sequence fields will be off. TCP checksum will catch these packets. Compressor looks for TCP retransmits then sends full header. Uses softstate for non-TCP packets. Periodically sends full header refreshes. Then does exponential backoffs to reduce the number of full headers sent. This is where generation field is used to establish new compressions state. Cost of sending full headers periodically only increases the average size of packets sent by 1.4 bits. This scheme can also be used for multicast and non-point to point links. Authors have not specified how which packets should use specific compressions state. Includes guidelines, but has not specified exactly. There is a tradeoff with how much compressions is done and implementation complexity. Need a way to tell these different headers apart. Could either get new link layer identifier (e.g., ethertype) or use different values in the version field. Group will discuss the merits on the ipng mailing list. SICS plans to make code available for the header compression implementation. ------------ Tunneling / Alex Conta New draft which includes changes agreed at previous meeting. Also added new section which discusses the dangers of recursive encapsulation. Other clarifications of document. Risk factors in Recursive encapsulation Type of tunnel Type of route to exit point: Type of Tunnel Inner tunnel with identical exit points, can be Fixed-exit pints (different entry points) Free-Exit inner tunnels (different entry points) Type of Route Route to a specific destination node / minimum risk Route to a specific prefix-net / min risk Route to an unspecified destination / Default route Default tunnel / Max risk! Discussion about necessity of need for tunnels in tunnels with same exit point. Desire to show some evidence in practice that there is a real problem to be solved. [Editor's note: cisco systems has similar mechanism in their proprietary tunneling protocol. It would be useful to find out how effective/necessary it has been.] Suggestion to include mechanism once in a while (one out of n packets). Group agreed to continue discussion on mailing list. ------------------ Proposal to Reorder Addresses in IPv6 Header / Mike Carlton Might be performance gain when forwarding packets if destination address is before source address. Presented example of how it affects cache in generic machine. Must check next header, hop limit, flow label. Write new hop limit. Validate source address. Use destination or flow label to search route cache. Upper part of source to determine address type Upper part or all of source to route multicast packets. Reordering will improve cache performance. Assumes FP is no more than 10 bits. Cache miss to 10-50 or more processor cycles. Long involved discussion. After long discussion, a straw poll was taken and the working group decided to leave the header order the way it was. This decision was reopened at the end of the session. After another long discussion the group could not make a decision and directed the working group chairs to discuss the issue and make a decision. That was done and the text of the message to the working group documenting this is included here: To: ipng@sunroof.Eng.Sun.COM Cc: hinden@ipsilon.com, deering@parc.xerox.com Subject: (IPng 1539) order of addresses in IPv6 header Date: Mon, 11 Mar 1996 18:39:33 PST From: Steve Deering Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Background: If you attended Wednesday's ipngwg meeting in LA, or if you listened to it over the MBone, you will know that we had a lively discussion about possibly swapping the order of the Source Address and Destination Address fields in the IPv6 header. Several folks argued that changing the address order would allow for faster software forwarding of IPv6 packets in particular implementations (e.g., for particular cache line sizes), and for those implementations where it didn't help, it also didn't hurt to change the order. The potential (but unproven) performance benefit had to be weighed against the less tangible costs of making such a fundamental change at this late state in the process, such as confusion in the implementor community, further delay in progressing the specs, and possible negative "PR" consequences. A poll of the meeting attendees showed no strong consensus one way or the other, but a modest majority were in favor of leaving the order as is. So in my role as chair of the meeting (and co-chair of the WG), I made a snap "ruling" to leave the address order as is. After doing so, I had serious second thoughts. I concluded that I had let non-technical concerns override my best technical judgement (given the information at hand, admittedly incomplete), and that that was inappropriate for the IETF. So at the end of the WG meeting, I said I wanted to change my "ruling" and swap the two address fields. Then things got really animated, and much more vigorous arguments were made for leaving the address order as is. Finally, I conducted another poll, and this time the number in favor and the number opposed to swapping the address were approximately equal (!), with many abstentions. In the face of this clear lack of consensus, the two co-chairs were delegated to make a decision and announce it to the mailing list. Decision by Deering and Hinden: *** The order of the addresses in the IPv6 header stays as is. *** *** That is, source address first, destination address second. *** Rationale: (1) Swapping the addresses would not be "harmless", performance-wise, in all circumstances, contrary to what I claimed in the meeting. As Tracy Mallory pointed out, for packets with non-zero flow labels, moving the source address after the destination address would force the router to look further into the header than would otherwise be necessary. Thus, on those architectures that benefit from not having to read the whole header, flow-based traffic would be penalized by a change of address order. (2) As Christian Huitema pointed out, necessary improvements in congestion handling for non-flow-based traffic, such as fair queueing or a statistical approximation of fair queueing, are likely to require examination of the full source address of every forwarded packet anyway, in which case moving the source address to the end buys nothing, and defeats the possible gain described in the next point... (3) Assuming adoption of the proposed unicast addressing plan in which the low-order 64-bits of an IPv6 unicast address are used only for intra-site purposes, all inter-site forwarding can be done without looking at the last 64 bits of the destination address. Thus if we leave the address order as-is, we can still exploit the benefit of not fetching the trailing 64 bits of the header for inter-site routing, where the highest throughputs are going to be needed. Note: Mike Carlton, who initiated the discussion of swapping the addresses in his presentation on cache effects on IPv6 header processing, agrees with this analysis and has withdrawn his request to change the address order. -------- Unique Interface ID's / KRE Proposal to change link link layer address to: +--------+------+----------------------+-----------------+ | Prefix | IID | anything | Interface Token | +--------+------+----------------------+-----------------+ |----32 bits----| "IID" is long term constant identifier of the interface, unique within the node. Notes: Optional: Nodes not required to use these fields. For Non-Participants Minor change to ND discovery procedures For Participants Generate modified LL-ADDR Modified DAD Need to be able to detect DAD from another local interface (same node) Modify Draft DAD NS Reply (NA) There was a general concensus to pursue this proposal. ========================================================================= ========================================================================= --============_-1380985786==_============-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 3 09:01:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09366; Fri, 3 May 96 09:01:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA09360; Fri, 3 May 96 09:01:18 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06366; Fri, 3 May 1996 08:58:35 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA13167; Fri, 3 May 1996 08:58:34 -0700 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1705) Re: variable length sockaddrs To: sklower@CS.Berkeley.EDU (Keith Sklower) Date: Fri, 3 May 1996 11:57:29 +0100 (BST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199605022200.PAA27933@vangogh.CS.Berkeley.EDU> from "Keith Sklower" at May 2, 96 03:00:33 pm Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But the real question I have, after working with inet_ntop and inet_pton > is why the third argument exists for inet_ntop? It is the length of the > binary address (4 or 16) but this is known from the first argument > (AF_INET or AF_INET6). Is the intent to handle (future?) addresses > that might have a variable-length binary format? > > Certainly unix domain sockaddrs are variable length. At the risk > of being plastered with tomatoes for bringing them up, so are > AF_ISO sockaddrs when the transport and presentation selectors are in > use. The sockaddr_iso was a minimum size, and was enough if you > did GOSIP version 1 with 2 byte - only TSELS and SSELS. Putting aside the IPv4/IPv6 issues where it doesnt arise we already have variable length formats in Linux (AX.25 being the major one that is involved). Better to keep the last value in. However for ipv4/6 its not an important issue beyond "Planning ahead" ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat May 4 10:37:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10167; Sat, 4 May 96 10:37:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10161; Sat, 4 May 96 10:36:56 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03567; Sat, 4 May 1996 10:34:14 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA15782; Sat, 4 May 1996 10:34:12 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id RA24864; Sun, 5 May 1996 03:34:05 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: (IPng 1706) Revised Interface Identifer (in link local addresses) draft Date: Sun, 05 May 1996 03:34:04 +1000 Message-Id: <2729.831231244@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have just submitted draft-ietf-ipngwg-iid-02.txt This is changed as discussed in LA - it now no longer requires any changes from nodes that want to leave their link local addresses full of zeroes in the middle, though I am not sure I explained why well, you might need to read carefully. This version also contains possible text to go in most of the IPv6 docs that neeed changing (I didn't bother with all of the IPv6 over foo drafts, they're all quite similar in this area, the changes to any not included should be obvious...) I would expect this to be announced about the middle of the week. For those of you who can't wait that long, you'll find a copy in the Big-Internet archives, that is: ftp://munnari.oz.au/big-internet/draft-ietf-ipngwg-iid-02.txt Again recall that the sole purpose of this draft is to get consensus on changes to the other docs, it is not intended to appear as an RFC itself, and consequently I an not much interested in spelling mistakes, typos, formatting errors, bad grammar, etc. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat May 4 14:19:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10291; Sat, 4 May 96 14:19:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10285; Sat, 4 May 96 14:18:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09523; Sat, 4 May 1996 14:16:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA03413; Sat, 4 May 1996 14:16:04 -0700 Received: by iol.unh.edu (4.1/SMI-4.1) id AA26987; Sat, 4 May 96 17:12:15 EDT From: qv@iol.unh.edu (Quaizar Vohra) Message-Id: <9605042112.AA26987@iol.unh.edu> Subject: (IPng 1707) AF_INET vs AF_INET6 sockets To: ipng@sunroof.eng.sun.com (ipng) Date: Sat, 4 May 1996 17:12:14 -0400 (EDT) X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Is it legal to have an AF_INET6 family socket bound ( or binded ) to an IPv4-mapped IPv6 address, though I don't see why an application would want to do that. Also if another application has an AF_INET family socket bound to the same IPv4 address and same port #, they are effectively two sockets receiving messages for the same local-port & local-address. So effectively IPv4 has to pass the packet to both sockets. It seems that nodes supporting IPv6 shouldn't allow the first case. Anyway, can someone please clarify this. Quaizar ------------------------------------------------------ Quaizar Vohra Inter-Operatibility Lab. (IOL), Univ. of New Hampshire E-mail : qv@sun4.iol.unh.edu Phone : (603)-862-0090 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 5 06:58:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10430; Sun, 5 May 96 06:58:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10424; Sun, 5 May 96 06:58:10 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17104; Sun, 5 May 1996 06:55:27 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA18284; Sun, 5 May 1996 06:55:23 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id PAA13675; Sun, 5 May 1996 15:55:21 +0200 (MET DST) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id PAA27032; Sun, 5 May 1996 15:55:20 +0200 Message-Id: <199605051355.PAA27032@givry.inria.fr> From: Francis Dupont To: qv@iol.unh.edu (Quaizar Vohra) Cc: ipng@sunroof.eng.sun.com (ipng) Subject: (IPng 1708) Re: AF_INET vs AF_INET6 sockets In-Reply-To: Your message of Sat, 04 May 1996 17:12:14 EDT. <9605042112.AA26987@iol.unh.edu> Date: Sun, 05 May 1996 15:55:13 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Is it legal to have an AF_INET6 family socket bound ( or binded ) to an IPv4-mapped IPv6 address, though I don't see why an application would want to do that. => it is legal and it must be legal because it is used by any IPv4/IPv6 applications for IPv4 compatibility: a mixed application uses only the IPv6 API with AF_INET6 family sockets. When an IPv4 address is needed then an IPv4-mapped IPv6 address is used. Also if another application has an AF_INET family socket bound to the same IPv4 address and same port #, they are effectively two sockets receiving messages for the same local-port & local-address. => in the general case it is not possible to have two sockets bound to the same address and port. An IPv4-mapped IPv6 address is in fact an IPv4 address and must be managed correctly by the IPv4 stack. So effectively IPv4 has to pass the packet to both sockets. => IPv4 input routines have to deal with both IPv4 and IPv4-mapped IPv6 addresses with an IP version switch per socket (or PCB). It works... It seems that nodes supporting IPv6 shouldn't allow the first case. => it is very important to have a real compatibility between IPv4 and IPv4/IPv6. The idea is to translate all the applications to the IPv6 API directly, the IPv4 case is dealed by the IPv4-mapped IPv6 hook. It has many side effects (ie bug opportunities :-) for instance: - IPv4 input routines can give (IPv4-mapped) IPv6 address - a wildcard IPv6 address for a server matches the IPv4 address then an IPv4 server and an IPv6 server cannot share the same port - IPv4 TOS and IPv6 priority are two faces of the same thing in current cases The old IPv4 API must be used only with some options, multicast (because there is no multicast address mapping) and stupid/historic usage of explicit IPv4 addresses in the application protocol. Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 5 16:22:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10623; Sun, 5 May 96 16:22:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10617; Sun, 5 May 96 16:22:12 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB05538; Sun, 5 May 1996 16:19:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA23803; Sun, 5 May 1996 16:19:27 -0700 Received: by iol.unh.edu (4.1/SMI-4.1) id AA03292; Sun, 5 May 96 19:15:20 EDT From: qv@iol.unh.edu (Quaizar Vohra) Message-Id: <9605052315.AA03292@iol.unh.edu> Subject: (IPng 1709) AF_INET vs AF_INET6 sockets To: Francis.Dupont@inria.fr (Francis Dupont) Date: Sun, 5 May 1996 19:15:19 -0400 (EDT) Cc: ipng@sunroof.eng.sun.com (ipng) In-Reply-To: <199605051355.PAA27032@givry.inria.fr> from "Francis Dupont" at May 5, 96 03:55:13 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, > >=> it is very important to have a real compatibility between IPv4 and >IPv4/IPv6. The idea is to translate all the applications to the IPv6 >API directly, the IPv4 case is dealed by the IPv4-mapped IPv6 hook. >It has many side effects (ie bug opportunities :-) for instance: > - IPv4 input routines can give (IPv4-mapped) IPv6 address > - a wildcard IPv6 address for a server matches the IPv4 address > then an IPv4 server and an IPv6 server cannot share the same port Can a server opening a socket of AF_INET family ( with a wildcard entry in the foreign address field in its in_pcb ) be passed packets received from v6 nodes. I think not, otherwise old v4 applications will not operate correctly on the extended API. Can we have 2 servers listening on the same port #, one of AF_INET family, other of AF_INET6 family ( both the sockets have wildcard entries in the foreign address field in their respective in_pcbs ). If the above is not allowed, then this should be allowed. > - IPv4 TOS and IPv6 priority are two faces of the same thing in > current cases >The old IPv4 API must be used only with some options, multicast >(because there is no multicast address mapping) and stupid/historic >usage of explicit IPv4 addresses in the application protocol. > Thanks Quaizar ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 6 01:10:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10782; Mon, 6 May 96 01:10:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10776; Mon, 6 May 96 01:09:58 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25116; Mon, 6 May 1996 01:07:13 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA05863; Mon, 6 May 1996 01:07:11 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id KAA19220; Mon, 6 May 1996 10:07:09 +0200 (MET DST) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id KAA27692; Mon, 6 May 1996 10:07:08 +0200 Message-Id: <199605060807.KAA27692@givry.inria.fr> From: Francis Dupont To: qv@iol.unh.edu (Quaizar Vohra) Cc: ipng@sunroof.eng.sun.com (ipng) Subject: (IPng 1710) Re: AF_INET vs AF_INET6 sockets In-Reply-To: Your message of Sun, 05 May 1996 19:15:19 EDT. <9605052315.AA03292@iol.unh.edu> Date: Mon, 06 May 1996 10:07:00 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Can a server opening a socket of AF_INET family ( with a wildcard entry in the foreign address field in its in_pcb ) be passed packets received from v6 nodes. I think not, otherwise old v4 applications will not operate correctly on the extended API. => no, the compatibility is from IPv6 to IPv4 only. Can we have 2 servers listening on the same port #, one of AF_INET family, other of AF_INET6 family ( both the sockets have wildcard entries in the foreign address field in their respective in_pcbs ). If the above is not allowed, then this should be allowed. => no, the wildcard of AF_INET6 is for any IPv6 address, including IPv4-mapped IPv6 then the wildcard of AF_INET is included in it. Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 6 09:54:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10977; Mon, 6 May 96 09:54:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10965; Mon, 6 May 96 09:53:50 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26213; Mon, 6 May 1996 09:51:02 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA00785; Mon, 6 May 1996 09:51:02 -0700 Received: by iol.unh.edu (4.1/SMI-4.1) id AA09747; Mon, 6 May 96 12:47:04 EDT From: qv@iol.unh.edu (Quaizar Vohra) Message-Id: <9605061647.AA09747@iol.unh.edu> Subject: (IPng 1711) Re: AF_INET vs AF_INET6 sockets To: Francis.Dupont@inria.fr (Francis Dupont) Date: Mon, 6 May 1996 12:47:03 -0400 (EDT) Cc: ipng@sunroof.eng.sun.com (ipng) In-Reply-To: <199605060807.KAA27692@givry.inria.fr> from "Francis Dupont" at May 6, 96 10:07:00 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, > > In your previous mail you wrote: > > Can we have 2 servers listening on the same port #, one of AF_INET > family, other of AF_INET6 family ( both the sockets have wildcard entries > in the foreign address field in their respective in_pcbs ). If the above is > not allowed, then this should be allowed. > >=> no, the wildcard of AF_INET6 is for any IPv6 address, including >IPv4-mapped IPv6 then the wildcard of AF_INET is included in it. > >Regards > >Francis.Dupont@inria.fr > If an IPv4 server opens an AF_INET socket, listening on port # n, then an IPv6 server wants to open an AF_INET6 socket, listening on the same port # n, this should be allowed as the first socket doesn't cover IPv6 addresses. But if these sockets were opened in reverse order, then they shouldn't be allowed as per your argument. Thanks Quaizar ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 6 09:54:16 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10978; Mon, 6 May 96 09:54:16 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10971; Mon, 6 May 96 09:53:57 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26253; Mon, 6 May 1996 09:51:10 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA00824; Mon, 6 May 1996 09:51:10 -0700 Received: from styrax.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA24393; Mon, 6 May 1996 12:35:56 -0400 Received: by tlaser.zk3.dec.com; (5.65v3.2/1.1.8.2/06Mar95-1016AM) id AA07467; Mon, 6 May 1996 12:35:40 -0400 Date: Mon, 6 May 1996 12:35:40 -0400 From: Jack McCann USG Message-Id: <9605061635.AA07467@tlaser.zk3.dec.com> To: Victor.DIAS-FERNANDES@dg12.cec.be, ipng@sunroof.eng.sun.com Subject: (IPng 1712) Re: Comments to: draft-ietf-ipngwg-pmtuv6-02.txt Cc: deering@parc.xerox.com, mccann@zk3.dec.com, mogul@pa.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From: Victor.DIAS-FERNANDES@dg12.cec.be >Date: Thu, 25 Apr 1996 15:39:43 +0200 >To: ipng@sunroof.eng.sun.com (Non Receipt Notification Requested) >Subject: (IPng 1622) Comments to: draft-ietf-ipngwg-pmtuv6-02.txt > >> In the first attack, the false message indicates a PMTU much smaller >> than reality. This should not entirely stop data flow, since the >> victim node should never set its PMTU estimate below the IPv6 minimum >> link MTU. It will, however, result in suboptimal performance. > >To minimize this type of attack the sending node could: > >1- Check if the received Packet Too Big Message (PTBm) is really a response >to a packed sent by the node, by checking the data returned in the PTBm. If >not ignore the PTBm and continue using the actual PMTU. > >2- Check if and acknowledgment for the supposed Too Big Packet was received. >If yes ignore the PTBm. If not save the actual PTMU value and begin using >the new PTMU value. If an acknowledgment arrives for the packet that was >sent and that had originated the PTBm (proving the PTBm was false) reset the >PTMU value to the old saved value (the save PTMU value can be cleared after >a specified timeout if an acknowledgment is not received) Or establish a security association with each router along the path, and authenticate the source of the PTBm. Perhaps one of you security gurus out there could comment on this? >To avoid the (eventually large) amount of iterations of >"packet-sent/Packet-Too-Big-message-received" until the correct PMTU >value is discovered a special packet could be defined to probe for the >correct PMTU value for a given path (like a new ICMP Type message). We considered a pmtu probe mechanism such as you suggest. I even went so far as to sketch out a rough draft. We decided not to include it in the pmtuv6 spec. A pmtu probe mechanism would be an add-on, we still need what's in the spec. The additional overhead of a pmtu probe might very well cost more than the savings of avoiding some packet too big drops (especially if you expect the packet loss frequency due to packet too big to be low). Working Group: do we need a pmtu probe mechanism? This should not hold up the current spec, IMHO. >> >> Path MTU Discovery supports multicast as well as unicast >> > >This implies that the _slower connection_ (smaller PMTU) will impose >its _speed_ to all the members of the multicast! This makes possible >the same type of attack as describe in [6. above] or worst completely >make the data useless in case the data is for time sensitive application, >due to _Too Small Packets_ or/and fragmentation. To avoid this situation >a minimum PMTU value to use (a configurable parameter for special >services) could be imposed and all PMTU value smaller than this minimum >value ignored. > The spec does suggest that an implementation provide a way to change the pmtu value for a given path, which in the case of multicast may actually be the set of paths to all members of the multicast. >Victor Dias Fernandes (victor.dias-fernandes@dg12.cec.be) - Jack McCann mccann@zk3.dec.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 6 15:01:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11292; Mon, 6 May 96 15:01:10 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11286; Mon, 6 May 96 15:00:53 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23320; Mon, 6 May 1996 14:58:07 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA20822; Mon, 6 May 1996 14:58:08 -0700 Received: (rja@localhost) by puli.cisco.com (8.6.8+c/8.6.5) id OAA21880; Mon, 6 May 1996 14:58:07 -0700 Date: Mon, 6 May 1996 14:58:07 -0700 From: Ran Atkinson Message-Id: <199605062158.OAA21880@puli.cisco.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1713) Re: Comments to: draft-ietf-ipngwg-pmtuv6-02.txt In-Reply-To: <9605061635.AA07467@tlaser.zk3.dec.com> Organization: cisco Systems, Inc., Menlo Park, Ca. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % From: Victor.DIAS-FERNANDES@dg12.cec.be % Date: Thu, 25 Apr 1996 15:39:43 +0200 % To: ipng@sunroof.eng.sun.com (Non Receipt Notification Requested) % Subject: (IPng 1622) Comments to: draft-ietf-ipngwg-pmtuv6-02.txt %> In the first attack, the false message indicates a PMTU much smaller %> than reality. This should not entirely stop data flow, since the %> victim node should never set its PMTU estimate below the IPv6 minimum %> link MTU. It will, however, result in suboptimal performance. % To minimize this type of attack the sending node could: % % 1- Check if the received Packet Too Big Message (PTBm) is really a response % to a packed sent by the node, by checking the data returned in the PTBm. If % not ignore the PTBm and continue using the actual PMTU. % % 2- Check if and acknowledgment for the supposed Too Big Packet was received. % If yes ignore the PTBm. If not save the actual PTMU value and begin using % the new PTMU value. If an acknowledgment arrives for the packet that was % sent and that had originated the PTBm (proving the PTBm was false) reset the % PTMU value to the old saved value (the save PTMU value can be cleared after % a specified timeout if an acknowledgment is not received) The 2 items above might be considered for inclusion as suggestions in the SECURITY CONSIDERATIONS portion of the I-D prior to its publication as an RFC. The attack(s) should probably be clearly described in the SECURITY CONSIDERATIONS section before publication as an RFC so that implementers and users are informed of the issue(s). In article <9605061635.AA07467@tlaser.zk3.dec.com> Jack wrote: > Or establish a security association with each router along the path, > and authenticate the source of the PTBm. Perhaps one of you security > gurus out there could comment on this? Hmm. The router sending the ICMPv6 error message could simply establish an IPsec SA with the message's destination and then use IPsec once the SA is established. I don't think it needs to be established for each router along the path or in advance of sending the message since we now have dynamic key management and its easy enough to queue a packet or two while key management sets up an IPsec SA. Btw, cisco's ISAKMP+Oakley key management daemon for UNIX is now freely available (it works out of the box on any node that implements NRL's PF_KEY API). The NRL PF_KEY API and related code are all freely available from the NRL IPv6/IPsec distribution. The ISAKMP and Oakley specs are online as I-Ds with names of the form draft-ietf-ipsec-[isakmp || oakley]-*.txt. I'd suggest a few simple things that have no impact at all on nodes where the administrator has not configured any IPsec Security Association: (1) If an appropriate IPsec Security Association exists between the router sending an ICMPv6 error message and the destination of that ICMPv6 error message, then IPsec MUST be used to protect that ICMPv6 error message. (2) IF a node receives an ICMPv6 error message from a node having an appropriate IPsec Security Association with the receiving node, then that received ICMPv6 error message MUST contain the IPsec optional headers and MUST pass the IPsec checks prior to processing by the ICMPv6 layer. Any such packets that omit IPsec or whose IPsec fails normal IPsec processing, are dropped prior to passing the message to ICMPv6 and the security failure is logged. (3) An AH transform should be defined that uses public-key signature techniques compatible with the public-keys that will be available via DNS Security. Then one would allocate a reserved SPI (e.g. SPI == 2) to indicate that the AH transform is the PK signature transform. Finally, a router sending an ICMPv6 error message that has no existing IPsec Security Association with the destination of that error message would apply AH (with the PK signature transform) to the message if the destination node had a signed public key stored in the DNS. These last 3 comments apply to ICMPv6 generally rather than just PMTU Discovery. Ran rja@cisco.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 6 16:21:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11371; Mon, 6 May 96 16:21:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11365; Mon, 6 May 96 16:21:05 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08680; Mon, 6 May 1996 16:18:18 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA15483; Mon, 6 May 1996 16:18:19 -0700 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA28075; Mon, 6 May 1996 19:14:08 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16511; Mon, 6 May 1996 19:14:08 -0400 Message-Id: <9605062314.AA16511@fwasted.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1714) SNMP and MIBs for IPv6 Date: Mon, 06 May 96 19:14:08 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob and Steve, As I go through my bag of things I need to ship IPv6 products to customers I think I will need SNMP update and a MIB for IPv6. Is someone in the app area working on this in the IETF or in our WG? Customers will want to know what the specification state is for these in the IETF so they are comfortable their IPv6 aware nodes can be managed? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 6 16:22:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11383; Mon, 6 May 96 16:22:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11377; Mon, 6 May 96 16:22:37 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09074; Mon, 6 May 1996 16:19:50 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA15907; Mon, 6 May 1996 16:19:50 -0700 From: bound@zk3.dec.com Received: from bwasted.zk3.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA26753; Mon, 6 May 1996 19:11:33 -0400 Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA16425; Mon, 6 May 1996 19:11:32 -0400 Message-Id: <9605062311.AA16425@fwasted.zk3.dec.com> To: qv@iol.unh.edu (Quaizar Vohra) Cc: Francis.Dupont@inria.fr (Francis Dupont), ipng@sunroof.eng.sun.com (ipng) Subject: (IPng 1715) Re: AF_INET vs AF_INET6 sockets In-Reply-To: Your message of "Mon, 06 May 96 12:47:03 EDT." <9605061647.AA09747@iol.unh.edu> Date: Mon, 06 May 96 19:11:32 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quaizar, I think this discussion should be taking place on the ipv6imp list not on the list where we build specifications for IPv6. So after this message would yo move this discussion to ipv6imp list. Thank You. I agree with 99% of the way Francis has responded. Except I did not implement the port space exactly as Francis may be depicting. This gets into the issue if you implemented a complete dual stack or a dual network layer stack. If you map all IPv4 addresses from the link and from the API to ipv4-mapped addresses then duplicating port space is not a good idea but no one can prevent one from implementing it that way. But the bigger issue is that customers will only want ONE COPY of telnet NOT "telnetv4 and telenetv6" is input from my customers on IPv6. So that means one port number. This can be done and our implementation can do it this way and it will work fine. But that means your application has to have the flexibility to handle both AF_INET and AF_INET6 and more complex modules like inetd.conf. >Hi Francis, >> >> In your previous mail you wrote: >> >> Can we have 2 servers listening on the same port #, one of AF_INET >> family, other of AF_INET6 family ( both the sockets have wildcard entries >> in the foreign address field in their respective in_pcbs ). If the above is >> not allowed, then this should be allowed. >> >>=> no, the wildcard of AF_INET6 is for any IPv6 address, including >>IPv4-mapped IPv6 then the wildcard of AF_INET is included in it. > >>Regards >> >>Francis.Dupont@inria.fr >> >If an IPv4 server opens an AF_INET socket, listening on port # n, then an >IPv6 server wants to open an AF_INET6 socket, listening on the same >port # n, this should be allowed as the first socket doesn't cover IPv6 >addresses. Not if you implement a non-IPv4-IPv6 transport layer and pcb's and your using IN6_ADDRANY (though a scheme could be devised if one really really wanted to do this), but it is possible when the port is bound to an address because an ipv4-mapped address is clearly different from an IPv6 address per the addressing spec. THough I cannot see the use of this and duplicating port space for IPv4 and IPv6 apps is a nightmare wating to happen in the real world. >But if these sockets were opened in reverse order, then they shouldn't be >allowed as per your argument. Does not matter if its reversed or not the same problem exists. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 6 18:05:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11455; Mon, 6 May 96 18:05:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11449; Mon, 6 May 96 18:05:16 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27629; Mon, 6 May 1996 18:02:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA11253; Mon, 6 May 1996 18:02:30 -0700 Received: from ftp.com by ftp.com ; Mon, 6 May 1996 21:02:29 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 6 May 1996 21:02:29 -0400 Received: from fenway.ftp.com by MAILSERV-D.FTP.COM (5.x/SMI-SVR4) id AA27858; Mon, 6 May 1996 21:03:01 -0400 Message-Id: In-Reply-To: <9605062314.AA16511@fwasted.zk3.dec.com> References: Conversation <9605062314.AA16511@fwasted.zk3.dec.com> with last message <9605062314.AA16511@fwasted.zk3.dec.com> Priority: Normal To: ipng@sunroof.eng.sun.com Mime-Version: 1.0 From: Frank T Solensky Subject: (IPng 1716) Re: SNMP and MIBs for IPv6 Date: Mon, 06 May 96 21:03:03 EDT Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >.. I will need SNMP update and a MIB for IPv6. Is > someone in the app area working on this in the IETF or in our WG? There's a IPv6 mib mailing list set up but it's been very quiet. The list address is ip6mib@research.ftp.com; usual "-request" suffix to join or leave. -- Frank ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 7 06:19:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11662; Tue, 7 May 96 06:19:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11656; Tue, 7 May 96 06:19:06 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27806; Tue, 7 May 1996 06:16:20 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA26562; Tue, 7 May 1996 06:16:20 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa14222; 7 May 96 9:15 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1717) I-D ACTION:draft-ietf-ipngwg-iid-02.txt Date: Tue, 07 May 96 09:15:12 -0400 Message-Id: <9605070915.aa14222@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Identifying IPv6 Interfaces in Link-Local Addresses Author(s) : R. Elz Filename : draft-ietf-ipngwg-iid-02.txt Pages : 16 Date : 05/06/1996 This draft proposes a change to the way that IPv6 link local addresses are constructed, so that a node can guarantee that all of its link local addresses are unique within the node. The current definition of a link local address, a well known prefix, some number of zero bits, and a link specific unique token, ensures that it will be unique on the link, which is what is required for communications using those addresses over the link, but does not require uniqueness of the addresses within a node. In some cases all of a nodes interfaces may share the same link local address. Even the possibility of this means that link local addresses, which may in some situations be the only addresses that exist, cannot be used for internal definition of interfaces, or other purposes within the node. This draft suggests a method by which nodes may overcome this problem, by redefining the bits between the prefix and the token to be available to be used by the node to cause the addresses to be unique. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-iid-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-iid-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-iid-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960506111630.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-iid-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-iid-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960506111630.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 7 06:52:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11693; Tue, 7 May 96 06:52:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11687; Tue, 7 May 96 06:52:00 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01030; Tue, 7 May 1996 06:49:13 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA04306; Tue, 7 May 1996 06:49:10 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id CAA05061; Tue, 7 May 1996 02:31:02 +0200 (MET DST) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id CAA29448; Tue, 7 May 1996 02:30:59 +0200 Message-Id: <199605070030.CAA29448@givry.inria.fr> From: Francis Dupont To: bound@zk3.dec.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1718) Re: SNMP and MIBs for IPv6 In-Reply-To: Your message of Mon, 06 May 1996 19:14:08 EDT. <9605062314.AA16511@fwasted.zk3.dec.com> Date: Tue, 07 May 1996 02:30:54 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: As I go through my bag of things I need to ship IPv6 products to customers I think I will need SNMP update and a MIB for IPv6. Is someone in the app area working on this in the IETF or in our WG? => I have not seen a significant progress on the IPv6 MIB ? Is there some nasty issues or has nobody enough time to work on it or simply am I not informed about it ? Thanks Francis.Dupont@inria.fr PS: with all the magic tools for parsing, verifying, building, ..., MIBs it should not be a problem ?! ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 7 07:08:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11709; Tue, 7 May 96 07:08:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11703; Tue, 7 May 96 07:08:09 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02579; Tue, 7 May 1996 07:05:22 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA08180; Tue, 7 May 1996 07:05:21 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id UAA00592; Mon, 6 May 1996 20:48:10 +0200 (MET DST) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id UAA29002; Mon, 6 May 1996 20:48:08 +0200 Message-Id: <199605061848.UAA29002@givry.inria.fr> From: Francis Dupont To: qv@iol.unh.edu (Quaizar Vohra) Cc: ipng@sunroof.eng.sun.com (ipng) Subject: (IPng 1719) Re: AF_INET vs AF_INET6 sockets In-Reply-To: Your message of Mon, 06 May 1996 12:47:03 EDT. <9605061647.AA09747@iol.unh.edu> Date: Mon, 06 May 1996 20:47:42 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: If an IPv4 server opens an AF_INET socket, listening on port # n, then an IPv6 server wants to open an AF_INET6 socket, listening on the same port # n, this should be allowed as the first socket doesn't cover IPv6 addresses. => I don't agree, it should be not allowed. But if these sockets were opened in reverse order, then they shouldn't be allowed as per your argument. => the order is not important, you can't have two servers with the same port in the general case (ie without a REUSEADDR/REUSEPORT option for UDP). Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 8 12:10:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12893; Wed, 8 May 96 12:10:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12887; Wed, 8 May 96 12:10:11 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14800; Wed, 8 May 1996 12:07:23 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA17496; Wed, 8 May 1996 12:07:17 -0700 Received: by stb.info.com (Smail3.1.28.1 #4) id m0uFsTV-000ZCWC; Sat, 4 May 96 18:19 PDT Message-Id: Date: Sat, 4 May 96 18:19 PDT From: Michael Gersten Received: by NeXT.Mailer (1.100) Received: by NeXT Mailer (1.100) To: ipng@sunroof.eng.sun.com Subject: (IPng 1720) Re: bsd-api-5 questions Reply-To: michael@stb.info.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've read most (all?) of the comments on the inet vs af name issue. As far as I can tell, the only reason for using inet instead of af is: 1. This is an inet spec, 2. If we use af, and make it general, then what do we do when it doesn't work (when an address format doesn't work for the given library routines). For #1, if you are trying to make any sort of protocol independent specs, you're looking at the wrong issue. I'll repeat what I've said before: I *HATE* the v4 socket protocol, because it is DEVICE DEPENDENT!!! Imaging having to specify a different flag to the open call every time, to specify whether you are opening a file on a floppy disk, a hard drive, or a network drive. Imagine having to write code differently to talk to the terminal, versus talking to a pipe for your output. Now imagine having to write your code differently to talk to remote server A versus remote server B, depending on what type of name the user gave you. That's what the existing sockets specs require. In fact, for 99% of the programs, all you want is the ability to take a string, do open/close/read/write on it, and use it transparently. Whether that string is "/path/name/file", or "\\computer\sharedir\path\file", or "/tmp/.X11/x-socket", or "some.host.name:port", or "http://www.somesite.com/" (at least, if that last one is a read only open call). The proposed getconninfo() (sorry if I misspelled it) was a great first step, as with it, you actually could write a library routine that would do all that. Suddenly, you gain device independence -- the very concept that helped make unix great in the first place. The whole point of these routines is to take an address specification, and convert it to a printable format, and visa-versa. One approach is to just use a single library call, and require all calls to it to test for an error return. The problem? Too many people don't test library return values. Another approach is to use an expandable library call. Allow (root) programs to extend it, or allow it to look up data in a disk based table to determine what the numbers refer to. There's a similar approach taken to deal with the daylight savings time mess. A third approach? Well, why is this even a library routine? Seriously, you are trying to take a data structure, that is logically owned by someone else (the network driver), and interpret what's inside it. ** FOLKS, THINK ADT's. THINK CLASSES. ** Translation from the name to the address format, or from the address format to the name, is a network protocol family issue, not a library issue. The library is the place to put a single, uniform interface to the protocol families, and then have that routine query every registered protocol family in the system until one of them says, "hey, I know what that is -- it's FOOBAR:[$SYS_FILE]". Michael p.s.: Note the following: I've implicitly assumed the following in the above, which may not be in the current specs: 1. It's possible to find out what the registered protocol/address families are. 2. It's possible for a protocol family driver to look at an address family structure, and determine if it is valid for that driver or not 3. You will never have to worry about two different drivers being able to interpret the same data block. Ideally, the way to do this is to say that the address structures are "owned" by the protocol drivers, and not assembled by user programs. This works if "getconninfo()" is in the specs, as it, plus a wrapper routine to try the various return values from it, can be used to generate such an address structure, without the program having to do any such work. (It will be done by either the library, or by the drivers; either way, the user code doesn't care about it and doesn't change anything). However, this is a significant change from the current approach. I (hate to say it) don't think it will make it into the current API specs. But I do think that anyone writting API specs should ask one line of questions: WHY is the API even an issue for the IPv6 group? If it is to make programming easier across different platforms, then: DO we really want a device dependent library that will make programming harder across different platforms? Michael -- Michael Gersten michael@stb.info.com http://www.stb.info.com/~michael NeXT Registered Developer (NeRD) # 3860 Without Prejudice, UCC 1-207 ** HIRE ME: http://www.stb.info.com/~michael/Work.html ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 8 12:17:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12923; Wed, 8 May 96 12:17:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12916; Wed, 8 May 96 12:16:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16369; Wed, 8 May 1996 12:14:02 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA19737; Wed, 8 May 1996 12:13:39 -0700 Received: from ftp.com by ftp.com ; Wed, 8 May 1996 15:13:35 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 8 May 1996 15:13:35 -0400 Received: by MAILSERV-D.FTP.COM (5.x/SMI-SVR4) id AA04580; Wed, 8 May 1996 15:12:31 -0400 Date: Wed, 8 May 1996 15:12:31 -0400 Message-Id: <9605081912.AA04580@MAILSERV-D.FTP.COM> To: bound@zk3.dec.com Subject: (IPng 1721) Re: SNMP and MIBs for IPv6 From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: ipng@sunroof.eng.sun.com Repository: mailserv-d.ftp.com, [message accepted at Wed May 8 15:12:21 1996] Originating-Client: d-cell.ftp.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Bob and Steve, > > As I go through my bag of things I need to ship IPv6 products to > customers I think I will need SNMP update and a MIB for IPv6. Is > someone in the app area working on this in the IETF or in our WG? > > Customers will want to know what the specification state is for these in > the IETF so they are comfortable their IPv6 aware nodes can be managed? there is an ipv6 mib working group. it is in the network management area. i've forwarded your comment on to dierdre kostick - the nmad. -- Frank Kastenholz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 8 14:27:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13084; Wed, 8 May 96 14:27:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13078; Wed, 8 May 96 14:27:29 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10349; Wed, 8 May 1996 14:24:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA29022; Wed, 8 May 1996 14:24:39 -0700 From: bound@zk3.dec.com Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id RAA09605; Wed, 8 May 1996 17:10:35 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA11527; Wed, 8 May 1996 17:09:08 -0400 Message-Id: <9605082109.AA11527@fwasted.zk3.dec.com> To: kasten@ftp.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1722) Re: SNMP and MIBs for IPv6 In-Reply-To: Your message of "Wed, 08 May 96 15:12:31 EDT." <9605081912.AA04580@MAILSERV-D.FTP.COM> Date: Wed, 08 May 96 17:09:08 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thanks Mike and Frank,..... /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 10 01:34:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14412; Fri, 10 May 96 01:34:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14406; Fri, 10 May 96 01:34:10 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02138; Fri, 10 May 1996 01:31:21 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA18526; Fri, 10 May 1996 01:31:13 -0700 Received: from (hdubois@localhost) by viviane.dassault-elec.fr (8.7.4/SMI-SVR4) id KAA02057 ; Fri, 10 May 1996 10:30:10 +0200 (MET DST) Date: Fri, 10 May 1996 10:30:10 +0200 (MET DST) From: Herve Dubois To: NG IP Subject: (IPng 1723) NDP specs Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, We have just started to develop a 4.4BSD based IPv6 software. We are dealing with routing aspects, and we have a few questions regarding NDP specifications. Most of the public implementations we know still use the IPv4 routing mechanisms. However, it appears to us that for a host configuration, the routing tables are replaced by the Destination and the Neighbor Caches. Is our understanding correct? Thanks in advance. herve ------------------------------------------------------------- Herve Dubois Dassault Electronique 55, quai Marcel Dassault Herve.Dubois@dassault-elec.fr 92214 Saint-Cloud ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 10 06:06:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14513; Fri, 10 May 96 06:06:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14507; Fri, 10 May 96 06:05:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16067; Fri, 10 May 1996 06:02:57 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA25162; Fri, 10 May 1996 06:02:58 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa12953; 10 May 96 9:02 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1724) I-D ACTION:draft-ietf-ipngwg-pppext-ipv6cp-03.txt Date: Fri, 10 May 96 09:02:08 -0400 Message-Id: <9605100902.aa12953@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-pppext-ipv6cp-03.txt Pages : 11 Date : 05/09/1996 The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-pppext-ipv6cp-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-pppext-ipv6cp-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-pppext-ipv6cp-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960509145039.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-pppext-ipv6cp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-pppext-ipv6cp-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960509145039.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 10 08:55:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14663; Fri, 10 May 96 08:55:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14657; Fri, 10 May 96 08:54:17 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05404; Fri, 10 May 1996 08:51:26 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA07373; Fri, 10 May 1996 08:51:20 -0700 From: Victor.DIAS-FERNANDES@DG12.cec.be X400-Received: by mta sun1.iihe.ac.be in /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Fri, 10 May 1996 14:37:52 +0200 X400-Received: by /PRMD=CEC/ADMD=RTT/C=BE/; Relayed; Fri, 10 May 1996 14:37:29 +0200 Date: Fri, 10 May 1996 14:37:29 +0200 X400-Originator: Victor.DIAS-FERNANDES@DG12.cec.be X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=CEC/ADMD=RTT/C=BE/;WIN2362-960510123729-38C5] Original-Encoded-Information-Types: undefined X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Comments to: Alternate-Recipient: Allowed Message-Id: To: ipng@sunroof.eng.sun.com (Non Receipt Notification Requested) Cc: mccann@zk3.dec.com (Non Receipt Notification Requested), rja@cisco.com (Non Receipt Notification Requested) Subject: (IPng 1725) Re: Comments to: draft-ietf-ipngwg-pmtuv6-02.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In article 9605061635.AA07467(a)tlaser.zk3.dec.com Jack McCann wrote: >Or establish a security association with each router along the path, >and authenticate the source of the PTBm. Perhaps one of you security >gurus out there could comment on this? > >We considered a pmtu probe mechanism such as you suggest. I even went >so far as to sketch out a rough draft. We decided not to include it in >the pmtuv6 spec. A pmtu probe mechanism would be an add-on, we still >need what's in the spec. The additional overhead of a pmtu probe might >very well cost more than the savings of avoiding some packet too big drops >(especially if you expect the packet loss frequency due to packet too big >to be low). > >Working Group: do we need a pmtu probe mechanism? > >This should not hold up the current spec, IMHO. I agree that if the (expected) packet loss frequency will be low then the PMTU probe mechanism is of no use. But if it will not be the case; then dropping big packets will be more expensive then treating a small packet as the PMTU probe packet. Only the experience can answer this question, and definitely I agree that _This should not hold up the current spec..._. In article 199605062158.OAA21880(a)puli.cisco.com Ran Atkinson wrote: >Hmm. The router sending the ICMPv6 error message could simply establish an >IPsec SA with the message's destination and then use IPsec once the SA is >established. I don't think it needs to be established for each router >along the path or in advance of sending the message since we now have >dynamic key management and its easy enough to queue a packet or two >while key management sets up an IPsec SA. > >... This will solve properly the security problem. Another possibility could be to have included in the routers tables the PMTU to the destinations. Each router could insert and update the MTU to the destinations and then the local router could inform directly (creating SA if needed) the local host the correct PMTU to use. This could be used to take decision on traffic forwarding based on the PMTU needed for the specific traffic (e.g., NFS). But again if the expected packet loss frequency will be low then there is no reason to modify the specifications. In article 9605061635.AA07467(a)tlaser.zk3.dec.com Jack McCann wrote: >The spec does suggest that an implementation provide a way to change the >pmtu value for a given path, which in the case of multicast may actually >be the set of paths to all members of the multicast. It is not clear to me if this configurable value will take precedence. In the specification we have: 4. Protocol Requirements .../... When a node receives a Packet Too Big message, it MUST reduce its estimate of the PMTU for the relevant path, based on the value of the MTU filed in the message. ... Victor Dias Fernandes (victor.dias-fernandes@dg12.cec.be) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 10 09:26:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14708; Fri, 10 May 96 09:26:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14702; Fri, 10 May 96 09:25:16 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10446; Fri, 10 May 1996 09:22:24 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA17447; Fri, 10 May 1996 09:22:23 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa17786; 10 May 96 12:18 EDT To: IETF-Announce:;@mercury Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 1726) Protocol Action: A Method for the Transmission of IPv6 Packets over Ethernet Networks to Proposed Standard Date: Fri, 10 May 96 12:18:17 -0400 Message-Id: <9605101218.aa17786@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft "A Method for the Transmission of IPv6 Packets over Ethernet Networks" as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary This memo specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in IPv6 Neighbor Discovery when those messages are transmitted on an Ethernet. Working Group Summary The Working Group Last-Call did not indicate any problems with this proposal. Protocol Quality This document has been reviewed for the IESG by Scott Bradner and Allison Mankin. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 10 11:30:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14896; Fri, 10 May 96 11:30:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14890; Fri, 10 May 96 11:30:27 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05617; Fri, 10 May 1996 11:27:38 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA07261; Fri, 10 May 1996 11:27:36 -0700 Received: from mailhost.ipsilon.com (localhost [127.0.0.1]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with ESMTP id LAA12680; Fri, 10 May 1996 11:26:52 -0700 Message-Id: <199605101826.LAA12680@mailhost.Ipsilon.COM> X-Mailer: exmh version 1.6.4 10/10/95 To: Victor.DIAS-FERNANDES@DG12.cec.be Cc: ipng@sunroof.eng.sun.com (Non Receipt Notification Requested), mccann@zk3.dec.com (Non Receipt Notification Requested), rja@cisco.com (Non Receipt Notification Requested) Subject: (IPng 1727) Re: Comments to: draft-ietf-ipngwg-pmtuv6-02.txt In-Reply-To: Your message of "Fri, 10 May 1996 14:37:29 +0200." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 10 May 1996 11:26:51 -0700 From: Peter Grehan Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Another possibility could be to have included in the routers tables the >PMTU to the destinations. Each router could insert and update the MTU to >the destinations and then the local router could inform directly >(creating SA if needed) the local host the correct PMTU to use. Aside from the fact that you will have to modify the existing v6 routing protocols to carry MTU information, this only works well within a routing domain where no aggregation occurrs. Since each network may have a different MTU, you have to know the MTU for *all* possible networks, which could make the routing tables somewhat large, or you would have to use the minimum MTU when you aggregate, which can give less-than-optimum performance. Peter. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 12 14:52:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15482; Sun, 12 May 96 14:52:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15476; Sun, 12 May 96 14:52:32 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03161; Sun, 12 May 1996 14:49:39 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA14110; Sun, 12 May 1996 14:49:39 -0700 From: bound@zk3.dec.com Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id RAA21118; Sun, 12 May 1996 17:42:04 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA23781; Sun, 12 May 1996 17:41:32 -0400 Message-Id: <9605122141.AA23781@fwasted.zk3.dec.com> To: Herve Dubois Cc: NG IP Subject: (IPng 1728) Re: NDP specs In-Reply-To: Your message of "Fri, 10 May 96 10:30:10 +0200." Date: Sun, 12 May 96 17:41:31 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >We have just started to develop a 4.4BSD based IPv6 software. >We are dealing with routing aspects, and we have a few questions >regarding NDP specifications. >Most of the public implementations we know still use the IPv4 >routing mechanisms. >However, it appears to us that for a host configuration, >the routing tables are replaced by the Destination and the >Neighbor Caches. >Is our understanding correct? >Thanks in advance. No. The suggestions in ND regarding the cache mechanisms are just that ----> suggestions. How you want to implement your routing tables is your choice of implementation thats not determined by the IETF. But when you do it you MUST do the parts specified by the NDP spec. Think about it? Many of the specs in the IETF are not written by implementors so how could they tell you to build your routing tables in an implementation? The key is for you to adhere to the spec then go to bake-offs to see if you interoperate with everyone. For serious implementation discussion of IPv6 you should join the ipv6 implementors list: ipv6imp-request@munnari.oz.au But I suggest you do put the ND cache in the routing table. I think anyone who does not update their implementation to the 4.4 rt_entry for ND is missing the boat, but that is a very biased opinion as I think highly of the 4.4 code base. You will face many design decisions on updating the ND and rt_entry and how best to manage the router discovery on a host receiving the advertisements. Have fun!!! /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 13 03:04:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15632; Mon, 13 May 96 03:04:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15626; Mon, 13 May 96 03:04:11 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03295; Mon, 13 May 1996 03:01:16 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA18887; Mon, 13 May 1996 03:01:11 -0700 From: Victor.DIAS-FERNANDES@DG12.cec.be X400-Received: by mta sun1.iihe.ac.be in /PRMD=IIHE/ADMD=RTT/C=BE/; Relayed; Mon, 13 May 1996 11:30:40 +0200 X400-Received: by /PRMD=CEC/ADMD=RTT/C=BE/; Relayed; Mon, 13 May 1996 10:56:50 +0200 Date: Mon, 13 May 1996 10:56:50 +0200 X400-Originator: Victor.DIAS-FERNANDES@DG12.cec.be X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=CEC/ADMD=RTT/C=BE/;WIN2362-960513085650-2E53] X400-Content-Type: P2-1984 (2) Content-Identifier: Re(2): (IPng 172 Alternate-Recipient: Allowed Message-Id: To: Peter Grehan (Non Receipt Notification Requested) Cc: " (Non Receipt Notification Requested)" (Non Receipt Notification Requested), " (Non Receipt Notification Requested)" (Non Receipt Notification Requested), " (Non Receipt Notification Requested)" (Non Receipt Notification Requested) In-Reply-To: <199605101826.LAA12680@mailhost.Ipsilon.COM> Subject: (IPng 1729) Re(2): Re: Comments to: draft-ietf-ipngwg-pmtuv6-02.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ------------------------------ Start of body part 1 > >Another possibility could be to have included in the routers tables the > >PMTU to the destinations. Each router could insert and update the MTU to > >the destinations and then the local router could inform directly > >(creating SA if needed) the local host the correct PMTU to use. > > Aside from the fact that you will have to modify the existing v6 > routing protocols to carry MTU information, this only works well within a > routing domain where no aggregation occurrs. > > Since each network may have a different MTU, you have to know the MTU for > *all* possible networks, which could make the routing tables somewhat > large, or you would have to use the minimum MTU when you aggregate, which > can give less-than-optimum performance. > > Peter. ------------------------------ Start of body part 2 I agree. When rethinking about this idea I was already blocked with the "default route" case. Sorry for this bad idea. Victor Dias Fernandes (victor.dias-fernandes@dg12.cec.be) ------------------------------ End of body part 2 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 13 12:15:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15899; Mon, 13 May 96 12:15:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15875; Mon, 13 May 96 12:14:52 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10084; Mon, 13 May 1996 12:11:57 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA19386; Mon, 13 May 1996 12:11:55 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa19109; 13 May 96 15:02 EDT To: IETF-Announce:;@mercury Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 1730) Protocol Action: An IPv6 Provider-Based Unicast Address Format to Proposed Standard Date: Mon, 13 May 96 15:02:23 -0400 Message-Id: <9605131502.aa19109@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft "An IPv6 Provider-Based Unicast Address Format" as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary This document defines an IPv6 provider-based unicast address format for use in the Internet. The address format defined in this document is consistent with previous documents from the IPng working group and is intended to facilitate scalable Internet routing. The unicast address format defined in this document doesn't preclude the use of other unicast address formats. Working Group Summary This document reflects comments recieved during IESG review. Protocol Quality The document was review for the IESG by Allison Mankin and Scott Bradner. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 15 09:36:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17261; Wed, 15 May 96 09:36:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17255; Wed, 15 May 96 09:35:23 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05393; Wed, 15 May 1996 09:32:27 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA07550; Wed, 15 May 1996 09:32:19 -0700 Received: from kssun9.rus.uni-stuttgart.de (kssun9.rus.uni-stuttgart.de [129.69.30.19]) by artemis.rus.uni-stuttgart.de with SMTP id SAA21970 (8.6.13/IDA-1.6); Wed, 15 May 1996 18:31:33 +0200 Received: by kssun9.rus.uni-stuttgart.de (5.0/SVR4/BelWue-1.0) id AA23369; Wed, 15 May 1996 18:29:11 --100 From: "Paul Christ" Message-Id: <9605151829.ZM23367@kssun9.rus.uni-stuttgart.de> Date: Wed, 15 May 1996 18:29:11 +0200 In-Reply-To: JOIN Project Team "IPv6 demo at JENC7, Budapest" (May 15, 4:51pm) References: X-Mailer: Z-Mail (3.2.1 10apr95) To: JOIN Project Team , ipv6@uni-muenster.de Subject: (IPng 1731) Re: IPv6 demo at JENC7, Budapest Cc: ipv6-wg@ripe.net, ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Definitely congratulations: Paul Christ Allmandring 30 Communication Systems & D 70550 Stuttgart BelWue Development tel ++49 711 13 19 105 Computing Center 'RUS' fax ++49 711 678 7626 University of Stuttgart christ@rus.uni-stuttgart.d400.de On May 15, 4:51pm, JOIN Project Team wrote: > Subject: IPv6 demo at JENC7, Budapest > > Hello, > > I would like to inform you about our IP version 6 demonstration at the > JENC7 (Joint European Networking Conference) May 13-16 in Budapest, > Hungary: > > We have setup an IPv6 test network in Budapest connected to the Danish > research network DENet and to our IPv6 lab at the University of Muenster > in Germany. For the demo we use routers from the Danish company Telebit > Communications A/S and Suns running IPv6 for Solaris 2.5 (release 4.0). > > In Budapest we connected two Telebit routers via a 34 mbps ATM link > running IPv6 over ATM and exchanging routing information with IDRPv6. One > router in Budapest is connected to the IPv6 networks in Germany and > Denmark using static configured IPv6 tunneling (over IPv4 internet) and > exchanging routing information also using IDRPv6. > > We use both IPv4 compatible IPv6 addresses and full IPv6 addresses > according to RFC1897. > > So with this setup we provide full native IPv6 connectivity using the > RFC1897 test address space to the applications included in the Sun > software... > > We have included a diagram detailing this demo setup in our web > pages. So for more information please refer to > > http://www.join.uni-muenster.de/JOIN/ipv6/texte-englisch/budapest.html > > Greetings from Budapest, > Guido > > > ------------------------------------------------------------------------------ > JOIN -- Join Open InterNetworks Guido Wessendorf > An IP Version 6 Project of DFN Westfaelische Wilhelms-Universitaet Muenster > Project Team Email: Universitaetsrechenzentrum > join@uni-muenster.de Einsteinstrasse 60 > http://www.join.uni-muenster.de D-48149 Muenster / Germany > > Phone: ++49 251 83 8459, Fax: ++49 251 83 2678, Email: wessend@uni-muenster.de > ------------------------------------------------------------------------------ > >-- End of excerpt from JOIN Project Team ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 15 10:07:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17338; Wed, 15 May 96 10:07:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17230; Wed, 15 May 96 07:55:13 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20675; Wed, 15 May 1996 07:52:17 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA26252; Wed, 15 May 1996 07:52:14 -0700 Received: from SOLARIX2.UNI-MUENSTER.DE by uni-muenster.de (AIX 3.2/UCB 5.64/4.03) id AA19228; Wed, 15 May 1996 16:50:04 +0200 Received: by solarix2.uni-muenster.de (5.x/SMI-SVR4) id AA11462; Wed, 15 May 1996 16:51:48 +0200 Date: Wed, 15 May 1996 16:51:45 +0200 (MEZ) From: JOIN Project Team To: ipv6@uni-muenster.de Cc: ipv6-wg@ripe.net, ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Subject: (IPng 1732) IPv6 demo at JENC7, Budapest Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I would like to inform you about our IP version 6 demonstration at the JENC7 (Joint European Networking Conference) May 13-16 in Budapest, Hungary: We have setup an IPv6 test network in Budapest connected to the Danish research network DENet and to our IPv6 lab at the University of Muenster in Germany. For the demo we use routers from the Danish company Telebit Communications A/S and Suns running IPv6 for Solaris 2.5 (release 4.0). In Budapest we connected two Telebit routers via a 34 mbps ATM link running IPv6 over ATM and exchanging routing information with IDRPv6. One router in Budapest is connected to the IPv6 networks in Germany and Denmark using static configured IPv6 tunneling (over IPv4 internet) and exchanging routing information also using IDRPv6. We use both IPv4 compatible IPv6 addresses and full IPv6 addresses according to RFC1897. So with this setup we provide full native IPv6 connectivity using the RFC1897 test address space to the applications included in the Sun software... We have included a diagram detailing this demo setup in our web pages. So for more information please refer to http://www.join.uni-muenster.de/JOIN/ipv6/texte-englisch/budapest.html Greetings from Budapest, Guido ------------------------------------------------------------------------------ JOIN -- Join Open InterNetworks Guido Wessendorf An IP Version 6 Project of DFN Westfaelische Wilhelms-Universitaet Muenster Project Team Email: Universitaetsrechenzentrum join@uni-muenster.de Einsteinstrasse 60 http://www.join.uni-muenster.de D-48149 Muenster / Germany Phone: ++49 251 83 8459, Fax: ++49 251 83 2678, Email: wessend@uni-muenster.de ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 15 12:40:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17564; Wed, 15 May 96 12:40:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17558; Wed, 15 May 96 12:39:16 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11662; Wed, 15 May 1996 12:36:19 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA14109; Wed, 15 May 1996 12:36:19 -0700 From: bound@zk3.dec.com Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA14949; Wed, 15 May 1996 15:20:50 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA31439; Wed, 15 May 1996 15:20:09 -0400 Message-Id: <9605151920.AA31439@fwasted.zk3.dec.com> To: JOIN Project Team Cc: ipv6@uni-muenster.de, ipv6-wg@ripe.net, ipng@sunroof.eng.sun.com, ipv6imp@munnari.oz.au Subject: (IPng 1733) Re: IPv6 demo at JENC7, Budapest In-Reply-To: Your message of "Wed, 15 May 96 16:51:45 +0200." Date: Wed, 15 May 96 15:20:09 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is absolutely OUTSTANDING... Congratulations, /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 15 15:12:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17742; Wed, 15 May 96 15:12:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17736; Wed, 15 May 96 15:12:07 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08786; Wed, 15 May 1996 15:09:09 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA03085; Wed, 15 May 1996 15:08:56 -0700 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id PAA11980; Wed, 15 May 1996 15:08:52 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 15 May 1996 15:09:38 -0700 To: jburgan@baynetworks.com From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1734) Request to Advance "IP Version 6 over PPP" Cc: ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us, hinden@Ipsilon.COM, mankin@isi.edu, sob@harvard.edu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a RFC with Proposed Standard status: Title : IP Version 6 over PPP Author(s) : D. Haskin, E. Allen Filename : draft-ietf-ipngwg-pppext-ipv6cp-03.txt Pages : 11 Date : 05/09/1996 The working group last call on this document ended on Tuesday May 7, 1996. The current draft (03) contains clarifications for comments received during the working group last call. Bob Hinden / Steve Deering ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 16 08:25:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18242; Thu, 16 May 96 08:25:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18236; Thu, 16 May 96 08:25:21 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29867; Thu, 16 May 1996 08:22:24 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA12390; Thu, 16 May 1996 08:22:21 -0700 Received: from [205.226.1.20] (acacia.Ipsilon.COM [205.226.1.20]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA08238; Thu, 16 May 1996 08:22:08 -0700 X-Sender: hinden@mailhost.ipsilon.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 May 1996 08:22:53 -0700 To: Jeffrey Burgan From: hinden@Ipsilon.COM (Bob Hinden) Subject: (IPng 1735) Re: Request to Advance "IP Version 6 over PPP" Cc: hinden@Ipsilon.COM (Bob Hinden), jburgan@BayNetworks.com, ipng@sunroof.eng.sun.com, scoya@cnri.reston.va.us, mankin@isi.edu, sob@harvard.edu Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jeff, >Thanks... We'll get moving on this. Great! Thanks much. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 17 08:30:36 1996 Return-Path: Received: by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA18875; Fri, 17 May 96 08:30:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA18869; Fri, 17 May 96 08:30:11 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07432; Fri, 17 May 1996 08:27:11 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA08942; Fri, 17 May 1996 08:27:10 -0700 Received: from shand.reo.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA18929; Fri, 17 May 1996 10:53:54 -0400 (EDT) Received: from localhost by shand.reo.dec.com (5.65/MS-010395) id AA14469; Fri, 17 May 1996 15:53:19 +0100 Message-Id: <9605171453.AA14469@shand.reo.dec.com> To: ipng@sunroof.eng.sun.com Cc: shand@shand.ENET.dec.com Subject: (IPng 1736) Responses to Comments on Multihoming draft Date: Fri, 17 May 96 15:53:19 +0100 From: (Mike Shand REO2 G/C2 DTN:830-4424) X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry its taken me so long to around to this. Anyway here goes. I've received written comments from Brian Carpenter and Dave Marlow. I'll try to respond to them below. Brian first > > Multi-homing Support in IPv6 > > As I said in LA, this would cause less confusion with the > multi-service provider kind of multihoming if you changed the > title slightly, e.g. to "Multi-homed Host Support in IPv6" > Agreed > ... > > 2.2.1 Type 2a (Equivalent addresses) > ... > > 2.2.2 Type 2b (Non-equivalent addresses) > > It isn't quite clear how this distinction applies to ATM addresses. > In a "classic" ATM LIS, addresses are equivalent. In a ROLC "cloud", > are topologically distant address equivalent or not? > I guess the distinction I am making between "equivalent" and "non-equivalent" addresses boils down to " does it MATTER which source address you choose?" If the answer is NO, then the addresses are equivalent. Clearly, if different addresses in a ROLC "cloud" result in different routing, and especially if one address is reachable while another is not, then they must be considered as non-equivalent. Whether or not we need to worry about a detailed taxonomy here is arguable. I suspect that when we get down to defining solutions we will only have a few simple cases to deal with. What I was trying to do here was prevent us from all having different ideas as to what we meant by "multi-homing". > ... > > 3. Some possible solutions > > > > Since the type 3 case is the most interesting and potentially impor- > > tant, we will focus on that case. > > It beats me how you reach this conclusion. I would have thought > it was the minority case. > OK, I'll come clean. What I meant was "*I* find this case most interesting" :-) I guess I've spent too long talking to people who want to do this kind of thing. I agree that some of the other cases are probably going to be much more common. I'll try to level the playing field a bit. > ... > > 3.1 Using a single IP address > > > > 3.1.1 Multi-lan subnets > > > > The IP (and IPv6) architecture effectively precludes this option. > > Yes, it just says "no". So why discuss it? (typing from a > proxy-arped subnet :-) Agreed, we don't need to discuss it, but perhaps we just need a note indicating why we rejected such an approach > > ... > > 3.1.2 Routing Hosts > > > > Another alternative is for the multihomed hosts to appear as routers > > with the single address present on a private subnet e.g. > > Ugly, ugly, ugly. Host routers are bad news operationally (being > managed by ignorant jerk system managers not by network managers). > Absolutely! again we need to say why we reject this. > ... > > 3.1.3 Using an anycast address > ... > > 2. The anycast subnet prefix could be distinct from any of the > > natural subnet prefixes. In this case all the LANs have to > > employ host routes. Although requiring slightly more context in > > the routers, this model might be preferable since it avoids the > > asymmetry inherent in the first model. > > Couldn't we invent a sort of "hidden anycast" where ND reveals > anycast hosts to the local router, i.e. >1 reply to a solicitation > is allowed and Duplicate address detection is suppressed? > I'm not quite sure what you are saying here. Do you mean that there is nothing to semantically distinguish an anycast address from a unicast address, but that we note their existence from the multiple replies. How do we know when we are permitted to suppress DAD? What I think I was after here (its been a long time...) was a prefix which indicates that this address may exist an any, or all, of the connected interfaces. So you should do ND for it on all your interfaces and you may see it multiple times on the same and/or different interfaces. One way of looking at this is to imagine a "virtual" subnet which contains all these addresses to which the systems have a "virtual" interface, but this maps to multiple physical interfaces, all of which need to do ND for the address. > ... > > 3.2.2.1 EID like > > > It would be possible to include something like an EID in the destina- > > tion header. Packets transmitted by the multihomed node would use > > A twist on this that occurs to me is a "primary address" destination > option, i.e. if a mutihomed host is talking on a secondary address > it uses the secondary address as its Source address, but adds > a destination option carrying whichever address is deemed to be > its Primary. This can be used as an EID, and can be used as an > alternate address in the dual rail case. (If you do this > symmetrically on two interfaces, it's "the dual rail hack"). > Yes, I like that idea. The primary address could either be another unicast address, or it could be an anycast address. i.e. we could choose which technique we wanted to use depending on the circumstances. I think this all plays with Jim Bound's Dynamic reassignment of addresses stuff. > That's about it. > > Brian Thanks Brian. Now for Dave's comments > I have read through Mike and Matt's Multihoming Support in IPv6 > (draft-shand-ipv6-multi-homing-00.txt). I think that this is a good > overview of the host multihoming problem. I have the following > points on the draft: > > 1. The draft covers host multihoming for UNICAST transfer but never > explicitly states this. Unicast transfer is the important case where > additional mechanisms appear to be needed. The draft needs to explicitly > state that it covers issues related to unicast transfer. An alternative > is to be explicit about the current text being for unicast and to add a > section or an appendix to cover the multicast issues. I have a few > comments on multicast transfer with multihomed hosts, but I do not see > multicast as a primary driver for this work. > Yes, your right of course. I really hadn't considered multicast at all in what I did. If its really simple we could just add it in, otherwise we might want to split it out. > 2. In section 2.3 (High Resilience Multiple Interfaces) there is a > list of ten requirements for host multihoming where each host has > multiple interfaces which are functionally equivalent. One additional > requirement that should be added is for a host originating multicast > packets to identify the interface that each packet is originated on. > This is currently assumed by all multicast routing protocols to ensure > that multicast routers can construct the proper tree. I think we need to have interface specific source addresses for unicast use too, so I don't have a problem with that. > > 3. I think that an explicit goal should be added to the list of section 2.3 > for unicast host multihoming to support both TCP and UDP transfers. > Unicast RSVP/Integrated Services operations should also be supported. yes, that's certainly an implicit goal, I have no problem with making it explicit. > > 4. One issue that I did not see covered in section 3 (Some possible solutions) > were DNS impacts. I am not sure whether any extensions are required to DNS > itself to cover host multihoming, but it seems possible that hosts may need > to treat information from a DNS server differently (i.e. duplicate DNS > responses). > I don't know. Any DNS experts care to comment. > > 5. There does not appear to be a need for any mechanisms, beyond those of > RFC 1112, to support host multihoming, multicast transfer. Further work is > needed to verify this. Section 4 of the internet draft (Selecting the > output interface) is an important issue for multicast transfer; however, the > multicast transfer has a different set of considerations than what is covered. > While there may not be a need for additional mechanisms, consistent operation > by a group of multihomed hosts using multicast transfer is needed and this > might be a subject for an informational document. The goals for host > multihoming's multicast capability should be to ensure that UDP multicast > transfer is supported along with multicast RSVP/Integrated Services > operations. > Yes we need to think about the multicast issues. > > Concluding remarks: I think that the current ID, with some modifications > to cover the identified issues, meets its objectives of providing a > taxonomy for host multihoming and a discussion of the issues. I would like > to see further work on the Type 3 case (High Resilience Multiple Interfaces). > Going over section 3 (Possible solutions) the anycast address and EID like > alternatives appear to meet the need for unicast host multihoming. Given > that anycast addresses are already being developed within the IPv6 effort > it would seem that this approach should be looked at first. > Yes I think we now need to come down on some hard proposals and see how they fly. If anyone has any input to this I'm sure I'll hear. Otherwise I'll just make some choices and wait for people to scream. My preference is for an anycast type style. I'd rather have the routing be done by the routers rather than have the source guess which destination address is going to work. One further thing. We may want to think about use "reverse path" information in determining which interface to transmit on. Of course this doesn't work well if the routes are asymetric, but it can give some useful information. Is anyone violently opposed to this? > Dave Thanks Dave I look forward to any further reactions. I'll try to get a redraft done in the next couple of weeks. Mike ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 19 00:29:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19809; Sun, 19 May 96 00:29:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19803; Sun, 19 May 96 00:28:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02488; Sun, 19 May 1996 00:25:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA07733; Sun, 19 May 1996 00:25:52 -0700 Received: by gw.home.vix.com id AAA07074; Sun, 19 May 1996 00:25:51 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA17254; Sun, 19 May 1996 00:25:51 -0700 Message-Id: <9605190725.AA17254@wisdom.home.vix.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1737) Speaking of RFC 1884, I have two requests for clarification Date: Sun, 19 May 1996 00:25:45 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (1) In section 2.2 we see the text: 1884> 2. Due to the method of allocating certain styles of IPv6 1884> addresses, it will be common for addresses to contain long 1884> strings of zero bits. In order to make writing addresses 1884> containing zero bits easier a special syntax is available to 1884> compress the zeros. The use of "::" indicates multiple groups 1884> of 16-bits of zeros. The "::" can only appear once in an 1884> address. The "::" can also be used to compress the leading 1884> and/or trailing zeros in an address. What of an address specifier which is entirely full even with no zero fill, and yet includes a ::? Examples are: ::1080:0:0:0:8:800:200C:417A 1080:0:0:0:8:800:200C:417A:: 1080:0:0:0:8::800:200C:417A Note that none of these has more than one instance of ::, and none of the ::'s shown are meaningful since there are eight (8) hexdigit strings. I believe (and if I'm not told otherwise by Steve or Bob, BIND will believe) that all three are valid and that each means the same as: 1080:0:0:0:8:800:200C:417A Which is the same address with just the eight hexdigit strings and no ::'s. (I am, in other words, going to be liberal in what I accept, but too liberal?) (2) In the same section, we then see: 1884> 3. An alternative form that is sometimes more convenient when 1884> dealing with a mixed environment of IPv4 and IPv6 nodes is 1884> x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values 1884> of the six high-order 16-bit pieces of the address, and the 'd's 1884> are the decimal values of the four low-order 8-bit pieces of the 1884> address (standard IPv4 representation). Examples: No reference is given for "standard IPv4 reppresentation", so I scanned some of the literature. RFC 790 is fascinating since it lists all the networks that had been allocated as of September 1981, in less than one page, but before doing this we see this introduction: 790> One notation for internet host addresses commonly used divides the 790> 32-bit address into four 8-bit fields and specifies the value of each 790> field as a decimal number with the fields separated by periods. For 790> example, the internet address of ISIF is 010.020.000.052. I could live with this as the definition for [RFC1884 2.2 3]'s "standard IPv4 representation" since I know of no software that would parse it the wrong way. (The leading 0's had me going for a minute there, I thought those were octal numbers or that BIND might have treated them as such, but all is well.) Internic's Gopher for "dotted quad" led me to RFC 1924, which I wish I had written but which I don't think I'll support in BIND, and to RFC 1278, whose title sounded promising anyway. RFC 819 has an interesting point or two, helping me understand the "#" address form in RFC 821 that has puzzled me for years: 819> Hosts are generally known by names. Sometimes a host is not known to 819> the translation function and communication is blocked. To bypass 819> this barrier two forms of addresses are also allowed for host 819> "names". One form is a decimal integer prefixed by a pound sign, "#". 819> Another form, called "dotted decimal", is four small decimal integers 819> separated by dots and enclosed by brackets, e.g., "[123.255.37.2]", 819> which indicates a 32-bit ARPA Internet Address in four 8-bit fields. 819> (Of course, these numeric address forms are specific to the Internet, 819> other forms may have to be provided if this problem arises in other 819> transport systems.) I think we can safely dispose of #int and [dot.ted.qu.ad] in interpreting [RFC1884 2.2 3]. :-). RFC 1127 pointed me at [AS 2.1] for this topic, so: 1123> Whenever a user inputs the identity of an Internet host, it SHOULD 1123> be possible to enter either (1) a host domain name or (2) an IP 1123> address in dotted-decimal ("#.#.#.#") form. The host SHOULD check 1123> the string syntactically for a dotted-decimal number before 1123> looking it up in the Domain Name System. RFC 1208 has this to say: 1208> dotted decimal notation: The syntactic representation for a 32-bit 1208> integer that consists of four 8-bit numbers written in base 10 with 1208> periods (dots) separating them. Used to represent IP addresses in 1208> the Internet as in: 192.67.67.20. Nowhere, anywhere, have I found something that tells us which byte comes first. That is, given only RFC 790 and no existing implementations to test against, it would be perfectly reasonable for a vendor to encode 10.0.0.53 with "53" in the high order octet of the IP source or destination address, rather than "10". Interoperability testing has helped us all in this regard. This subject should have made it into the "oral traditions" RFC a while back. RFC 1884 has the same omission. Nowhere is it said that the address forms should be parsed left to right with respect to filling in the packet slots where addresses have to go. We native english speakers are familiar enough with left-to-right and top-to-bottom and "network byte order" so we do OK; however, the document should probably make this point. A reasonable person would read the "alternative" description in [RFC1884 2.2 3] and use that to help interpret [RFC1884 2.2 2] and [RFC1884 2.2 1], but not all implementors are reasonable. Why am I telling you this? Because the classic BSD inet_aton() and older inet_addr() calls have an abbreviated form, shown here from inet(3) (a "man" page): man> INTERNET ADDRESSES man> man> Values specified using the `.' notation take one of the following forms: man> man> a.b.c.d man> a.b.c man> a.b man> a man> man> When four parts are specified, each is interpreted as a byte of data and man> assigned, from left to right, to the four bytes of an Internet address. man> Note that when an Internet address is viewed as a 32-bit integer quantity man> on the VAX the bytes referred to above appear as ``d.c.b.a''. That is, man> VAX bytes are ordered from right to left. man> man> When a three part address is specified, the last part is interpreted as a man> 16-bit quantity and placed in the right-most two bytes of the network ad- man> dress. This makes the three part address format convenient for specify- man> ing Class B network addresses as ``128.net.host''. man> man> When a two part address is supplied, the last part is interpreted as a man> 24-bit quantity and placed in the right most three bytes of the network man> address. This makes the two part address format convenient for specify- man> ing Class A network addresses as ``net.host''. man> man> When only one part is given, the value is stored directly in the network man> address without any byte rearrangement. man> man> All numbers supplied as ``parts'' in a `.' notation may be decimal, oc- man> tal, or hexadecimal, as specified in the C language (i.e., a leading 0x man> or 0X implies hexadecimal; otherwise, a leading 0 implies octal; other- man> wise, the number is interpreted as decimal). Now, before you laugh so hard you fall out of your collective seats, please give BSD credit for actually mentioning the byte order problem with respect to dotted quads. Probably that VAX reference should be excised from BIND's version of this man page, but that's another story. What this man page is trying to tell you is that BSD users have historically said "10.73" rather than "10.0.0.73" because they both worked any place where either worked. This includes DNS primary zone files, by the way. I am pretty much assuming that the IETF does not want to standardize this BSD practice, and that we ought not to accept ::10.73 as equivilent to the longer ::10.0.0.73, especially given that the degenerate case given in that man page would be ambiguous with respect to ::1234, a valid RFC1884 address specifier whose low order 16 bits are hexadecimal 1234 rather than decimal 1234. However, that's only _my_ assumption, and some other implementor may feel differently. In fact some other implementor of RFC 1884 might decide to just call inet_aton() for parsing that IPv4 "dotted quad", which is what I almost did. You can consider this a long winded request that the document be made more clear on these two topics. Advice sent to me personally will also be muchly appreciated, since it will affect what BIND does and what BIND documents. Paul Vixie ISC ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 19 08:43:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19903; Sun, 19 May 96 08:43:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19897; Sun, 19 May 96 08:43:26 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12672; Sun, 19 May 1996 08:40:23 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA25376; Sun, 19 May 1996 08:40:23 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id RAA23371; Sun, 19 May 1996 17:40:22 +0200 (MET DST) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id RAA21147; Sun, 19 May 1996 17:40:21 +0200 Message-Id: <199605191540.RAA21147@givry.inria.fr> From: Francis Dupont To: Paul A Vixie Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1738) Re: Speaking of RFC 1884, I have two requests for clarification In-Reply-To: Your message of Sun, 19 May 1996 00:25:45 PDT. <9605190725.AA17254@wisdom.home.vix.com> Date: Sun, 19 May 1996 17:40:18 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: (1) In section 2.2 we see the text: 1884> 2. Due to the method of allocating certain styles of IPv6 1884> addresses, it will be common for addresses to contain long 1884> strings of zero bits. In order to make writing addresses 1884> containing zero bits easier a special syntax is available to 1884> compress the zeros. The use of "::" indicates multiple groups 1884> of 16-bits of zeros. The "::" can only appear once in an 1884> address. The "::" can also be used to compress the leading 1884> and/or trailing zeros in an address. What of an address specifier which is entirely full even with no zero fill, and yet includes a ::? => it is not yet permitted by the standard, I believe multiple is one or more. Examples are: ::1080:0:0:0:8:800:200C:417A 1080:0:0:0:8:800:200C:417A:: 1080:0:0:0:8::800:200C:417A Note that none of these has more than one instance of ::, and none of the ::'s shown are meaningful since there are eight (8) hexdigit strings. I believe (and if I'm not told otherwise by Steve or Bob, BIND will believe) that all three are valid and that each means the same as: 1080:0:0:0:8:800:200C:417A Which is the same address with just the eight hexdigit strings and no ::'s. (I am, in other words, going to be liberal in what I accept, but too liberal?) => if you don't produce such things you can't be too liberal. (2) In the same section, we then see: => I am strongly in favor of full dotted quad, ie on 10.0.0.53 is valid because it is not a good idea to introduce too much ambiguity... Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 19 10:11:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19945; Sun, 19 May 96 10:11:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19939; Sun, 19 May 96 10:11:44 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14906; Sun, 19 May 1996 10:08:41 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA29228; Sun, 19 May 1996 10:08:33 -0700 Received: (from roque@localhost) by oberon (8.6.6.Beta9/8.6.6.Beta9) id RAA05103; Sun, 19 May 1996 17:54:50 +0100 Date: Sun, 19 May 1996 17:54:50 +0100 From: Pedro Roque Marques Message-Id: <199605191654.RAA05103@oberon> To: (Mike Shand REO2 G/C2 DTN:830-4424) Cc: ipng@sunroof.eng.sun.com, shand@shand.ENET.dec.com Subject: (IPng 1739) Responses to Comments on Multihoming draft In-Reply-To: <9605171453.AA14469@shand.reo.dec.com> References: <9605171453.AA14469@shand.reo.dec.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Mike" == Mike Shand REO2 G/C2 DTN:830-4424 writes: >> ... > 3.2.2.1 EID like >> >> > It would be possible to include something like an EID in the >> destina- > tion header. Packets transmitted by the multihomed >> node would use >> >> A twist on this that occurs to me is a "primary address" >> destination option, i.e. if a mutihomed host is talking on a >> secondary address it uses the secondary address as its Source >> address, but adds a destination option carrying whichever >> address is deemed to be its Primary. This can be used as an >> EID, and can be used as an alternate address in the dual rail >> case. (If you do this symmetrically on two interfaces, it's >> "the dual rail hack"). >> Mike> Yes, I like that idea. The primary address could either be Mike> another unicast address, or it could be an anycast Mike> address. i.e. we could choose which technique we wanted to Mike> use depending on the circumstances. I think this all plays Mike> with Jim Bound's Dynamic reassignment of addresses stuff. As this seams to be a cue for some more input on the Dynamic IP addresses draft and Jim is on vacation i believe i'll take it and try to clarify a bit our proposal. In the multi-homed draft EIDs appear once more as a possible solution to the problems of communicating with hosts that have multiple addresses. Personally i think EIDs, per se, don't solve the problem at hands. I'll try to sustain my claim... Before thinking about the solution lets dig into the problem first. The issue here is the desire to communicate between hosts where one or more hosts have multiple addresses and the "best" address for communication might change *during* the communication period. This problem is present in multi-homed hosts when networks are replicated for reliability, on mobile hosts and it comes into play when we think on renumbering and multi-homed domains with one prefix for provider. The big issue is that the mapping from host (that can be identified by a DNS name or some otherwise meaningless number) to "best" address for communication is dynamic. So having an EID here buys you just the same thing as having a DNS name since the problems raised on mapping from DNS name or EIDs to IP addresses are the same: the mapping is static. The "Dynamic Address Reassignment" draft tries to address precisely this issue and like the other two proposals i'm aware of: Huitema's "Multi-homed TCP" and Perkins mobile draft, it's pretty independent of EIDs. Thus, IMHO, EIDs have yet to find a "raison d'etre". Where the "Dynamic IP" draft comes into play is that is one of the proposals for managing such an host <-> available addresses mapping. It does this by allowing hosts to exchange information with communication peers about the "best" address for communication. In practice, the changes involved in implementations would be, besides encoding and decoding options, restricted to a confined area that deals with outgoing address selection and packet demultiplexing for transport protocols. When we look at BSD systems, packet demultiplexing is done by in_pcblookup by both TCP and UDP. Also, the destination address on connected sockets is determinated by the in_pcb. Incorporating changes at this level does not imply changes to transport protocols. And note that there is already one mapping being done: from internal pcb to address, although static. This is an extension to the actual systems we run today not a redo of the architecture. This is not a simple issue to solve and the draft only tries to point out one base model that could be used. Personally i don't believe this to be either unrealistic or impossible to do, as i do believe that is an issue that deserves our attention. regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 19 16:59:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20037; Sun, 19 May 96 16:59:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20031; Sun, 19 May 96 16:59:05 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28681; Sun, 19 May 1996 16:56:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA28911; Sun, 19 May 1996 16:56:03 -0700 Received: by gw.home.vix.com id QAA06110; Sun, 19 May 1996 16:56:02 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA17993; Sun, 19 May 1996 16:56:02 -0700 Message-Id: <9605192356.AA17993@wisdom.home.vix.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1740) The IPv6 BSD API met RFC 1884 today, and BIND has two more questions Date: Sun, 19 May 1996 16:56:02 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk inet_ntop() needs a heuristic for formatting encapsulated IPv4 addresses. right now i'm choosing to output ::13.1.68.3 as ::13.1.68.3, but ::FFFF:129.144.52.38 is output as ::ffff:8190:3426. that is, if the first 12 octets are zeros, I print the last four octets as a dotted quad. otherwise i print the whole thing as 16-bit words. are there in fact addressing schemes for which it would be useful to print the last four octets as an IPv4 dotted quad, but for which the top 12 octets are nonzero in some way? if so, i will consider adding an external table to recognize these. i'd hate to have somebody be stuck with 16-bit words even though they are speaking IPv4 and "thinking in" IPv4. as long as i've got your attention, i've been thinking about address format autoselection in gethostby*(). if RES_TRY_INET6 is enabled in _res.options, i check for a T_AAAA in gethostbyname(). so far, so good. but if there is no T_AAAA and i end up finding a T_A, i need to produce a "::dot.ted.qu.ad" per our previous flamew.. er, discussions. ok. i may need to change the option's name from RES_TRY_INET6 to RES_USE_INET6 in that case, but that's not a big deal. the question is, given all of that, ought i also return a "::dot.ted.qu.ad" from gethostbyaddr() (that's addr, not name, plz notice) even if handed something whose addrtype is AF_INET on the "input side" ? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 19 17:09:22 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20050; Sun, 19 May 96 17:09:22 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20044; Sun, 19 May 96 17:09:05 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29032; Sun, 19 May 1996 17:06:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA29756; Sun, 19 May 1996 17:06:03 -0700 Received: by gw.home.vix.com id RAA06608; Sun, 19 May 1996 17:06:02 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA17894; Sun, 19 May 1996 17:06:02 -0700 Message-Id: <9605200006.AA17894@wisdom.home.vix.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1741) i propose another change to the IPv6 BSD API document Date: Sun, 19 May 1996 17:06:02 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I propose: int inet_pton __P((int af, const char *src, u_char *dst)); char *inet_ntop __P((int af, const u_char *src, int len)); This differs from the current draft in that the type of the network-format address is "u_char *" rather than "void *". My reason is that I am not comfortable returning a "length" from inet_pton(), or accepting a "length" in inet_ntop(), if the thing whose length I'm counting has an opaque type. In practice, this just means folks will have to cast when they call these functions. But I like the idea of returning and accepting the "number of u_char's" in the address, rather than the "number of voids". I guess I'm also a little worried that folks will try to map these addresses to structures whose internal padding doesn't exactly map the network format, and so making them cast to (u_char*) seems likely to slow them down and make them think about what they are probably doing. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 19 23:47:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20180; Sun, 19 May 96 23:47:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20174; Sun, 19 May 96 23:47:14 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16351; Sun, 19 May 1996 23:44:12 -0700 Received: by mercury.Sun.COM (Sun.COM) id XAA03869; Sun, 19 May 1996 23:44:05 -0700 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA18003; Mon, 20 May 1996 08:44:03 +0200 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA04460; Mon, 20 May 1996 08:44:02 +0200 Message-Id: <9605200644.AA04460@dxcoms.cern.ch> Subject: (IPng 1742) Re: Responses to Comments on Multihoming draft To: ipng@sunroof.eng.sun.com Date: Mon, 20 May 1996 08:44:02 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <9605171453.AA14469@shand.reo.dec.com> from "shand@shand.reo.dec.com" at May 17, 96 03:53:19 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, > > ... > > > 3.1.3 Using an anycast address > > ... > > > 2. The anycast subnet prefix could be distinct from any of the > > > natural subnet prefixes. In this case all the LANs have to > > > employ host routes. Although requiring slightly more context in > > > the routers, this model might be preferable since it avoids the > > > asymmetry inherent in the first model. > > > > Couldn't we invent a sort of "hidden anycast" where ND reveals > > anycast hosts to the local router, i.e. >1 reply to a solicitation > > is allowed and Duplicate address detection is suppressed? > > > > I'm not quite sure what you are saying here. Do you mean that there is nothing > to semantically distinguish an anycast address from a unicast address, but > that we note their existence from the multiple replies. How do we know when we > are permitted to suppress DAD? > Good question. Another example of why I am very unclear whether anycast addresses are useful and implementable. > What I think I was after here (its been a long time...) was a prefix > which indicates that this address may exist an any, or all, of the connected > interfaces. So you should do ND for it on all your interfaces and you may see it > multiple times on the same and/or different interfaces. One way of looking at this > is to imagine a "virtual" subnet which contains all these addresses to which > the systems have a "virtual" interface, but this maps to multiple physical > interfaces, all of which need to do ND for the address. > Yes, but then you have a *new* address type ("Virtual" rather than "anycast"). Brian Carpenter > > ... > > > 3.2.2.1 EID like > > > > > It would be possible to include something like an EID in the destina- > > > tion header. Packets transmitted by the multihomed node would use > > > > A twist on this that occurs to me is a "primary address" destination > > option, i.e. if a mutihomed host is talking on a secondary address > > it uses the secondary address as its Source address, but adds > > a destination option carrying whichever address is deemed to be > > its Primary. This can be used as an EID, and can be used as an > > alternate address in the dual rail case. (If you do this > > symmetrically on two interfaces, it's "the dual rail hack"). > > > > Yes, I like that idea. The primary address could either be another unicast > address, or it could be an anycast address. i.e. we could choose which technique > we wanted to use depending on the circumstances. I think this all plays with > Jim Bound's Dynamic reassignment of addresses stuff. > > > > > That's about it. > > > > Brian > > > Thanks Brian. > > Now for Dave's comments > > > I have read through Mike and Matt's Multihoming Support in IPv6 > > (draft-shand-ipv6-multi-homing-00.txt). I think that this is a good > > overview of the host multihoming problem. I have the following > > points on the draft: > > > > 1. The draft covers host multihoming for UNICAST transfer but never > > explicitly states this. Unicast transfer is the important case where > > additional mechanisms appear to be needed. The draft needs to explicitly > > state that it covers issues related to unicast transfer. An alternative > > is to be explicit about the current text being for unicast and to add a > > section or an appendix to cover the multicast issues. I have a few > > comments on multicast transfer with multihomed hosts, but I do not see > > multicast as a primary driver for this work. > > > > Yes, your right of course. I really hadn't considered multicast at all > in what I did. If its really simple we could just add it in, otherwise > we might want to split it out. > > > 2. In section 2.3 (High Resilience Multiple Interfaces) there is a > > list of ten requirements for host multihoming where each host has > > multiple interfaces which are functionally equivalent. One additional > > requirement that should be added is for a host originating multicast > > packets to identify the interface that each packet is originated on. > > This is currently assumed by all multicast routing protocols to ensure > > that multicast routers can construct the proper tree. > > I think we need to have interface specific source addresses for unicast use > too, so I don't have a problem with that. > > > > > 3. I think that an explicit goal should be added to the list of section 2.3 > > for unicast host multihoming to support both TCP and UDP transfers. > > Unicast RSVP/Integrated Services operations should also be supported. > > yes, that's certainly an implicit goal, I have no problem with making it explicit. > > > > > > 4. One issue that I did not see covered in section 3 (Some possible solutions) > > were DNS impacts. I am not sure whether any extensions are required to DNS > > itself to cover host multihoming, but it seems possible that hosts may need > > to treat information from a DNS server differently (i.e. duplicate DNS > > responses). > > > I don't know. Any DNS experts care to comment. > > > > > > > 5. There does not appear to be a need for any mechanisms, beyond those of > > RFC 1112, to support host multihoming, multicast transfer. Further work is > > needed to verify this. Section 4 of the internet draft (Selecting the > > output interface) is an important issue for multicast transfer; however, the > > multicast transfer has a different set of considerations than what is covered. > > While there may not be a need for additional mechanisms, consistent operation > > by a group of multihomed hosts using multicast transfer is needed and this > > might be a subject for an informational document. The goals for host > > multihoming's multicast capability should be to ensure that UDP multicast > > transfer is supported along with multicast RSVP/Integrated Services > > operations. > > > > Yes we need to think about the multicast issues. > > > > Concluding remarks: I think that the current ID, with some modifications > > to cover the identified issues, meets its objectives of providing a > > taxonomy for host multihoming and a discussion of the issues. I would like > > to see further work on the Type 3 case (High Resilience Multiple Interfaces). > > Going over section 3 (Possible solutions) the anycast address and EID like > > alternatives appear to meet the need for unicast host multihoming. Given > > that anycast addresses are already being developed within the IPv6 effort > > it would seem that this approach should be looked at first. > > > Yes I think we now need to come down on some hard proposals and see how they fly. > If anyone has any input to this I'm sure I'll hear. Otherwise I'll just make > some choices and wait for people to scream. My preference is for an anycast > type style. I'd rather have the routing be done by the routers rather than have > the source guess which destination address is going to work. > > > One further thing. We may want to think about use "reverse path" information in > determining which interface to transmit on. Of course this doesn't work well if the > routes are asymetric, but it can give some useful information. Is anyone > violently opposed to this? > > > Dave > > > Thanks Dave > > > I look forward to any further reactions. I'll try to get a redraft done in > the next couple of weeks. > > > Mike > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 00:46:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20245; Mon, 20 May 96 00:46:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20239; Mon, 20 May 96 00:46:05 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19963; Mon, 20 May 1996 00:43:02 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA09909; Mon, 20 May 1996 00:43:02 -0700 Received: from shand.reo.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id DAA19320; Mon, 20 May 1996 03:38:06 -0400 (EDT) Received: from localhost by shand.reo.dec.com (5.65/MS-010395) id AA20596; Mon, 20 May 1996 08:37:29 +0100 Message-Id: <9605200737.AA20596@shand.reo.dec.com> To: ipng@sunroof.eng.sun.com Cc: shand@shand.reo.dec.com, roque@di.fc.ul.pt Subject: (IPng 1743) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of "Sun, 19 May 96 17:54:50 BST." <199605191654.RAA05103@oberon> Date: Mon, 20 May 96 08:37:29 +0100 From: (Mike Shand REO2 G/C2 DTN:830-4424) X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro, Perhaps I should never have mentioned EID's, since they carry various historical conotations. I guess there are two cases hidden in here. 1) Cases where the "best" reception interface (I'm not going to use the emotive word "address") changes over time (e.g. Mobile, or multihoming cases where the "primary" home changes, or renumbering). This is the scenario the "Dynamic address Reassignment" is designed to deal with, and it seems to do the job well. 2) Cases where there are a set of "best" interfaces all of which may be usable. The decision about which interface to use for a particular packet is the responsibility of the routing layer. It would not be appropriate to dynamically reassign the address for each packet. What I want to be able to do is use some form of "address" that has anycast semantics, which will allow routing to deliver to the interface which it determines is currently the "best". This may involve path splitting between two or more interfaces. However, if we do this, then there will be a mismatch between the source address used when transmitting packets (which for reasons outlined in the draft, we want to be interface specific), and the destination address used for reception of packets (i.e. the anycast like address). I want to use the dynamic address stuff to enable this to work. But I also like the idea of being able to use the same mechanism (i.e. the dynamic address stuff), when we don't want to use an anycast address, but just have "primary" and "scondary" addresses. > The big issue is that the mapping from host (that can be identified by > a DNS name or some otherwise meaningless number) to "best" address for > communication is dynamic. So having an EID here buys you just the same > thing as having a DNS name since the problems raised on mapping from > DNS name or EIDs to IP addresses are the same: the mapping is static. Not if the "EID" is a routable address i.e. the anycast address. Mike ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 03:08:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20336; Mon, 20 May 96 03:08:30 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20330; Mon, 20 May 96 03:08:17 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26849; Mon, 20 May 1996 03:05:10 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA25717; Mon, 20 May 1996 03:05:09 -0700 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1744) Re: i propose another change to the IPv6 BSD API document To: paul@vix.com (Paul A Vixie) Date: Mon, 20 May 1996 11:10:19 +0100 (BST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9605200006.AA17894@wisdom.home.vix.com> from "Paul A Vixie" at May 19, 96 05:06:02 pm Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > address is "u_char *" rather than "void *". My reason is that I am not > comfortable returning a "length" from inet_pton(), or accepting a "length" > in inet_ntop(), if the thing whose length I'm counting has an opaque type. Will people please stop using things like "u_char" in standards. u_char is _MEANINGLESS_. Its "unsigned char" in ANSI C, unless you want to list all the typedefs in documents all the time. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 04:54:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20371; Mon, 20 May 96 04:54:51 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20365; Mon, 20 May 96 04:54:36 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00941; Mon, 20 May 1996 04:51:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA05729; Mon, 20 May 1996 04:51:34 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with SMTP id EAA25177; Mon, 20 May 1996 04:51:32 -0700 (MST) Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA11782; Mon, 20 May 96 04:51:32 MST; for ipng@sunroof.eng.sun.com Message-Id: <9605201151.AA11782@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Mon, 20 May 1996 04:51:32 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Paul A Vixie , ipng@sunroof.eng.sun.com Subject: (IPng 1745) Re: i propose another change to the IPv6 BSD API document Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of May 19, 5:06pm you write:] > I propose: > > int inet_pton __P((int af, const char *src, u_char *dst)); > char *inet_ntop __P((int af, const u_char *src, int len)); > > This differs from the current draft in that the type of the network-format > address is "u_char *" rather than "void *". My reason is that I am not > comfortable returning a "length" from inet_pton(), or accepting a "length" > in inet_ntop(), if the thing whose length I'm counting has an opaque type. I think the pointers should remain void* and I thought we had agreed that the lengths were size_t, not ints. This is what all the ANSI C mem*() functions use, along with the 4.4BSD b*() functions. The return value from inet_pton() should also be ssize_t, not int. Also, what happened to the 4th argument to inet_ntop(), the buffer pointer (which can be null)? Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 06:07:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20441; Mon, 20 May 96 06:07:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20435; Mon, 20 May 96 06:07:02 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04518; Mon, 20 May 1996 06:03:58 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA16857; Mon, 20 May 1996 06:03:58 -0700 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA20562; Mon, 20 May 1996 15:03:52 +0200 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA23134; Mon, 20 May 1996 15:03:51 +0200 Message-Id: <9605201303.AA23134@dxcoms.cern.ch> Subject: (IPng 1746) Re: Responses to Comments on Multihoming draft To: perk@watson.ibm.com Date: Mon, 20 May 1996 15:03:51 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9605201152.AA26030@hawpub1.watson.ibm.com> from "Charlie Perkins" at May 20, 96 07:52:34 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Scott, Charlie, > > > Good question. Another example of why I am very unclear whether > > anycast addresses are useful and implementable. I accept the rebukes: yes, anycast addresses can be *useful*. I'm still not clear that we know how to implement them - the interactions with ND, DAD, tunnels, and network management have definitely not been tied down yet. Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 09:41:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20564; Mon, 20 May 96 09:41:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20377; Mon, 20 May 96 04:55:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01007; Mon, 20 May 1996 04:52:44 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA05909; Mon, 20 May 1996 04:52:42 -0700 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by igw2.watson.ibm.com (8.7.4/8.7.1) with SMTP id HAA18899; Mon, 20 May 1996 07:52:54 -0400 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/4/8/96) id AA26030; Mon, 20 May 1996 07:52:35 -0400 From: Charlie Perkins Message-Id: <9605201152.AA26030@hawpub1.watson.ibm.com> To: "Brian Carpenter CERN-CN" Cc: ipng@sunroof.eng.sun.com Reply-To: perk@watson.ibm.com Subject: (IPng 1747) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of Mon, 20 May 96 08:44:02 O. <9605200644.AA04460@dxcoms.cern.ch> Date: Mon, 20 May 96 07:52:34 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think that the particular variety of anycast which identifies routers on a subnet is very useful. For mobile nodes that wish to discover a home agent, the predefined anycast address specified in RFC1884 (IPv6 Addressing Architecture) is perfect. >> ........ Do you mean that there is nothing >> to semantically distinguish an anycast address from a unicast address, but >> that we note their existence from the multiple replies. How do we know when >> we are permitted to suppress DAD? > Good question. Another example of why I am very unclear whether > anycast addresses are useful and implementable. For cases where the nodes performing DAD for the anycast address can detect each other's multicast ND packets, I don't think there is a problem. On the one hand, if a node does DAD and it's NOT part of the anycast address group, it should not take the anycast address. On the other hand, if a node does DAD and it IS part of the anycast address group, it won't be too concerned about getting multiple replies -- in fact, initiating DAD is basically a waste, unless something clever is put into place about how anycast nodes can find each other this way. It is important for anycast nodes to respond to DAD for the anycast address so that other hosts won't erroneously try to use the address. Maybe it's worthwhile to specify that anycast nodes MUST be able to detect each other's ND multicasts. Also, anycast addresses seem to require some manual (or at least unusual) configuration; it seems that one cannot create an anycast group using an address which was already "claimed" by an IPv6 host that had already completed its process of validating the address via DAD. Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 12:29:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20750; Mon, 20 May 96 12:29:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20744; Mon, 20 May 96 12:29:20 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01975; Mon, 20 May 1996 12:26:17 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA15737; Mon, 20 May 1996 12:26:04 -0700 Received: from Ronaldo.tba.com.br (200.19.122.113) by srv1inet.tba.com.br (EMWAC SMTPRS 0.80) with SMTP id ; Mon, 20 May 1996 16:28:03 -0300 Received: by Ronaldo.tba.com.br with Microsoft Mail id <01BB4668.F294C600@Ronaldo.tba.com.br>; Mon, 20 May 1996 16:25:24 -0300 Message-Id: <01BB4668.F294C600@Ronaldo.tba.com.br> From: =?iso-8859-1?Q?TBA_INFORM=C1TICA?= To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 1748) Courses Date: Mon, 20 May 1996 16:25:23 -0300 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please, Where can I find informations on courses about IPng? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 13:11:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20783; Mon, 20 May 96 13:11:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20777; Mon, 20 May 96 13:10:52 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08781; Mon, 20 May 1996 13:07:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA27648; Mon, 20 May 1996 13:07:45 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0406; Mon, 20 May 96 16:07:33 EDT Received: by RTP (XAGENTA 4.0) id 4178; Mon, 20 May 1996 16:07:37 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA18431; Mon, 20 May 1996 16:07:26 -0400 Message-Id: <9605202007.AA18431@cichlid.raleigh.ibm.com> To: "Brian Carpenter CERN-CN" Cc: perk@watson.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 1749) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of "Mon, 20 May 1996 15:03:51 +0200." <9605201303.AA23134@dxcoms.cern.ch> Date: Mon, 20 May 1996 16:07:25 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Brian Carpenter CERN-CN" writes: >I accept the rebukes: yes, anycast addresses can be *useful*. >I'm still not clear that we know how to implement them - >the interactions with ND, DAD, tunnels, and network management >have definitely not been tied down yet. As far as I know, there are no loose ends wrt DAD (and ND in general) and anycast addresses (knock on wood). Although anycast addresses are syntactically equivalent to unicast addresses, they are not semantically equivalent, and an anycast address assigned to an interface is treated differently by that interface. Namely: 1) Addrconf explicitly says not to perform DAD on anycast addresses. 2) NS messages received for an anycast address assigned to an interface are processed differently from those for unicast addresses. NA messages are delayed for a short random time, and the override flag is set to 0 (in contrast to unicast advertisements). So, special code is needed to handle anycasts correctly. That's made quite clear in the ND spec. If anyone is aware of any loose ends with ND and anycast addresses, please post the details. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 13:26:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20815; Mon, 20 May 96 13:26:26 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20809; Mon, 20 May 96 13:26:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11980; Mon, 20 May 1996 13:23:04 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA02655; Mon, 20 May 1996 13:23:03 -0700 Received: by gw.home.vix.com id NAA19893; Mon, 20 May 1996 13:22:59 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA20837; Mon, 20 May 1996 13:22:58 -0700 Message-Id: <9605202022.AA20837@wisdom.home.vix.com> To: Richard Stevens Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1750) Re: i propose another change to the IPv6 BSD API document In-Reply-To: Your message of "Mon, 20 May 1996 04:51:32 PDT." <9605201151.AA11782@gemini.tuc.noao.edu> Date: Mon, 20 May 1996 13:22:58 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think the pointers should remain void* and I thought we had agreed that > the lengths were size_t, not ints. This is what all the ANSI C mem*() > functions use, along with the 4.4BSD b*() functions. The return value > from inet_pton() should also be ssize_t, not int. OK, I'll do all of that. > Also, what happened to the 4th argument to inet_ntop(), the buffer pointer > (which can be null)? I forgot. I'll put it in. Do we need a bufsize parameter as well, to avoid gets() sickness? Speaking of that, does inet_pton() need a buflen parameter? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 13:44:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20835; Mon, 20 May 96 13:44:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20829; Mon, 20 May 96 13:44:15 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15148; Mon, 20 May 1996 13:41:11 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA08564; Mon, 20 May 1996 13:41:11 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with SMTP id NAA11544; Mon, 20 May 1996 13:41:05 -0700 (MST) Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA16461; Mon, 20 May 96 13:40:49 MST; for ipng@sunroof.eng.sun.com Message-Id: <9605202040.AA16461@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Mon, 20 May 1996 13:40:49 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Paul A Vixie Subject: (IPng 1751) Re: i propose another change to the IPv6 BSD API document Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of May 20, 1:22pm you write:] > > Do we need a bufsize parameter as well, to avoid > gets() sickness? Speaking of that, does inet_pton() need a buflen parameter? I've wondered about that all along. Has this been discussed before? Both the host and service arguments to getnameinfo() have an associated length. Isn't it "correct" to always pass a length when you take a pointer argument to fill in? Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 14:56:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20936; Mon, 20 May 96 14:56:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20930; Mon, 20 May 96 14:56:38 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28423; Mon, 20 May 1996 14:53:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA01681; Mon, 20 May 1996 14:53:30 -0700 Received: by gw.home.vix.com id OAA26005; Mon, 20 May 1996 14:53:28 -0700 Date: Mon, 20 May 1996 14:53:28 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 1752) Re: i propose another change to the IPv6 BSD API document Organization: Vixie Enterprises Message-Id: References: <9605202040.AA16461@gemini.tuc.noao.edu> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: rstevens@noao.edu's message of 20 May 1996 13:54:15 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Do we need a bufsize parameter as well, to avoid >> gets() sickness? Speaking of that, does inet_pton() need a buflen param? > >I've wondered about that all along. Has this been discussed before? >Both the host and service arguments to getnameinfo() have an associated >length. Isn't it "correct" to always pass a length when you take a >pointer argument to fill in? ssize_t inet_pton __P((int af, const char *src, void *dst)); char *inet_ntop __P((int af, const void *src, size_t len, char *dst)); As much as it pains me to do so, I think we ought to remove the fourth parameter from inet_ntop() and just return a static. Folks can wrap the call in a strcpy() or strdup() if they want to copy the result somewhere. Our alternative is to have a function with so many arguments that nobody will want to call it. At least with the static, the library knows the size without being told. inet_pton() should have a fourth argument giving the size of the dst. ssize_t inet_pton __P((int af, const char *src, void *dst, int size)); char *inet_ntop __P((int af, const void *src, size_t len, char *dst, int size)); I would actually rather do away with the idea of variable length addresses: int inet_pton __P((int af, const char *src, void *dst, int size)); char *inet_ntop __P((int af, const void *src, char *dst, int size)); But I expect that this has been discussed before my time, and turned down? Listen, folks, BIND needs to ship something, and it ain't changing after that. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 14:57:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20943; Mon, 20 May 96 14:57:10 PDT Received: from pacific.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA20920; Mon, 20 May 96 14:52:31 PDT Received: from lucknow.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA04956; Mon, 20 May 1996 14:49:14 -0700 Received: by lucknow.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA05139; Mon, 20 May 1996 14:49:01 -0700 Date: Mon, 20 May 1996 14:49:01 -0700 From: mukesh@caribe (Mukesh Kacker) Message-Id: <199605202149.OAA05139@lucknow.eng.sun.com> To: paul@vix.com, ipng@sunroof.eng.sun.com, rstevens@noao.edu Subject: (IPng 1753) Re: i propose another change to the IPv6 BSD API document Cc: mukesh@caribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: UJG6PGe4WUf4KkeyvxF0pw== Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > int inet_pton __P((int af, const char *src, u_char *dst)); > > char *inet_ntop __P((int af, const u_char *src, int len)); > > > > This differs from the current draft in that the type of the network-format > > address is "u_char *" rather than "void *". My reason is that I am not > > comfortable returning a "length" from inet_pton(), or accepting a "length" > > in inet_ntop(), if the thing whose length I'm counting has an opaque type. > > I think the pointers should remain void* and I thought we had agreed that > the lengths were size_t, not ints. This is what all the ANSI C mem*() > functions use, along with the 4.4BSD b*() functions. The return value > from inet_pton() should also be ssize_t, not int. > Hello, I have not followed the issues related to these functions recently but I would STRONGLY ADVISE AGAINST the use of size_t and ssize_t (except in interfaces where it is absolutely necessary) and inet_pton() and inet_top() do not seem to be such interfaces. I would recommend their removal from other interfaces in the IPv6 Socket API though I am sure the suggestion here was to be consistent. This issue has been a topic of recent discussions in forums dealing with cleaning up interfaces for 64 bit transition in the industry. Here are the arguments against size_t. size_t is defined to have a range to be represent the largest size opaque buffer (SSIZE_MAX). ssize_t is defined to be atlesast in the range -1 to SSIZE_MAX. These types are useful with interfaces which do benefit from ability to address large buffers and memory spaces (in memory databases etc). There is a need for them in interfaces like seek(), read(), write()[ mem*() and b*() copy routines also need to deal with such objects ]. They are not useful types to use in interfaces like inet_ntop() and inet_pton() and other Socket interfaces where the namespace does not benefit from ability to address the largest size object on the machine. The range needed to be represented by the namespaces where int is used above is not likely to grow beyond the value representable current sizeof (int) bytes on most platforms (i.e. 2^32 ?). The unintended consequence of indiscriminate use of size_t and ssize_t that can happen is the binary interface (ABI) for these calls will change whenever size_t changes [ e.g when the industry moves from 32-bit OS to 64-bit OS ]. These interfaces do not benefit in anyway from that transition and their binary interface should be immune from the changes that accompany such transitions. The binary interface should not use types which change in length when it does not benefit from it and it can be avoided. Not doing that doubles the number of calls in OS ABIs and can introduce binary compatibility issues in applications that least expect it. [ Unfortunately, this mistake has been made in the "standardized" version the BSD SOcket interface by some formal standard bodies in representing address lengths and option lengths etc. was changed from int to size_t. Most of us regard that as a mistake and are trying to correct that too. (That's not just people at Sun...I have heard that in discussions from other major system vendors engineers also. There is no need for Socket APIs binary interfaces such as bind() need to change when 32 bit to 64 bit transitions happen in operating system interfaces and size_t gets bigger. (I don't think there are any networking technolgies on the horizon whose address length will exceed 2^32. :-)). Why that happened in the standards world and whether and how that will get fixed depends on how the voting winds blow :-) and out of bounds of this discussion. ] But it would be good to learn from it and not perpetuate that mistake in any more interfaces especially new ones being proposed. I would suggest keeping the return value an int and maybe unsigned int for the length. But please stay away from size_t/ssize_t in interfaces which do not have objects that benefit from largest representable buffer size in a system address space. In the context of Socket interface. only read(), write(), send/sendmsg(), recv/recvmsg() etc. should be using size_t/ssize_t and not other interfaces. -Mukesh Kacker Internet Engineering SunSoft Inc. mukesh.kacker@eng.sun.com 415-786-5156. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 16:38:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21068; Mon, 20 May 96 16:38:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21062; Mon, 20 May 96 16:37:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16739; Mon, 20 May 1996 16:34:56 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA29937; Mon, 20 May 1996 16:34:55 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with SMTP id QAA17445; Mon, 20 May 1996 16:34:52 -0700 (MST) Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA18104; Mon, 20 May 96 16:34:46 MST; for ipng@sunroof.eng.sun.com Message-Id: <9605202334.AA18104@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Mon, 20 May 1996 16:34:45 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Mukesh.Kacker@Eng (Mukesh Kacker), paul@vix.com, ipng@sunroof.eng.sun.com Subject: (IPng 1754) Re: i propose another change to the IPv6 BSD API document Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mukesh, Your email surprises me. I've never seen a comment of this form in the past 2 years on the Posix.1g mailing list. (My guess is you're presently looking at some future 64-bit version of Solaris and are now having to deal with the binary compatability issues? :-) ) OK, back to the standards. ANSI C says that size_t is "the unsigned integral type of the result of the sizeof operator". I think that makes it completely appropriate for all of the socket address structure length fields in the sockets API. When I code the third argument to bind(), say, as "sizeof(struct sockaddr_in)" that sure looks like a size_t to me. Looking in the Rationale of the ANSI C standard, they note that "size_t is also a convienent type for array sizes, and so is used in several library functions". For example, fread(), calloc(). The Rationale also notes that "size_t is the appropriate type for an object size and for an array bound". Looking at the various functions that use size_t for an array size in /usr/include/*.h, there are a lot: getcwd(), strftime(), and ttyname_r(), for example. Again, I think the "equivalence" of these array bounds with the "sizeof" the array is why these were defined to use size_t. So I think size_t is appropriate for what the IPv6 sockets API is using it for: the length in bytes of the address being converted by inet_ntop(). I also think it's appropriate for what Posix.1g is using it for. ssize_t is a Posix invention, not from ANSI C. It is basically a counter (e.g., a size_t) that can also be an error indication (e.g., -1). Posix.1 uses this for the return value from read() and write(), which makes sense. I think using it as the return value from inet_pton(), where the return is a count of the number of bytes or -1, again makes sense. If I understand your objections, you are saying that when one moves from a 32-bit architecture to a 64-bit architecture, int has to stay at 32 bits, but long moves to 64 bits, and then size_t and ssize_t will both be 64 bits (to allow huge reads and writes and huge memcpy's). But you have to provide binary compatability for the older 32-bit applications? So you want all these integer values that need not be 64 bits to be ints and not size_t or ssize_t? It seems like your complaint is with ANSI for not defining two size_t's (one for "huge" values and one for "smaller" values such as array bounds) and the same for Posix with ssize_t? How are other vendors with 64-bit architectures dealing with these problems? Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 16:50:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21089; Mon, 20 May 96 16:50:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21083; Mon, 20 May 96 16:49:58 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18591; Mon, 20 May 1996 16:46:55 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA03322; Mon, 20 May 1996 16:46:52 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with SMTP id QAA17734; Mon, 20 May 1996 16:46:49 -0700 (MST) Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA18250; Mon, 20 May 96 16:46:49 MST; for ipng@sunroof.eng.sun.com Message-Id: <9605202346.AA18250@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Mon, 20 May 1996 16:46:48 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: paul@vix.com (Paul A Vixie), ipng@sunroof.eng.sun.com Subject: (IPng 1755) Re: i propose another change to the IPv6 BSD API document Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of May 20, 2:53pm you write:] > > ssize_t inet_pton __P((int af, const char *src, void *dst)); > char *inet_ntop __P((int af, const void *src, size_t len, char *dst)); > > As much as it pains me to do so, I think we ought to remove the fourth > parameter from inet_ntop() and just return a static. Folks can wrap the > call in a strcpy() or strdup() if they want to copy the result somewhere. Isn't it too late upon return to save it (if it's already been written over)? > Our alternative is to have a function with so many arguments that nobody > will want to call it. Kind of like gethostbyname_r() ? :-) > inet_pton() should have a fourth argument giving the size of the dst. > > ssize_t inet_pton __P((int af, const char *src, void *dst, int size)); > char *inet_ntop __P((int af, const void *src, size_t len, char *dst, > int size)); Yes. > I would actually rather do away with the idea of variable length addresses: > > int inet_pton __P((int af, const char *src, void *dst, int size)); > char *inet_ntop __P((int af, const void *src, char *dst, int size)); > > But I expect that this has been discussed before my time, and turned down? I brought this up a few weeks back and some people stated that you need the size for some other protocol suites. But since we're using the inet_ prefix, I'd vote to get rid of the size too. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 18:01:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21147; Mon, 20 May 96 18:01:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21141; Mon, 20 May 96 18:01:00 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28651; Mon, 20 May 1996 17:57:56 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA19154; Mon, 20 May 1996 17:57:55 -0700 From: bmanning@ISI.EDU Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 20 May 1996 17:57:55 -0700 Posted-Date: Mon, 20 May 1996 17:57:40 -0700 (PDT) Message-Id: <199605210057.AA17697@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Mon, 20 May 1996 17:57:40 -0700 Subject: (IPng 1756) Re: Courses To: Ronaldo@tba.com.br (=?iso-8859-1?Q?TBA_INFORM=C1TICA?=) Date: Mon, 20 May 1996 17:57:40 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <01BB4668.F294C600@Ronaldo.tba.com.br> from "=?iso-8859-1?Q?TBA_INFORM=C1TICA?=" at May 20, 96 04:25:23 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Please, > Where can I find informations on courses about IPng? > Some say, "Stay the Course" Others, "Steer Clear" As always, avoid interference with the lane markers. --bill Key fingerprint = FA 2A 63 DA 63 2E CB DB 26 2F 7A 12 B1 07 7D 68 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 18:09:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21172; Mon, 20 May 96 18:09:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21166; Mon, 20 May 96 18:09:20 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA29854; Mon, 20 May 1996 18:06:16 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA20793; Mon, 20 May 1996 18:06:14 -0700 Received: by gw.home.vix.com id SAA07374; Mon, 20 May 1996 18:06:13 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA21203; Mon, 20 May 1996 18:06:13 -0700 Message-Id: <9605210106.AA21203@wisdom.home.vix.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1757) Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... Date: Mon, 20 May 1996 18:06:12 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have different PTR locations. We kinda need to know whether both are under IP6.INT or whether both are under IN-ADDR.ARPA or whether they're split in some way. My assumption is that the following three calls will all return the same result, though in different address formats befitting the address families: struct hostent *native_hp, *mapped_hp, *tunnel_hp; char native[INADDRSZ], mapped[IN6ADDRSZ], tunnel[IN6ADDRSZ]; (void) inet_pton(AF_INET, "192.5.5.1", native); (void) inet_pton(AF_INET6, "::192.5.5.1", tunnel); (void) inet_pton(AF_INET6, "::FFFF:192.5.5.1", mapped); native_hp = gethostbyaddr(native, INADDRSZ, AF_INET); mapped_hp = gethostbyaddr(mapped, IN6ADDRSZ, AF_INET6); tunnel_hp = gethostbyaddr(tunnel, IN6ADDRSZ, AF_INET6); All three will search for 1.5.5.192.IN-ADDR.ARPA's PTR RR. None of them use or fall back to IP6.INT. Further, if the RES_USE_INET6 option is set in the resolver, the hostent returned by the first call will be in ::FFFF:192.5.5.1 format (16 bytes). If I'm headed in the wrong direction with this stuff, stop me now! ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 21:05:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21262; Mon, 20 May 96 21:05:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21256; Mon, 20 May 96 21:05:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13889; Mon, 20 May 1996 21:02:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA15802; Mon, 20 May 1996 21:02:31 -0700 Received: by gw.home.vix.com id VAA17437; Mon, 20 May 1996 21:02:30 -0700 Date: Mon, 20 May 1996 21:02:30 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 1758) Re: i propose another change to the IPv6 BSD API document Organization: Vixie Enterprises Message-Id: References: <9605202346.AA18250@gemini.tuc.noao.edu> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: rstevens@noao.edu's message of 20 May 1996 16:55:55 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> As much as it pains me to do so, I think we ought to remove the fourth >> parameter from inet_ntop() and just return a static. Folks can wrap the >> call in a strcpy() or strdup() if they want to copy the result somewhere. > >Isn't it too late upon return to save it (if it's already been written over)? In the sense of thread safety, yes. In the sense of multiple calls as part of the same eval, no. Functions which accept a string pointer and return that pointer, like strcpy() and strcat(), can be used in much the same way as nested assignment expressions. Therefore: char name1[MAXHOSTNAMELEN], name2[MAXHOSTNAMELEN]; printf("Address 1 is [%s], but address 2 is [%s]\n", strcpy(name1, inet_ntop(af1, addr1, len1, NULL)), strcpy(name2, inet_ntop(af2, addr1, len1, NULL))); ...is perfectly safe, since the strcpy()'s into name1 and name2 will happen in some order which we don't know, but definitely to be interspersed with the two calls to inet_ntop(). Therefore inet_ntop()'s internal "static char[]" will not be reused until after the previous call's result has been strcpy()'d. This doesn't work with threads. It absolutely fails with threads, since some other thread can execute this or some other code which calls inet_ntop() in an overlap situation, thus sharing/stomping the internal "static char[]". I was not sure whether the optional fourth argument to inet_ntop() was meant to solve the threads problem, or just the old inet_ntoa() problem where something like: printf("Address 1 is [%s], but address 2 is [%s]\n", inet_ntoa(addr1), inet_ntoa(addr2)); ...would print the same address twice (though there was never any guarantee of which one it would be, since C doesn't nec'ily eval function arguments in a left to right fashion). Note that strdup() is also available for those who like overhead: char *name1, *name2; printf("Address 1 is [%s], but address 2 is [%s]\n", (name1 = strdup(inet_ntop(af1, addr1, len1, NULL))), (name2 = strdup(inet_ntop(af2, addr2, len2, NULL)))); free(name1); free(name2); I think the threads argument is compelling enough that I'm going to give my second strong (that is to say, pig headed and self assured) bit of design input (my first was about the names of these functions). I think we should just do away with the internal "static char[]" and have inet_ntop()'s fourth argument be nonoptional, followed by a fifth argument of type size_t giving the size of the array. Thus, ssize_t inet_pton __P((int af, const char *src, void *dst, int size)); char *inet_ntop __P((int af, const void *src, size_t len, char *dst, int size)); These functions will have an assymetry that annoys me a little, though I can and expect to "just live with it". The assymetry is caused by the extraneous "len" parameter on inet_ntop(), required only because someone here present wants to be able to use these functions on address families with variable length addresses. I have always thought and still think that these are just useful for "inet" addresses, and after watching the debate over SIPP I don't think there's anybody anywhere who thinks IPv7 or some other future standard will ever have variable length addresses. Therefore my actual preference is still for: int inet_pton __P((int af, const char *src, void *dst, int size)); char *inet_ntop __P((int af, const void *src, char *dst, int size)); ...which returns a simple zero/nonzero from inet_pton(), and which does not have a "len" parameter on inet_ntop(). Rich agreed with me, stating: >I brought this up a few weeks back and some people stated that you need >the size for some other protocol suites. But since we're using the inet_ >prefix, I'd vote to get rid of the size too. I believe that I shall simply define them this way and wait for somebody to yell at me. (Some of you will recognize my IETF modus operendi in action.) Btw, I'd like to share a dirty little secret with all of you: the reason I don't care much whether these functions handle the non-Internet protocols or not is because I consider that a much tougher nut to crack; we can't solve it without integrating naming and address presentation and sockaddr's, and the inability to do it well keeps me from wanting to bolt half assed junk onto something which could be clean and simple if it "did one thing well." What _I_ use when I need to write a protocol independent application is a library that implements the following API. No man pages, but you can have it if you want it, free of charge and with the usual ISC copyright: /*----------------------- sock*.c -----------------------*/ /* recognized now: * ip/tcp/DOTTEDQUAD/PORTNUM * ip/udp/DOTTEDQUAD/PORTNUM * futures: * bsd/ABSPATHNAME * dna/AREA.NUMBER/OBJECTNUM * sna/??? * apple/??? * xns/??? * ipx/??? */ extern const char _sock_IP[], _sock_IP_TCP[], _sock_IP_UDP[], _sock_IP_Wildcard[]; struct sock { int type; struct sockaddr addr; }; #define SOCK_F_RSVD 0x0001 /* XXX - IP specific */ #define IN_WILD_ADDR(sin) ((sin).sin_addr.s_addr == INADDR_ANY) #define IN_WILD_PORT(sin) (ntohs((sin).sin_port) == 0) #define sock_af(sp) ((sp)->addr.sa_family) #define sock_len(sp) ((sp)->addr.sa_len) #define sock_ntoa __vix_sock_ntoa char *sock_ntoa __P((const struct sock *src)); #define sock_ntox __vix_sock_ntox char *sock_ntox __P((const struct sock *src)); #define sock_aton __vix_sock_aton int sock_aton __P((const char *src, struct sock *dst)); #define sock_same __vix_sock_same int sock_same __P((const struct sock *s1, const struct sock *s2)); #define sock_alen __vix_sock_alen int sock_alen __P((const struct sockaddr *sa)); #define sock_isdgram __vix_sock_isdgram int sock_isdgram __P((const struct sock *s)); #define sock_isstream __vix_sock_isstream int sock_isstream __P((const struct sock *s)); #define sock_fdtype __vix_sock_fdtype int sock_fdtype __P((int fd)); #define sock_listening __vix_sock_listening int sock_listening __P((int fd)); #define sock_sock __vix_sock_sock struct sock sock_sock __P((int type, const struct sockaddr *sa)); #define sock_name __vix_sock_name int sock_name __P((int src, struct sock *dst)); #define sock_peer __vix_sock_peer int sock_peer __P((int src, struct sock *dst)); #define sock_bind __vix_sock_bind int sock_bind __P((int s, struct sock *a, int f)); -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 22:42:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21350; Mon, 20 May 96 22:42:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21344; Mon, 20 May 96 22:41:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21137; Mon, 20 May 1996 22:38:46 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA27079; Mon, 20 May 1996 22:38:46 -0700 Received: by gw.home.vix.com id WAA22430; Mon, 20 May 1996 22:38:44 -0700 Date: Mon, 20 May 1996 22:38:44 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 1759) Re: i propose another change to the IPv6 BSD API document Organization: Vixie Enterprises Message-Id: References: <9605202346.AA18250@gemini.tuc.noao.edu> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: vixie@vix.com's message of 21 May 1996 04:02:28 GMT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What I'm currently working with, just to give those of you who don't read my longer and windier articles a chance to catch up, is: int inet_pton __P((int af, const char *src, void *dst, size_t size)); const char *inet_ntop __P((int af, const void *src, char *dst, size_t size)); I'm using size_t for the expressed size of dst, since as Rich Stevens pointed out, this is the type of a sizeof expression and that's what will most often be used here. I'm returning an int from inet_pton() because it's just -1, 0, or 1. I'm returning a "const char *" from inet_ntop() even though it will always just be NULL or dst, and dst is not a const; it seems prudent that one ought not to write upon the return value of inet_ntop(), no matter whether one knows where that value started its life. These functions differ from their classic IPv4 counterparts in several ways. Most notably, they can return a wider range of values. inet_aton() cannot return -1, and inet_ntoa() cannot return NULL, so the following was safe: if (inet_aton(foo, &bar)) printf("%s\n", inet_ntoa(bar)); It is _not_ quite as safe to do this with the inet_pton() and inet_ntop() functions, since the first can return a nonzero value which is not success (i.e., -1), and the second can return a value which is not suitable for %s, that being NULL. I intend to enumerate the possible errors in the man pages for these functions, such that any programmer who can externally ensure that the conditions won't be encountered, can safely depend on error free result values. It is quite important that all non-BIND implementations of these functions (if such there be, given that BIND's are freely reusable without fee or encumbrance) have the same set of error conditions so that safe callers of one will be safe callers of another. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 20 23:54:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21384; Mon, 20 May 96 23:54:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21378; Mon, 20 May 96 23:53:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24696; Mon, 20 May 1996 23:50:56 -0700 Received: by mercury.Sun.COM (Sun.COM) id XAA04281; Mon, 20 May 1996 23:50:14 -0700 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA18925; Tue, 21 May 1996 08:49:46 +0200 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA07013; Tue, 21 May 1996 08:49:35 +0200 Message-Id: <9605210649.AA07013@dxcoms.cern.ch> Subject: (IPng 1760) Re: Responses to Comments on Multihoming draft To: narten@VNET.IBM.COM (Thomas Narten) Date: Tue, 21 May 1996 08:49:35 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: perk@watson.ibm.com, ipng@sunroof.eng.sun.com In-Reply-To: <9605202007.AA18431@cichlid.raleigh.ibm.com> from "Thomas Narten" at May 20, 96 04:07:25 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As far as I know, there is no way to know that something is an anycast address by looking at it, since it is syntactically identical to a unicast address. Therefore, how does ND (or addrconf) *know* it is dealing with an anycast address? Clearly, this cannot be answered "by configuration", since the whole point of ND (or addrconf) is to avoid the need for configuration. The issue for network management is the same I think. For tunnels, it is the whole question of how to handle tunnels with anycast exits, especially when the tunnel needs to fragment packets. Brian >--------- Text sent by Thomas Narten follows: > > "Brian Carpenter CERN-CN" writes: > > >I accept the rebukes: yes, anycast addresses can be *useful*. > >I'm still not clear that we know how to implement them - > >the interactions with ND, DAD, tunnels, and network management > >have definitely not been tied down yet. > > As far as I know, there are no loose ends wrt DAD (and ND in general) > and anycast addresses (knock on wood). Although anycast addresses are > syntactically equivalent to unicast addresses, they are not > semantically equivalent, and an anycast address assigned to an > interface is treated differently by that interface. Namely: > > 1) Addrconf explicitly says not to perform DAD on anycast addresses. > > 2) NS messages received for an anycast address assigned to an > interface are processed differently from those for unicast addresses. > NA messages are delayed for a short random time, and the override flag > is set to 0 (in contrast to unicast advertisements). So, special code > is needed to handle anycasts correctly. That's made quite clear in the > ND spec. > > If anyone is aware of any loose ends with ND and anycast addresses, > please post the details. > > Thomas > ------------------------------------------------------------------------------ > IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng > IPng Home Page: http://playground.sun.com/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 03:44:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21576; Tue, 21 May 96 03:44:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21570; Tue, 21 May 96 03:44:01 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07163; Tue, 21 May 1996 03:40:56 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA02207; Tue, 21 May 1996 03:40:56 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id MAA16496; Tue, 21 May 1996 12:40:49 +0200 (MET DST) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id MAA23669; Tue, 21 May 1996 12:40:47 +0200 Message-Id: <199605211040.MAA23669@givry.inria.fr> From: Francis Dupont To: Paul A Vixie Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1761) Re: The IPv6 BSD API met RFC 1884 today, and BIND has two more questions In-Reply-To: Your message of Sun, 19 May 1996 16:56:02 PDT. <9605192356.AA17993@wisdom.home.vix.com> Date: Tue, 21 May 1996 12:40:45 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: inet_ntop() needs a heuristic for formatting encapsulated IPv4 addresses. right now i'm choosing to output ::13.1.68.3 as ::13.1.68.3, but ::FFFF:129.144.52.38 is output as ::ffff:8190:3426. that is, if the first 12 octets are zeros, I print the last four octets as a dotted quad. otherwise i print the whole thing as 16-bit words. => it is not necessary (ie no MUST) to format encapsulated IPv4 addresses in a special way but if you'd like to do it I believe it is more natural for IPv4-mapped addresses (which are in fact IPv4 addresses) then for IPv4-compatible addresses even it is more easy for them (but there is a function which recognizes IPv4-mapped addresses)... are there in fact addressing schemes for which it would be useful to print the last four octets as an IPv4 dotted quad, but for which the top 12 octets are nonzero in some way? if so, i will consider adding an external table to recognize these. i'd hate to have somebody be stuck with 16-bit words even though they are speaking IPv4 and "thinking in" IPv4. => humans are supposed to use names and it is more true with IPv6... as long as i've got your attention, i've been thinking about address format autoselection in gethostby*(). => I believe it is a bad idea: this should be by another function (like the hostname2addr old proposal) or at an higher level. the question is, given all of that, ought i also return a "::dot.ted.qu.ad" from gethostbyaddr() (that's addr, not name, plz notice) even if handed something whose addrtype is AF_INET on the "input side" ? => it is not necessary to break current codes. All these things have been previously discussed in the mailing lists... The hostname2addr/addr2hostname proposal works, is already used and has only two issues: - how to implement multithread support/reentrancy - is a higher level function needed (the answer is in the last draft but hostname2addr/addr2hostname functions have been removed which is an error because we need them too) Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 03:52:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21588; Tue, 21 May 96 03:52:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21582; Tue, 21 May 96 03:51:58 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AB07492; Tue, 21 May 1996 03:48:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA03271; Tue, 21 May 1996 03:48:53 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id MAA16583; Tue, 21 May 1996 12:48:51 +0200 (MET DST) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id MAA23740; Tue, 21 May 1996 12:48:50 +0200 Message-Id: <199605211048.MAA23740@givry.inria.fr> From: Francis Dupont To: =?iso-8859-1?Q?TBA_INFORM=C1TICA?= Cc: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 1762) Re: Courses In-Reply-To: Your message of Mon, 20 May 1996 16:25:23 -0300. <01BB4668.F294C600@Ronaldo.tba.com.br> Date: Tue, 21 May 1996 12:48:47 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Where can I find informations on courses about IPng? => I know only a lecture by Rich Stevens. I have a private(*) copy of the USENIX tutorial notes... Francis.Dupont@inria.fr (*) PS: Rich Stevens is self-employed and gets his money with his tutorials and books then I may not redistribute his tutorial notes... ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 03:55:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21600; Tue, 21 May 96 03:55:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21594; Tue, 21 May 96 03:55:38 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07706; Tue, 21 May 1996 03:52:33 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA03769; Tue, 21 May 1996 03:52:33 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id MAA16610; Tue, 21 May 1996 12:52:31 +0200 (MET DST) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id MAA23751; Tue, 21 May 1996 12:52:30 +0200 Message-Id: <199605211052.MAA23751@givry.inria.fr> From: Francis Dupont To: Paul A Vixie Cc: Richard Stevens , ipng@sunroof.eng.sun.com Subject: (IPng 1763) Re: i propose another change to the IPv6 BSD API document In-Reply-To: Your message of Mon, 20 May 1996 13:22:58 PDT. <9605202022.AA20837@wisdom.home.vix.com> Date: Tue, 21 May 1996 12:52:26 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I think the pointers should remain void* and I thought we had agreed that > the lengths were size_t, not ints. This is what all the ANSI C mem*() > functions use, along with the 4.4BSD b*() functions. The return value > from inet_pton() should also be ssize_t, not int. OK, I'll do all of that. => we need a ssize_t because inet_pton should be usable with variable length addresses (like OSI addresses). Do we need a bufsize parameter as well, to avoid gets() sickness? Speaking of that, does inet_pton() need a buflen parameter? => the maximum lengths are well known constants (they are in the API draft). Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 04:11:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21616; Tue, 21 May 96 04:11:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21607; Tue, 21 May 96 04:10:51 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08432; Tue, 21 May 1996 04:07:47 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA05737; Tue, 21 May 1996 04:07:46 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id NAA16779; Tue, 21 May 1996 13:07:45 +0200 (MET DST) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id NAA23816; Tue, 21 May 1996 13:07:44 +0200 Message-Id: <199605211107.NAA23816@givry.inria.fr> From: Francis Dupont To: paul@vix.com (Paul A Vixie) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1764) Re: i propose another change to the IPv6 BSD API document In-Reply-To: Your message of Mon, 20 May 1996 14:53:28 PDT. Date: Tue, 21 May 1996 13:07:30 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >I've wondered about that all along. Has this been discussed before? >Both the host and service arguments to getnameinfo() have an associated >length. Isn't it "correct" to always pass a length when you take a >pointer argument to fill in? ssize_t inet_pton __P((int af, const char *src, void *dst)); char *inet_ntop __P((int af, const void *src, size_t len, char *dst)); As much as it pains me to do so, I think we ought to remove the fourth parameter from inet_ntop() and just return a static. => no, the fourth argument is very useful in a multithreaded environment. Until C will get a garbage collector to give a buffer with a well-known maximum length (it is the case here) is a nice idea! inet_pton() should have a fourth argument giving the size of the dst. => it is not necessary because the maximum size is well known (it is a constant of the address family too). But I expect that this has been discussed before my time, and turned down? => it is the case of course... Listen, folks, BIND needs to ship something, and it ain't changing after that. => the ascii2addr/addr2ascii or inet_pton/ntop proposal of one of the last API drafts works and is enough for a minimal support of AAAA RRs in BIND. I am strongly in favor to get this minimal support NOW (ie more than one full year after the first implementation) and to talk about other issues like IPv6 support in the resolver (useful only for systems with IPv6) after. Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 04:14:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21633; Tue, 21 May 96 04:14:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21627; Tue, 21 May 96 04:14:18 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08598; Tue, 21 May 1996 04:11:13 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA06485; Tue, 21 May 1996 04:11:13 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0881; Tue, 21 May 96 07:11:03 EDT Received: by RTP (XAGENTA 4.0) id 4247; Tue, 21 May 1996 07:11:00 -0400 Received: from rsalh1p81.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA15004; Tue, 21 May 1996 07:10:52 -0400 Received: from hygro.raleigh.ibm.com (narten@loopback [127.0.0.1]) by hygro.raleigh.ibm.com (8.6.12/8.6.9) with ESMTP id HAA00190; Tue, 21 May 1996 07:06:36 -0400 Message-Id: <199605211106.HAA00190@hygro.raleigh.ibm.com> To: "Brian Carpenter CERN-CN" Cc: perk@watson.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 1765) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of "Tue, 21 May 1996 08:49:35 +0200." <9605210649.AA07013@dxcoms.cern.ch> Date: Tue, 21 May 1996 07:06:36 -0400 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >As far as I know, there is no way to know that something is >an anycast address by looking at it, since it is syntactically >identical to a unicast address. Therefore, how does ND (or addrconf) >*know* it is dealing with an anycast address? >From ND's perspective, the only nodes that process anycast addresses differently from unicast addresses are those that have assigned it to an interface. Of course, such nodes will need to specially configure the anycast address, but I don't see that as a particular problem. The nodes that don't realize an address is anycast don't do anything special (again from ND's perspective). Where trouble brews is with nodes that use an anycast address as if it were an unicast address at a higher level (above ND), e.g., opening a TCP connection to an anycast address. But that is a different issue. >The issue for network management is the same I think. For tunnels, >it is the whole question of how to handle tunnels with anycast exits, >especially when the tunnel needs to fragment packets. No disagreement here. I'm just asserting that ND shouldn't be listed as one of the problem areas. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 04:28:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21681; Tue, 21 May 96 04:28:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21675; Tue, 21 May 96 04:28:13 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09349; Tue, 21 May 1996 04:25:08 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA09222; Tue, 21 May 1996 04:25:08 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id NAA17003; Tue, 21 May 1996 13:25:06 +0200 (MET DST) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id NAA23858; Tue, 21 May 1996 13:25:05 +0200 Message-Id: <199605211125.NAA23858@givry.inria.fr> From: Francis Dupont To: Paul A Vixie Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1766) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of Mon, 20 May 1996 18:06:12 PDT. <9605210106.AA21203@wisdom.home.vix.com> Date: Tue, 21 May 1996 13:25:02 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have different PTR locations. We kinda need to know whether both are under IP6.INT or whether both are under IN-ADDR.ARPA or whether they're split in some way. => ::FFFF:I.P.V.4 is a real IPv4 address then the PTR is obviously 4.V.P.I.in-addr.arpa. It is not very clear for ::I.P.V.4, I already tried to have a discussion about it in this list... Further, if the RES_USE_INET6 option is set in the resolver, the hostent returned by the first call will be in ::FFFF:192.5.5.1 format (16 bytes). => I don't agree *this* point. The RES_USE_INET6 option is not the good way to say IPv6 is in use (why not simply use the address family argument ?). If I'm headed in the wrong direction with this stuff, stop me now! => I believe the IPv6 support in the resolver is far less pressing that AAAA RR support for named and named-xfer. We should serialize the different issues or wait for the next century? Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 05:07:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21730; Tue, 21 May 96 05:07:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21724; Tue, 21 May 96 05:06:45 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10860; Tue, 21 May 1996 05:03:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA17041; Tue, 21 May 1996 05:03:41 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-15Apr96) with SMTP id FAA05274; Tue, 21 May 1996 05:03:40 -0700 (MST) Received: by gemini.tuc.noao.edu (4.1/SAG.sat.14) id AA23103; Tue, 21 May 96 05:03:39 MST; for ipng@sunroof.eng.sun.com Message-Id: <9605211203.AA23103@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Tue, 21 May 1996 05:03:39 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: paul@vix.com (Paul A Vixie), ipng@sunroof.eng.sun.com Subject: (IPng 1767) Re: i propose another change to the IPv6 BSD API document Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [In your message of May 20, 9:02pm you write:] > > Therefore my actual preference is still for: > > int inet_pton __P((int af, > const char *src, > void *dst, int size)); > char *inet_ntop __P((int af, > const void *src, > char *dst, int size)); > > ...which returns a simple zero/nonzero from inet_pton(), and which does not > have a "len" parameter on inet_ntop(). I like these, but since we've gotten rid of the binary length argument for the second function, can't we also get rid of the size argument for the first? It's really the size of the binary address (4 or 16), not quite the same as the size of a char[] that might overflow depending on the actual value of the printable string. If the first argument is AF_INET6 then dst had better point to an in6_addr{}. > I believe that I shall simply define them this way and wait for somebody to > yell at me. (Some of you will recognize my IETF modus operendi in action.) Fine with me. Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 05:26:08 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21768; Tue, 21 May 96 05:26:08 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21762; Tue, 21 May 96 05:25:55 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11761; Tue, 21 May 1996 05:22:50 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA19888; Tue, 21 May 1996 05:22:51 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id FAA21534; Tue, 21 May 1996 05:20:21 -0700 (PDT) Message-Id: <199605211220.FAA21534@aland.bbn.com> To: =?iso-8859-1?Q?TBA_INFORM=C1TICA?= Cc: Subject: (IPng 1768) Re: Courses From: Craig Partridge Date: Tue, 21 May 96 05:20:20 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Where can I find informations on courses about IPng? Steve Deering is teaching a course at SIGCOMM '96 (see http://www.acm.org/sigcomm/sigcomm96). Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 06:54:45 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21806; Tue, 21 May 96 06:54:45 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21800; Tue, 21 May 96 06:54:32 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18468; Tue, 21 May 1996 06:51:29 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA07166; Tue, 21 May 1996 06:51:27 -0700 From: bmanning@ISI.EDU Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 21 May 1996 06:51:21 -0700 Posted-Date: Tue, 21 May 1996 06:51:06 -0700 (PDT) Message-Id: <199605211351.AA18316@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Tue, 21 May 1996 06:51:06 -0700 Subject: (IPng 1769) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... To: paul@vix.com (Paul A Vixie) Date: Tue, 21 May 1996 06:51:06 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9605210106.AA21203@wisdom.home.vix.com> from "Paul A Vixie" at May 20, 96 06:06:12 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have different > PTR locations. We kinda need to know whether both are under IP6.INT or > whether both are under IN-ADDR.ARPA or whether they're split in some way. My reading of the specs indicate that any IPv6 format should resolve its PTR record in the IP6.INT domain. The case you use above would be in two seperate places in the IP6.INT ptr tree. > All three will search for 1.5.5.192.IN-ADDR.ARPA's PTR RR. None of them > use or fall back to IP6.INT. I think this is wrong. --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 07:09:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21819; Tue, 21 May 96 07:09:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21813; Tue, 21 May 96 07:09:39 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19898; Tue, 21 May 1996 07:06:35 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA10916; Tue, 21 May 1996 07:06:34 -0700 Received: from munin.fnal.gov ("port 3946"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I4YNAQ9IEC001USQ@FNAL.FNAL.GOV>; Tue, 21 May 1996 09:06:30 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id JAA24241; Tue, 21 May 1996 09:05:43 -0500 (CDT) Date: Tue, 21 May 1996 09:05:42 -0500 From: Matt Crawford Subject: (IPng 1770) Re: Responses to Comments on Multihoming draft In-Reply-To: "21 May 1996 08:49:35 +0200." <"9605210649.AA07013"@dxcoms.cern.ch> To: Brian Carpenter CERN-CN Cc: narten@VNET.ibm.COM (Thomas Narten), perk@WATSON.ibm.COM, ipng@sunroof.eng.sun.com Message-Id: <199605211405.JAA24241@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ As far as I know, there is no way to know that something is > an anycast address by looking at it, since it is syntactically > identical to a unicast address. Therefore, how does ND (or addrconf) > *know* it is dealing with an anycast address? > > Clearly, this cannot be answered "by configuration", since the > whole point of ND (or addrconf) is to avoid the need for configuration. (I don't see any replies yet, so I'll assume this is not rendered moot by our difference in longitude.) The hosts which have interfaces which answer to an anycast address have to know that the address is anycast. This is quite explicit on page 12 of RFC 1884. Those nodes must do ND a little differently for that address. Other nodes need not be configured with any special knowledge; the difference in Neighbor Advertisement processing is governed by the "O" (override) flag in the packet. Anycast is not the sole use of the O flag. > For tunnels, it is the whole question of how to handle tunnels with > anycast exits, especially when the tunnel needs to fragment packets. Well, an anycast address will never be the exit of an automatic tunnel. Configuring a tunnel which may require fragmentation is already deprecated ("Packet Size Issues," RFC 1883). Is that good enough? _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 07:32:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21846; Tue, 21 May 96 07:32:29 PDT Received: from pacific.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21836; Tue, 21 May 96 07:32:09 PDT Received: from lucknow.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA18807; Tue, 21 May 1996 07:29:03 -0700 Received: by lucknow.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA05290; Tue, 21 May 1996 07:28:50 -0700 Date: Tue, 21 May 1996 07:28:50 -0700 From: mukesh@caribe (Mukesh Kacker) Message-Id: <199605211428.HAA05290@lucknow.eng.sun.com> To: Mukesh.Kacker@Eng, paul@vix.com, ipng@sunroof.eng.sun.com, rstevens@noao.edu Subject: (IPng 1771) Re: i propose another change to the IPv6 BSD API document X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Your email surprises me. I've never seen a comment of this form in the > past 2 years on the Posix.1g mailing list. (My guess is you're presently > looking at some future 64-bit version of Solaris and are now having to deal > with the binary compatability issues? :-) ) > Speaking just for myself....I can say that there is an overwhelming amount of standards activity and some of us have limited amount of cycles for it. :-) We are not able to monitor every change or its consequences as well as we should. You are right in observing that this issue (and the semantics of it in the 64 bit context) have been realized recently. You can accusse the us of negligence/incompetence etc.:-) to let some of the issues slip through if people had their wits together about the transitions such as 64 bits. You are right that this alarm bell is being sounded too late. But the issue is what to do about it now that the issue is at the foreront. We are now just trying to discourage these problems from being introduced atleast in the new interfaces. > OK, back to the standards. ANSI C says that size_t is "the unsigned > integral type of the result of the sizeof operator". I think that > makes it completely appropriate for all of the socket address structure > length fields in the sockets API. When I code the third argument to > bind(), say, as "sizeof(struct sockaddr_in)" that sure looks like a > size_t to me. > > Looking in the Rationale of the ANSI C standard, they note that "size_t is > also a convienent type for array sizes, and so is used in several library > functions". For example, fread(), calloc(). The Rationale also notes > that "size_t is the appropriate type for an object size and for an array > bound". Looking at the various functions that use size_t for an array > size in /usr/include/*.h, there are a lot: getcwd(), strftime(), and > ttyname_r(), for example. Again, I think the "equivalence" of these > array bounds with the "sizeof" the array is why these were defined to > use size_t. > I am not certain if the use of "sizeof(sockaddr_in)" makes for a good rationale to determine the length type in bind [ you can cast it or define an IN_SOCKADDR_LEN ]. Some of the other interface you are citing have a need to be able to deliver an object that can be referenced by the largest size object (e.g. calloc). Other such as getcwd() are not. There is a current "64 bit cleanup" effort underway industry consortia like X/Open and I am not sure howthese interfaces are getting fixed (or not - will check). I am not certain how "size_t" was originally specified in ANSI C, but in the bleeding edge standards current definition is that it is a type that spans the full range of the largest representable size on the machine. So the feeling is that it should be used only in those interfaces that need to address such memory objects. > So I think size_t is appropriate for what the IPv6 sockets API is using > it for: the length in bytes of the address being converted by inet_ntop(). > I also think it's appropriate for what Posix.1g is using it for. > I guess we disagree that the return type for sizeof() (which should be able to handle the largest size object) should be the basis for deciding the data type for interfaces where it happens to get used if that is what you are saying. The data types for such objects such as "network address length" and "socket option length" or "length for string representation of network address" should be decided on its own merit and not based on the what is the type used for sizeof(). I am probably not as much literate on what was the intent in how certain standards evolved but sometimes these issues need a fresh look with binary compatibility issues in mind. > ssize_t is a Posix invention, not from ANSI C. It is basically a counter > (e.g., a size_t) that can also be an error indication (e.g., -1). Posix.1 > uses this for the return value from read() and write(), which makes sense. > I think using it as the return value from inet_pton(), where the return > is a count of the number of bytes or -1, again makes sense. > I view the requirements for read() and write() different from that for inet_pton(). The view is to not look at all interfaces that return a "count of number of bytes" in the same manner. > If I understand your objections, you are saying that when one moves from > a 32-bit architecture to a 64-bit architecture, int has to stay at 32 bits, > but long moves to 64 bits, and then size_t and ssize_t will both be 64 bits > (to allow huge reads and writes and huge memcpy's). But you have to provide > binary compatability for the older 32-bit applications? So you want all > these integer values that need not be 64 bits to be ints and not size_t > or ssize_t? It seems like your complaint is with ANSI for not defining > two size_t's (one for "huge" values and one for "smaller" values such as > array bounds) and the same for Posix with ssize_t? How are other vendors > with 64-bit architectures dealing with these problems? > "ANSI not defining two size_t" is one way to look at it. Another way to state is that size_t is a type to use where the type of object can potentially span the largest size object on the machine [ with a reality check :-) no arguments about source code portability with 8-bit machines ]. I am not sure I will choose array bounds as an example of "smaller" values since I am not sure how the code for in-memory databases look like. But a good example would be a "network address length". :-). Maybe there are some network technologies address length which might be on the 1 byte to 2 byte boundary but none can use even 4 bytes. So use of size_t there just because they can also be viewed as a count of bytes is not fine because of the issues with binary compatibility it raises. Proliferation of size_t based interfaces would mean different binary interfaces for a lot of calls which do not need it. So I am not conivnce that "size_t" is needed in IPv6 interfaces though I understand that the current version is consistent with what has been recent practice in standardization of similar interfaces. I would suggest the group of folks evolving this draft to consider this issue even though it comes too late. The industry trend is likely to be move away from "size_t" based interfaces mostly forced by an adverse impact on the 64-bit transition. -Mukesh Kacker ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 08:00:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21881; Tue, 21 May 96 08:00:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21875; Tue, 21 May 96 08:00:15 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25254; Tue, 21 May 1996 07:57:11 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA25609; Tue, 21 May 1996 07:57:09 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id OA22963; Wed, 22 May 1996 00:56:56 +1000 (from kre@munnari.OZ.AU) To: paul@vix.com (Paul A Vixie) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1772) Re: i propose another change to the IPv6 BSD API document In-Reply-To: Your message of "Mon, 20 May 1996 21:02:30 MST." Date: Wed, 22 May 1996 00:56:47 +1000 Message-Id: <6610.832690607@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 20 May 1996 21:02:30 -0700 From: paul@vix.com (Paul A Vixie) Message-ID: >Isn't it too late upon return to save it ... In the sense of thread safety, yes. In the sense of multiple calls as part of the same eval, no. I think the point is that the external strdup() design (static buffer in the function) is only safe if you can guarantee that all users of the function will do the strdup() thing - if anyone just calls the function and remembers a pointer to it, then there's no way any other caller can protect against the data being overwritten (or no rational way). Clearly here there's friction between doing things right, which requires the caller to pass in a buffer (and its size), and the desire to make it easy in the vast majority of cases where none of this matters, and the only use of the value of the function is to immediately log it somewhere, or similar. Rather than attempting to make one function suit all purposes, the correct solution here would seem to be to define two functions, one which has a bunch of parameters, is a bit ugly to call, but for which the definition at least is completely safe (as long as that's true the implementation can be made safe). Then, add an easy to call wrapper function, with the static buffer, etc, that users who don't need the protection can call. This is just like we still all call time() rather than gettimeofday() except when the extra info is really needed, because time() is a much simpler interface to use, but gettimeofday() is what time() really does (on most systems). This can be thread safe, signal handler safe, everything safe - anything in a "dangerous" environment just calls the lower level function, or provides their own wrapper (perhaps which mallocs a buffer and calls the function to fill the buffer, then returns that) as needed. Further, those can co-exist with other code that in its own little world isn't thread safe. With this almost all of the questions now being asked can be answered. The low level function takes all of the length parameters, etc, both for the size of the buffer for the result, and the size of the address. The upper level function can be tailored for IPv4 and IPv6, return a static buffer, and simply be given the address, and address family (the latter just because it now seems easier to have one function for both IPv6 and IPv6 addresses). I think we should just do away with the internal "static char[]" and have inet_ntop()'s fourth argument be nonoptional, followed by a fifth argument of type size_t giving the size of the array. I would certainly do it this way in the lower level function. I would also define "easy to call" functions, that are more like void * "pton"(int af, const char *src); (and have the dest addr be returned, or NULL on failure - the actual return type will depend upon af - though this may be a bit radical), and char * "ntop"(int af, const void *src); to go the other way. I have put the names in quotes as I'm not intending to suggest that's what they should be called. Perhaps the inet_ntop (etc) forms should be the "easy to call" and the other names discussed recently be the lower level functions? Whatever. ntop() is easy ... char *ntop(int af, const void *src) { static char buf[WHATEVER_CONST]; char *p; return inet_ntop(af, src, buf, sizeof buf); } pton() would be a little harder, but not a lot. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 08:08:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21898; Tue, 21 May 96 08:08:27 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21892; Tue, 21 May 96 08:08:14 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26366; Tue, 21 May 1996 08:05:09 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA28323; Tue, 21 May 1996 08:05:05 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA26831; Wed, 22 May 1996 01:05:00 +1000 (from kre@munnari.OZ.AU) To: Paul A Vixie Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1773) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of "Mon, 20 May 1996 18:06:12 MST." <9605210106.AA21203@wisdom.home.vix.com> Date: Wed, 22 May 1996 01:04:52 +1000 Message-Id: <6615.832691092@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 20 May 1996 18:06:12 -0700 From: Paul A Vixie Message-ID: <9605210106.AA21203@wisdom.home.vix.com> Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have different PTR locations. We kinda need to know whether both are under IP6.INT or whether both are under IN-ADDR.ARPA or whether they're split in some way. Don't confuse the issue. Look up *all* IPv6 addresses in IP6.INT. The only argument against doing that is that it seems to require that end users maintain separate zone files for their IPv4 address spaces. However, this is not necessarily true at all - that's purely an implementation issue in the server. It may be true today, but there aren't really enough people using IPv6 today for it to really matter (those people are already living in an evnironment where they're bring on lots of extra work on themselves - for the good of everyone). Nameservers could though, when receiving a query in the IP6.INT space they control, and nothing that its in a mapped IPv4 part of the IPv6 addr space, turn that into an IN-ADDR.ARPA query to resolve the address, and return the result, or they could have easy to use config option that loads the appropriate data into both zones to produce the same result. That way, those who want the two identical have the two be identical, and those who don't aren't constrained. In any case, the resolvers when presented with an IPv6 address (no matter what address space it's in) should be doing IP6.INT type queries, nothing else makes sense. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 08:17:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21918; Tue, 21 May 96 08:17:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21912; Tue, 21 May 96 08:17:16 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27551; Tue, 21 May 1996 08:14:12 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA00983; Tue, 21 May 1996 08:14:09 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id PA09144; Wed, 22 May 1996 01:13:53 +1000 (from kre@munnari.OZ.AU) To: "Brian Carpenter CERN-CN" Cc: narten@VNET.IBM.COM (Thomas Narten), perk@watson.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 1774) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of "Tue, 21 May 1996 08:49:35 +0200." <9605210649.AA07013@dxcoms.cern.ch> Date: Wed, 22 May 1996 01:13:45 +1000 Message-Id: <6620.832691625@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 21 May 1996 08:49:35 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Message-ID: <9605210649.AA07013@dxcoms.cern.ch> Clearly, this cannot be answered "by configuration", since the whole point of ND (or addrconf) is to avoid the need for configuration. ND has nothing to do with configuration, ND is ARP renamed (and reinvented). addrconf has nothing to do with anycast addresses. The current plan is certainly for anycast addresses to be configured, though I would suppose they could be configured in a DHCP server and handed out in response to a query like "tell me the anycast addresses for time servers on this net" - if the client of that request is an ordinary host, it probably wants to contact a time server, and will use the address returned as the dest addr of query packets. On the other hand, if the host is itself a timeserver, it would configure its interface(s) to respond to the returned anycast address(es). While I'm here, on the issue of autoconf of stuff in general, I'd request that implementors bear in mind that we're likely to need more than "autoconfigure this value" and "here is the value, use it". Both of those modes are certainly needed, but we're also likely to want to be able to say (to our implementation) things like "find the local network number, and append to it to form an address", which could be a way to semi-autoconfigure an anycast address (with the value obtained being treated as anycast), in that the low bits would be configured on the host, but the network number bits would be obtained the autoconf way, and be as liable to change as any other autoconf'd address. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 08:52:43 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21962; Tue, 21 May 96 08:52:43 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA21956; Tue, 21 May 96 08:52:29 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02778; Tue, 21 May 1996 08:49:25 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA12744; Tue, 21 May 1996 08:49:23 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id RAA21546; Tue, 21 May 1996 17:49:21 +0200 (MET DST) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id RAA24699; Tue, 21 May 1996 17:49:14 +0200 Message-Id: <199605211549.RAA24699@givry.inria.fr> From: Francis Dupont To: bmanning@isi.edu Cc: paul@vix.com (Paul A Vixie), ipng@sunroof.eng.sun.com Subject: (IPng 1775) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of Tue, 21 May 1996 06:51:06 PDT. <199605211351.AA18316@zed.isi.edu> Date: Tue, 21 May 1996 17:48:55 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > > Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have different > PTR locations. We kinda need to know whether both are under IP6.INT or > whether both are under IN-ADDR.ARPA or whether they're split in some way. My reading of the specs indicate that any IPv6 format should resolve its PTR record in the IP6.INT domain. The case you use above would be in two seperate places in the IP6.INT ptr tree. => I disagree for the ::FFFF:I.P.V.4 which *is* an IPv4 address. I don't know what to do for ::I.P.V.4, then today I use the default rule for IPv6 addresses (ie ip6.int). Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 09:44:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22024; Tue, 21 May 96 09:44:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22018; Tue, 21 May 96 09:44:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11598; Tue, 21 May 1996 09:41:02 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA01174; Tue, 21 May 1996 09:41:01 -0700 From: bmanning@ISI.EDU Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 21 May 1996 09:41:00 -0700 Posted-Date: Tue, 21 May 1996 09:40:45 -0700 (PDT) Message-Id: <199605211640.AA18685@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Tue, 21 May 1996 09:40:45 -0700 Subject: (IPng 1776) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... To: Francis.Dupont@inria.fr (Francis Dupont) Date: Tue, 21 May 1996 09:40:45 -0700 (PDT) Cc: bmanning@ISI.EDU, paul@vix.com, ipng@sunroof.eng.sun.com In-Reply-To: <199605211549.RAA24699@givry.inria.fr> from "Francis Dupont" at May 21, 96 05:48:55 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > My reading of the specs indicate that any IPv6 format should > resolve its PTR record in the IP6.INT domain. The case you > use above would be in two seperate places in the IP6.INT > ptr tree. > > => I disagree for the ::FFFF:I.P.V.4 which *is* an IPv4 address. > I don't know what to do for ::I.P.V.4, then today I use the > default rule for IPv6 addresses (ie ip6.int). > > Francis.Dupont@inria.fr Hum... IPv4 addresses are 32 bits, yes? ::FFFF:I.P.V.4 is more than 32 bits, yes? so is ::FFFF:I.P.V.4 a real, 32bit IPv4 address? I'd say no. It is mapped to and treated like one in a transition environment, but it is -not- a IPv4 address, just a cute faux. Use IP6.INT. -- --bill Key fingerprint = FA 2A 63 DA 63 2E CB DB 26 2F 7A 12 B1 07 7D 68 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 10:18:20 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22074; Tue, 21 May 96 10:18:20 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22068; Tue, 21 May 96 10:18:01 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18705; Tue, 21 May 1996 10:14:56 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA13639; Tue, 21 May 1996 10:14:50 -0700 Received: (from roque@localhost) by oberon (8.6.6.Beta9/8.6.6.Beta9) id SAA01909; Tue, 21 May 1996 18:11:40 +0100 Date: Tue, 21 May 1996 18:11:40 +0100 From: Pedro Roque Marques Message-Id: <199605211711.SAA01909@oberon> To: bmanning@ISI.EDU Cc: Francis.Dupont@inria.fr (Francis Dupont), paul@vix.com, ipng@sunroof.eng.sun.com Subject: (IPng 1777) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: <199605211640.AA18685@zed.isi.edu> References: <199605211549.RAA24699@givry.inria.fr> <199605211640.AA18685@zed.isi.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "bmanning" == bmanning writes: >> My reading of the specs indicate that any IPv6 format should >> resolve its PTR record in the IP6.INT domain. The case you use >> above would be in two seperate places in the IP6.INT ptr tree. >> >> => I disagree for the ::FFFF:I.P.V.4 which *is* an IPv4 >> address. I don't know what to do for ::I.P.V.4, then today I >> use the default rule for IPv6 addresses (ie ip6.int). >> >> Francis.Dupont@inria.fr bmanning> Hum... IPv4 addresses are 32 bits, yes? bmanning> ::FFFF:I.P.V.4 is more than 32 bits, yes? bmanning> so bmanning> is ::FFFF:I.P.V.4 a real, 32bit IPv4 address? bmanning> I'd say no. It is mapped to and treated like one in a bmanning> transition environment, but it is -not- a IPv4 address, bmanning> just a cute faux. bmanning> Use IP6.INT. I've to agree with Francis here. For implementations ::FFFF:d.d.d.d is a v4 address since socket operations performed with those addresses go though v4 code. The bsd-api draft is clear about the fact that implementations should have one instance of transport protocols accessible by both APIs and hable to communicate with both network protocols. If an app using INET6 binds to * a syn traveling in v4 will be accepted to that port and the app will receive a mapped address in the accept. The communication will then procced using IPv4... When the app does gethostbyaddr it should get the ptr registred in in-addr.arpa since the host it's talking to may be v4 only. It's the same namespace, it should be the same naming authority. regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 10:24:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22099; Tue, 21 May 96 10:24:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22093; Tue, 21 May 96 10:24:19 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19915; Tue, 21 May 1996 10:21:13 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA15979; Tue, 21 May 1996 10:21:07 -0700 Received: (from roque@localhost) by oberon (8.6.6.Beta9/8.6.6.Beta9) id SAA01922; Tue, 21 May 1996 18:19:50 +0100 Date: Tue, 21 May 1996 18:19:50 +0100 From: Pedro Roque Marques Message-Id: <199605211719.SAA01922@oberon> To: "Brian Carpenter CERN-CN" Cc: narten@VNET.IBM.COM (Thomas Narten), perk@watson.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 1778) Re: Responses to Comments on Multihoming draft In-Reply-To: <9605210649.AA07013@dxcoms.cern.ch> References: <9605202007.AA18431@cichlid.raleigh.ibm.com> <9605210649.AA07013@dxcoms.cern.ch> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Brian" == Brian Carpenter CERN-CN writes: Brian> As far as I know, there is no way to know that something is Brian> an anycast address by looking at it, since it is Brian> syntactically identical to a unicast address. Therefore, Brian> how does ND (or addrconf) *know* it is dealing with an Brian> anycast address? I believe careful network administrators will configure their networks as to have all anycast address on different subnet ids than their anycast addresses so that at least they can distinguish them syntacticly. The issue is a bit if the IETF should make this practice mandatory and specify that anycast address should be on subnet X from the prefix being avaliable to a domain. I don't have a clear case on this... ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 10:34:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22116; Tue, 21 May 96 10:34:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22110; Tue, 21 May 96 10:33:58 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21846; Tue, 21 May 1996 10:30:51 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA19897; Tue, 21 May 1996 10:30:50 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id NAA07619; Tue, 21 May 1996 13:17:24 -0400 (EDT) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA02648; Tue, 21 May 1996 13:16:52 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id NAA07487; Tue, 21 May 1996 13:21:44 GMT Message-Id: <199605211321.NAA07487@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: bmanning@isi.edu Cc: Francis.Dupont@inria.fr (Francis Dupont), paul@vix.com, ipng@sunroof.eng.sun.com Subject: (IPng 1779) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of "Tue, 21 May 1996 09:40:45 MST." <199605211640.AA18685@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 21 May 1996 13:21:36 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hum... IPv4 addresses are 32 bits, yes? > ::FFFF:I.P.V.4 is more than 32 bits, yes? Not on the wire. ::FFFF:I.P.V.4 causes an IPv4 packet to be sent. > so > > is ::FFFF:I.P.V.4 a real, 32bit IPv4 address? Yes. > I'd say no. It is mapped to and treated like > one in a transition environment, but it is > -not- a IPv4 address, just a cute faux. I disagree. Will ::FFFF:a.b.c.d be used for any thing other IPv4 addresses? Not likely. Even more importantly, if I am IPv6 and using IPv4 mapped addresses, those people I talk to using IPv4 mapped addresses are not going to set PTR records for their IPv4 mapped addresses just so I can backtranslate their names. The only way I be to go from address to name is if you use the in-addr.arpa hierarchy. IPv4 compatible addresses assume the remote system is running at least a bit of IPv6 (which means they could/should be in DNS and should use IP6.INT to backtranslate them). IPv6 mapped addresses make no such assumption except they are IPv4 and for that reason in-addr.arpa is the right place to look them up. > Use IP6.INT. No. -- Matt Thomas Internet: matt@3am-software.com 3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt.html Westford, MA Disclaimer: I disavow all knowledge of this message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 12:41:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22238; Tue, 21 May 96 12:41:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22227; Tue, 21 May 96 12:31:38 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12944; Tue, 21 May 1996 12:28:32 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA05041; Tue, 21 May 1996 12:28:30 -0700 From: bmanning@ISI.EDU Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 21 May 1996 12:28:29 -0700 Posted-Date: Tue, 21 May 1996 12:28:07 -0700 (PDT) Message-Id: <199605211928.AA18890@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Tue, 21 May 1996 12:28:07 -0700 Subject: (IPng 1780) Re: Nobody seems to know if ::I.P.V.4 and To: matt@lkg.dec.com (Matt Thomas) Date: Tue, 21 May 1996 12:28:07 -0700 (PDT) Cc: bmanning@ISI.EDU, Francis.Dupont@inria.fr, paul@vix.com, ipng@sunroof.eng.sun.com In-Reply-To: <199605211321.NAA07487@whydos.lkg.dec.com> from "Matt Thomas" at May 21, 96 01:21:36 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > > Hum... IPv4 addresses are 32 bits, yes? > > ::FFFF:I.P.V.4 is more than 32 bits, yes? > > Not on the wire. ::FFFF:I.P.V.4 causes an IPv4 packet > to be sent. Is this an implementation choice? > > Use IP6.INT. > > No. > -- (Whine mode) But its good for you! > Matt Thomas Internet: matt@3am-software.com --bill ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 13:12:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22303; Tue, 21 May 96 13:12:40 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22291; Tue, 21 May 96 13:12:10 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18950; Tue, 21 May 1996 13:09:06 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA17909; Tue, 21 May 1996 13:09:03 -0700 Received: by muenster.westfalen.de (/\oo/\ Smail3.1.29.1 #29.3) id ; Tue, 21 May 96 21:52 MET DST Received: by khms.westfalen.de (CrossPoint v3.1 R/C435); 21 May 1996 21:33:54 +0200 Date: 21 May 1996 19:43:00 +0200 From: kai@khms.westfalen.de (Kai Henningsen) To: ipng@sunroof.eng.sun.com Message-Id: <69GdUlDEcsB@khms.westfalen.de> In-Reply-To: <199605211125.NAA23858@givry.inria.fr> Subject: (IPng 1781) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P. X-Mailer: CrossPoint v3.1 R/C435 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Organisation? Me?! Are you kidding? X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis.Dupont@inria.fr (Francis Dupont) wrote on 21.05.96 in <199605211125.NAA23858@givry.inria.fr>: > In your previous mail you wrote: > > Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have different > PTR locations. We kinda need to know whether both are under IP6.INT or > whether both are under IN-ADDR.ARPA or whether they're split in some way. > > => ::FFFF:I.P.V.4 is a real IPv4 address then the PTR is obviously > 4.V.P.I.in-addr.arpa. It is not very clear for ::I.P.V.4, > I already tried to have a discussion about it in this list... Well, these addresses are supposed to be used in the first place because they enable communication with IPv4 hosts. To that end, they should have PTRs in IN-ADDR.ARPA. Obviously, mapped addresses won't have PTR records in IP6.INT. The other variant could; however, as IN-ADDR.ARPA PTRs should also be there, this is a duplication that might lead to inconsistencies - do we really want (the possibility of) IPv4 hosts to get different reverse address resolution on the same address as IPv6 hosts? MfG Kai ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 13:12:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22304; Tue, 21 May 96 13:12:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22297; Tue, 21 May 96 13:12:20 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18968; Tue, 21 May 1996 13:09:16 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA17952; Tue, 21 May 1996 13:09:11 -0700 Received: by muenster.westfalen.de (/\oo/\ Smail3.1.29.1 #29.3) id ; Tue, 21 May 96 21:52 MET DST Received: by khms.westfalen.de (CrossPoint v3.1 R/C435); 21 May 1996 21:33:54 +0200 Date: 21 May 1996 20:01:00 +0200 From: kai@khms.westfalen.de (Kai Henningsen) To: ipng@sunroof.eng.sun.com Message-Id: <69GdV6fjcsB@khms.westfalen.de> In-Reply-To: <199605211428.HAA05290@lucknow.eng.sun.com> Subject: (IPng 1782) Re: i propose another change to the IPv6 BSD API docum X-Mailer: CrossPoint v3.1 R/C435 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Organization: Organisation? Me?! Are you kidding? X-No-Junk-Mail: I do not want to get *any* junk mail. Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mukesh.Kacker@Eng.Sun.COM (Mukesh Kacker) wrote on 21.05.96 in <199605211428.HAA05290@lucknow.eng.sun.com>: > The industry trend is likely to be move away from "size_t" based > interfaces mostly forced by an adverse impact on the 64-bit transition. This is surprising to say the least. I have serious trouble believing it. Frankly, I believe the technical argument to be completely spurious. First, as long as you talk about source compatibility, size_t is quite obviously the easy way to get it. So I'm going to assume you talk about binary compatibility. Now, for binary compatibility, and assuming the usual flat memory design (instead of, say, 8086 segments), I'd expect the usual definition of size_t to be such that sizeof(size_t) == min(sizeof(int), sizeof(void *)). Given that, replacing size_t by int obviously only "helps" in cases where sizeof(int) < sizeof(void *). With regards to binary compatibility and the 32->64 bit transition, you obviously envision a move from sizeof(void *)==4 to sizeof(void *)==8, with sizeof(int)==4 in both cases. However, given that, binary compatibility is already hopelessly lost wherever you have a pointer. This is _much_ harder to fix than the sizeof(sizeof_t) problem; however, we need not even think that far: in any case where size_t is used to specify the size of an object, there already is a pointer to that object around, and that pointer already is not binary compatible. In short, it doesn't seem that there's anything to gain by preaching against size_t. In fact, because of the source compatibility qustion, it seems to me that using size_t is actually a net win in the move to 64 bits. MfG Kai ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 13:37:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22349; Tue, 21 May 96 13:37:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22343; Tue, 21 May 96 13:37:43 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23340; Tue, 21 May 1996 13:34:37 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA26629; Tue, 21 May 1996 13:34:18 -0700 From: bmanning@ISI.EDU Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 21 May 1996 13:34:02 -0700 Posted-Date: Tue, 21 May 1996 13:33:47 -0700 (PDT) Message-Id: <199605212033.AA19046@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Tue, 21 May 1996 13:33:47 -0700 Subject: (IPng 1783) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P. To: kai@khms.westfalen.de (Kai Henningsen) Date: Tue, 21 May 1996 13:33:47 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <69GdUlDEcsB@khms.westfalen.de> from "Kai Henningsen" at May 21, 96 07:43:00 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Obviously, mapped addresses won't have PTR records in IP6.INT. The other > variant could; however, as IN-ADDR.ARPA PTRs should also be there, this is > a duplication that might lead to inconsistencies - do we really want (the > possibility of) IPv4 hosts to get different reverse address resolution on > the same address as IPv6 hosts? > It is conceivable. -- --bill Key fingerprint = FA 2A 63 DA 63 2E CB DB 26 2F 7A 12 B1 07 7D 68 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 13:56:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22408; Tue, 21 May 96 13:56:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22402; Tue, 21 May 96 13:56:39 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA26656; Tue, 21 May 1996 13:53:35 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA03736; Tue, 21 May 1996 13:53:34 -0700 Received: by gw.home.vix.com id NAA22276; Tue, 21 May 1996 13:53:33 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA23514; Tue, 21 May 1996 13:53:32 -0700 Message-Id: <9605212053.AA23514@wisdom.home.vix.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1784) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of "Wed, 22 May 1996 01:04:52 +1000." <6615.832691092@munnari.OZ.AU> Date: Tue, 21 May 1996 13:53:32 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Re: "nothing else makes sense" These are transition addresses, and so if IPv6's pundits are at all correct, we will not be dealing with ::i.p.v.4 or ::FFFF:i.p.v.4 for very much longer. We are therefore arguing over transition strategies. In either the ::i.p.v.4 or ::FFFF:i.p.v.4 case, an IPv6 stack is speaking the IPv4 wire protocol to an IPv4 endpoint. In the ::i.p.v.4 case, that IPv4 endpoint is a tunnel exit to an IPv6 host, and there is an IPv6 packet encapsulated inside the IPv4 packet. In the ::FFFF:i.p.v.4 case, the packet is pure IPv4 on the wire, and the remote host doesn't have to know IPv6 at all. In no case mentioned thus far do we have an IPv4 address which has not been delegated and allocated and named as part of the universally unique IPv4 address space. If we looked up a PTR at: 4(l).4(h).v(l).v(h).p(l).p(h).i(l).i(h).0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT or 4(l).4(h).v(l).v(h).p(l).p(h).i(l).i(h).f.f.f.f.0.0.0.0.0.0.0.0.IP6.INT and got a different result than when we looked up a PTR at: 4.v.p.i.IN-ADDR.ARPA then at least one of those PTR's is wrong. This is _not_ a matter about which correct implementations can disagree. When asking the question: "what name is bound to this IPv4 address" there is only one correct answer. Getting a different answer based on whether you are using an IPv6 stack to speak IPv4, or an IPv6 stack to tunnel over IPv4, or just using an IPv4 stack, would be pure madness. It is most unfortunate that nonterminal CNAMEs aren't specified for DNS, and that we decided to use nybbles rather than octets for the IPv6 inverse naming. But for those two faults, we could use CNAMEs to union the namespaces. I have heard nothing yet in this discussion, either from Francis, or Robert, or Bill, to change my mind. I'm happy as hell that Matt seems to have the same position I do. I don't think that we will make progress convincing each other, so somebody ought to put this on some IETF WG agenda for Montreal. I agree with Francis that it's not essential that we nail this down right now; the BIND resolver's method of dealing with it can be considered experimental until we can come to some kind of consensus on this point. The most important thing for IPv6 right now is that the BIND server support AAAA when loading, dumping, caching, and transferring zones. That part, at least, we can agree upon. And as of 4.9.4-T1A (released to the bind-workers list last night), that part is all done. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 15:18:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22465; Tue, 21 May 96 15:18:23 PDT Received: from pacific.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22459; Tue, 21 May 96 15:18:04 PDT Received: from lucknow.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA14729; Tue, 21 May 1996 15:14:41 -0700 Received: by lucknow.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA05483; Tue, 21 May 1996 15:14:25 -0700 Date: Tue, 21 May 1996 15:14:25 -0700 From: mukesh@caribe (Mukesh Kacker) Message-Id: <199605212214.PAA05483@lucknow.eng.sun.com> To: ipng@sunroof.eng.sun.com, kai@khms.westfalen.de Subject: (IPng 1785) Re: i propose another change to the IPv6 BSD API docum Cc: mukesh@caribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Md5: 0VkJQzHMHWmu6WTQRISv4w== Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >=20 > Mukesh.Kacker@Eng.Sun.COM (Mukesh Kacker) wrote on 21.05.96 in=20 <199605211428.HAA05290@lucknow.eng.sun.com>: >=20 > > The industry trend is likely to be move away from "size_t" based > > interfaces mostly forced by an adverse impact on the 64-bit = transition. >=20 > This is surprising to say the least. I have serious trouble believing = it. >=20 Maybe if you look at that statement out of context. I will advocate size_t use in interfaces which need it and not in interfaces that do not. Interfaces that do not should choose types based on the semantics of the object they are trying to represent and not use size_t indiscriminately for everything that returns a count of bytes. size_t may have started out as a type to represent return value for sizeof() but it has come to mean and imply something that represents the type for the largest size memory object. That is the context in which it should be used and not everywhere you have a count of bytes. Both 32 and 64 bit machines will live for a long time. Maybe there will be 128 machines in the future. Why not have one binary interface that will work for all of them when that is possible. I do not think the requirement for the *binary* interface like inet_pton() changes when you make these transitions. (not counting the change in pointer sizes which is a different issue that does effect). > Frankly, I believe the technical argument to be completely spurious. >=20 > First, as long as you talk about source compatibility, size_t is quite = = =20 > obviously the easy way to get it. So I'm going to assume you talk = about =20 > binary compatibility. > A lot of the interfaces that formerly used =0D"int" are being = transformed to size_t unnecessarily and I will not call that a win for source compatibility either. And what I am pointing out is that it raises binary compatibility problems. There are lot of internal common code paths especially in the kernel = where you do not want to check for overflows/range-checks etc. depending on whether the object is from 64-bit or 32 bit application. Even in user level applications there are instance where you would want code not to change in transitions whenver size_t changes size. By proliferating these interfaces unncessarily...you generate more = problems. > Now, for binary compatibility, and assuming the usual flat memory = design =20 > (instead of, say, 8086 segments), I'd expect the usual definition of =20 > size_t to be such that sizeof(size_t) =3D=3D min(sizeof(int), = sizeof(void *)). >=20 > Given that, replacing size_t by int obviously only "helps" in cases = where =20 > sizeof(int) < sizeof(void *). >=20 > With regards to binary compatibility and the 32->64 bit transition, = you =20 > obviously envision a move from sizeof(void *)=3D=3D4 to sizeof(void = *)=3D=3D8, =20 > with sizeof(int)=3D=3D4 in both cases. >=20 Yes that is the transition we are talking about. In LP64 model your equality assertion is not true. > However, given that, binary compatibility is already hopelessly lost =20 > wherever you have a pointer. This is _much_ harder to fix than the =20 > sizeof(sizeof_t) problem; however, we need not even think that far: in = any =20 > case where size_t is used to specify the size of an object, there = already =20 > is a pointer to that object around, and that pointer already is not = binary =20 > compatible. >=20 You may have a point based on application compatibility since most applications will be using pointers. However just because applications need to deal with change in sizeof (void *), we should not force them to deal with overflow problems, portability problems, expose latent bugs in every namespace of interfaces by choosing size_t everywhere. You can have an impact on the magnitude of the problem if not on the existence = of a binary compatibility problem. I can come up with contrived examples where multiple size address spaces are supported for applications that need larger addressability by interesting remappings tricks so why introduce the size_t problem also where one need not exist. If you are looking for portability and compatibility problems there are plenty to choose from but the point is to not increase the set. [ You might have notice how all Socket standards step around the sa_len field issue which is a change in BSD (done for OSI support ?) that the rest of the industry did not buy because of the binary (and less of source) compatibility issues ] > In short, it doesn't seem that there's anything to gain by preaching =20 > against size_t. In fact, because of the source compatibility question, = it =20 > seems to me that using size_t is actually a net win in the move to 64 = =20 > bits. >=20 size_t is a *must* for 64 bits but should be used in moderation and only where necessary. The right medicine should be used for the right = ailment. Same applies to data types. If having the largest possible size in every possible interface was such a hot idea, you would have seen every interface use a "long" and not an "int" in the past for maximum mileage. Efficiency and appropriateness is and should be a concern. size_t is not just a nice of representing counts but has binary representation requirement that has certain properties such as being able to represent the largest size object. I personally would not like to live for the day when we would really *need* size_t for network address lengths :-) So I do not think simple statement like "using size_t is actually a net = win in the move to 64 bits" should apply for every context without = qualification. size_t is the right data type for interfaces like read(), write() which potentially have to deal with the largest size memory object on a machine and it is appropriate for use there. Proliferating size_t indiscriminately will increase ABI interfaces, = increase sizeof of objects, and other inefficiencies and all the side effects = which might be hard to quantify. [ When you move to a 128 bit machine, would you really like your cache misses because all your caches lines were full referencing variables which could have been only 4 bytes (or less) long but are 16 bytes long in your application which was written as portable code and declared them to be size_t. ? To a lesser degree you can imagine the same in 64 bit world ]. I understand why size_t is there in IPv6 drafts as it also got used (most likely unwittingly before problems with it were noticed) by in some standards developments. However, people have realized now it is not a good idea to use it in all cases. Atleast the IETF development process has an edge over others in being faster in acknowledging and reacting and changing to the possibility of feedback based on practice and this is one case where it should react. These problems have been realized and acknoledged only recently. This is not just a view from Sun but based on what I have heard from = other vendors too. (They probably do not want the tomatoes to fly in their direction just yet :-)). No one wants to proliferate binary interfaces = that have to change unnecessarily. For vendors every binary interface (and = all the possible application problems and code paths it implies) is one has = to be supported for a long time against bugs and what not for a long time. Therefore I think the IPv6 BSD API should refrain from using size_t whereever it is not really needed (which might be all instances ?). -Mukesh Kacker Internet Engineering Sun Microsystems Inc (SunSoft) mukesh.kacker@eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 21:17:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22723; Tue, 21 May 96 21:17:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22717; Tue, 21 May 96 21:17:36 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25536; Tue, 21 May 1996 21:14:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA17972; Tue, 21 May 1996 21:14:30 -0700 Received: by gw.home.vix.com id VAA18971; Tue, 21 May 1996 21:14:29 -0700 Date: Tue, 21 May 1996 21:14:29 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 1786) Re: i propose another change to the IPv6 BSD API document Organization: Vixie Enterprises Message-Id: References: <199605211052.MAA23751@givry.inria.fr> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: Francis.Dupont@inria.fr's message of 21 May 1996 04:00:47 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [dupont] > we need a ssize_t because inet_pton should be usable with > variable length addresses (like OSI addresses). Given that we are treating the network-form address as a {void *buf; int size;} it is not unreasonable of us to demand that any address family implemented for inet_ntop() and inet_pton() will either be fixed length, or will have a length field inside the void*, known to the caller and known to the address family independent portions of inet_pton() and inet_ntop(). OSI is a degenerate case for several reasons; most people who program ISO stuff do it with ISODE, and they aren't likely to switch to inet_mumble() just because we build it. I am willing to code up the AF_ISO arm of inet_pton() and inet_ntop() but I will do it in terms of a struct that encapsulates the address and its count field. Nobody would be happier to see inet_nsap_addr() & inet_nsap_ntoa() die, than I. >[vixie] >> Do we need a bufsize parameter as well, to avoid gets() sickness? >> Speaking of that, does inet_pton() need a buflen parameter? [dupont] > the maximum lengths are well known constants (they are in the API draft). I found while recasting the function signatures a few nights ago that I did not much mind _reading_ memory which might not belong to my variable, but that I was quite reluctant to _write_on_ such memory. In either case the program will exhibit undefined behaviour, but in the latter case it's bit cancer and I really do prefer the former case. Thus I sized both `dst' fields. However: [stevens] > I like these, but since we've gotten rid of the binary length argument for > the second function, can't we also get rid of the size argument for the > first? It's really the size of the binary address (4 or 16), not quite the > same as the size of a char[] that might overflow depending on the actual > value of the printable string. If the first argument is AF_INET6 then dst > had better point to an in6_addr{}. I think of them in the same light as I do getpeername() or getsockname(). But I am able to see your point -- if I'm depending on the network-form address to have a certain size when I read it, I may as well depend on the same when I write on it. Argh. But, OK, I will make this change before the next BIND cut. I think I feel an I-D coming on, as well. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 21 21:20:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22730; Tue, 21 May 96 21:20:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22724; Tue, 21 May 96 21:20:21 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25629; Tue, 21 May 1996 21:17:15 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA18313; Tue, 21 May 1996 21:17:16 -0700 Received: by gw.home.vix.com id VAA19009; Tue, 21 May 1996 21:17:15 -0700 Date: Tue, 21 May 1996 21:17:15 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 1787) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P. Organization: Vixie Enterprises Message-Id: References: <69GdUlDEcsB@khms.westfalen.de> <199605212033.AA19046@zed.isi.edu> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: bmanning@ISI.EDU's message of 21 May 1996 13:43:45 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Henningsen] > Obviously, mapped addresses won't have PTR records in IP6.INT. The other > variant could; however, as IN-ADDR.ARPA PTRs should also be there, this is > a duplication that might lead to inconsistencies - do we really want (the > possibility of) IPv4 hosts to get different reverse address resolution on > the same address as IPv6 hosts? No, we don't. Warnier and Orr proved to my satisfaction that data which has to be updated in several places will (*will* not *might*) become inconsistent. [manning] > It is conceivable. I will temporarily suspend disbelief. Please outline a scenario for me. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 22 00:25:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22953; Wed, 22 May 96 00:25:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA22947; Wed, 22 May 96 00:25:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06593; Wed, 22 May 1996 00:22:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA10003; Wed, 22 May 1996 00:22:03 -0700 Received: from shand.reo.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id DAA11797; Wed, 22 May 1996 03:19:10 -0400 (EDT) Received: from localhost by shand.reo.dec.com (5.65/MS-010395) id AA27525; Wed, 22 May 1996 08:18:34 +0100 Message-Id: <9605220718.AA27525@shand.reo.dec.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1788) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of "Tue, 21 May 96 18:19:50 BST." <199605211719.SAA01922@oberon> Date: Wed, 22 May 96 08:18:34 +0100 From: (Mike Shand REO2 F/D9 DTN:830-4424) X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think configuring anycast addresses to be a "separate subnet" makes sense. The thought of an anycast address which has scope wider than a single physical LAN, but has an address which corresponds to the subnet on a single LAN seems very confusing. What I have yet to understand about anycast addresses is exactly how the routers know which are anycast addresses, and exactly what their scope is. If this is written down somewhere, please point me to the right place, but I haven't seen any detailed discussion of this area. There seems to be a general idea that the scoping is done by some sort of prefixing, but it isn't clear (to me anyway) how this actually works. Mike ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 22 10:54:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23269; Wed, 22 May 96 10:54:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23263; Wed, 22 May 96 10:54:36 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03599; Wed, 22 May 1996 10:51:29 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA26218; Wed, 22 May 1996 10:51:29 -0700 From: bmanning@ISI.EDU Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Wed, 22 May 1996 10:51:28 -0700 Posted-Date: Wed, 22 May 1996 10:51:12 -0700 (PDT) Message-Id: <199605221751.AA19616@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Wed, 22 May 1996 10:51:12 -0700 Subject: (IPng 1789) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P. To: paul@vix.com (Paul A Vixie) Date: Wed, 22 May 1996 10:51:12 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: from "Paul A Vixie" at May 21, 96 09:17:15 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > [Henningsen] > > Obviously, mapped addresses won't have PTR records in IP6.INT. The other > > variant could; however, as IN-ADDR.ARPA PTRs should also be there, this is > > a duplication that might lead to inconsistencies - do we really want (the > > possibility of) IPv4 hosts to get different reverse address resolution on > > the same address as IPv6 hosts? > > No, we don't. Warnier and Orr proved to my satisfaction that data which has > to be updated in several places will (*will* not *might*) become inconsistent. > > [manning] > > It is conceivable. > > I will temporarily suspend disbelief. Please outline a scenario for me. Ok, I have a host foo.example.org in a 192.0.2.255 255.2.0.192.in-addr.arpa. in ptr foo.example.org I want to tranistion this host. In doing so, I want to make it clear that there is a difference between the ip4 and ip6 instatiations, much like identifing different interfaces on a router. So I wont do something like this: foo.example.org in a 192.0.2.255 foo.example.org in a ::FFFF:192.0.2.255 foo.example.org in aaaa ::FFFF:192.0.2.255 255.2.0.192.in-addr.arpa. in ptr foo.example.org unless I'm allowed to. Is this confusing or what? Much better to "encourage" this type of behaviour: foo.example.org in a 192.0.2.255 255.2.0.192.in-addr.arpa. in ptr foo.example.org bar.example.org in aaaa ::FFFF:192.0.2.255 255.2.0.192.f.f.f.f.f.f.f.f.ip6.int. in ptr bar.example.org so all quad A records map to ip6.int and straight A records map to in-addr.arpa. Makes it much easier for ops people to figure out where things are. --bill Key fingerprint = FA 2A 63 DA 63 2E CB DB 26 2F 7A 12 B1 07 7D 68 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 22 11:11:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23308; Wed, 22 May 96 11:11:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23253; Wed, 22 May 96 10:49:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02565; Wed, 22 May 1996 10:46:22 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA24079; Wed, 22 May 1996 10:46:17 -0700 Received: (from andre@localhost) by tatui.insite.com.br (8.6.12/8.6.9) id OAA00633; Wed, 22 May 1996 14:46:27 -0300 Date: Wed, 22 May 1996 14:46:27 -0300 (EST) From: Andre Uratsuka Manoel X-Sender: andre@tatui.insite.com.br To: =?iso-8859-1?Q?TBA_INFORM=C1TICA?= Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1790) Re: Courses In-Reply-To: <199605211220.FAA21534@aland.bbn.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ooops Desculpe. Nao tem nada a ver com a sua pergunta sobre cursos sobre IPv6, mas sera que nao seria melhor trocar o nome que voce configurou no seu MUA (Eudora ou Netscape) para retirar os acentos? Eles ficam horriveis... Abraco Andre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 22 11:47:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23408; Wed, 22 May 96 11:47:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23402; Wed, 22 May 96 11:47:42 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14057; Wed, 22 May 1996 11:44:36 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA16622; Wed, 22 May 1996 11:44:25 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id OAA15384; Wed, 22 May 1996 14:33:34 -0400 (EDT) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA24370; Wed, 22 May 1996 14:33:02 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id OAA02812; Wed, 22 May 1996 14:38:02 GMT Message-Id: <199605221438.OAA02812@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: bmanning@isi.edu Cc: paul@vix.com (Paul A Vixie), ipng@sunroof.eng.sun.com Subject: (IPng 1791) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P. In-Reply-To: Your message of "Wed, 22 May 1996 10:51:12 MST." <199605221751.AA19616@zed.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 May 1996 14:37:57 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mapped (::FFFF:1.2.3.4) IPv4 address are only used when talking to IPv4 systems. They mat or may not be running IPv6 but it does not matter. To you, they are simply an IPv4 system that you will be talking to over IPv4. There is no way for the remote system to know that you are coming from an IPv6 system nor does it care (since it is an IPv4 system). In fact, you can use Mapped IPv6 addresses on an IPv4 system which implements only the IPv6 BSD API but there is no real IPv6 protocol code. (I have diffs for FreeBSD which does exactly this). -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 22 13:27:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23539; Wed, 22 May 96 13:27:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23533; Wed, 22 May 96 13:26:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA04809; Wed, 22 May 1996 13:23:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA20217; Wed, 22 May 1996 13:23:34 -0700 Received: from munin.fnal.gov ("port 4655"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I50EPJMWC6001ZF8@FNAL.FNAL.GOV>; Wed, 22 May 1996 15:21:56 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id PAA04475; Wed, 22 May 1996 15:21:08 -0500 (CDT) Date: Wed, 22 May 1996 15:20:38 -0500 From: Matt Crawford Subject: (IPng 1792) Re: Courses In-Reply-To: "22 May 1996 14:46:27 -0300." <"Pine.LNX.3.91.960522144503.560A-100000"@tatui.insite.com.br> To: Andre Uratsuka Manoel Cc: =?iso-8859-1?Q?TBA_INFORM=C1TICA?= , ipng@sunroof.eng.sun.com Message-Id: <199605222021.PAA04475@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ ..., mas sera que nao seria melhor trocar o nome que voce > configurou no seu MUA (Eudora ou Netscape) para retirar os acentos? > Eles ficam horriveis... Acho que o endereco do homem de TBA fora escrito na forma estandardizada "quoted-printable". O meu MUA (exmh) me mostrou perfeito! Abraco, Matt _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 23 00:19:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23891; Thu, 23 May 96 00:19:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA23885; Thu, 23 May 96 00:18:46 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23984; Thu, 23 May 1996 00:15:39 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA29946; Thu, 23 May 1996 00:15:39 -0700 Received: by gw.home.vix.com id AAA27274; Thu, 23 May 1996 00:15:37 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA26844; Thu, 23 May 1996 00:15:36 -0700 Message-Id: <9605230715.AA26844@wisdom.home.vix.com> To: internet-drafts@ietf.cnri.reston.va.us Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1793) draft-vixie-ipng-ipv4ptr-00.txt Date: Thu, 23 May 1996 00:15:36 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IP: Next Generation Area Paul Vixie (ISC) INTERNET-DRAFT May, 1996 Reverse Name Lookups of Encapsulated IPv4 Addresses in IPv6 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract [RFC1884] specified two IPv6 address forms that encapsulated IPv4 addresses. [RFC1886] specified a new DNS RR type (AAAA) to map domain names to IPv6 addresses, and also specified the form of the PTR RR owner name used to map IPv6 addresses back to the domain name of that host or interface. This memo amends [RFC1886] and gives two exceptions to its rules regarding PTR RR owner name correspondance to IPv6 addresses. Specifically, the two IPv4 encapsulation methods are exempted from [RFC1886]'s nybble mapping, and are made subject to the appropriate rules from [RFC1035] and [RFC1101]. Expires November 1996 [Page 1] INTERNET-DRAFT IPV6 PTR May 1996 1 - Overview 1.1. In [RFC1884 2.4.4] we see that addresses of the form ::D.D.D.D (which means the first 96 bits of the address are binary zero, and the last 32 bits are an IPv4 address) are used to ``tunnel IPv6 packets over IPv4 routing infrastructure.'' Later in [ibid] we see that addresses of the form ::FFFF:D.D.D.D (that is, 80 ``zero'' bits, 16 ``one'' bits, and an IPv4 address) are used to ``represent the addresses of IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses.'' 1.2. In [RFC1886 2.5] we see that an inverse name lookup for an IPv6 address is done by reversing the nybbles, formatting them as hexadecimal ASCII, and using each as a DNS label under the domain IP6.INT. Thus, to find the name associated with address ``4321:0:1:2:3:4:567:89ab,'' one would search for a PTR RR at the name: b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT 1.3. This leaves open the question of how to do inverse name lookups on the two IPv6 address forms which actually describe IPv4 endpoints. Should a resolver look under the IP6.INT for a nybble wise name, or under IN-ADDR.ARPA for a byte wise name? Due to format differences, there is no data oriented solution (such as CNAME RRs or replicate NS RRs) available to simply make a union in the namespace so that it does not matter which query name is used. 1.4. This memo recommends that the two IPv6 address forms which encapsulate IPv4 addresses shall follow the usual IPv6 inverse naming rules (i.e., IN-ADDR.ARPA). It is the author's view that inverse naming authority and address allocation authority must always be delegated together, and that any IPv4 address, no matter what context it is used in, has a single correct PTR RRset denoting the name(s) of the host or interface to which that address is bound. Expires November 1996 [Page 2] INTERNET-DRAFT IPV6 PTR May 1996 2 - Detail 2.1. For a mapped or tunnelled IPv4 address represented in IPv6 notation, inverse name lookups are to be done by stripping off the first 96 bits of the address, and using the last 32 bits as a raw IPv4 address. From [RFC1884]: IPv6-Tunnelled IPv4 Address | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|0000| IPv4 address | +--------------------------------------+----+---------------------+ IPv6-Mapped IPv4 Address | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+ 2.2. The encapsulated 32 bit IPv4 is to be broken down into four octets, and these octets are reversed, formatted in decimal ASCII, and used as labels under the IN-ADDR.ARPA domain. IPv4 Address | 8 bits | 8 bits | 8 bits | 8 bits | +----------------+----------------+----------------+----------------+ | Octet1 | Octet2 | Octet3 | Octet4 | +----------------+----------------+----------------+----------------+ IN-ADDR.ARPA Owner Name . . . . IN-ADDR . ARPA 2.3. A normal DNS query for a PTR RR is done. If the response contains an RRset matching the owner name and PTR type, then the RDATA(s) of these RRs are the names associated with the hosts or interfaces using the IPv4 address corresponding to this owner name. Multiple RRs can be present in the response PTR RRset, if this address is reachable by more than one A RR name. Thus, A RRs and PTR RRs are symmetric, while CNAME aliases are single ended. Expires November 1996 [Page 3] INTERNET-DRAFT IPV6 PTR May 1996 3 - Example IPv6 Address PTR Owner Name -------------------------------------------------- ::13.1.68.3 3.68.1.13.IN-ADDR.ARPA ::FFFF:129.144.52.38 38.52.144.129.IN-ADDR.ARPA 4 - Security Considerations None. 5 - References [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification,'' RFC 1035, USC/Information Sciences Institute, November 1987. [RFC1101] P. Mockapetris, ``DNS Encoding of Network Names and Other Types,'', RFC 1101, USC/Information Sciences Institute, April 1898. [RFC1884] R. Hinden, S. Deering, ``IP Version 6 Addressing Architecture,'' RFC 1884, Ipsilon Networks and Xerox PARC, December, 1995. [RFC1886] S. Thomson, C. Huitema, ``DNS Extensions to support IP version 6,'' RFC 1886, Bellcore and INRIA, December 1995. 6 - Acknowledgements The mailing list was instrumental in crystallizing the views presented in this document. 7 - Author's Address Paul Vixie Internet Software Consortium Star Route Box 159A Woodside, CA 94062 +1 415 747 0204 Expires November 1996 [Page 4] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 23 01:24:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24006; Thu, 23 May 96 01:24:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24000; Thu, 23 May 96 01:23:46 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27753; Thu, 23 May 1996 01:20:39 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA08441; Thu, 23 May 1996 01:20:38 -0700 Received: by gw.home.vix.com id BAA02742; Thu, 23 May 1996 01:20:37 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA27727; Thu, 23 May 1996 01:20:36 -0700 Message-Id: <9605230820.AA27727@wisdom.home.vix.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1794) Jun-ichiro Itoh: Re: draft-vixie-ipng-ipv4ptr-00.txt Date: Thu, 23 May 1996 01:20:32 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ooops. I'll correct this in the next rev. Thank you, Itoh-san. ------- Forwarded Message To: Paul A Vixie Subject: Re: (IPng 1793) draft-vixie-ipng-ipv4ptr-00.txt Date: Thu, 23 May 1996 17:11:18 +0900 From: Jun-ichiro Itoh Hello, this is Jun Itoh. i found a typo in your draft. > 1.4. This memo recommends that the two IPv6 address forms which > encapsulate IPv4 addresses shall follow the usual IPv6 inverse naming ~~~~IPv4 > rules (i.e., IN-ADDR.ARPA). It is the author's view that inverse naming > authority and address allocation authority must always be delegated > together, and that any IPv4 address, no matter what context it is used > in, has a single correct PTR RRset denoting the name(s) of the host or > interface to which that address is bound. Jun-ichiro Itoh itojun@csl.sony.co.jp ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 23 01:46:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24029; Thu, 23 May 96 01:46:39 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24023; Thu, 23 May 96 01:46:25 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA28880; Thu, 23 May 1996 01:43:19 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA11137; Thu, 23 May 1996 01:43:09 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id KAA10466; Thu, 23 May 1996 10:42:11 +0200 (MET DST) Received: from givry.inria.fr (localhost.inria.fr [127.0.0.1]) by givry.inria.fr (8.6.10/8.6.6) with ESMTP id KAA26586; Thu, 23 May 1996 10:40:55 +0200 Message-Id: <199605230840.KAA26586@givry.inria.fr> From: Francis Dupont To: bmanning@isi.edu Cc: paul@vix.com, ipng@sunroof.eng.sun.com Subject: (IPng 1795) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of Tue, 21 May 1996 09:40:45 PDT. <199605211640.AA18685@zed.isi.edu> Date: Thu, 23 May 1996 10:37:07 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Hum... IPv4 addresses are 32 bits, yes? ::FFFF:I.P.V.4 is more than 32 bits, yes? so is ::FFFF:I.P.V.4 a real, 32bit IPv4 address? I'd say no. It is mapped to and treated like one in a transition environment, but it is -not- a IPv4 address, just a cute faux. Use IP6.INT. => ::FFFF:I.P.V.4 is an IPv4 address in an IPv6 syntax used only by the IPv6 API (today you can't have it in a packet on a wire). Are you volunteer for the management of the 10 million RR zone f.f.f.f.0.0....0.ip6.int which is the in-addr.arpa zone in another syntax? Don't joke! Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 23 03:07:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24114; Thu, 23 May 96 03:07:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24108; Thu, 23 May 96 03:06:53 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02798; Thu, 23 May 1996 03:03:45 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA22175; Thu, 23 May 1996 03:03:38 -0700 Received: (from roque@localhost) by oberon (8.6.6.Beta9/8.6.6.Beta9) id LAA01598; Thu, 23 May 1996 11:02:16 +0100 Date: Thu, 23 May 1996 11:02:16 +0100 From: Pedro Roque Marques Message-Id: <199605231002.LAA01598@oberon> To: bmanning@ISI.EDU Cc: paul@vix.com (Paul A Vixie), ipng@sunroof.eng.sun.com Subject: (IPng 1796) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P. In-Reply-To: <199605221751.AA19616@zed.isi.edu> References: <199605221751.AA19616@zed.isi.edu> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "bmanning" == bmanning writes: bmanning> Much better to "encourage" this type of behaviour: bmanning> foo.example.org in a 192.0.2.255 bmanning> 255.2.0.192.in-addr.arpa. in ptr foo.example.org bmanning> bar.example.org in aaaa ::FFFF:192.0.2.255 bmanning> 255.2.0.192.f.f.f.f.f.f.f.f.ip6.int. in ptr bar.example.org IPv4-mapped addresses should not be allowed in quad-A records. ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 23 06:35:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24176; Thu, 23 May 96 06:35:53 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24170; Thu, 23 May 96 06:35:34 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13701; Thu, 23 May 1996 06:32:27 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA21746; Thu, 23 May 1996 06:32:27 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa16659; 23 May 96 9:25 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1797) I-D ACTION:draft-ietf-ipngwg-fddi-ntwrks-04.txt Date: Thu, 23 May 96 09:25:18 -0400 Message-Id: <9605230925.aa16659@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : A Method for the Transmission of IPv6 Packets over FDDI Networks Author(s) : M. Crawford Filename : draft-ietf-ipngwg-fddi-ntwrks-04.txt Pages : 6 Date : 05/22/1996 This memo specifies the MTU and frame format for transmission of IPv6 [IPV6] packets on FDDI networks, including a method for MTU determination in the presence of 802.1d bridges to other media. It also specifies the method of forming IPv6 link-local addresses on FDDI networks and the content of the Source/Target Link-layer Address option used the the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement messages described in [DISC], when those messages are transmitted on an FDDI network. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-fddi-ntwrks-04.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-fddi-ntwrks-04.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-fddi-ntwrks-04.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960522100514.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-fddi-ntwrks-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-fddi-ntwrks-04.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960522100514.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 23 13:37:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24549; Thu, 23 May 96 13:37:17 PDT Received: from pacific.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24486; Thu, 23 May 96 12:26:34 PDT Received: from frontier.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA19512; Thu, 23 May 1996 12:23:26 -0700 Received: by frontier.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA12769; Thu, 23 May 1996 12:23:16 -0700 Date: Thu, 23 May 1996 12:23:16 -0700 From: therbert@caribe (Tom Herbert) Message-Id: <199605231923.MAA12769@frontier.eng.sun.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1798) Proposed socket option X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The sending/receiving interface specification has been withdrawn from the "Basic Socket Interface Extensions for IPv6", however, in implementing a router discovery networking daemon and RIPv6 in a daemon, we found that a mechanism was needed for specifying an out going interface and determining the incoming interface for link local and multicast packets. To support this we created the IPV6_BOUND_IF socket option (bind the socket to an interface). This is similar in use to IPV6_MULTICAST_IF, except that it specifies the outgoing interface for packets sent on the socket and a receiving interface for the socket. I propose that such an option be included in the API, it's straightforward and would facilitate development of similar network daemons. Tom ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 23 13:41:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24602; Thu, 23 May 96 13:41:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24596; Thu, 23 May 96 13:41:30 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18704; Thu, 23 May 1996 13:38:19 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA13810; Thu, 23 May 1996 13:38:14 -0700 Received: from munin.fnal.gov ("port 1202"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I51TK2PIOY0021U6@FNAL.FNAL.GOV>; Thu, 23 May 1996 15:38:13 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id PAA12968; Thu, 23 May 1996 15:37:24 -0500 (CDT) Date: Thu, 23 May 1996 15:37:23 -0500 From: Matt Crawford Subject: (IPng 1799) Re: Proposed socket option In-Reply-To: "23 May 1996 12:23:16 PDT." <"199605231923.MAA12769"@frontier.eng.sun.com> To: Tom.Herbert@Eng (Tom Herbert) Cc: ipng@sunroof.eng.sun.com Message-Id: <199605232037.PAA12968@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ To support this we created the IPV6_BOUND_IF socket option (bind the socket > to an interface). This is similar in use to IPV6_MULTICAST_IF, except that > it specifies the outgoing interface for packets sent on the socket and a > receiving interface for the socket. What should happen if a packet comes in which matches the PCB for your socket, except that the incoming interface is wrong? _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 23 15:20:53 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24753; Thu, 23 May 96 15:20:53 PDT Received: from pacific.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24747; Thu, 23 May 96 15:20:35 PDT Received: from frontier.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA24465; Thu, 23 May 1996 15:17:29 -0700 Received: by frontier.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA13573; Thu, 23 May 1996 15:17:17 -0700 Date: Thu, 23 May 1996 15:17:17 -0700 From: therbert@caribe (Tom Herbert) Message-Id: <199605232217.PAA13573@frontier.eng.sun.com> To: crawdad@FNAL.GOV Subject: (IPng 1800) Re: Proposed socket option Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From owner-ipng@sunroof Thu May 23 13:41:42 1996 > Date: Thu, 23 May 1996 15:37:23 -0500 > From: Matt Crawford > Subject: (IPng 1799) Re: Proposed socket option > To: Tom.Herbert@Eng (Tom Herbert) > Cc: ipng@sunroof.eng.sun.com > Content-Transfer-Encoding: 7BIT > X-Face: > > To support this we created the IPV6_BOUND_IF socket option (bind the socket > > to an interface). This is similar in use to IPV6_MULTICAST_IF, except that > > it specifies the outgoing interface for packets sent on the socket and a > > receiving interface for the socket. > > What should happen if a packet comes in which matches the PCB for > your socket, except that the incoming interface is wrong? Packets are only sent up to a socket that is bound to an interface if they were received on the bound interface. In the case above, the packet would not be sent to that socket. We do this for all packets, but the real case we wanted to capture was a multihomed host receiving and relying to hosts when link local addresses (or multicast) are used in the source and destination. Tom ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 23 15:27:02 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24773; Thu, 23 May 96 15:27:02 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24767; Thu, 23 May 96 15:26:44 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA07251; Thu, 23 May 1996 15:23:36 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA17160; Thu, 23 May 1996 15:23:37 -0700 Received: by gw.home.vix.com id PAA27687; Thu, 23 May 1996 15:23:36 -0700 Date: Thu, 23 May 1996 15:23:36 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 1801) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P. Organization: Vixie Enterprises Message-Id: References: <199605231002.LAA01598@oberon> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: roque@di.fc.ul.pt's message of 23 May 1996 03:13:38 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk bmanning> bar.example.org in aaaa ::FFFF:192.0.2.255 pedro> IPv4-mapped addresses should not be allowed in quad-A records. I don't agree, for at least three reasons. First, there's no way to prevent it. Second, it is quite useful for testing IPv6 stacks, which universally use IPv4 infrastructure to get off-campus at this point. Third, there is no reason to try to prevent it. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 23 16:51:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24879; Thu, 23 May 96 16:51:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24873; Thu, 23 May 96 16:51:34 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20354; Thu, 23 May 1996 16:48:27 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA10279; Thu, 23 May 1996 16:47:51 -0700 Received: (from roque@localhost) by oberon (8.6.6.Beta9/8.6.6.Beta9) id AAA02890; Fri, 24 May 1996 00:47:00 +0100 Date: Fri, 24 May 1996 00:47:00 +0100 From: Pedro Roque Marques Message-Id: <199605232347.AAA02890@oberon> To: paul@vix.com (Paul A Vixie) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1802) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P. In-Reply-To: References: <199605231002.LAA01598@oberon> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Paul" == Paul A Vixie writes: bmanning> bar.example.org in aaaa ::FFFF:192.0.2.255 pedro> IPv4-mapped addresses should not be allowed in quad-A pedro> records. Paul> I don't agree, for at least three reasons. First, there's Paul> no way to prevent it. Second, it is quite useful for Paul> testing IPv6 stacks, which universally use IPv4 Paul> infrastructure to get off-campus at this point. Third, Paul> there is no reason to try to prevent it. The is a reason, i belive: an A pointer to d1.d2.d3.d4 and an AAAA pointer to ::ffff:d1.d2.d3.d4 are exactly the same information. This is redundant information that can lead to inconsistencies. What happens if the quad-A record exists and the A record doesn't ? do it mean that d1.d2.d3.d4 is still a valid IPv4 address to that host ? Should pure v4 stacks use it ? They mean exactly the same, that's why i believe that there should only one record present with this information, and it has to be the A record. I'm not understanding your second point: why is it useful ? if an host is using the ipv6 API shouldn't the resolver return the A records in mapped format to the application ? If not i withdraw my opinion, but it would seam the easiest operation method to me since otherwise we are requiring everybody to update their DNS so that apps that only use the INET6 API can talk to their hosts. As for your first point: if you would agree with me I'm sure bind would at least give a warning message to the administrator ;-) That would most likely avoid it. ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 23 16:56:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24895; Thu, 23 May 96 16:56:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24889; Thu, 23 May 96 16:56:43 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21278; Thu, 23 May 1996 16:53:35 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA12305; Thu, 23 May 1996 16:53:33 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id TAA08313; Thu, 23 May 1996 19:47:09 -0400 (EDT) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA11150; Thu, 23 May 1996 19:46:38 -0400 Received: from localhost (localhost [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id TAA12996; Thu, 23 May 1996 19:51:33 GMT Message-Id: <199605231951.TAA12996@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: Tom.Herbert@Eng (Tom Herbert) Cc: crawdad@fnal.gov, ipng@sunroof.eng.sun.com Subject: (IPng 1803) Re: Proposed socket option In-Reply-To: Your message of "Thu, 23 May 1996 15:17:17 MST." <199605232217.PAA13573@frontier.eng.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 May 1996 19:51:28 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We do this a bit differently. You can specifiy a socket option which enables the interface index being returned as control data via recvmsg(). We are writing a BSD advanced API draft for those systems which use a BSD4.4 socket framework. It makes heavy use of ancillary control data. It also discusses those needed by gated or routed. -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 23 17:14:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24925; Thu, 23 May 96 17:14:36 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA24919; Thu, 23 May 96 17:14:16 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24137; Thu, 23 May 1996 17:11:09 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA16470; Thu, 23 May 1996 17:11:07 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.4/8.6.12) with SMTP id UAA27213; Thu, 23 May 1996 20:10:33 -0400 (EDT) Message-Id: <199605240010.UAA27213@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Pedro Roque Marques Cc: paul@vix.com (Paul A Vixie), ipng@sunroof.eng.sun.com Subject: (IPng 1804) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P. In-Reply-To: Your message of "Fri, 24 May 1996 00:47:00 BST." <199605232347.AAA02890@oberon> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 23 May 1996 20:10:24 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro Roque Marques writes: > >>>>> "Paul" == Paul A Vixie writes: > > bmanning> bar.example.org in aaaa ::FFFF:192.0.2.255 > pedro> IPv4-mapped addresses should not be allowed in quad-A > pedro> records. > > Paul> I don't agree, for at least three reasons. First, there's > Paul> no way to prevent it. Second, it is quite useful for > Paul> testing IPv6 stacks, which universally use IPv4 > Paul> infrastructure to get off-campus at this point. Third, > Paul> there is no reason to try to prevent it. I would like to say at this juncture that I completely agree with Paul on this. > The is a reason, i belive: > an A pointer to d1.d2.d3.d4 and an AAAA pointer to ::ffff:d1.d2.d3.d4 > are exactly the same information. This is redundant information that > can lead to inconsistencies. The fact that A records and PTR records are separate also leads to inconsistancies. There isn't always a PTR for every A. Should we therefore go to INVQs or similar abortions? Yes, inconsistancies can arise, but we've lived with them. (The best way to deal with them is of course to generate your zone files automatically from a database, but thats another story.) > What happens if the quad-A record exists > and the A record doesn't ? Not much harm so far as I can tell. > Should pure v4 stacks use it ? They won't since their apps don't know about AAAA. It is not a problem. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 23 22:23:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25105; Thu, 23 May 96 22:23:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25099; Thu, 23 May 96 22:23:30 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21247; Thu, 23 May 1996 22:20:22 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA02509; Thu, 23 May 1996 22:20:21 -0700 Received: by gw.home.vix.com id WAA21559; Thu, 23 May 1996 22:20:18 -0700 Date: Thu, 23 May 1996 22:20:18 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 1805) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P. Organization: Vixie Enterprises Message-Id: References: <199605232347.AAA02890@oberon> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: roque@di.fc.ul.pt's message of 23 May 1996 17:00:27 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The is a reason, i belive: >an A pointer to d1.d2.d3.d4 and an AAAA pointer to ::ffff:d1.d2.d3.d4 >are exactly the same information. This is redundant information that >can lead to inconsistencies. What happens if the quad-A record exists >and the A record doesn't ? do it mean that d1.d2.d3.d4 is still a >valid IPv4 address to that host ? Should pure v4 stacks use it ? >They mean exactly the same, that's why i believe that there should >only one record present with this information, and it has to be the A >record. In point of fact, this is the reason I added the RES_USE_INET6 option to BIND 4.9.4. If set, the result of a gethostbyname() or gethostbyaddr() will always have h_length==16 and h_addrtype==AF_INET6, even if all gethostbyname() could find were A RRs (no AAAAs available) or if gethostbyaddr() was passed in a "type" of AF_INET. If I did the right thing, then I will write a draft describing that behaviour and I will add text to my ipv6ptr draft saying that "oh by the way, there should be no AAAA RRs with ::FFFF:i.p.v.4 addresses in them since A RRs will fulfill the same function on all IPv6 hosts which follow paul's other draft." If we fail to get agreement on that basic point, then there's no way we can mandate the nonexistence of mapped AAAA RR's. If we can get agreement on this point, I will happily add a syslog(LOG_WARN) to BIND's db_load.c so that primary and secondary zones containing mapped AAAA RRs will be very irritating for those who try to make them. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 24 07:02:19 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25504; Fri, 24 May 96 07:02:19 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25491; Fri, 24 May 96 07:01:49 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20798; Fri, 24 May 1996 06:58:41 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA07823; Fri, 24 May 1996 06:58:40 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18668; 24 May 96 9:13 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1807) I-D ACTION:draft-ietf-ipngwg-pmtuv6-03.txt Date: Fri, 24 May 96 09:13:32 -0400 Message-Id: <9605240913.aa18668@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : Path MTU Discovery for IP version 6 Author(s) : J. McCann, S. Deering, J. Mogul Filename : draft-ietf-ipngwg-pmtuv6-03.txt Pages : 16 Date : 05/23/1996 This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC-1191, which describes Path MTU Discovery for IP version 4. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-pmtuv6-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-pmtuv6-03.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-pmtuv6-03.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960523144137.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-pmtuv6-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-pmtuv6-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960523144137.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 24 07:02:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25503; Fri, 24 May 96 07:02:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25490; Fri, 24 May 96 07:01:48 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20794; Fri, 24 May 1996 06:58:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA07821; Fri, 24 May 1996 06:58:39 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18647; 24 May 96 9:13 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng 1806) I-D ACTION:draft-ietf-ipngwg-nsap-ipv6-01.txt Date: Fri, 24 May 96 09:13:21 -0400 Message-Id: <9605240913.aa18647@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Note: This revision reflects comments received during the last call period. Title : OSI NSAPs and IPv6 Author(s) : J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd Filename : draft-ietf-ipngwg-nsap-ipv6-01.txt Pages : 19 Date : 05/23/1996 This document recommends that network implementors who have planned or deployed an OSI NSAP addressing plan, and who wish to deploy or transition to IPv6, should redesign a native IPv6 addressing plan to meet their needs. However, it also defines a set of mechanisms for the support of OSI NSAP addressing in an IPv6 network. These mechanisms are the ones that MUST be used if such support is required. This document also defines a mapping of IPv6 addresses within the OSI address format, should this be required. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-nsap-ipv6-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-nsap-ipv6-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-nsap-ipv6-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960523112140.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-nsap-ipv6-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-nsap-ipv6-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960523112140.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 24 07:13:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25525; Fri, 24 May 96 07:13:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25519; Fri, 24 May 96 07:12:53 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22032; Fri, 24 May 1996 07:09:45 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA10430; Fri, 24 May 1996 07:09:37 -0700 Received: from dos-lan.cs.up.ac.za by inet.up.ac.za with esmtp (Smail3.1.29.1 #5) id m0uMxZy-0001bnC; Fri, 24 May 96 16:10 WET Received: from DOS-LAN/SpoolDir by dos-lan.cs.up.ac.za (Mercury 1.21); 24 May 96 16:01:07 +0200 Received: from SpoolDir by DOS-LAN (Mercury 1.21); 24 May 96 16:00:51 +0200 From: "Naveed Kashif" Organization: University of Pretoria To: ipng@sunroof.eng.sun.com Date: Fri, 24 May 1996 16:00:46 CAT-2 Subject: (IPng 1808) Re: Implementation of IPng Priority: normal X-Mailer: Pegasus Mail v3.22 Message-Id: <1AF9D1D231E@dos-lan.cs.up.ac.za> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Would it be possible for any body to guide me to implement the IPng. I would like to implement the IPng in our lab and do some performance measurments as compared to IP ver 4. I need a documentation or guidlines about it. Regards Naveed ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 24 07:23:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25565; Fri, 24 May 96 07:23:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25549; Fri, 24 May 96 07:22:39 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23087; Fri, 24 May 1996 07:19:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA12938; Fri, 24 May 1996 07:19:27 -0700 Received: from dxcoms.cern.ch by dxmint.cern.ch id AA23625; Fri, 24 May 1996 16:19:09 +0200 Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA09762; Fri, 24 May 1996 16:18:50 +0200 Message-Id: <9605241418.AA09762@dxcoms.cern.ch> Subject: (IPng 1809) NSAP draft- explanation To: ipng@sunroof.eng.sun.com (IPv6 List), nosi@sunroof.eng.sun.com (Nosi List) Date: Fri, 24 May 1996 16:18:50 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: iana@isi.edu X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPv6 folks, and NOSI folks, cc IANA This is to explain the re-issuing of the IPv6 NSAP draft as draft-ietf-ipngwg-nsap-ipv6-01.txt. The previous version was approved by the IPNG WG, and by the IESG, for publication as an Experimental RFC. However, the IANA subsequently objected that the draft consumed 100% of the address space allocated to IANA by ISO in the form of an ICD code. We have therefore been negotiating with ISO/IEC JTC1/SC6, coordinated with ITU-T. As a result, an AFI code has been reserved and a draft to allocate it formally is in progress within SC6. The revised Internet Draft reflects this change from an ICD code to an AFI code, which gives the IANA two extra bytes to allocate, if necessary at some time in the future. The changes are exclusively in Section 6 of the draft, and the only change "on the wire" is that in the address format concerned, the first 3 bytes (sorry, octets) have a different constant value. We believe that this is not a substantive change and does not need a new last call, but that is for the WG Chair to decide. Regards, Brian Carpenter + co-authors ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 24 07:43:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25684; Fri, 24 May 96 07:43:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25674; Fri, 24 May 96 07:42:45 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25431; Fri, 24 May 1996 07:39:36 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA20711; Fri, 24 May 1996 07:39:34 -0700 Received: from pferguso-pc.cisco.com (c1robo16.cisco.com [171.68.13.16]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id HAA12027; Fri, 24 May 1996 07:39:36 -0700 Message-Id: <199605241439.HAA12027@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 24 May 1996 10:39:04 -0400 To: "Naveed Kashif" From: Paul Ferguson Subject: (IPng 1810) Re: Implementation of IPng Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 04:00 PM 5/24/96 CAT-2, Naveed Kashif wrote: > >Would it be possible for any body to guide me to implement the IPng. > >I would like to implement the IPng in our lab and do some performance >measurments as compared to IP ver 4. I need a documentation or >guidlines about it. > >Regards >Naveed See: http://playground.sun.com/pub/ipng/html/ipng-implementations.html - paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 24 09:38:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25921; Fri, 24 May 96 09:38:29 PDT Received: from pacific.eng.sun.com by sunroof.eng.sun.com (4.1/SMI-4.1) id AA25884; Fri, 24 May 96 09:18:02 PDT Received: from bobo.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA02838; Fri, 24 May 1996 09:14:54 -0700 Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10111; Fri, 24 May 1996 09:14:37 -0700 Date: Fri, 24 May 1996 09:14:37 -0700 From: nordmark@pacific-86 (Erik Nordmark) Message-Id: <199605241614.JAA10111@bobo.eng.sun.com> To: paul@vix.com Subject: (IPng 1811) Re: Speaking of RFC 1884, I have two requests for clarification Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree that the document seems underspecified in this area. > 790> One notation for internet host addresses commonly used divides the > 790> 32-bit address into four 8-bit fields and specifies the value of each > 790> field as a decimal number with the fields separated by periods. For > 790> example, the internet address of ISIF is 010.020.000.052. > > I could live with this as the definition for [RFC1884 2.2 3]'s "standard IPv4 > representation" since I know of no software that would parse it the wrong way. > (The leading 0's had me going for a minute there, I thought those were octal > numbers or that BIND might have treated them as such, but all is well.) The inet_addr function in 4.3 and 4.4 BSD does indeed treat leading zeros as octal numbers as shown by this example on 4.4: % /sbin/ping -v 010.020.000.052 PING 010.020.000.052 (8.16.0.42): 56 data bytes That function also handles hex numbers preceeded by '0x' in the "dotted decimal" format. So when specifying the details of the dotted decimal format I think it would make sense to restrict the format to not have leading zeros. This would avoid unneeded changes in lots of implementations. Erik ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 24 12:51:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26158; Fri, 24 May 96 12:51:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26152; Fri, 24 May 96 12:51:23 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17264; Fri, 24 May 1996 12:48:14 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA05573; Fri, 24 May 1996 12:48:13 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3283; Fri, 24 May 96 15:48:01 EDT Received: by RTP (XAGENTA 4.0) id 5121; Fri, 24 May 1996 15:48:04 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20585; Fri, 24 May 1996 15:48:01 -0400 Message-Id: <9605241948.AA20585@cichlid.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1812) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of "Wed, 22 May 1996 08:18:34 BST." <9605220718.AA27525@shand.reo.dec.com> Date: Fri, 24 May 1996 15:48:00 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pedro Roque Marques writes: >I believe careful network administrators will configure their networks >as to have all anycast address on different subnet ids than their >anycast addresses so that at least they can distinguish them ^^^^^^^ >syntacticly. I think "unicast" is meant above. (Mike Shand REO2 F/D9 DTN:830-4424) writes: >I think configuring anycast addresses to be a "separate subnet" makes >sense. The thought of an anycast address which has scope wider than a >single physical LAN, but has an address which corresponds to the subnet >on a single LAN seems very confusing. I'm not sure I understand what is being described above. Are you saying that the prefixes used for routing to unicast addresses (i.e., normal routing) will always be different from prefixes that cover anycast addresses? Seems to me that this is precisely the wrong way to go, because it means extra routing information (i.e., the anycast prefixes and/or anycast addresses themselves) gets propagated through the routing system. In contrast, if the anycast addresses differ from unicast addresses only in the host/local part of the address, one gets "free" routing to anycast addresses without the need to inject extra routing prefixes into the system. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 24 15:42:05 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26460; Fri, 24 May 96 15:42:05 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26450; Fri, 24 May 96 15:41:33 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15433; Fri, 24 May 1996 15:38:23 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA22161; Fri, 24 May 1996 15:38:24 -0700 Received: by gw.home.vix.com id PAA21574; Fri, 24 May 1996 15:38:23 -0700 Date: Fri, 24 May 1996 15:38:23 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 1813) Re: Speaking of RFC 1884, I have two requests for clarification Organization: Vixie Enterprises Message-Id: References: <199605241614.JAA10111@bobo.eng.sun.com> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: nordmark@pacific-86.Eng.Sun.COM's message of 24 May 1996 09:46:46 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >The inet_addr function in 4.3 and 4.4 BSD does indeed treat leading >zeros as octal numbers as shown by this example on 4.4: >% /sbin/ping -v 010.020.000.052 >PING 010.020.000.052 (8.16.0.42): 56 data bytes > >That function also handles hex numbers preceeded by '0x' in >the "dotted decimal" format. Absolutely true. >So when specifying the details of the dotted decimal format >I think it would make sense to restrict the format to not have leading >zeros. This would avoid unneeded changes in lots of implementations. Nowhere have I specified these details, but I will watch carefully to see that whoever does specify them leaves out all special processing such as that being done by BSD's inet_aton() and the older inet_addr() functions. This is a very strong case of introducing errors by being overly liberal. Your example above is a precise depiction of what can go wrong. I think that the original Assigned Numbers draft should be our guide to acceptable dotted quad formats, and if the examples therefrom will not work on BSD, then BSD is wrong. Any standards work done by the IETF ought to prefer simplicity and early use. And note that BIND's inet_pton() treats everything as decimal and has no 0x or 0(octal) or less-than-three-dots processing. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 24 23:36:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26647; Fri, 24 May 96 23:36:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26641; Fri, 24 May 96 23:36:04 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA16992; Fri, 24 May 1996 23:32:55 -0700 Received: by mercury.Sun.COM (Sun.COM) id XAA17187; Fri, 24 May 1996 23:32:52 -0700 Received: from jb.utm.my (jb.utm.my [161.139.16.2]) by jaring.my (8.7.5/8.7.1) with SMTP id OAA25670 for ; Sat, 25 May 1996 14:32:43 +0800 (MYT) Received: from fsksmjb.utm.my by jb.utm.my (AIX 3.2/UCB 5.64/UTMnet) id AA08239; Sat, 25 May 1996 14:32:23 +0800 Received: by fsksmjb.utm.my (5.0/SMI-SVR4) id AA22097; Sat, 25 May 1996 14:33:30 --800 Date: Sat, 25 May 1996 14:33:30 --800 From: maznah@fsksmjb.utm.my (Maznah Kamat) Message-Id: <9605250633.AA22097@fsksmjb.utm.my> Content-Type: text Apparently-To: ipng@sunroof.eng.Sun.COM Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk How would an ipv6 node interoperate with an ipv4 application, I heard the address mapping can be done, but wouldn't it degrade the performance of the system? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat May 25 22:35:14 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26987; Sat, 25 May 96 22:35:14 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA26981; Sat, 25 May 96 22:35:02 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA00885; Sat, 25 May 1996 22:31:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA01314; Sat, 25 May 1996 22:31:52 -0700 Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa00711; 26 May 96 1:31:22 EDT To: ipng@sunroof.eng.sun.com From: Dave Johnson Subject: (IPng 1814) IPv6 for NetBSD? Date: Sun, 26 May 96 01:31:20 -0400 Message-Id: <709.833088680@CHIMAY.MACH.CS.CMU.EDU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We are interested in setting up some machines running IPv6 in order to begin playing with implementation of Mobile IP for IPv6. Since we are already running NetBSD and have done a Mobile IP for IPv4 implementation in NetBSD, we'd like to also do this under NetBSD (although FreeBSD would be possible). I'm looking for some advice from others who may already be running IPv6 under NetBSD. In particular, are you running the NRL code or the INRIA code (or some other code?), and under what version of NetBSD? What kind of hacking was necessary to get it integrated? Thanks... Dave -- David B. Johnson E-mail: dbj@cs.cmu.edu Assistant Professor Home page: http://www.cs.cmu.edu/~dbj/ Computer Science Department Phone: (412) 268-7399 Carnegie Mellon University Fax: (412) 268-5576 5000 Forbes Avenue Pittsburgh, PA 15213-3891 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 26 20:22:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27347; Sun, 26 May 96 20:22:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27341; Sun, 26 May 96 20:22:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02766; Sun, 26 May 1996 20:18:56 -0700 Received: by mercury.Sun.COM (Sun.COM) id UAA02591; Sun, 26 May 1996 20:18:56 -0700 From: bound@zk3.dec.com Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id XAA23387; Sun, 26 May 1996 23:14:27 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA13843; Sun, 26 May 1996 23:13:56 -0400 Message-Id: <9605270313.AA13843@fwasted.zk3.dec.com> To: bmanning@ISI.EDU Cc: paul@vix.com (Paul A Vixie), ipng@sunroof.eng.sun.com Subject: (IPng 1815) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of "Tue, 21 May 96 06:51:06 PDT." <199605211351.AA18316@zed.isi.edu> Date: Sun, 26 May 96 23:13:55 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> >> Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have different >> PTR locations. We kinda need to know whether both are under IP6.INT or >> whether both are under IN-ADDR.ARPA or whether they're split in some way. > > My reading of the specs indicate that any IPv6 format should > resolve its PTR record in the IP6.INT domain. The case you > use above would be in two seperate places in the IP6.INT > ptr tree. Hold on folks. I think there is serious confusion here. ::FFFF:I.P.V.4 Is a MAPPED ADDRESS. Its not a valid address to have in a PTR location or as an AAAA Record. Its created when one wants to use an IPv4 address for a node that maps to an IPv6 address internally to the implementation. I don't think it should be seen externally anywhere on the internet, Internet, or even in /etc/hosts. I am on vacation until June 3rd but was checking mail. Please read the Transition spec before much more discussion takes place. Its defined in the address arch spec but explained more clearly in the transition spec but not much. In our implementation on DUNIX its used to permit the kernel to treat IPv4 addresses as 16byte thingees whether the socket was opened with the old AF_INET or with the new AF_INET6. It existed where the IPv4 exists today. Its a "fake" address type not a real one IMHO. /jim /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 26 20:26:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27367; Sun, 26 May 96 20:26:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27361; Sun, 26 May 96 20:26:28 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02926; Sun, 26 May 1996 20:23:16 -0700 Received: by mercury.Sun.COM (Sun.COM) id UAA02994; Sun, 26 May 1996 20:23:17 -0700 From: bound@zk3.dec.com Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id XAA12318; Sun, 26 May 1996 23:17:40 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA13917; Sun, 26 May 1996 23:17:09 -0400 Message-Id: <9605270317.AA13917@fwasted.zk3.dec.com> To: bmanning@ISI.EDU Cc: Francis.Dupont@inria.fr (Francis Dupont), paul@vix.com, ipng@sunroof.eng.sun.com Subject: (IPng 1816) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of "Tue, 21 May 96 09:40:45 PDT." <199605211640.AA18685@zed.isi.edu> Date: Sun, 26 May 96 23:17:09 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bill and Kre are completely right. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 26 20:41:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27395; Sun, 26 May 96 20:41:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27389; Sun, 26 May 96 20:41:15 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03384; Sun, 26 May 1996 20:38:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id UAA03919; Sun, 26 May 1996 20:38:03 -0700 From: bound@zk3.dec.com Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id XAA10504; Sun, 26 May 1996 23:30:56 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA14328; Sun, 26 May 1996 23:30:04 -0400 Message-Id: <9605270330.AA14328@fwasted.zk3.dec.com> To: Pedro Roque Marques Cc: bmanning@ISI.EDU, Francis.Dupont@inria.fr (Francis Dupont), paul@vix.com, ipng@sunroof.eng.sun.com Subject: (IPng 1817) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of "Tue, 21 May 96 18:11:40 BST." <199605211711.SAA01909@oberon> Date: Sun, 26 May 96 23:30:04 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I've to agree with Francis here. For implementations ::FFFF:d.d.d.d is >a v4 address since socket operations performed with those addresses go >though v4 code. The bsd-api draft is clear about the fact that >implementations should have one instance of transport protocols >accessible by both APIs and hable to communicate with both network >protocols. Exactly. The mapped address is to achieve that design goal and on incoming messages too. Its not intended to be "stored" anywhere though. >If an app using INET6 binds to * a syn traveling in v4 will be >accepted to that port and the app will receive a mapped address in the >accept. The communication will then procced using IPv4... When the app >does gethostbyaddr it should get the ptr registred in in-addr.arpa >since the host it's talking to may be v4 only. It's the same >namespace, it should be the same naming authority. No not at all. I will try to talk in simple terms to solve this quickly as its really a gigantic misunderstanding of IPv6 addresses, the API spec, and more importantly transition. t v4 ---> (forget about syn this has to work for UDP too) to net layer map the addr to ::ffff.i.p.v.4 do what you want in your implementation as far as how its in the pcb or your flavor of transport data structure.... (again don't go down the rat hole of inpcb or tcppcb it does not matter)... if no connection awaiting treat it as IPv4 for AF_INET API if connection waiting: AF_INET ? AF_INET6 --> send to right api. gethostbyaddr_2() [for IPv6] or gethostbyaddr() [for IPv4] returns the right address. But ::ffff.i.p.v.4 does not exist its created if needed. If IPv6 API is used and its not found as AAAA record then you look for A record i.p.v.4 if your using AF_INET6 API or have some other transition scenario figured out then you make it "like" an IPv6 address via ffff. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun May 26 21:56:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27488; Sun, 26 May 96 21:56:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27482; Sun, 26 May 96 21:56:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06094; Sun, 26 May 1996 21:53:20 -0700 Received: by mercury.Sun.COM (Sun.COM) id VAA09778; Sun, 26 May 1996 21:53:19 -0700 From: bound@zk3.dec.com Received: from fwasted.zk3.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id AAA16454; Mon, 27 May 1996 00:49:36 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA06465; Mon, 27 May 1996 00:49:04 -0400 Message-Id: <9605270449.AA06465@fwasted.zk3.dec.com> To: Dave Johnson Cc: ipng@sunroof.eng.sun.com, qv@iol.unh.edu, thomas@netrix.lkg.dec.com Subject: (IPng 1818) Re: IPv6 for NetBSD? In-Reply-To: Your message of "Sun, 26 May 96 01:31:20 EDT." <709.833088680@CHIMAY.MACH.CS.CMU.EDU> Date: Mon, 27 May 96 00:49:03 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave, >We are interested in setting up some machines running IPv6 in order to >begin playing with implementation of Mobile IP for IPv6. Since we are >already running NetBSD and have done a Mobile IP for IPv4 implementation >in NetBSD, we'd like to also do this under NetBSD (although FreeBSD >would be possible). > >I'm looking for some advice from others who may already be running >IPv6 under NetBSD. In particular, are you running the NRL code or the >INRIA code (or some other code?), and under what version of NetBSD? >What kind of hacking was necessary to get it integrated? Have funding to port IPv6 to Alpha NETBSD and will be duplicating that port on Intel Freebsd. The port will be done by University of New Hampshire and us at Digital working on IPv6 Digital UNIX who will be working with UNH folks to port to those two platforms. I look for a usable stack by Dec 96 that has the important specs completed and the APIs. This code base will be completely unencumbered as its sources will be located at UNH. We will integrate Paul Vixie IPv6 BIND and Dyn Upd to DNS too as its ready and integrated with DHCPv6. As far as code used its being designed from scratch, of course we have been building IPv6 since the SIP days so I guess we will give UNH our view of the world architecturally. But it will not be based on INRIA or NRL code base, in fact some clear differences I believe will be quite apparent especially around transition. The project objective is to have a public domain version of IPv6 on Alpha NETBSD for the community to use and contribute to as it evolves. The reason for the Intel port is threefold, 1) nice to run the code on our laptops, 2) Intel Freebsd is a good client test machine for client/server models like Service Location, DHCPv6, and DNSINDv6, and 3) Intel FreeBSD would be a nice Mobile Agent to test with for IPv6 and deploy for use on the emerging 6bone. As far as integrating it thats not really a big deal if you have been working with the 4.4 model. For Digital UNIX we have so its not a problem. Maybe hooking up on doing mobile would be cool. I am "personally" leaning towards yours and Charlie Perkins IPv6 Mobile approach fyi, as I think it has a nice integration effect to the existing IPv4 work and takes advantage of the new features in IPv6 without reinventing a lot of new baggage like EIDs and such to solve the problem. I am pretty much out of it until June 3rd but if you want to contact Matt Thomas at Digital or Quaizar Vohra at UNH this week go for it and they can give you more status, until I get back (I cc'd them in the mail so you have their eaddr). /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 27 02:36:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27561; Mon, 27 May 96 02:36:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27555; Mon, 27 May 96 02:35:46 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17905; Mon, 27 May 1996 02:32:34 -0700 Received: by mercury.Sun.COM (Sun.COM) id CAA00686; Mon, 27 May 1996 02:32:33 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id JA11799; Mon, 27 May 1996 19:29:11 +1000 (from kre@munnari.OZ.AU) To: bound@zk3.dec.com Cc: bmanning@ISI.EDU, Francis.Dupont@inria.fr (Francis Dupont), paul@vix.com, ipng@sunroof.eng.sun.com Subject: (IPng 1819) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of "Sun, 26 May 1996 23:17:09 -0400." <9605270317.AA13917@fwasted.zk3.dec.com> Date: Mon, 27 May 1996 19:29:00 +1000 Message-Id: <713.833189340@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 26 May 96 23:17:09 -0400 From: bound@zk3.dec.com Message-ID: <9605270317.AA13917@fwasted.zk3.dec.com> Bill and Kre are completely right. Actually, now I doubt that I was completely right, and said so to Paul V - I agree now that the ::FFFF:dot.ted.qu.ad should be handled "by magic" and looked up in in-addr.arpa, right from the start. However, if I could see some rational way to have this lookup sent in IP6.INT to some server(s) which would recognise the special case, and rewrite it as IN-ADDR.ARPA, get the answer, and then return that, I would much favour that way, as that keeps the magic in far fewer places, which would make it feasible to eventually get rid of the magic once IPv4 is just a distant memory from the past. If this does go in the clients then it is going to be around forever, and the ::FFFF:xxxx:xxxx address space will be forever reserved. Clearly the code could be made to do this easily enough (servers for the f.f.f.f.0.0...0.IP6.INT zone could have magic code in them easily enough), but this looks as if it would create a terrible choke point, esp as in the early days it is likely that most queries would go that way. On the other hand, I am still strongly of the opinion that the ::dot.ted.qu.ad type addresses should be looked up in IP6.INT with no magic anywhere in the protocols - but perhaps a considerate server implementation that would allow sites to use a single zone file (on one format or the other) to answer queries for both their in-addr.arpa and ip6.int zones for these addresses, without needing to duplicate data (even in the server database). kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 27 03:12:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27620; Mon, 27 May 96 03:12:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27614; Mon, 27 May 96 03:12:20 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA19005; Mon, 27 May 1996 03:09:08 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA02991; Mon, 27 May 1996 03:08:12 -0700 Received: by aic.net (8.7.3/8.7.3) id OAA09028; Mon, 27 May 1996 14:07:16 +0400 (AMST) From: "Edgar V.S. Der-Danieliantz" Message-Id: <199605271007.OAA09028@aic.net> Subject: (IPng 1820) Re: IPv6 for NetBSD? To: dbj@cs.cmu.edu (Dave Johnson) Date: Mon, 27 May 1996 14:07:16 +0400 (AMST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <709.833088680@CHIMAY.MACH.CS.CMU.EDU> from "Dave Johnson" at May 26, 96 01:31:20 am Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I also interested in IPv6 for NetBSD/FreeBSD. We have ethernet network with about 20 NetBSD/FreeBSD machines. Where I can get more information about installing IPv6 on these OSes? Thanks in advance, Edgar -- A computer is a universal machine and I have proved how it can perform any task that can be described in symbols. I would go further. It is my view that a computer can perform any task that the human brain can carry out. Any task... - Alan Turing (1912-1954) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 27 06:32:47 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27702; Mon, 27 May 96 06:32:47 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27696; Mon, 27 May 96 06:32:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA24520; Mon, 27 May 1996 06:29:23 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA15707; Mon, 27 May 1996 06:29:23 -0700 Received: by zephyr.isi.edu (5.65c/5.61+local-23) id ; Mon, 27 May 1996 06:26:36 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199605271326.AA19498@zephyr.isi.edu> Subject: (IPng 1821) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... To: kre@munnari.OZ.AU (Robert Elz) Date: Mon, 27 May 1996 06:26:36 -0700 (PDT) Cc: bound@zk3.dec.com, bmanning@ISI.EDU, Francis.Dupont@inria.fr, paul@vix.com, ipng@sunroof.eng.sun.com In-Reply-To: <713.833189340@munnari.OZ.AU> from "Robert Elz" at May 27, 96 07:29:00 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While Robert has this wonderful world view (which is a neat operational utopia), I'll stick my neck out and vote for multiple rentry points addres to lable mappings. Being stuck with in-addr.arpa may still get us into trouble and recasting similar "magic" to enshrine IP6.INT even with the additional namshub to handle the conversion of mapped ip4 addresses is, IMHO, a bad idea. Easier to code, yes. Easier to operate, yes. Scalable? Not sure. -- --bill Key fingerprint = FA 2A 63 DA 63 2E CB DB 26 2F 7A 12 B1 07 7D 68 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 27 06:44:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27722; Mon, 27 May 96 06:44:28 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27716; Mon, 27 May 96 06:44:13 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25041; Mon, 27 May 1996 06:41:01 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA16663; Mon, 27 May 1996 06:41:00 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id NA02290; Mon, 27 May 1996 23:38:11 +1000 (from kre@munnari.OZ.AU) To: bmanning@ISI.EDU (Bill Manning) Cc: bound@zk3.dec.com, Francis.Dupont@inria.fr, paul@vix.com, ipng@sunroof.eng.sun.com Subject: (IPng 1822) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of "Mon, 27 May 1996 06:26:36 MST." <199605271326.AA19498@zephyr.isi.edu> Date: Mon, 27 May 1996 23:38:00 +1000 Message-Id: <851.833204280@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 27 May 1996 06:26:36 -0700 (PDT) From: bmanning@ISI.EDU (Bill Manning) Message-ID: <199605271326.AA19498@zephyr.isi.edu> While Robert has this wonderful world view (which is a neat operational utopia), What was that? I'll stick my neck out and vote for multiple rentry points addres to lable mappings. I'm afraid I'm being illiterate here. Just what is it that you're proposing? Being stuck with in-addr.arpa may still get us into trouble and recasting similar "magic" to enshrine IP6.INT even with the additional namshub to handle the conversion of mapped ip4 addresses is, IMHO, a bad idea. Easier to code, yes. Easier to operate, yes. Scalable? Not sure. That may be exactly what I said, but I'm not exactly sure. Without doubt we need some way to translate addresses into names, and as IQUERY was never going to work, in-addr.arpa or ip6.int seems to be the best choice we currently have. Is there a different (kind of) proposal around? The only question right now seems to be if it ever makes sense to use in-addr.arpa to lookup a 128 bit address. My current opinion is that it probably does in the one (and only one) case of ::FFFF:dot.ted.qu.ad though I wish there was a (scalable) way that would allow it to be otherwise (and allow IP6.INT to be used by clients for all 128 bit name conversions). kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 27 07:29:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27816; Mon, 27 May 96 07:29:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27810; Mon, 27 May 96 07:29:12 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27060; Mon, 27 May 1996 07:26:00 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA20280; Mon, 27 May 1996 07:26:00 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id HAA27015; Mon, 27 May 1996 07:23:51 -0700 (PDT) Message-Id: <199605271423.HAA27015@aland.bbn.com> To: "Thomas Narten" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1823) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of Fri, 24 May 96 15:48:00 -0300. <9605241948.AA20585@cichlid.raleigh.ibm.com> Date: Mon, 27 May 96 07:23:50 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In contrast, if the anycast addresses differ from unicast addresses only in the host/local part of the address, one gets "free" routing to anycast addresses without the need to inject extra routing prefixes into the system. Thomas: There's a tradeoff here (discussed in some detail in RFC 1546): * putting anycast in the regular space gives "free" routing to any anycast address (assuming you don't replicate the anycast address outside your network -- which you may want to -- for instance, if NetScape wanted regional replication of www.netscape.com, you'd see host routes for the anycast address) * specially tagging anycast addresses as distinct allows applications and protocols to know they are communicating with an anycast host (which may be useful, for example, in making TCP connections to anycast host works). Now there's a middle ground -- require anycast addresses to have a special format in the subnet address so you can indentify them, but they get the routing for "free" (in cases where all replication is within the subnet). Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 27 09:28:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27944; Mon, 27 May 96 09:28:33 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27938; Mon, 27 May 96 09:28:19 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA01726; Mon, 27 May 1996 09:25:06 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA00597; Mon, 27 May 1996 09:25:07 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16206(1)>; Mon, 27 May 1996 09:25:02 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 27 May 1996 09:24:54 -0700 To: Craig Partridge Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1824) Re: Responses to Comments on Multihoming draft In-Reply-To: craig's message of Mon, 27 May 96 07:23:50 -0800. <199605271423.HAA27015@aland.bbn.com> Date: Mon, 27 May 1996 09:24:48 PDT From: Steve Deering Message-Id: <96May27.092454pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, > * putting anycast in the regular space gives "free" routing to any > anycast address (assuming you don't replicate the anycast address > outside your network -- which you may want to -- for instance, if > NetScape wanted regional replication of www.netscape.com, you'd see > host routes for the anycast address) Argg. Don't even suggest using global anycast addresses for "popular" services -- we've got enough trouble with backbone router table space without everyone insisting on a host route (anycast address) for their service. First it would just be for netscape and alta-vista and yahoo, but soon we'd end up with global anycast addresses for round-table-pizza and united-airlines and united-colors-of-benetton and ... I suggest that the problem of locating nearby instances of global services is better handled using mechanisms other than anycast. > > * specially tagging anycast addresses as distinct allows applications > and protocols to know they are communicating with an anycast host (which > may be useful, for example, in making TCP connections to anycast > host works). For IPv6, a node to which an anycast address is assigned must be aware that the address is anycast. We can then handle the TCP problem at the responder end, rather than the initiator end, by having nodes refuse to accept an incoming connection to an anycast address. > Now there's a middle ground -- require anycast addresses to have a special > format in the subnet address so you can indentify them, but they get the > routing for "free" (in cases where all replication is within the subnet). First, we don't want to limit the replication to within a single subnet, e.g., we want to be able to use anycast addresses for identification of boundaries of large topological aggregates such as provider infrastructure (so we can use the route header with anycast for provider selection). Second, there isn't a fixed size for the "interface" field within the subnet, so it would be awkward to define a general syntactic tag (other than simply declaring the lowest-order bit to be an anycast/unicast flag, which would effectively be giving away half the address space to anycast, and would make autoconfig with 802 addresses messier). Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 27 13:16:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28030; Mon, 27 May 96 13:16:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28024; Mon, 27 May 96 13:16:07 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12059; Mon, 27 May 1996 13:12:54 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA27865; Mon, 27 May 1996 13:12:54 -0700 Received: by gw.home.vix.com id NAA04719; Mon, 27 May 1996 13:12:53 -0700 Date: Mon, 27 May 1996 13:12:53 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 1825) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... Organization: Vixie Enterprises Message-Id: References: <9605270330.AA14328@fwasted.zk3.dec.com> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: bound@zk3.dec.com's message of 26 May 1996 20:40:59 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [jim bound] >gethostbyaddr_2() [for IPv6] or gethostbyaddr() [for IPv4] returns the >right address. But ::ffff.i.p.v.4 does not exist its created if needed. >If IPv6 API is used and its not found as AAAA record then you look for A >record i.p.v.4 if your using AF_INET6 API or have some other transition >scenario figured out then you make it "like" an IPv6 address via ffff. All correct except that it's gethostbyname() (for IPv4 or IPv6/IPv4 systems) and gethostbyname2() (for IPv4 or IPv6/IPv4 systems). The fact that I have not yet implemented gethostbyname2(AF_DNET, "foo") in terms of getnodename() is no excuse for DUNIX shipping without this functionality :-). It's what Matt should have done originally for DNU, and I told him so at the time :-). -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 27 13:25:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28042; Mon, 27 May 96 13:25:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28036; Mon, 27 May 96 13:25:17 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12424; Mon, 27 May 1996 13:22:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA28691; Mon, 27 May 1996 13:22:05 -0700 Received: by gw.home.vix.com id NAA05396; Mon, 27 May 1996 13:22:04 -0700 Date: Mon, 27 May 1996 13:22:04 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 1826) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... Organization: Vixie Enterprises Message-Id: References: <713.833189340@munnari.OZ.AU> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: kre@munnari.OZ.AU's message of 27 May 1996 02:35:55 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [robert elz] > On the other hand, I am still strongly of the opinion that the > ::dot.ted.qu.ad type addresses should be looked up in IP6.INT > with no magic anywhere in the protocols - but perhaps a considerate > server implementation that would allow sites to use a single zone > file (on one format or the other) to answer queries for both their > in-addr.arpa and ip6.int zones for these addresses, without needing > to duplicate data (even in the server database). And I still think that this is wrong, since it demands parallel databases. When a NIC allocates a chunk of the IPv4 address space, it has to enter one or more NS or CNAME RRs into one or more of its mumble.IN-ADDR.ARPA zones. Each target of one of these needs to set up a zone to "catch" the queries. This work has been done as well as it can or will ever be done for the IPv4 address space. It's not perfect -- many mumble.IN-ADDR.ARPA CNAME or NS targets are lame or nonexistent. But it will get no better; we're at the theoretical maximum of getting people to do the right (complicated) thing. To expect the NIC's and every IPv6-capable address block to duplicate this effort for IP6.INT and thereafter keep both the delegation trees (which can be multilevel) and the reverse-lookup zones all synchronized, is to fail to learn a lesson from the incomplete coverage of IN-ADDR.ARPA as it is now. Unless we expect the IPv4 addresses used within IPv6 "mapped addresses" to be allocated differently (that is, to no longer be unique in the same context) as IPv4 addresses used by native IPv4 implementations, or unless we expect the need to support now-existing clients with IN-ADDR.ARPA compiled into them to end within our lifetimes, there is NO cause for asking that IPv6 "mapped" IPv4 addresses have different reverse lookup mechanisms than native IPv4's. If anyone can argue against that, which is my fundamental reason for wording the IPV6PTR I-D as I did, then I am listening. I would very much like to get beyond this point before we all meet in Montreal, so that we can use our time together on something newer and more interesting. Failing that, and I do expect that goal not to be met, how do I get this issue onto some IPng WG's agenda? -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 27 13:38:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28066; Mon, 27 May 96 13:38:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28060; Mon, 27 May 96 13:38:00 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12910; Mon, 27 May 1996 13:34:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA29771; Mon, 27 May 1996 13:34:48 -0700 Received: by gw.home.vix.com id NAA05966; Mon, 27 May 1996 13:34:47 -0700 Date: Mon, 27 May 1996 13:34:47 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 1827) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... Organization: Vixie Enterprises Message-Id: References: <851.833204280@munnari.OZ.AU> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: kre@munnari.OZ.AU's message of 27 May 1996 06:44:02 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Without doubt we need some way to translate addresses into >names, and as IQUERY was never going to work, in-addr.arpa >or ip6.int seems to be the best choice we currently have. > >Is there a different (kind of) proposal around? Yes. Bill Simpson proposed a new ICMP type so that we could just ask the host itself what its name is. I opposed this proposal at the time based on inadequate (i.e., "no") caching and a weak security model (which means I like the idea of having your network manager nominally responsible for your address->name mapping, to make spoofing of .rhosts a tiny bit harder.) Bill's fundamental argument in favour was that with DHCPv6, all IPv6 addresses would be transient, and the only time you could get a reliable address->name mapping for a given address was during the short time that the host had a particular address. Given that, the caching counterargument may not hold, since caching implies many people asking for information that stays valid. If Bill is willing to recast his proposal in terms of a T/TCP or UDP service (so that BSD-based resolvers would not need to be setuid "root" to speak ICMP) I think I'm ready to support it. Note that this would be an IPv6 only issue, thus the "tunnelled IPv4 address" question we're arguing about would not come up. If you know a host speaks IPv6, either with real or tunnelled addresses, than you know it is willing to tell you its host name. A "mapped IPv4" address would use IN-ADDR.ARPA since it is not known to speak IPv6. I'd consider a fallback whereby one attempts first to ask the host for its name and then moves on to IN-ADDR.ARPA (or even IP6.INT if that's the compromise position.) I no longer mind the death of .rhosts. Enough time has passed. RFC 1788 contained Bill's ICMP proposal, which went out as an FYI. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 27 14:22:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28187; Mon, 27 May 96 14:22:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28181; Mon, 27 May 96 14:22:47 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14922; Mon, 27 May 1996 14:19:34 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA03315; Mon, 27 May 1996 14:19:33 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id OAA27475; Mon, 27 May 1996 14:17:25 -0700 (PDT) Message-Id: <199605272117.OAA27475@aland.bbn.com> To: Steve Deering Cc: Craig Partridge , ipng@sunroof.eng.sun.com Subject: (IPng 1828) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of Mon, 27 May 96 09:24:48 -0700. <96May27.092454pdt.75270@digit.parc.xerox.com> Date: Mon, 27 May 96 14:17:24 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Argg. Don't even suggest using global anycast addresses for "popular" services -- we've got enough trouble with backbone router table space without everyone insisting on a host route (anycast address) for their service. First it would just be for netscape and alta-vista and yahoo, but soon we'd end up with global anycast addresses for round-table-pizza and united-airlines and united-colors-of-benetton and ... Steve: I know we disagree about this. I think global anycast is a very useful idea. Just that we don't yet know how to implement it so it scales nicely. I suggest that the problem of locating nearby instances of global services is better handled using mechanisms other than anycast. So far, the ones I've seen are less clean. We can then handle the TCP problem at the responder end, rather than the initiator end, by having nodes refuse to accept an incoming connection to an anycast address. Yes, but I want TCP connections to an anycast address to work, not be refused. Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 27 15:06:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28230; Mon, 27 May 96 15:06:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28224; Mon, 27 May 96 15:06:00 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17421; Mon, 27 May 1996 15:02:47 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA06957; Mon, 27 May 1996 15:02:47 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <16210(10)>; Mon, 27 May 1996 15:02:35 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Mon, 27 May 1996 15:02:26 -0700 To: Craig Partridge Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1829) Re: Responses to Comments on Multihoming draft In-Reply-To: craig's message of Mon, 27 May 96 14:17:24 -0800. <199605272117.OAA27475@aland.bbn.com> Date: Mon, 27 May 1996 15:02:18 PDT From: Steve Deering Message-Id: <96May27.150226pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, > We can then handle the TCP problem at the responder > end, rather than the initiator end, by having nodes refuse to accept an > incoming connection to an anycast address. > > Yes, but I want TCP connections to an anycast address to work, not be > refused. Fine, but that does not require syntactic indication of anycast-ness. Rather it requires a change to TCP to enable the responder to say "use this unicast address for the rest of this conversation". Or do you have some other mechanism in mind, by which syntactic recognizability of anycast addresses eliminates the need to change TCP? Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 27 18:31:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28311; Mon, 27 May 96 18:31:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28305; Mon, 27 May 96 18:31:41 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25981; Mon, 27 May 1996 18:28:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA22038; Mon, 27 May 1996 18:28:28 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id SAA27695; Mon, 27 May 1996 18:26:18 -0700 (PDT) Message-Id: <199605280126.SAA27695@aland.bbn.com> To: Steve Deering Cc: Craig Partridge , ipng@sunroof.eng.sun.com Subject: (IPng 1830) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of Mon, 27 May 96 15:02:18 -0700. <96May27.150226pdt.75270@digit.parc.xerox.com> Date: Mon, 27 May 96 18:26:18 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Yes, but I want TCP connections to an anycast address to work, not be > refused. Fine, but that does not require syntactic indication of anycast-ness. Rather it requires a change to TCP to enable the responder to say "use this unicast address for the rest of this conversation". Agreed, but I'd prefer that mechanism not be general (only available for certain classes of addresses). A general mechanism makes TCP connection hijacking too easy. (Restricting addresses doesn't eliminate the hijacking problem but restricts its scope which may make the hijacking solution somewhat easier, since it doesn't need to be quite so general). Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon May 27 22:29:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28351; Mon, 27 May 96 22:29:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28345; Mon, 27 May 96 22:29:23 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA08280; Mon, 27 May 1996 22:26:11 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA13119; Mon, 27 May 1996 22:26:10 -0700 Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <15717(6)>; Mon, 27 May 1996 22:26:05 PDT Received: by redwing.parc.xerox.com id <3648>; Mon, 27 May 1996 22:25:59 -0700 Date: Mon, 27 May 1996 22:25:45 PDT From: Lixia Zhang To: ipng@sunroof.eng.sun.com Subject: (IPng 1831) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of Mon, 27 May 1996 18:26:18 -0700 Message-Id: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Yes, but I want TCP connections to an anycast address to work, not be > > refused. > > Fine, but that does not require syntactic indication of anycast-ness. Rather > it requires a change to TCP to enable the responder to say "use this unicast > address for the rest of this conversation". > > Agreed, but I'd prefer that mechanism not be general (only available for > certain classes of addresses). A general mechanism makes TCP connection > hijacking too easy. sorry for jumping into the middle of a discussion (just saw the last few exchanges), but this issue relates to another one being pursued (being able to change IP address in the middle of a connection, as Christian talked couple IETF back). Seems to me that one should reduce the hijacking risk by encryption (unclear how much limiting the address classes could help here) Lixia ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 00:36:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28473; Tue, 28 May 96 00:36:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28467; Tue, 28 May 96 00:35:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15026; Tue, 28 May 1996 00:32:46 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA24823; Tue, 28 May 1996 00:32:46 -0700 Received: from shand.reo.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id DAA30327; Tue, 28 May 1996 03:27:12 -0400 (EDT) Received: from localhost by shand.reo.dec.com (5.65/MS-010395) id AA14621; Tue, 28 May 1996 08:26:40 +0100 Message-Id: <9605280726.AA14621@shand.reo.dec.com> To: ipng@sunroof.eng.sun.com Cc: shand@shand.reo.dec.com Subject: (IPng 1832) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of "Fri, 24 May 96 15:48:00 -0300." <9605241948.AA20585@cichlid.raleigh.ibm.com> Date: Tue, 28 May 96 08:26:39 +0100 From: (Mike Shand REO2 G/C2 DTN:830-4424) X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Thomas Narten" said... > I'm not sure I understand what is being described above. Are you > saying that the prefixes used for routing to unicast addresses (i.e., > normal routing) will always be different from prefixes that cover > anycast addresses? > > Seems to me that this is precisely the wrong way to go, because it > means extra routing information (i.e., the anycast prefixes and/or > anycast addresses themselves) gets propagated through the routing > system. In contrast, if the anycast addresses differ from unicast > addresses only in the host/local part of the address, one gets "free" > routing to anycast addresses without the need to inject extra routing > prefixes into the system. > > Thomas For anycast addresses in general there are two distinct cases 1) Those anycast addresses whose scope is confined to that of a single subnet 2) Those with wider scope. Clearly in case (1) where all the potential recipients of that anycast address are co-located on the same subnet, then it makes sense for the anycast address to have a prefix corresponding to that subnet and get routing "for free". However, in case (2), where the scope of the anycast address may span multiple subnets, it is necessary for the routers to generate "host routes" to describe the locations of the recipients. Of course the scope of the host routes can be limited to the scope of the anycast address, and hence may be sumarized external to the anycast scope (but I have yet to see any detailed description of how this is going to be achieved). In this case, it seems to me, using a prefix which is both distinct from any of the "natural" subnet prefixes, and identifies the address as being a "non-local scope" anycast address, seems to make sense. I fully agree with Steve about the extreme undesirability of global host routes. What I'm looking for is a mechanism which permits anycast host routes whose scope is limited to "a few" subnets, and hence only causes route inflation locally. These would appear to be very useful for solving some of the multihoming cases (I agree that not ALL cases of multihoming would require the use of such anycast addresses - we can use dynamic address techniques to solve many of them). Mike ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 01:28:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28527; Tue, 28 May 96 01:28:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28521; Tue, 28 May 96 01:28:44 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA17055; Tue, 28 May 1996 01:25:31 -0700 Received: by mercury.Sun.COM (Sun.COM) id BAA00286; Tue, 28 May 1996 01:25:30 -0700 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1833) Re: Responses to Comments on Multihoming draft To: lixia@parc.xerox.com (Lixia Zhang) Date: Tue, 28 May 1996 09:32:55 +0100 (BST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: from "Lixia Zhang" at May 27, 96 10:25:45 pm Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Agreed, but I'd prefer that mechanism not be general (only available for > > certain classes of addresses). A general mechanism makes TCP connection > > hijacking too easy. > > Seems to me that one should reduce the hijacking risk by encryption > (unclear how much limiting the address classes could help here) The current Linux kernel has freely available source to transparent application level proxies (ie the useful direct equivalent of hijacking). Anyone can write a hijacking tool trivially anyway, this code makes it even easier. Use security mechanisms dont cripple new features with old and poor assumptions. Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 03:27:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28577; Tue, 28 May 96 03:27:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28571; Tue, 28 May 96 03:27:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA23373; Tue, 28 May 1996 03:24:17 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA13415; Tue, 28 May 1996 03:24:17 -0700 Received: from matisse (matisse.ibp.fr [132.227.61.26]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with SMTP id MAA19385 for ; Tue, 28 May 1996 12:24:15 +0200 Date: Tue, 28 May 1996 12:24:15 +0200 Message-Id: <199605281024.MAA19385@ibp.ibp.fr> X-Sender: eh@hera.ibp.fr X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: "Eric HORLAIT (MASI-CNRS)" Subject: (IPng 1834) draft-ietf-ipng-bsd-api-05 and inet6_isipv4addr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is there any reason for namming a procedure inet6_isipv4addr when other functions are inet_pton or inet_ntop? BTW, this procedure (inet6_isipv4addr) is used to know if an address is an IPv4 mapped address, so of the form ::XXYY:ZZTT. Does it recognize also adresses of the form ::FFFF:XXYY:ZZTT, which are also some sort of mapped IPv4 adresses? Eric ---------------------- Professeur Eric HORLAIT ------------------------ Universite Pierre et Marie Curie Tel: 33-1-44-27-73-83 Institut Blaise Pascal - Labo MASI Fax: 33-1-44-27-62-86 4, place Jussieu e-mail: Eric.Horlait@masi.ibp.fr 75252 PARIS Cedex 05 Telex: UPMCSIX 200-145 F http://www-masi-net.ibp.fr/~eh ----------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 06:29:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28699; Tue, 28 May 96 06:29:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28693; Tue, 28 May 96 06:28:59 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA03518; Tue, 28 May 1996 06:25:45 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA10471; Tue, 28 May 1996 06:25:43 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0002; Tue, 28 May 96 09:25:30 EDT Received: by RTP (XAGENTA 4.0) id 5514; Tue, 28 May 1996 09:25:37 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA08378; Tue, 28 May 1996 09:25:30 -0400 Message-Id: <9605281325.AA08378@cichlid.raleigh.ibm.com> To: paul@vix.com (Paul A Vixie) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1835) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of "Mon, 27 May 1996 13:34:47 PDT." Date: Tue, 28 May 1996 09:25:30 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk paul@vix.com (Paul A Vixie) writes: >Bill's fundamental argument in favour was that with DHCPv6, all IPv6 addresses >would be transient, perhaps... >and the only time you could get a reliable address->name >mapping for a given address was during the short time that the host had a >particular address. I'm not sure what you mean by "short", but I don't think the time will be short in general. It has always been a goal of DHCP to return the same address for a given interface token. Such behavior is not *required*, but is expected to be common. And since the v6 space is so large (i.e., can be allocated sparsely), reallocating unused addresses to other machines seems much less critical than in v4. Also, if one believes stateless address autoconfiguration will dominate, address<->name mappings will remain relatively constant. Of course, as address prefixes change, addresses will change. But I don't expect we'll see folks renumbering on a daily basis. In anycase, if a host gets a new address, the DNS needs to be updated with a new name->address mapping. Given that, it's not a whole lot more work to also put in a PTR mapping. Thus, I don't believe Bill's ICMP query proposal eliminates all that much work in practice. >If Bill is willing to recast his proposal in terms of a T/TCP Huh? Requiring/assuming T/TCP seems like a pretty hefty prerequisite. In any case, TCP doesn't seem particularly appropriate for the simple request/response exchange that I understand Bill's proposal to be. >or UDP >service (so that BSD-based resolvers would not need to be setuid "root" to >speak ICMP) I think I'm ready to support it. BSD implementationisms seems like a bad reason to move something to UDP that logically belongs at ICMP. One could work around this problem in BSD. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 06:58:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28719; Tue, 28 May 96 06:58:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28713; Tue, 28 May 96 06:57:54 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA05730; Tue, 28 May 1996 06:54:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA17075; Tue, 28 May 1996 06:54:38 -0700 Received: from RTP by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0965; Tue, 28 May 96 09:54:27 EDT Received: by RTP (XAGENTA 4.0) id 5530; Tue, 28 May 1996 09:54:34 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20153; Tue, 28 May 1996 09:54:23 -0400 Message-Id: <9605281354.AA20153@cichlid.raleigh.ibm.com> To: Steve Deering Cc: Craig Partridge , ipng@sunroof.eng.sun.com Subject: (IPng 1836) Re: Responses to Comments on Multihoming draft In-Reply-To: Your message of "Mon, 27 May 1996 09:24:48 PDT." <96May27.092454pdt.75270@digit.parc.xerox.com> Date: Tue, 28 May 1996 09:54:23 -0300 From: "Thomas Narten" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >For IPv6, a node to which an anycast address is assigned must be aware that >the address is anycast. We can then handle the TCP problem at the responder >end, rather than the initiator end, by having nodes refuse to accept an >incoming connection to an anycast address. Do we need to think about having an ICMP error type saying the equivalent of "connection refused, address specified is an anycast address?" There is a difference between rejecting a TCP connection to a port that has no listeners and rejecting one to an anycast address. One real problem with using anycast addresses more generally is the trust model. Right now, if you use a unicast address, it identifies a single machine. Although hijacking/spoofing is possible, it takes a bit of work. One implicitely trusts the routing system to deliver the packet to the right machine (with a reasonably high probability that the integrity of the routing infrastructure is intact). However, if we add a mechanism that says "you tried to connect to anycast address XXX, use unicast address YYY instead", there is the hard question of how one knows that YYY is authorized to be XXX (in the trust model sense). To get any sort of level of security, one is pretty much forced to use IPSec to authenticate YYY before continuing further. Is the cost of using anycast addresses that one MUST also authenticate using IPSec? Is this a reasonable cost? Note: I don't want to get sidetracked into a discussion about how routing isn't secure today. We're talking relative degrees. Using anycast addresses for locating services would seem to significantly increase the potential for vulnerabilities through hijacking/spoofing. Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 07:40:13 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28776; Tue, 28 May 96 07:40:13 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28770; Tue, 28 May 96 07:40:01 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09716; Tue, 28 May 1996 07:36:47 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA27854; Tue, 28 May 1996 07:36:45 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id KAA06141; Tue, 28 May 1996 10:36:40 -0400 Date: Tue, 28 May 1996 10:36:40 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9605281036.ZM6139@seawind.bellcore.com> In-Reply-To: Craig Partridge "(IPng 1828) Re: Responses to Comments on Multihoming draft" (May 27, 2:17pm) References: <199605272117.OAA27475@aland.bbn.com> X-Mailer: Z-Mail (3.2.0 06sep94) To: Craig Partridge Subject: (IPng 1837) Re: Responses to Comments on Multihoming draft Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On May 27, 2:17pm, Craig Partridge wrote: > Subject: (IPng 1828) Re: Responses to Comments on Multihoming draft > > Argg. Don't even suggest using global anycast addresses for "popular" > services -- we've got enough trouble with backbone router table space > without everyone insisting on a host route (anycast address) for their > service. First it would just be for netscape and alta-vista and yahoo, > but soon we'd end up with global anycast addresses for round-table-pizza > and united-airlines and united-colors-of-benetton and ... > > Steve: > > I know we disagree about this. I think global anycast is a very > useful idea. Just that we don't yet know how to implement it so it scales > nicely. The basic idea of unicast is to use network level routing to "get to the nearest instance of foo". As such, anycast implies that there is exactly one address per type of foo. These addresses may indeed be aggregated, but there will have to be one aggregate, i.e. a routing prefix, per "class of replication" i.e. per group of servers replicated at about the same places and providing about the same services. Now, today's definition of a service is a web page, not a host. Replication patterns vary widely, thus making aggregation unlikely. Do you really want to have a global routing entry for each popular page ? When the services that we replicate have a finer grain than hosts and interfaces, using Internet addresses to identify them does not strike me as a move in the right direction. Also, there are very few services where "network distance" is the sole criterium for chosing a server. Printers, for example, are chosen based on capacity and phycical location, not network distance. Applications would "get a menu and pick" rather than "pick at random based on cabling". This looks like a predication for multicast, not anycast. Using multicasting has in fact a few other advantages: * avoids confusing TCP, * does not depend on locality, can be hard-coded in application, * allows synchronization between similar servers, e.g. for load sharing. I guess I stand with Steve on this point. The only clear use of anycast is for source routing through clouds -- a network function. -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 07:49:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28792; Tue, 28 May 96 07:49:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28786; Tue, 28 May 96 07:49:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA10785; Tue, 28 May 1996 07:46:17 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA00439; Tue, 28 May 1996 07:46:17 -0700 Received: from munin.fnal.gov ("port 2581"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I58GQ4G0MM000VT0@FNAL.FNAL.GOV>; Tue, 28 May 1996 09:46:00 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id JAA06130; Tue, 28 May 1996 09:45:10 -0500 (CDT) Date: Tue, 28 May 1996 09:45:09 -0500 From: Matt Crawford Subject: (IPng 1838) Re: Responses to Comments on Multihoming draft In-Reply-To: "28 May 1996 09:54:23 -0300." <"9605281354.AA20153"@cichlid.raleigh.ibm.com> To: Thomas Narten Cc: Steve Deering , Craig Partridge , ipng@sunroof.eng.sun.com Message-Id: <199605281445.JAA06130@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Do we need to think about having an ICMP error type saying the > equivalent of "connection refused, address specified is an anycast > address?" There is a difference between rejecting a TCP connection to > a port that has no listeners and rejecting one to an anycast address. I just now realized that ICMPv6 has dropped the unreachable code that ICMPv4 had: protocol unreachable. But for its non-existence, that would seem to be the most appropriate reply. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 07:57:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28804; Tue, 28 May 96 07:57:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28798; Tue, 28 May 96 07:57:31 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11629; Tue, 28 May 1996 07:54:17 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA02833; Tue, 28 May 1996 07:54:17 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id KAA21305; Tue, 28 May 1996 10:37:25 -0400 (EDT) Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA12986; Tue, 28 May 1996 10:36:54 -0400 Received: by netrix.lkg.dec.com; (5.65v3.2/1.1.8.2/28May95-0415PM) id AA24640; Tue, 28 May 1996 10:36:45 -0400 Date: Tue, 28 May 1996 10:36:45 -0400 From: Dan Harrington Message-Id: <9605281436.AA24640@netrix.lkg.dec.com> To: paul@vix.com Subject: (IPng 1839) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... Cc: dan@netrix.lkg.dec.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: paul@vix.com (Paul A Vixie) >>Is there a different (kind of) proposal around? > > Yes. Bill Simpson proposed a new ICMP type so that we could just ask the > host itself what its name is. I opposed this proposal at the time based > on inadequate (i.e., "no") caching and a weak security model (which means > I like the idea of having your network manager nominally responsible for > your address->name mapping, to make spoofing of .rhosts a tiny bit harder.) I'm currently working on a draft which will use UDP to provide a name <=> *link-local* address mapping service. I focussed on this because it's needed for plug-and-play operation, and because I think it's inappropriate (and unmanageable) to put link-local addresses in DNS. I didn't want to tackle anything beyond link-local, though... > RFC 1788 contained Bill's ICMP proposal, which went out as an FYI. Thanks for the pointer...I was unaware of this earlier work. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 09:40:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28922; Tue, 28 May 96 09:40:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28916; Tue, 28 May 96 09:40:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA27164; Tue, 28 May 1996 09:36:52 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA07086; Tue, 28 May 1996 09:36:51 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id QA17668; Wed, 29 May 1996 02:36:40 +1000 (from kre@munnari.OZ.AU) To: paul@vix.com (Paul A Vixie) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1840) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of "Mon, 27 May 1996 13:22:04 MST." Date: Wed, 29 May 1996 02:36:28 +1000 Message-Id: <1834.833301388@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 27 May 1996 13:22:04 -0700 From: paul@vix.com (Paul A Vixie) Message-ID: And I still think that this is wrong, since it demands parallel databases. No, it does not. It permits parallel databases. It also allows administrations which would be required to run parallel databases, want the data in both to be identical, and want to avoid duplication to run a server that allows the two databases to be constructed, virtually (as required) out of one. Performing the mapping at the client means that administrations which actually want the two databases to be different, perhaps because they only have a few ::dot.ted.qu.ad addresses valid for IPv6, and lots of dot.ted.qu.ad addresses valid for IPv4, and only want the IP6.INT mapping to be valid for the ::a.b.c.d addresses they have actually assigned (which are actually in use) cannot achieve that aim. The client has forced the entire in-addr.arpa space into ip6.int without consulting anyone. Personally, I find that distasteful. To expect the NIC's and every IPv6-capable address block to duplicate this effort for IP6.INT and thereafter keep both the delegation trees (which can be multilevel) and the reverse-lookup zones all synchronized, is to fail to learn a lesson from the incomplete coverage of IN-ADDR.ARPA as it is now. There is no reason they need to be synchronised. Eg: if I were to run an IPv6 node here at Melbourne (which I may very well do), I'd want to run the relevant IP6.INT nameserver, and choose the name by which my node appears to the world, which may be (almost certainly would be) unrelated to the name it has in the IPv4 universe. Unless we expect the IPv4 addresses used within IPv6 "mapped addresses" to be allocated differently (that is, to no longer be unique in the same context) I'm not sure what "same context" the parenthitical remark refers to, but I do expect that name<->addr mappings for hosts in IPv6 will (sometimes) differ from the mappings for the same hosts in IPv4. Name<->address mappings are transitory things, they are not something etched into stone once, never to be revised. Given that (everyone agrees I believe) that they can be altered, there's no reason to demand that the visible name in the IPv6 space be identical to that in the IPv4 space. I mean, it isn't as if even IPv4 hosts have just one name, many have several... or unless we expect the need to support now-existing clients with IN-ADDR.ARPA compiled into them to end within our lifetimes, I expect it to ve virtually ended within the lifetimes of some people reading these messages, if not 100% ended within that timeframe. I don't expect it to be ended within all our lifetimes. But I fail to see the relevance anyway. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 10:02:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28942; Tue, 28 May 96 10:02:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27723; Mon, 27 May 96 06:44:42 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25072; Mon, 27 May 1996 06:41:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA16687; Mon, 27 May 1996 06:41:21 -0700 Received: from fganffm.ffm.fgan.de by deneb.dfn.de (4.1/SMI-4.2) id AA24451; Mon, 27 May 96 15:40:03 +0200 From: Christian Riechmann Message-Id: <9605271341.AA04441@fganffm.ffm.fgan.de> Subject: (IPng 1841) IPv6 for Linux ? To: ipng@sunroof.eng.sun.com Date: Mon, 27 May 96 15:41:03 WET DST X-Mailer: ELM [version 2.3 PL0] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, because there were some mails concerning IPv6 implementations for small machines with NetBSD/FreeBSD, please let me ask whether similar work is going on for Linux? Regards Christian Riechmann -- Christian Riechmann E-Mail: riechmann@fgan.de c/o FGAN/FFM X.400: s=rie;ou=rufsun9;o=ffm;p=fgan;a=d400;c=de Neuenahrer Strasse 20 Tel: (+49) 228/9435 533 D-53343 Wachtberg Fax: (+49) 228/348 953 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 10:02:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28949; Tue, 28 May 96 10:02:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27723; Mon, 27 May 96 06:44:42 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25072; Mon, 27 May 1996 06:41:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA16687; Mon, 27 May 1996 06:41:21 -0700 Received: from fganffm.ffm.fgan.de by deneb.dfn.de (4.1/SMI-4.2) id AA24451; Mon, 27 May 96 15:40:03 +0200 From: Christian Riechmann Message-Id: <9605271341.AA04441@fganffm.ffm.fgan.de> Subject: (IPng 1842) IPv6 for Linux ? To: ipng@sunroof.eng.sun.com Date: Mon, 27 May 96 15:41:03 WET DST X-Mailer: ELM [version 2.3 PL0] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, because there were some mails concerning IPv6 implementations for small machines with NetBSD/FreeBSD, please let me ask whether similar work is going on for Linux? Regards Christian Riechmann -- Christian Riechmann E-Mail: riechmann@fgan.de c/o FGAN/FFM X.400: s=rie;ou=rufsun9;o=ffm;p=fgan;a=d400;c=de Neuenahrer Strasse 20 Tel: (+49) 228/9435 533 D-53343 Wachtberg Fax: (+49) 228/348 953 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 11:04:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29074; Tue, 28 May 96 11:04:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29068; Tue, 28 May 96 11:04:45 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA13201; Tue, 28 May 1996 11:01:29 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA12045; Tue, 28 May 1996 11:01:28 -0700 Received: (from shaver@localhost) by neon.ingenia.com (8.8.Alpha.2/8.6.9) id NAA07223; Tue, 28 May 1996 13:39:06 -0400 From: Mike Shaver Message-Id: <199605281739.NAA07223@neon.ingenia.com> Subject: (IPng 1843) Re: IPv6 for Linux ? To: rie@fganffm.ffm.fgan.de (Christian Riechmann) Date: Tue, 28 May 1996 13:39:05 -0400 (EDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9605271341.AA04441@fganffm.ffm.fgan.de> from "Christian Riechmann" at May 27, 96 03:41:03 pm X-Mailer: ELM [version 2.4 PL24 PGP3 *ALPHA*] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake Christian Riechmann: > because there were some mails concerning IPv6 implementations for small > machines with NetBSD/FreeBSD, please let me ask whether similar work > is going on for Linux? Yup. It's being spearheaded by Pedro Roque Marques, and there's a mailing list set up. Send mail to majordomo@roxanne.nuclecu.unam.mx with the message: subscribe netdev Patches are available at ftp://ftp.di.fc.ul.pt/pub/systems/Linux/IPv6. Right now, it's talking via IPv6-in-IPv4, and we got a cross-Atlantic telnet6 yesterday. Mike -- #> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation <# #> UNIX medicine man -- dark magick, cheap! <# #> <# #> When the going gets tough, the tough give cryptic error messages. <# #> "We believe in rough consensus and running code." <# ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 11:31:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29111; Tue, 28 May 96 11:31:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29105; Tue, 28 May 96 11:31:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA18340; Tue, 28 May 1996 11:27:54 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA20969; Tue, 28 May 1996 11:27:52 -0700 Message-Id: From: iialan@iifeak.swan.ac.uk (Alan Cox) Subject: (IPng 1844) Re: IPv6 for Linux ? To: rie@fganffm.ffm.fgan.de (Christian Riechmann) Date: Tue, 28 May 1996 19:35:23 +0100 (BST) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9605271341.AA04441@fganffm.ffm.fgan.de> from "Christian Riechmann" at May 27, 96 03:41:03 pm Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > because there were some mails concerning IPv6 implementations for small > machines with NetBSD/FreeBSD, please let me ask whether similar work > is going on for Linux? > Yes. Its being developed, I hope to merge it (in an ALPHA state) into 2.1. See /usr/src/linux/net/ipv6/README in a current kernel ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 15:32:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29348; Tue, 28 May 96 15:32:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29342; Tue, 28 May 96 15:32:44 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA02116; Tue, 28 May 1996 15:29:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA10702; Tue, 28 May 1996 15:29:16 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14797(10)>; Tue, 28 May 1996 15:28:58 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 28 May 1996 15:28:55 -0700 To: ipng@sunroof.eng.sun.com Cc: deering@parc.xerox.com Subject: (IPng 1845) Re: Responses to Comments on Multihoming draft Date: Tue, 28 May 1996 15:28:40 PDT From: Steve Deering Message-Id: <96May28.152855pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Craig Partridge > > From: Steve Deering > > Fine, but that does not require syntactic indication of anycast-ness. > Rather it requires a change to TCP to enable the responder to say "use > this unicast address for the rest of this conversation". > > Agreed, but I'd prefer that mechanism not be general (only available for > certain classes of addresses). A similar "redirect" mechanism is likely to be just as useful for regular unicast connection initiations, e.g., to handle multihoming, renumbering, mobility, etc. > A general mechanism makes TCP connection > hijacking too easy. (Restricting addresses doesn't eliminate the hijacking > problem but restricts its scope which may make the hijacking solution > somewhat easier, since it doesn't need to be quite so general). I think we need to stop perpetrating the myth that there are any significant security properties associated with types of addresses. The way to assure that you are talking to the desired service is by proper service authentication, either using service-specific mechanisms or IPsec AH mechanisms. > From: < (Mike Shand REO2 G/C2 DTN:830-4424) shand@shand.reo.dec.com> > > For anycast addresses in general there are two distinct cases > > 1) Those anycast addresses whose scope is confined to that of a single subnet > > 2) Those with wider scope. > > Clearly in case (1) where all the potential recipients of that anycast > address Eare co-located on the same subnet, then it makes sense for the > anycast address to have a prefix corresponding to that subnet and get > routing "for free". Or, more generally, an anycast address should be given the longest prefix sufficient to cover the topological distribution of the members of that anycast group. If all the members are to be located on the same subnet, they should be given an address taken from the subnet's prefix. If some members are be in different subnets but within the same subscriber site, they should be given an address taken from the site's prefix. And so on. This strategy limits the scope of the anycast-address route entry to the minimum required to do the job. > However, in case (2), where the scope of the anycast address may span > multiple subnets, it is necessary for the routers to generate "host routes" > to describe the locations of the recipients. Of course the scope of the > host routes can be limited to the scope of the anycast address, and hence > may be sumarized external to the anycast scope (but I have yet to see any > detailed description of how this is going to be achieved). If you follow my suggestion above, then the summarization happens naturally. I acknowledge that a detailed description of how to allocate/manage/route/etc. anycast address is missing and desired -- I think we're still in the process of figuring these issues out. That's why the curent addressing spec takes a very conservative approach to specifying the use of anycast addresses. > In this case, it seems to me, using a prefix which is both distinct from > any of the "natural" subnet prefixes, and identifies the address as being > a "non-local scope" anycast address, seems to make sense. I agree with you that using a distinct "virtual subnet" prefix for anycast groups that span multiple subnets of a site is probably sensible for ease of address management and problem diagnosis, though it is not strictly necessary. Taking addresses for multi-subnet anycast groups from an existing subnet's prefix does not save any routing overhead (a "host route" has to be generated even for those members that happen to be on the subnet identified by the address prefix, so that the longest-match routing rule won't prevent delivery to those members). However, I think these are issues of policy, and suggest that our mechanisms should allow either approach to anycast address allocation. > From: "Thomas Narten" > > Do we need to think about having an ICMP error type saying the > equivalent of "connection refused, address specified is an anycast > address?" There is a difference between rejecting a TCP connection to > a port that has no listeners and rejecting one to an anycast address. The rejection of anycast packets is a transport- or higher-layer decision, and it should be signalled by those higher-layer protocols, not ICMP. E.g., for TCP, perhaps there ought to be defined a new option type, to accompany FIN and/or RST messages, explaining the reason for the close or reset. > Although hijacking/spoofing is possible, it takes a bit of work. All it takes is one hacker to encapsulate his or her hijacking technique in a freely FTP-able program, and the amount of work drops to almost zero. It's time (actually, well past time) to move to strong end-to-end authentication as routine Internet practice. > From: Matt Crawford > > I just now realized that ICMPv6 has dropped the unreachable code that > ICMPv4 had: protocol unreachable. But for its non-existence, that > would seem to be the most appropriate reply. ICMPv4 Destination Unreachable: Protocol Unreachable is used to report an unrecognized/unsupported value in the Protocol field of the IPv4 header. In v6, we replaced the Protocol field by the Next Header field, so we replaced the Protocol Unreachable message with an Unrecognized Next Header Type message, and because there can be more than one Next Header field in a packet, we changed this message to be a subtype of Parameter Problem (which has a pointer field), rather than being a subtype of Destination Unreachable (which does not). Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 15:51:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29366; Tue, 28 May 96 15:51:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29360; Tue, 28 May 96 15:51:25 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA06340; Tue, 28 May 1996 15:48:09 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA16928; Tue, 28 May 1996 15:48:09 -0700 Received: from munin.fnal.gov ("port 3053"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I58XJVZL7K000VT0@FNAL.FNAL.GOV>; Tue, 28 May 1996 17:48:08 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id RAA08468; Tue, 28 May 1996 17:47:18 -0500 (CDT) Date: Tue, 28 May 1996 17:47:17 -0500 From: Matt Crawford Subject: (IPng 1846) Re: Responses to Comments on Multihoming draft In-Reply-To: "28 May 1996 15:28:40 PDT." <"96May28.152855pdt.75270"@digit.parc.xerox.com> To: Steve Deering Cc: ipng@sunroof.eng.sun.com Message-Id: <199605282247.RAA08468@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ > From: Matt Crawford > > I just now realized that ICMPv6 has dropped the unreachable code that > > ICMPv4 had: protocol unreachable. [...] > > [...] we replaced the Protocol field by the Next Header field, so we > replaced the Protocol Unreachable message with an Unrecognized Next Header Yes, I knew about that one. "Unrecognized Next Header" has a distinctly different implication that "Protocol Unreachable." If this error may be given in response to packets with perfectly well-known next header values, but which can't be delivered at a certain IP address because it's anycast, then I think there needs to be a clarification. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 16:22:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29392; Tue, 28 May 96 16:22:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29386; Tue, 28 May 96 16:22:42 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11919; Tue, 28 May 1996 16:19:28 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA27216; Tue, 28 May 1996 16:19:28 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14854(8)>; Tue, 28 May 1996 16:19:22 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Tue, 28 May 1996 16:19:19 -0700 To: Matt Crawford Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 1847) Re: Responses to Comments on Multihoming draft In-Reply-To: crawdad's message of Tue, 28 May 96 15:47:17 -0800. <199605282247.RAA08468@munin.fnal.gov> Date: Tue, 28 May 1996 16:19:15 PDT From: Steve Deering Message-Id: <96May28.161919pdt.75270@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, > > [...] we replaced the Protocol field by the Next Header field, so we > > replaced the Protocol Unreachable message with an Unrecognized Next Header > > Yes, I knew about that one. "Unrecognized Next Header" has a > distinctly different implication that "Protocol Unreachable." If > this error may be given in response to packets with perfectly > well-known next header values, but which can't be delivered at a > certain IP address because it's anycast, then I think there needs to > be a clarification. Sorry, I should have been clearer. I do *not* advocate using the ICMP Unrecognized Next Header message as a way to signal the refusal of anycast packets. Rather, as I said in another part of my previous message, I think it is responsibility of the higher-layer protocol to use its own, higher- layer messages to complain about anycast, if that's what it wants to do. If the IPv6 module recognizes the Next Header type, it should hand the packet to the module for that type, regardless of the destination address. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue May 28 16:41:58 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29424; Tue, 28 May 96 16:41:58 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29408; Tue, 28 May 96 16:37:09 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA14026; Tue, 28 May 1996 16:33:55 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA01182; Tue, 28 May 1996 16:33:53 -0700 Received: from drugs.syd.dms.CSIRO.AU by dmssyd.syd.dms.CSIRO.AU (4.1/5.17) id AA12010; Wed, 29 May 96 09:33:40 EST (from Mark.Andrews@dms.csiro.au (Mark Andrews)) Message-Id: <9605282333.AA12010@dmssyd.syd.dms.CSIRO.AU> To: "Eric HORLAIT (MASI-CNRS)" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1848) Re: draft-ietf-ipng-bsd-api-05 and inet6_isipv4addr In-Reply-To: Your message of "Tue, 28 May 1996 12:24:15 +0200." <199605281024.MAA19385@ibp.ibp.fr> Date: Wed, 29 May 1996 09:33:34 +1000 From: Mark Andrews Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Is there any reason for namming a procedure inet6_isipv4addr when other > functions are inet_pton or inet_ntop? > inet6_isipv4addr is family specific, whereas the others are generic. inet6_isipv4addr is a good choice here. > BTW, this procedure (inet6_isipv4addr) is used to know if an address is an > IPv4 mapped address, so of the form ::XXYY:ZZTT. Does it recognize also > adresses of the form ::FFFF:XXYY:ZZTT, which are also some sort of mapped > IPv4 adresses? inet6_isipv4addr returns 1 for ::FFFF:XXYY:ZZTT not ::XXYY:ZZTT. You would use it when determining which form of the PORT command to use in FTP. It is to be used when you need to know whether you are talking IPv4 through the IPv6 API. Mark -- Mark Andrews, CSIRO Div Maths & Stats Locked Bag 17, North Ryde, NSW 2113, Australia. PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au MOBIL: +61 41 942 9884 UUCP:....!uunet!syd.dms.csiro.au!marka ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 29 10:03:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29995; Wed, 29 May 96 10:03:57 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29989; Wed, 29 May 96 10:03:37 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA12208; Wed, 29 May 1996 10:00:20 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA08117; Wed, 29 May 1996 10:00:21 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa21915; 29 May 96 12:55 EDT To: IETF-Announce:;@mercury Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 1849) Protocol Action: Path MTU Discovery for IP version 6 to Proposed Standard Date: Wed, 29 May 96 12:55:26 -0400 Message-Id: <9605291255.aa21915@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft "Path MTU Discovery for IP version 6" as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Scott Bradner and Allison Mankin. Technical Summary This document describes Path MTU Discovery for IP version 6. It defines a method to determine the largest packet size that can successfully traverse the path from the source node to the destination node. The procedure is largely derived from RFC-1191, which describes Path MTU Discovery for IP version 4. Since IPv6 routers do not fragment packets the use of Path MTU Discovery should be implemented in all IPv6 nodes which would like to send packets greater than the IPv6 minimum packet size (576 bytes) long. Working Group Summary The Working Group Last-Call produced no issues about the proposal. Protocol Quality This document was reviewed for the IESG by Scott Bradner and Allison Mankin. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 29 15:22:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00551; Wed, 29 May 96 15:22:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00545; Wed, 29 May 96 15:22:29 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA09256; Wed, 29 May 1996 15:19:12 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA01149; Wed, 29 May 1996 15:19:10 -0700 Received: from ccu1.auckland.ac.nz (rossa@ccu1.auckland.ac.nz [130.216.3.1]) by mailhost.auckland.ac.nz (8.7.3/8.7.3-ua) with ESMTP id KAA26497 for ; Thu, 30 May 1996 10:19:08 +1200 (NZST) Received: (from rossa@localhost) by ccu1.auckland.ac.nz (8.7.3/8.7.3) id KAA07236 for ipng@sunroof.eng.sun.com; Thu, 30 May 1996 10:19:06 +1200 (NZT) From: Ross Alexander Message-Id: <199605292219.KAA07236@ccu1.auckland.ac.nz> Subject: (IPng 1850) Address clarifications To: ipng@sunroof.eng.sun.com Date: Thu, 30 May 1996 10:19:05 +1200 (NZT) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Here is a summary of IPv6 addressing as I see it (please correct me) IPv6 machine with IPv6 IPv4 machine with address xxxx:yyyy:zzzz:wwww IPv4 address and IPv4 address a.b.c.d i.j.k.l ------------------------ ------------------------ | IPv6 appl talking to | | IPv4 appl talking to | | IPv4 applt sees addrs| | IPv4 appl sees | | ffff:ffff:a.b.c.d & | | i.j.k.l & a.b.c.d | | ffff:ffff:i.j.k.l | |----------------------| |----------------------| | IPv4 stack sees | | IPv4 stack | Ethernet with | addresses | | sees addresses | 0x0800 802.3 | i.j.k.l & | | a.b.c.d & | identifier | a.b.c.d | | i.j.k.l |--------------------| | ------------------------ ------------------------ IPv6 machine with IPv6 IPv6 with addr address xxxx:yyyy:zzzz:wwww pppp:qqqq:rrrr:ssss & and IPv4 address a.b.c.d IPv4 addr i.j.k.l ------------------------ ------------------------ | IPv6 appl talking to | | IPv6 appl talking to | | talking to IPv6 appl | | talking to IPv6 appl | | over IPv4 | | over IPv4 | | sees addresses | | sees addresses | | 0:0:a.b.c.d & | | 0:0:a.b.c.d & | | 0:0:i.j.k.l | | 0:0:i.j.k.l | |----------------------| |----------------------| | IPv6 stack using | | IPv6 stack using | | IPv4 as transport | | IPv4 as transport | |----------------------| |----------------------| | IPv4 stack with addr | Ethernet with | IPv4 stack with addr | | a.c.d.d & |--------------------| i.j.k.l & a.b.c.d | | i.j.k.l | 802.3 identifier | | ------------------------ 0x0800 ------------------------ IPv6 machine with IPv6 IPv6 with addr address xxxx:yyyy:zzzz:wwww pppp:qqqq:rrrr:ssss & and IPv4 address a.b.c.d IPv4 addr i.j.k.l ------------------------ ------------------------ | IPv6 appl talking to | | IPv6 appl talking to | | talking to IPv6 appl | | talking to IPv6 appl | | over IPv6 sees | | over IPv6 seees | | xxxx:yyyy:zzzz:wwww &| | pppp:qqqq:rrrr:ssss &| | pppp.qqqq.rrrr.ssss | | xxxx:yyyy:zzzz:wwww | |----------------------| |----------------------| | IPv6 stack with addr | Ethernet with | IPv6 stack with addr | | xxxx:yyyy:zzzz:wwww &|--------------------| i.j.k.l & a.b.c.d | | pppp:qqqq:rrrr:ssss | 802.3 identifier | | ------------------------ 0x86DD ------------------------ For BIND the follow situations apply Machine A (IPv6) blah.blah.edu. IN AAAA xxxx:yyyy:zzzz:wwww IN AAAA 0:0:a.b.c.d IN A a.b.c.d w.w.w.w.z.z.z.z.y.y.y.y.x.x.x.x.IP6.int PTR blah.blah.edu. d.c.b.a.0.0.0.0.0.0.0.0.0.0.0.0.IP6.int PTR blah.blah.edu. d.c.d.a.in-addr.arpa PTR blah.blah.edu. Machine B (IPv4 only) natter.natter.com. IN A i.j.k.l. l.k.j.i.in-addr.arpa PTR natter.natter.com. Machine C (IPv6) yack.yack.net. IN AAAA pppp:qqqq:rrrr:ssss IN AAAA 0:0:i.j.k.l IN A i.j.k.l s.s.s.s.r.r.r.r.q.q.q.q.p.p.p.p.IP6.int PTR yack.yack.net. l.k.j.i.0.0.0.0.0.0.0.0.0.0.0.0.IP6.int PTR yack.yack.net. l.k.j.i.in-addr.arpa PTR yack.yack.net. This causes the following situations to apply Machine A checks AAAA records for machine B and does not get any so tries to get A record. Uses IPv4. Machine A checks AAAA records for machine C and gets two back. Attempts to connect using pppp:qqqq:rrrr:ssss and cannot, so tries second address, with is IPv4 compatible address, so using IPv4 as tunnel. Machine A checks AAAA records for machine C and gets two back. Attempts to connect using pppp:qqqq:rrrr:ssss over IPv6 and does, end of story. Any comments, corrections, etc. Ross ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 29 16:31:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00603; Wed, 29 May 96 16:31:00 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00597; Wed, 29 May 96 16:30:41 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA20419; Wed, 29 May 1996 16:27:26 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA20151; Wed, 29 May 1996 16:27:25 -0700 Received: by gw.home.vix.com id QAA13924; Wed, 29 May 1996 16:27:24 -0700 Date: Wed, 29 May 1996 16:27:24 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 1851) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... Organization: Vixie Enterprises Message-Id: References: <9605281325.AA08378@cichlid.raleigh.ibm.com> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: narten@VNET.IBM.COM's message of 28 May 1996 06:28:36 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On the one hand, I'm not sure that ICMP is "more correct" than UDP when designing a mechanism by which a host may be asked for its name. Doing it with UDP implies that a UNIX host in single user mode won't be willing to tell you its hostname, which strikes me as somehow appropriate. Doing it with UDP implies that multiple host names, perhaps correspondind to variant interfaces, could be returned, whereas the ICMP handler (the kernel, usually) could be expected to know at most one host name (the "real" one). On the other hand, Thomas is quite right that DHCP tries to maintain long term stability in the mapping between MAC addresses and IP addresses. Thus my primary assumption wasn't valid, and I hereby retract my RFC 1788 comments. -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed May 29 16:36:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00618; Wed, 29 May 96 16:36:06 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00612; Wed, 29 May 96 16:35:46 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA21215; Wed, 29 May 1996 16:32:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id QAA21633; Wed, 29 May 1996 16:32:24 -0700 Received: by gw.home.vix.com id QAA14405; Wed, 29 May 1996 16:32:23 -0700 Date: Wed, 29 May 1996 16:32:23 -0700 X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 1852) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... Organization: Vixie Enterprises Message-Id: References: <1834.833301388@munnari.OZ.AU> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: kre@munnari.OZ.AU's message of 28 May 1996 09:39:55 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> And I still think that this is wrong, since it demands parallel databases. > No, it does not. Yes, it does. The allocation and delegation that caused a certain IPv4 address to be assigned to a particular interface can not be different for IPv4 native and IPv6 tunnelled or mapped addresses, unless one of them is wrong. Thus there is a hard requirement that the two databases give identical results when queried. Thanks to Jim Bound, we're done arguing about the mapped addresses since those are clearly local to a host's IPv6 stack and will never appear in DNS anyway. So now we're just down to the IPv6 tunnelling question. > There is no reason they need to be synchronised. Eg: if I were > to run an IPv6 node here at Melbourne (which I may very well do), > I'd want to run the relevant IP6.INT nameserver, and choose the > name by which my node appears to the world, which may be (almost > certainly would be) unrelated to the name it has in the IPv4 > universe. Do we have consensus on that point? (I, at least, strongly disagree.) -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 30 07:57:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00946; Thu, 30 May 96 07:57:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00940; Thu, 30 May 96 07:57:26 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA11162; Thu, 30 May 1996 07:54:09 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA17459; Thu, 30 May 1996 07:54:02 -0700 Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa18742; 30 May 96 10:53 EDT To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: IESG Secretary Subject: (IPng 1853) Last Call: IP Version 6 over PPP to Proposed Standard Date: Thu, 30 May 96 10:53:44 -0400 Message-Id: <9605301053.aa18742@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider "IP Version 6 over PPP" for the status of 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 June 13, 1996. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu May 30 08:31:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00964; Thu, 30 May 96 08:31:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA00958; Thu, 30 May 96 08:31:08 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA15615; Thu, 30 May 1996 08:27:49 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA28674; Thu, 30 May 1996 08:27:26 -0700 Received: from matisse (matisse.ibp.fr [132.227.61.26]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with SMTP id RAA26968 for ; Thu, 30 May 1996 17:27:19 +0200 Date: Thu, 30 May 1996 17:27:19 +0200 Message-Id: <199605301527.RAA26968@ibp.ibp.fr> X-Sender: eh@hera.ibp.fr X-Mailer: Windows Eudora Light Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com From: "Eric HORLAIT (MASI-CNRS)" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk index ipng ---------------------- Professeur Eric HORLAIT ------------------------ Universite Pierre et Marie Curie Tel: 33-1-44-27-73-83 Institut Blaise Pascal - Labo MASI Fax: 33-1-44-27-62-86 4, place Jussieu e-mail: Eric.Horlait@masi.ibp.fr 75252 PARIS Cedex 05 Telex: UPMCSIX 200-145 F http://www-masi-net.ibp.fr/~eh ----------------------------------------------------------------------- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri May 31 09:32:59 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02090; Fri, 31 May 96 09:32:59 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01745; Thu, 30 May 96 18:01:35 PDT Received: from mercury.Sun.COM (mercury.EBay.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA22256; Thu, 30 May 1996 17:58:17 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA08958; Thu, 30 May 1996 00:25:32 -0700 Received: from pride.syd.dms.CSIRO.AU by dmssyd.syd.dms.CSIRO.AU (4.1/5.17) id AA20929; Thu, 30 May 96 17:25:17 EST (from Mark.Andrews@dms.csiro.au (Mark Andrews)) Message-Id: <9605300725.AA20929@dmssyd.syd.dms.CSIRO.AU> To: paul@vix.com (Paul A Vixie) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1854) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of "Wed, 29 May 1996 16:32:23 MST." Date: Thu, 30 May 1996 17:25:15 +1000 From: Mark Andrews Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Paul, by your logic all the le0:X interfaces would have to have the same names. We are talking interface names here not addresses. I could well imagine someone wanting ::1.2.3.4 to be foo-ip6.bar and 1.2.3.4 to be foo.bar. I can see no reason for forcing these to be identical. I would prefer them to be identical however and providing a mechanism that facilitates this would be useful. The alternative could be to look in ip6.int and if you get NXDOMAIN retry in in-addr.arpa. Basically this section of the ip6.int tree would be translucent. Mark -- Mark Andrews, CSIRO Div Maths & Stats Locked Bag 17, North Ryde, NSW 2113, Australia. PHONE: +61 2 325 3148 INTERNET: marka@syd.dms.csiro.au MOBIL: +61 41 942 9884 UUCP:....!uunet!syd.dms.csiro.au!marka ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com