From owner-ipng@sunroof.eng.sun.com Thu May 4 16:33:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e44NJmQ23865 for ipng-dist; Thu, 4 May 2000 16:19:48 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e44NJf723858 for ; Thu, 4 May 2000 16:19:41 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id QAA11426 for ipng@sunroof.eng.sun.com; Thu, 4 May 2000 16:19:15 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e3UEae714658 for ; Sun, 30 Apr 2000 07:36:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA27605 for ; Sun, 30 Apr 2000 07:36:36 -0700 (PDT) Received: from cerberus.nemoto.ecei.tohoku.ac.jp ([130.34.199.67]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27629 for ; Sun, 30 Apr 2000 08:36:35 -0600 (MDT) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id XAA00888; Sun, 30 Apr 2000 23:36:13 +0900 To: ipng@sunroof.eng.sun.com CC: snap-users@kame.net, linux-ipv6@inner.net Subject: socklen_t vs size_t From: Hideaki YOSHIFUJI X-Mailer: Mew version 1.94 on Emacs 20.5 / Mule 4.1 =?iso-2022-jp?B?KBskQjAqGyhCKQ==?= X-URL: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ X-Fingerprint: F7 31 65 99 5E B2 BB A7 15 15 13 23 18 06 A9 6F 57 00 6B 25 X-Pgp5-Key-Url: http://cerberus.nemoto.ecei.tohoku.ac.jp/%7Eyoshfuji/yoshfuji@ecei.tohoku.ac.jp.asc Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Apr_30_23:36:09_2000_446)--" Content-Transfer-Encoding: 7bit Message-Id: <20000430233613H.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Date: Sun, 30 Apr 2000 23:36:13 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 83 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----Next_Part(Sun_Apr_30_23:36:09_2000_446)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, all. Glibc people has recently changed prototypes of getnameinfo() and inet_ntop etc. (size_t -> socklen_t) like this: extern int getnameinfo (__const struct sockaddr *__restrict __sa, socklen_t __salen, char *__restrict __host, socklen_t __hostlen, char *__restrict __serv, socklen_t __servlen, int __flags) __THROW; extern __const char *inet_ntop (int __af, __const void *__cp, char *__buf, socklen_t __len) __THROW; Are the definitions in RFC2553 obsolate as they say? Or, shall POSIX and XPG be changed? Thanks in advance. -- Hideaki YOSHIFUJI Web Page: http://www.ecei.tohoku.ac.jp/%7Eyoshfuji/ PGP5i FP: F731 6599 5EB2 BBA7 1515 1323 1806 A96F 5700 6B25 ----Next_Part(Sun_Apr_30_23:36:09_2000_446)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Return-Path: Return-Path: Received: from ecei.tohoku.ac.jp (eimail.ecei.tohoku.ac.jp [130.34.195.2]) by cerberus.nemoto.ecei.tohoku.ac.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id NAA00432 for ; Sun, 30 Apr 2000 13:32:06 +0900 X-Authentication-Warning: cerberus.nemoto.ecei.tohoku.ac.jp: Host eimail.ecei.tohoku.ac.jp [130.34.195.2] claimed to be ecei.tohoku.ac.jp Received: from cygnus.com (runyon.cygnus.com [205.180.230.5]) by ecei.tohoku.ac.jp (8.9.3/3.7W) with ESMTP id NAA04772 for ; Sun, 30 Apr 2000 13:33:47 +0900 (JST) Received: from otr.mynet (dialin-sv-02.cygnus.com [205.180.231.52]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id VAA06485; Sat, 29 Apr 2000 21:31:56 -0700 (PDT) Received: (from drepper@localhost) by otr.mynet (8.9.3/8.9.3/ud-990718) id VAA15426; Sat, 29 Apr 2000 21:29:46 -0700 Sender: drepper@cygnus.com To: Hideaki YOSHIFUJI Cc: Jakub Jelinek Subject: Re: socklen_t vs size_t References: <20000426114442A.yoshfuji@cerberus.nemoto.ecei.tohoku.ac.jp> Reply-To: drepper@cygnus.com (Ulrich Drepper) X-fingerprint: BE 3B 21 04 BC 77 AC F0 61 92 E4 CB AC DD B9 5A Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Ulrich Drepper Date: 29 Apr 2000 21:29:46 -0700 In-Reply-To: Hideaki YOSHIFUJI's message of "Wed, 26 Apr 2000 11:44:42 +0900" Message-ID: Lines: 20 X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Big Bend" Hideaki YOSHIFUJI writes: > They MUST be > const char *inet_ntop(int af, const void *src, > char *dst, size_t size); > and > int getnameinfo(const struct sockaddr *sa, socklen_t salen, > char *host, size_t hostlen, > char *serv, size_t servlen, > int flags); > as RFC2553 says. This is outdated. The types used for information involving length in all network functions is socklen_t and not size_t. The is from POSIX and XPG. Better update the RFCs. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------ ----Next_Part(Sun_Apr_30_23:36:09_2000_446)---- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 9 08:46:57 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e49FVIp27307 for ipng-dist; Tue, 9 May 2000 08:31:18 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e49FV4727300 for ; Tue, 9 May 2000 08:31:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA12781 for ; Tue, 9 May 2000 08:31:00 -0700 (PDT) Received: from lychee.itojun.org (dhcp0.itojun.org [210.160.95.106]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04072 for ; Tue, 9 May 2000 09:30:49 -0600 (MDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e49FUQE05019; Wed, 10 May 2000 00:30:26 +0900 (JST) To: crawdad@fnal.gov cc: ipng@sunroof.eng.sun.com Subject: icmp-name-lookups-05.txt>: NOOP X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Wed, 10 May 2000 00:30:26 +0900 Message-ID: <5017.957886226@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk icmp-name-lookups-05 says the following. >5.1. NOOP > > This NI type has no defined flags and never has a Data field. A > Reply to a NI NOOP Query tells the Querier that a node with the > Queried Address is up and reachable, implements the Node Information > protocol, and incidentally happens to reveal whether the Queried > Address was an anycast address. However, since these seem to be no Code defined for empty Data field, it is not possible for a Querier to transmit NOOP packet with empty Data field. Definition of NOOP and Code seems, at least, contradictory. Or is the evaluation of Code field dependent to Qtype field? (i.e. we should ignore Code field if Qtype equals to NOOP or Qtype equals to Supported Qtypes) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 12 08:16:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4CEudC29457 for ipng-dist; Fri, 12 May 2000 07:56:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4CEuR729450 for ; Fri, 12 May 2000 07:56:28 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA18217 for ; Fri, 12 May 2000 07:56:24 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03361 for ; Fri, 12 May 2000 07:56:23 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03293; Fri, 12 May 2000 10:56:19 -0400 (EDT) Message-Id: <200005121456.KAA03293@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-rfc2553bis-00.txt Date: Fri, 12 May 2000 10:56:19 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-rfc2553bis-00.txt Pages : 34 Date : 11-May-00 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2553bis-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-rfc2553bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000511124727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2553bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000511124727.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 12 09:35:22 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4CGMb629588 for ipng-dist; Fri, 12 May 2000 09:22:37 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4CGMP729581 for ; Fri, 12 May 2000 09:22:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA17536 for ; Fri, 12 May 2000 09:22:23 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA01019 for ; Fri, 12 May 2000 09:22:12 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA01762 for ; Sat, 13 May 2000 01:22:05 +0900 (JST) to: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: rfc2553bis-00: ip6.arpa? From: itojun@iijlab.net Date: Sat, 13 May 2000 01:22:05 +0900 Message-ID: <1760.958148525@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While I was reading rfc2553bis-00, I noticed that ip6.arpa is referenced already, with no special comment. Was it already decided to use ip6.arpa for A6 reverse query tree? I don't think I saw the announcement... ip6.arpa is still empty (no NS record). itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 12 09:37:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4CGTJI29600 for ipng-dist; Fri, 12 May 2000 09:29:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4CGT9729593 for ; Fri, 12 May 2000 09:29:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA19341 for ; Fri, 12 May 2000 09:29:08 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18289 for ; Fri, 12 May 2000 10:29:04 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4CGSqx31592; Fri, 12 May 2000 18:28:52 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA00688; Fri, 12 May 2000 18:28:51 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA72860; Fri, 12 May 2000 18:30:28 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005121630.SAA72860@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: MOBILE-IP@STANDARDS.NORTELNETWORKS.COM Cc: ipng@sunroof.eng.sun.com Subject: ID mobileip-ipv6-12.txt and Duplicated Address Detection Date: Fri, 12 May 2000 18:30:28 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't like many things in draft-ietf-mobileip-ipv6-12.txt section 10.19: - DAD only for the home address when after it is for all addresses - a wrong duplicate case - the MUST for the unspecified address as source (incorrect because it is not always needed, ugly because the answer will be sent the the all-nodes multicast) - the MUST NOT for DAD when there are some cases DAD could be performed without harm (then it should be performed :-) - nothing about the case when the mobile returns at home during the DAD procedure performed by the home agent. First they are many cases: - the mobile asked for DAD or not in its (previous) home registration - the mobile set a zero or a not zero prefix length in its home registration - the mobile returns at home during the DAD procedure done by the home agent or after, ie a DAD collision is possible or not (*) - the mobile knows or doesn't know the link-layer address of the home agent. (*) the mobile node should know if a DAD collision is possible because the home agent sends the acknowledge after DAD: - Finally, if the Duplicate Address Detection (D) bit is set in the Binding Update, this home agent MUST perform Duplicate Address Detection [27] on the mobile node's home link for the home address in this binding (before returning the Binding Acknowledgement). Note this statement should be changed in order to perform DAD for all addresses if prefix length is not zero as it is described in the prefix length paragraph. --first point-- A summary about DAD procedure: DAD uses NS/NA, NSs are special (source is the unspecified address) and NAs are answers to special NSs (and a bit non-standard too because they are sent to the all-node multicast address). During DAD, special NSs are sent with: - the unspecified address as source - the solicited-node multicast address (of the checked address) as destination - checked address as target - no source link-layer extension On reception of NSs: - if the source is unicast (ie for standard NSs), the NS is discarded - if the source is unspecified (ie for special NSs) and the packet from another node, then there is a duplicate. On reception of NAs: - the checked address is a duplicate. After/without DAD, the only specific processing is for special NSs: a NA must be sent to the all-nodes multicast destination, in order to signal to the other node that the address is already used, with a link-layer address extension (because the destination is a multicast). Then in short DAD has two phases: - DAD itself (special NSs) == "perform DAD" - after DAD or without DAD (answer to special NSs) == "defend for DAD" If the mobile returns at home when the home agent is performing DAD on mobile addresses, then the mobile will answer to special NDs and home registration will fail. I believe it doesn't matter because the mobile has to send a home deregistration but this is another proof that the mobile must deregister before perform a DAD (see after the 4th point). --fifth point-- The proposed solution is to fake a DAD for the home agent address (this is *confusing*) and to get the link-layer address in the NA... ... If the mobile node does Neighbor Solicitation to learn the home agent's link-layer address, in this special case of the mobile node returning home, the mobile node MUST set the Source Address of this Neighbor Solicitation to the unspecified address. I think there are better solutions and they are necessary only with a non-zero prefix length (ie with a zero prefix length the link-local address can be used, checked by DAD, ..., without problems). --third point-- The following statement from ID 12 is wrong: In particular, a Neighbor Solicitation from the mobile node using its home address as the Source Address would be detected by the home agent as a duplicate address. because the DAD is using special NDs. In this case the home agent can log the event (as it should be done for the similar in ARP) but the problem is not a false duplicate. The home address (and others if prefix length is not zero) are proxied by the home agent then the home agent doesn't know how to reach them (in fact it believes they are at the end of an old tunnel or must be discarded) until the home agent processes the home deregistration. This problem occurs only when the mobile needs to do a NS/NA exchange in order to get the home agent link-layer address and hurts only with a non-zero prefix length (which makes all the mobile addresses unusable). --second point-- This statement is not accurate: In addition, when returning home and configuring its home address on its network interface on its home link, the mobile node MUST NOT perform Duplicate Address Detection on its own home address, in order to avoid confusion or conflict with its home agent's use of the same address. In fact, the mobile node may perform DAD but after home deregistration: - the mobile node sends a binding update for home deregistration - the home agent ceases to defend addresses for DAD and flush them from its neighbor cache/proxy server - the home agent does a NS/NA exchange with the mobile node in order to get its link-layer address from its home address - the home agent sends a binding acknowledge for home deregistration - then the mobile node may perform DAD. --fourth point-- Here is a proposal for a better (IMHO) solution for the 3rd point: the mobile recognizes the case (no known link-layer address of the home agent, non-zero prefix length), creates a temporary address with a local interface ID, performs DAD for it (mandatory!) and uses it only for the NS/NA exchange with the home agent. Regards Francis.Dupont@enst-bretagne.fr PS: two remarks: - the DAD procedure itself is short (DupAddrDetectTransmits(1) * RetransTimer(1000ms) ie *one* second for the default) - I don't know whether the zero or the non-zero prefix length is the common case. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 12 10:34:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4CHNuu29729 for ipng-dist; Fri, 12 May 2000 10:23:57 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4CHNh729722 for ; Fri, 12 May 2000 10:23:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA03536 for ; Fri, 12 May 2000 10:23:42 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA27495 for ; Fri, 12 May 2000 11:23:27 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id KAA27143; Fri, 12 May 2000 10:20:59 -0700 (PDT) From: Bill Manning Message-Id: <200005121720.KAA27143@boreas.isi.edu> Subject: Re: rfc2553bis-00: ip6.arpa? To: itojun@iijlab.net Date: Fri, 12 May 2000 10:20:59 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <1760.958148525@coconut.itojun.org> from "itojun@iijlab.net" at May 13, 2000 01:22:05 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk it's still premature. % % While I was reading rfc2553bis-00, I noticed that ip6.arpa is % referenced already, with no special comment. % Was it already decided to use ip6.arpa for A6 reverse query tree? % I don't think I saw the announcement... ip6.arpa is still empty % (no NS record). % % itojun % -------------------------------------------------------------------- % IETF IPng Working Group Mailing List % IPng Home Page: http://playground.sun.com/ipng % FTP archive: ftp://playground.sun.com/pub/ipng % Direct all administrative requests to majordomo@sunroof.eng.sun.com % -------------------------------------------------------------------- % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 13 06:53:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4DD7qM00366 for ipng-dist; Sat, 13 May 2000 06:07:52 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4DD7S700359 for ; Sat, 13 May 2000 06:07:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA11368 for ; Sat, 13 May 2000 06:07:21 -0700 (PDT) Received: from flipper.cisco.com (flipper.cisco.com [171.69.63.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA13007 for ; Sat, 13 May 2000 06:07:21 -0700 (PDT) Received: (fred@localhost) by flipper.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) id GAA12363; Sat, 13 May 2000 06:00:13 -0700 (PDT) Date: Sat, 13 May 2000 06:00:13 -0700 (PDT) From: Fred Baker Message-Id: <200005131300.GAA12363@flipper.cisco.com> To: bound@zk3.dec.com, gilligan@freegate.net, ipng@sunroof.eng.sun.com, rstevens@kohala.com, set@thumper.bellcore.com Subject: draft-ietf-ipngwg-rfc2553bis-00.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I notice that you recently posted a new internet draft. A document that might be worth reading is http://www.ietf.org/ID-nits.html This document was put together by members of the IESG to help the community know what are the most common problems that we see in documents, whether from working groups or individual submissions, and proactively avoid them. Let me know if you have any questions I can answer. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 13 14:52:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4DLDXf00500 for ipng-dist; Sat, 13 May 2000 14:13:33 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4DLD5700493 for ; Sat, 13 May 2000 14:13:07 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA29101 for ; Sat, 13 May 2000 14:12:59 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12903 for ; Sat, 13 May 2000 14:12:59 -0700 (PDT) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id 9913A3ADE; Sat, 13 May 2000 17:12:58 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 50320380D; Sat, 13 May 2000 17:12:58 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id RAA0000890928; Sat, 13 May 2000 17:12:57 -0400 (EDT) From: Jim Bound Message-Id: <200005132112.RAA0000890928@anw.zk3.dec.com> To: Fred Baker Cc: bound@zk3.dec.com, gilligan@freegate.net, ipng@sunroof.eng.sun.com, rstevens@kohala.com, set@thumper.bellcore.com Subject: Re: draft-ietf-ipngwg-rfc2553bis-00.txt In-reply-to: Your message of "Sat, 13 May 2000 06:00:13 PDT." <200005131300.GAA12363@flipper.cisco.com> Date: Sat, 13 May 2000 17:12:57 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I will check it out Fred for sure. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 14 06:30:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4ECdqc00734 for ipng-dist; Sun, 14 May 2000 05:39:52 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4ECde700727 for ; Sun, 14 May 2000 05:39:41 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA03818 for ; Sun, 14 May 2000 05:39:40 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA08231 for ; Sun, 14 May 2000 05:39:40 -0700 (PDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id 79375A16; Sun, 14 May 2000 07:39:39 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id 4E96BA64; Sun, 14 May 2000 07:39:35 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id IAA0000526899; Sun, 14 May 2000 08:39:34 -0400 (EDT) From: Jim Bound Message-Id: <200005141239.IAA0000526899@anw.zk3.dec.com> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis-00: ip6.arpa? In-reply-to: Your message of "Sat, 13 May 2000 01:22:05 +0900." <1760.958148525@coconut.itojun.org> Date: Sun, 14 May 2000 08:39:33 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While I was reading rfc2553bis-00, I noticed that ip6.arpa is referenced already, with no special comment. Was it already decided to use ip6.arpa for A6 reverse query tree? I don't think I saw the announcement... ip6.arpa is still empty (no NS record). This is a done deal. But because it is still empty if we get the spec quickly to a new RFC I will add comment as follows: ------------------------------- Note: ip6.arpa domain at this time is being created but will become the predominant inverse domain, if not there for now use ip6.int. --------------------------------- Or words that the Chairs or ADs would like to see. But I believe we must leave it in for programmers and net managers. regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 14 07:32:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4EDrJb00765 for ipng-dist; Sun, 14 May 2000 06:53:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4EDr2700758 for ; Sun, 14 May 2000 06:53:05 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id GAA25337 for ; Sun, 14 May 2000 06:52:58 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA16746 for ; Sun, 14 May 2000 06:52:55 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id GAA17275; Sun, 14 May 2000 06:46:11 -0700 (PDT) From: Bill Manning Message-Id: <200005141346.GAA17275@boreas.isi.edu> Subject: Re: rfc2553bis-00: ip6.arpa? To: bound@zk3.dec.com (Jim Bound) Date: Sun, 14 May 100 06:46:11 -0700 (PDT) Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com In-Reply-To: <200005141239.IAA0000526899@anw.zk3.dec.com> from "Jim Bound" at May 14, 0 08:39:33 am X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is it really? % % % While I was reading rfc2553bis-00, I noticed that ip6.arpa is % referenced already, with no special comment. % Was it already decided to use ip6.arpa for A6 reverse query tree? % I don't think I saw the announcement... ip6.arpa is still empty % (no NS record). % % This is a done deal. But because it is still empty if we get the spec % quickly to a new RFC I will add comment as follows: % % ------------------------------- % Note: % % ip6.arpa domain at this time is being created but will become the % predominant inverse domain, if not there for now use ip6.int. % % --------------------------------- % % Or words that the Chairs or ADs would like to see. % % But I believe we must leave it in for programmers and net managers. % % regards, % /jim % -------------------------------------------------------------------- % IETF IPng Working Group Mailing List % IPng Home Page: http://playground.sun.com/ipng % FTP archive: ftp://playground.sun.com/pub/ipng % Direct all administrative requests to majordomo@sunroof.eng.sun.com % -------------------------------------------------------------------- % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 14 09:49:05 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4EFxpu00826 for ipng-dist; Sun, 14 May 2000 08:59:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4EFxY700819 for ; Sun, 14 May 2000 08:59:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA05269 for ; Sun, 14 May 2000 08:59:27 -0700 (PDT) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA28749 for ; Sun, 14 May 2000 09:59:26 -0600 (MDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.3/8.9.3) id LAA03456 for ipng@sunroof.eng.sun.com; Sun, 14 May 2000 11:59:26 -0400 (EDT) Date: Sun, 14 May 2000 11:59:26 -0400 (EDT) From: Scott Bradner Message-Id: <200005141559.LAA03456@newdev.harvard.edu> To: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis-00: ip6.arpa? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While I was reading rfc2553bis-00, I noticed that ip6.arpa is referenced already, with no special comment. Was it already decided to use ip6.arpa for A6 reverse query tree? I don't think I saw the announcement... ip6.arpa is still empty (no NS record). see http://www.iab.org/iab/statement-on-infrastructure-domains.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 15 01:18:41 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4F7kQ201104 for ipng-dist; Mon, 15 May 2000 00:46:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4F7kG701097 for ; Mon, 15 May 2000 00:46:17 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA16137 for ; Mon, 15 May 2000 00:46:15 -0700 (PDT) Received: from mumm.ibr.cs.tu-bs.de (mumm.ibr.cs.tu-bs.de [134.169.34.190]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA20028 for ; Mon, 15 May 2000 00:46:12 -0700 (PDT) Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id JAA21226; Mon, 15 May 2000 09:46:17 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id JAA07539; Mon, 15 May 2000 09:46:09 +0200 Date: Mon, 15 May 2000 09:46:09 +0200 Message-Id: <200005150746.JAA07539@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: ipng@sunroof.eng.sun.com Subject: rfc2553bis-00: nai_strerror() ? Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am sure this has been asked before. But anyway. After writing some code according to RFC 2553, I was wondering why there is no nai_strerror() function which works similar to gai_strerror(). /js -- Juergen Schoenwaelder Technical University Braunschweig Dept. Operating Systems & Computer Networks Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany Fax: +49 531 391 5936 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 15 07:48:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4FERGX01296 for ipng-dist; Mon, 15 May 2000 07:27:16 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4FER5701289 for ; Mon, 15 May 2000 07:27:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA20635 for ; Mon, 15 May 2000 07:27:03 -0700 (PDT) Received: from ztxmail05.ztx.compaq.com (ztxmail05.ztx.compaq.com [161.114.1.209]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26973 for ; Mon, 15 May 2000 07:27:02 -0700 (PDT) Received: by ztxmail05.ztx.compaq.com (Postfix, from userid 12345) id A88CF9FB; Mon, 15 May 2000 09:26:57 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail05.ztx.compaq.com (Postfix) with ESMTP id A0B4B7FC; Mon, 15 May 2000 09:26:56 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id KAA0000701859; Mon, 15 May 2000 10:26:56 -0400 (EDT) From: Jim Bound Message-Id: <200005151426.KAA0000701859@anw.zk3.dec.com> To: Bill Manning Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis-00: ip6.arpa? In-reply-to: Your message of "Sun, 14 May 2000 06:46:11 PDT." <200005141346.GAA17275@boreas.isi.edu> Date: Mon, 15 May 2000 10:26:55 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thats my impression???? is it not? thx /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 15 08:00:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4FEeDD01324 for ipng-dist; Mon, 15 May 2000 07:40:13 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4FEe1701317 for ; Mon, 15 May 2000 07:40:02 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA26763 for ; Mon, 15 May 2000 07:40:01 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04613 for ; Mon, 15 May 2000 07:40:00 -0700 (PDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id HAA16619; Mon, 15 May 2000 07:33:23 -0700 (PDT) From: Bill Manning Message-Id: <200005151433.HAA16619@boreas.isi.edu> Subject: Re: rfc2553bis-00: ip6.arpa? To: bound@zk3.dec.com (Jim Bound) Date: Mon, 15 May 2000 07:33:23 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), ipng@sunroof.eng.sun.com In-Reply-To: <200005151426.KAA0000701859@anw.zk3.dec.com> from "Jim Bound" at May 15, 2000 10:26:55 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % thats my impression???? % % is it not? % % thx % /jim Seems to be coming down from the IAB as a politically driven item. Seems to avoid the issue of the installed resolver base that can actually parse ip6.int, which was added in 1996(ish) and is now in ~10 million nodes. Even if it is deemed to be "correct", it will be decades before the old code is gone and we can kill off the .int entries... just about as long as it took to get the in-addr zone out of the .arpa one. --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 15 08:18:24 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4FF4J501379 for ipng-dist; Mon, 15 May 2000 08:04:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4FF49701372 for ; Mon, 15 May 2000 08:04:09 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA00286; Mon, 15 May 2000 08:04:06 -0700 (PDT) Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05280; Mon, 15 May 2000 09:04:02 -0600 (MDT) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA26410; Mon, 15 May 2000 11:03:59 -0400 Received: from ludwigia.raleigh.ibm.com (ludwigia.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA33312; Mon, 15 May 2000 11:04:00 -0400 Received: from ludwigia.raleigh.ibm.com (localhost [127.0.0.1]) by ludwigia.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id LAA07167; Mon, 15 May 2000 11:01:18 -0400 Message-Id: <200005151501.LAA07167@ludwigia.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com cc: deering@cisco.com (Steve Deering), Bob Hinden , Erik Nordmark Subject: Infrastructure TLDs: .ARPA should be used Date: Mon, 15 May 2000 11:01:18 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear IPng WG: Over the last few months, the IAB has been discussing possible complications stemming from the use of the ".INT" TLD as a location for Internet infrastructure domains. The result of those discussions was a recommendation to the IESG that infrastructure domains be placed in ".ARPA" rather than in ".INT" where feasible. See http://www.iab.org/iab/statement-on-infrastructure-domains.txt for the full recommendation. Earlier this year, the IPng WG discussed the implication and feasibility of placing the new bitstring-based reverse DNS lookup (as described in draft-ietf-ipngwg-dns-lookups-nn.txt) under ".ARPA" instead of ".INT". Subsequently, the IPng Chairs indicated that there was consensus that such a change would create no technical problems and negligible deployment or operational impact at this point in time and that the WG was willing to change its usage of ".INT" to something else if so requested. This note is to formally request that the WG make such a change. That is, based on the IAB recommendation, the IESG requests that the the bitstring-based reverse DNS lookup tree be placed under the ".ARPA" TLD. For the IESG, Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 15 09:17:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4FG3Os01466 for ipng-dist; Mon, 15 May 2000 09:03:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4FG3D701459 for ; Mon, 15 May 2000 09:03:13 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA12189; Mon, 15 May 2000 09:03:06 -0700 (PDT) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA00036; Mon, 15 May 2000 09:03:04 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA12442; Mon, 15 May 2000 09:02:18 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200005151501.LAA07167@ludwigia.raleigh.ibm.com> References: <200005151501.LAA07167@ludwigia.raleigh.ibm.com> Date: Mon, 15 May 2000 09:03:43 -0700 To: Thomas Narten From: Steve Deering Subject: Re: Infrastructure TLDs: .ARPA should be used Cc: ipng@sunroof.eng.sun.com, Bob Hinden , Erik Nordmark Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just to refresh everyone's memory, the request regarding .arpa applies only to the new, bitstring-based reverse DNS entries, *not* the nybble- based entries that are currently in use. There is no intent or proposal to move the nybble-based entries out of .int. A secondary issue that was never formally resolved was what second-level domain to use: .ip6.arpa or .in6-addr.arpa. From the discussion in February, the few people who commented on that all preferred the shorter string (.ip6.arpa), simply because it was fewer characters to type. So I propose we go with ip6.arpa. Any objections (speak quickly)? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 15 09:17:47 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4FG8AJ01476 for ipng-dist; Mon, 15 May 2000 09:08:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4FG81701469 for ; Mon, 15 May 2000 09:08:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA14048 for ; Mon, 15 May 2000 09:07:59 -0700 (PDT) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24078 for ; Mon, 15 May 2000 10:07:57 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id JAA12840 for ; Mon, 15 May 2000 09:07:53 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: Date: Mon, 15 May 2000 09:09:18 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: Fwd: Re: Infrastructure TLDs: .ARPA should be used Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk By the way, that message I just sent was intended for the working group, not for Thomas. I forgot to change the To: field before sending it. Steve >Date: Mon, 15 May 2000 09:03:43 -0700 >To: Thomas Narten >From: Steve Deering >Subject: Re: Infrastructure TLDs: .ARPA should be used >Cc: ipng@sunroof.eng.sun.com, Bob Hinden , Erik Nordmark > >Just to refresh everyone's memory, the request regarding .arpa applies >only to the new, bitstring-based reverse DNS entries, *not* the nybble- >based entries that are currently in use. There is no intent or proposal >to move the nybble-based entries out of .int. > >A secondary issue that was never formally resolved was what second-level >domain to use: .ip6.arpa or .in6-addr.arpa. From the discussion in >February, the few people who commented on that all preferred the shorter >string (.ip6.arpa), simply because it was fewer characters to type. >So I propose we go with ip6.arpa. Any objections (speak quickly)? > >Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 16 05:39:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4GC9Dc02319 for ipng-dist; Tue, 16 May 2000 05:09:13 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4GC90702312 for ; Tue, 16 May 2000 05:09:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA13362; Tue, 16 May 2000 05:08:42 -0700 (PDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA28001; Tue, 16 May 2000 05:08:40 -0700 (PDT) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA00597; Tue, 16 May 2000 05:08:05 -0700 (PDT) From: Bill Manning Message-Id: <200005161208.FAA00597@zephyr.isi.edu> Subject: Re: Infrastructure TLDs: .ARPA should be used To: narten@raleigh.ibm.com (Thomas Narten) Date: Tue, 16 May 2000 05:08:05 -0700 (PDT) Cc: ipng@sunroof.eng.sun.com, deering@cisco.com (Steve Deering), hinden@iprg.nokia.com (Bob Hinden), Erik.Nordmark@eng.sun.com (Erik Nordmark) In-Reply-To: <200005151501.LAA07167@ludwigia.raleigh.ibm.com> from "Thomas Narten" at May 15, 2000 11:01:18 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % Earlier this year, the IPng WG discussed the implication and % feasibility of placing the new bitstring-based reverse DNS lookup (as % described in draft-ietf-ipngwg-dns-lookups-nn.txt) under ".ARPA" % instead of ".INT". Subsequently, the IPng Chairs indicated that there % was consensus that such a change would create no technical problems % and negligible deployment or operational impact at this point in time % and that the WG was willing to change its usage of ".INT" to something % else if so requested. % in 1996, I raised the issue of moving the installed base from in-addr.arpa into the .int domain. The operational impact was that the installed resolver base had the values -hardcoded- and so the impact was pretty high. At that point in time, the IP6 tree was anchored in the IP6.INT zone and -every- resolver since then has these two entries -hardcoded-. At last count, thats over 10 million nodes. While it is technically possible to change, it seems a bit naive to claim "negligable deployment or operational impact" -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 16 05:39:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4GCBMr02328 for ipng-dist; Tue, 16 May 2000 05:11:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4GCBB702321 for ; Tue, 16 May 2000 05:11:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA12255; Tue, 16 May 2000 05:11:10 -0700 (PDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA17464; Tue, 16 May 2000 06:11:08 -0600 (MDT) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id FAA00688; Tue, 16 May 2000 05:10:31 -0700 (PDT) From: Bill Manning Message-Id: <200005161210.FAA00688@zephyr.isi.edu> Subject: Re: Infrastructure TLDs: .ARPA should be used To: deering@cisco.com (Steve Deering) Date: Tue, 16 May 2000 05:10:31 -0700 (PDT) Cc: narten@raleigh.ibm.com (Thomas Narten), ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com (Bob Hinden), Erik.Nordmark@eng.sun.com (Erik Nordmark) In-Reply-To: from "Steve Deering" at May 15, 2000 09:03:43 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % Just to refresh everyone's memory, the request regarding .arpa applies % only to the new, bitstring-based reverse DNS entries, *not* the nybble- % based entries that are currently in use. There is no intent or proposal % to move the nybble-based entries out of .int. What technical reason is there to do this? Or is this politically motivated? % A secondary issue that was never formally resolved was what second-level % domain to use: .ip6.arpa or .in6-addr.arpa. From the discussion in % February, the few people who commented on that all preferred the shorter % string (.ip6.arpa), simply because it was fewer characters to type. % So I propose we go with ip6.arpa. Any objections (speak quickly)? See the previous post to Thos. But, if you insist on fragmenting IPv6 resolution, then i guess ip6.arpa is the least offensive. -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 16 08:17:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4GEwc302507 for ipng-dist; Tue, 16 May 2000 07:58:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4GEwP702500 for ; Tue, 16 May 2000 07:58:25 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA02450; Tue, 16 May 2000 07:58:16 -0700 (PDT) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA27510; Tue, 16 May 2000 08:58:14 -0600 (MDT) Received: by sentry.gw.tislabs.com; id LAA28756; Tue, 16 May 2000 11:00:05 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma028732; Tue, 16 May 00 10:59:08 -0400 Received: from english (clipper.gw.tislabs.com [10.33.1.2]) by clipper.gw.tislabs.com (8.9.3/8.9.1) with SMTP id KAA01826; Tue, 16 May 2000 10:51:21 -0400 (EDT) Message-Id: <4.1.20000516103109.00c99730@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 16 May 2000 10:40:00 -0400 To: Bill Manning , narten@raleigh.ibm.com (Thomas Narten) From: Olafur Gudmundsson Subject: Re: Infrastructure TLDs: .ARPA should be used Cc: ipng@sunroof.eng.sun.com, deering@cisco.com (Steve Deering), hinden@iprg.nokia.com (Bob Hinden), Erik.Nordmark@eng.sun.com (Erik Nordmark) In-Reply-To: <200005161208.FAA00597@zephyr.isi.edu> References: <200005151501.LAA07167@ludwigia.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 08:08 AM 5/16/00 , Bill Manning wrote: >% Earlier this year, the IPng WG discussed the implication and >% feasibility of placing the new bitstring-based reverse DNS lookup (as >% described in draft-ietf-ipngwg-dns-lookups-nn.txt) under ".ARPA" >% instead of ".INT". Subsequently, the IPng Chairs indicated that there >% was consensus that such a change would create no technical problems >% and negligible deployment or operational impact at this point in time >% and that the WG was willing to change its usage of ".INT" to something >% else if so requested. >% > >in 1996, I raised the issue of moving the installed base from >in-addr.arpa into the .int domain. The operational impact was that >the installed resolver base had the values -hardcoded- and so the >impact was pretty high. At that point in time, the IP6 tree was >anchored in the IP6.INT zone and -every- resolver since then has >these two entries -hardcoded-. At last count, thats over 10 million >nodes. While it is technically possible to change, it seems >a bit naive to claim "negligable deployment or operational impact" > This is a great test case for DNAME records and exactly what they where invented for. If these 10M+ resolvers understand DNAME then there is no problem. Even if the resolvers do not understand DNAME's, CNAME records can be used to get the resolvers to the right place. I do not think that the ip6.int domain is going away any time soon, and this may cause some operational problems in the short run but better now than later. Olafur -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 16 20:49:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4H3QXm03190 for ipng-dist; Tue, 16 May 2000 20:26:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4H3QL703183 for ; Tue, 16 May 2000 20:26:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA14974; Tue, 16 May 2000 20:26:15 -0700 (PDT) Received: from postoffice.cisco.com (postoffice.cisco.com [171.69.198.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA11432; Tue, 16 May 2000 21:26:13 -0600 (MDT) Received: from [171.68.181.227] (atlantis-dial-1-95.cisco.com [171.68.181.96]) by postoffice.cisco.com (8.8.7-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id UAA01162; Tue, 16 May 2000 20:25:05 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200005161208.FAA00597@zephyr.isi.edu> References: <200005161208.FAA00597@zephyr.isi.edu> Date: Tue, 16 May 2000 20:24:04 -0700 To: Bill Manning From: Steve Deering Subject: Re: Infrastructure TLDs: .ARPA should be used Cc: narten@raleigh.ibm.com (Thomas Narten), ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com (Bob Hinden), Erik.Nordmark@eng.sun.com (Erik Nordmark) Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:08 AM -0700 5/16/00, Bill Manning wrote: >in 1996, I raised the issue of moving the installed base from >in-addr.arpa into the .int domain. The operational impact was that >the installed resolver base had the values -hardcoded- and so the >impact was pretty high. At that point in time, the IP6 tree was >anchored in the IP6.INT zone and -every- resolver since then has >these two entries -hardcoded-. At last count, thats over 10 million >nodes. While it is technically possible to change, it seems >a bit naive to claim "negligable deployment or operational impact" Bill, >From the email discussion in February, we were led to believe that there was not yet any significant deployment or use of the *bitstring-based* reverse DNS lookup code, and therefore it would be possible to change the hardcoded string used by that *new* code without serious deployment or operational impact. Was that incorrect or has it since become incorrect? >What technical reason is there to do this? >Or is this politically motivated? See the IAB statement cited by Thomas and Scott for the reasons. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 17 03:03:26 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4H9NCY03369 for ipng-dist; Wed, 17 May 2000 02:23:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4H9Mt703362 for ; Wed, 17 May 2000 02:22:56 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA20051; Wed, 17 May 2000 02:22:43 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA17906; Wed, 17 May 2000 03:22:42 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id CAA19741; Wed, 17 May 2000 02:22:38 -0700 (PDT) From: Bill Manning Message-Id: <200005170922.CAA19741@boreas.isi.edu> Subject: Re: Infrastructure TLDs: .ARPA should be used To: deering@cisco.com (Steve Deering) Date: Wed, 17 May 100 02:22:38 -0700 (PDT) Cc: bmanning@ISI.EDU, narten@raleigh.ibm.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com, Erik.Nordmark@eng.sun.com In-Reply-To: from "Steve Deering" at May 16, 0 08:24:04 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % >a bit naive to claim "negligable deployment or operational impact" % % Bill, % % >From the email discussion in February, we were led to believe that there % was not yet any significant deployment or use of the *bitstring-based* % reverse DNS lookup code, and therefore it would be possible to change the % hardcoded string used by that *new* code without serious deployment or % operational impact. Was that incorrect or has it since become incorrect? I beleive that there is limited deployment of the *bitstring-based* DNS code. None the less, the impact is in splitting the lookup. Operationally this will lead to substantial confusion since it will be unclear in which tree the lable is anchored, ip6.int or ip6.arpa. I expect that there will be a call to try and syncronize these two trees, which will fail. The confusion will impact the deployment of IP6. % >What technical reason is there to do this? % >Or is this politically motivated? % See the IAB statement cited by Thomas and Scott for the reasons. Ah... ok. no real technical reason for the requested change. % Steve % % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 17 07:11:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4HDl6M03523 for ipng-dist; Wed, 17 May 2000 06:47:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4HDki703516 for ; Wed, 17 May 2000 06:46:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA00882; Wed, 17 May 2000 06:45:44 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03159; Wed, 17 May 2000 07:45:22 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA08086; Wed, 17 May 2000 08:45:17 -0500 (CDT) Message-Id: <200005171345.IAA08086@gungnir.fnal.gov> To: Bill Manning Cc: deering@cisco.com (Steve Deering), narten@raleigh.ibm.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com, Erik.Nordmark@eng.sun.com From: "Matt Crawford" Subject: Re: Infrastructure TLDs: .ARPA should be used In-reply-to: Your message of Wed, 17 May 0100 02:22:38 PDT. <200005170922.CAA19741@boreas.isi.edu> Date: Wed, 17 May 2000 08:45:17 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I beleive that there is limited deployment of the *bitstring-based* > DNS code. None the less, the impact is in splitting the lookup. Operationally > this will lead to substantial confusion since it will be unclear in which > tree the lable is anchored, ip6.int or ip6.arpa. I expect that there will > be a call to try and syncronize these two trees, which will fail. > The confusion will impact the deployment of IP6. Even I think you're overestimating the potential for confusion. But no matter -- every implementation that understands bitstring labels will understand the DNAME record, and 16 DNAME records just under ip6.arpa will make the confusion you fear moot. 0.ip6.arpa. 999999 IN DNAME 0.ip6.int. ; etc ... This, as you know, won't interfere with any data under \[b0].ip6.arpa. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 17 07:25:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4HE2aH03546 for ipng-dist; Wed, 17 May 2000 07:02:36 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4HE2L703539 for ; Wed, 17 May 2000 07:02:22 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA02818 for ; Wed, 17 May 2000 07:02:20 -0700 (PDT) Received: from lychee.itojun.org (dhcp0.itojun.org [210.160.95.106]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA12895 for ; Wed, 17 May 2000 08:02:18 -0600 (MDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e4HDX8f04271; Wed, 17 May 2000 22:33:08 +0900 (JST) cc: ipng@sunroof.eng.sun.com to: crawdad@fnal.gov X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: ipngwg-icmp-name-lookups-05: dns compression From: Jun-ichiro itojun Hagino Date: Wed, 17 May 2000 22:33:08 +0900 Message-ID: <4269.958570388@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, again I have couple of questions about name-lookups-05. if we (as ipngwg) are more likely to go to multicast DNS than icmp name lookup, please tell us so - we at KAME are very interested in zeroconf-oriented configurations and love to provide/test common local name lookup mechanisms without config twists. itojun 1. DNS compression the draft uses DNS wire format (as defined in RFC1035) in two places; subject DNS name in queries (very last paragraph in section 3), and DNS names in replies (5.3). My question is: if we are to use DNS message compression (RFC1035 4.1.4), where should we count offset from? Will it be the beginning of ICMPv6 message, or beginning of the part formatted by DNS wire format? or is DNS message compression is not permitted at all? 2. restriction on IPv6 destination address for validation on receiving side, section 4 says like the folloing: > Upon receiving a NI Query, the Responder must check the Query's IPv6 > destination address and discard the Query without further processing > unless it is one of the Responder's unicast or anycast addresses, a > NI Group Address for a name belonging to the Responder, or a NI > Group Address for a name for which the Responder is providing proxy > service. considering that ICMPv6 specification recommends a node to reply to ICMPv6 echo request toward multicast destination, I'm not sure if the above restriction buys us much protection. I can query hostnames for all nodes in the site, by the following steps: - ping6 ff05::1 - for all nodes answered, send node information query, with subject address (equal to IPv6 destination) I agree that icmp6 to wide-area multicast would be insecure, however, at least name-lookup draft is not very consistent with ICMPv6 RFC. Also, we find name lookup queries to ff02::1 very useful as debugging tool. How about permitting these? - unicast address - anycast address - link-local multicast addresses the node joins the last item is less strict than 05 draft. sender rule needs to be changed too if we take this route. 4. Subject address validation for validation on receiving side, section 4 says like the folloing: > A Responder must also silently discard a Query whose > Subject Address or Name (in the Data field) does not belong to that > node, unless it is providing proxy service for that Subject. A > single-component Subject Name matches any fully-qualified name whose > first label matches the Subject. All name matching is done in a > case-independent manner. What defines "address belongs to node"? for example, is "::1" valid as subject address? all IPv6 nodes supposed to have ::1 on loopback interface, so ::1 is valid for all nodes. Is a query packet with empty Subject valid? what should the code field be? also, we may have scope issue here. What should happen in the following cases: - if you got node information query from/to global IPv6 address, with link-local subject address for your node - if we got query from/to link-local address on interface A, with link-local subject address for interface B - if your (receiving) node node offers proxy service, and you've got scoped subject address in a query packet, how should we interpret the subject address? what is the suggested behavior? 5. code field on queries again, I don't understand how should a responding node must validate code field and subject field in the query message. (this is a recap) I'm not sure about the following: - what should be put into code field when subject part needs to be empty (NOOP, supported qtypes) - if it is legal to leave Subject portion of query empty, what should be put into code field? Basically, I think we'd need a table of valid combinations. the text leaves many cases unanswered. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 17 08:01:17 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4HEgdo03594 for ipng-dist; Wed, 17 May 2000 07:42:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4HEgR703587 for ; Wed, 17 May 2000 07:42:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA07346 for ; Wed, 17 May 2000 07:42:20 -0700 (PDT) Received: from oak.cats.ohiou.edu (oak.cats.ohiou.edu [132.235.8.44]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA06960 for ; Wed, 17 May 2000 08:42:18 -0600 (MDT) Received: from dolphin (dhcp-196-126.cns.ohiou.edu [132.235.196.126]) by oak.cats.ohiou.edu (8.9.3/8.9.3) with ESMTP id KAA08542 for ; Wed, 17 May 2000 10:42:17 -0400 (EDT) From: "Vitali A. Chipitsyn" Date: Wed, 17 May 2000 10:43:31 -0400 To: IPNG WG Subject: Re: Infrastructure TLDs: .ARPA should be used In-Reply-To: <200005171345.IAA08086@gungnir.fnal.gov> References: <200005171345.IAA08086@gungnir.fnal.gov> Your message of Wed, 17 May 0100 02:22:38 PDT. <200005170922.CAA19741@boreas.isi.edu> Message-ID: X-Mailer: Execmail for Win32 5.1.1 Build (10) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 17 May 2000 08:45:17 -0500 Matt Crawford wrote: > > I beleive that there is limited deployment of the > *bitstring-based* > > DNS code. None the less, the impact is in splitting the lookup. > Operationally > > this will lead to substantial confusion since it will be unclear in > which > > tree the lable is anchored, ip6.int or ip6.arpa. I expect that there > will > > be a call to try and syncronize these two trees, which will fail. > > The confusion will impact the deployment of IP6. > > Even I think you're overestimating the potential for confusion. But > no matter -- every implementation that understands bitstring labels > will understand the DNAME record, and 16 DNAME records just under > ip6.arpa will make the confusion you fear moot. I agree with Matt that there is not much of a confusion if DNAME is used. However, I have run into the problem of reaching the 512 bytes limit on DNS UDP packets very quickly. We have 3 hierarchical levels within our site's IPv6 address space and use a fake ip6.int domain which means that *no* public topology hierarchical levels are defined. Therefore, adding another level of indirection brings us closer to the 512 bytes limit. I know that there have been attempts to solve this limit, but I am outdated on their status. Also, existence of this 512 bytes limit is another argument to using ip6.arpa as opposed to in6-addr.arpa. --vc > > 0.ip6.arpa. 999999 IN DNAME 0.ip6.int. > ; etc ... > > This, as you know, won't interfere with any data under \[b0].ip6.arpa. > > Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 17 08:12:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4HEwVt03636 for ipng-dist; Wed, 17 May 2000 07:58:31 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4HEwJ703629 for ; Wed, 17 May 2000 07:58:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA09528; Wed, 17 May 2000 07:58:08 -0700 (PDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA19177; Wed, 17 May 2000 07:58:06 -0700 (PDT) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id HAA08081; Wed, 17 May 2000 07:57:22 -0700 (PDT) From: Bill Manning Message-Id: <200005171457.HAA08081@zephyr.isi.edu> Subject: Re: Infrastructure TLDs: .ARPA should be used To: crawdad@fnal.gov (Matt Crawford) Date: Wed, 17 May 2000 07:57:22 -0700 (PDT) Cc: bmanning@ISI.EDU (Bill Manning), deering@cisco.com (Steve Deering), narten@raleigh.ibm.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com, Erik.Nordmark@eng.sun.com In-Reply-To: <200005171345.IAA08086@gungnir.fnal.gov> from "Matt Crawford" at May 17, 2000 08:45:17 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % > I beleive that there is limited deployment of the *bitstring-based* % > DNS code. None the less, the impact is in splitting the lookup. Operationally % > this will lead to substantial confusion since it will be unclear in which % > tree the lable is anchored, ip6.int or ip6.arpa. I expect that there will % > be a call to try and syncronize these two trees, which will fail. % > The confusion will impact the deployment of IP6. % % Even I think you're overestimating the potential for confusion. But % no matter -- every implementation that understands bitstring labels % will understand the DNAME record, and 16 DNAME records just under % ip6.arpa will make the confusion you fear moot. % % 0.ip6.arpa. 999999 IN DNAME 0.ip6.int. % ; etc ... % % This, as you know, won't interfere with any data under \[b0].ip6.arpa. % % Matt I hope you are right. I remain unconvinced. Deployment of new code is not all that quick. nearly 20% of the installed base is still running pre 4.9 code... :( And since the remaining 80% are running code that supports useful IP6 RR types, it will be operationally interesting to tell thousands of operators that due to a marginal political -potential- disagreement, they must upgrade to support new RR types. Or if your statement is that they won't know or care since only the ip6.arpa server has to know, that is only marginally palateable, since the many thousands of trees and much education over the past five years has gone into training people where the IP6 tree is anchored. Rooting this out is not a negligable thing from an operational perspective. May I direct all queries for clarification on this issue over the next five years to these in favor of this change? Surely if it has the characteristics imputed to it, this should not be an onurus request. :) --bill --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 17 10:22:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4HH7iB03750 for ipng-dist; Wed, 17 May 2000 10:07:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4HH7Z703743 for ; Wed, 17 May 2000 10:07:35 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA00635 for ; Wed, 17 May 2000 10:07:18 -0700 (PDT) Received: from da1server.martin.fl.us (da1server.martin.fl.us [198.136.32.5]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19033 for ; Wed, 17 May 2000 10:07:16 -0700 (PDT) Received: from localhost (gmaxwell@localhost) by da1server.martin.fl.us (8.8.8/8.8.8) with SMTP id NAA12669; Wed, 17 May 2000 13:05:11 -0400 (EDT) Date: Wed, 17 May 2000 13:05:10 -0400 (EDT) From: Greg Maxwell X-Sender: gmaxwell@da1server To: "Vitali A. Chipitsyn" cc: IPNG WG Subject: Re: Infrastructure TLDs: .ARPA should be used In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 17 May 2000, Vitali A. Chipitsyn wrote: [snip] > adding another level of indirection brings us closer to the 512 bytes limit. I know that > there have been attempts to solve this limit, but I am outdated on their status. [snip] I would imagine that the large minimum MTU with IPv6 would the 512 byte limit even less of an issue. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 17 13:05:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4HJoRF03881 for ipng-dist; Wed, 17 May 2000 12:50:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4HJoG703874 for ; Wed, 17 May 2000 12:50:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA15380 for ; Wed, 17 May 2000 12:50:14 -0700 (PDT) Received: from tlnmail1.toplayer.com (mail.TopLayer.com [216.90.225.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA23486 for ; Wed, 17 May 2000 13:49:48 -0600 (MDT) Received: from TopLayer.com (fenway.TopLayer.com [199.103.238.14]) by tlnmail1.toplayer.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id K0JYSHRN; Wed, 17 May 2000 15:49:43 -0400 Message-ID: <3922F7C0.D88CCC5F@TopLayer.com> Date: Wed, 17 May 2000 15:49:20 -0400 From: Frank Solensky Organization: Top Layer Networks X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Greg Maxwell CC: "Vitali A. Chipitsyn" , IPNG WG Subject: Re: Infrastructure TLDs: .ARPA should be used References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greg Maxwell wrote: > > On Wed, 17 May 2000, Vitali A. Chipitsyn wrote: > > [snip] > > adding another level of indirection brings us closer to the 512 bytes limit. I know that > > there have been attempts to solve this limit, but I am outdated on their status. > [snip] > > I would imagine that the large minimum MTU with IPv6 would the 512 byte > limit even less of an issue. It's been a while since I looked but IIRC, DNS still has a 512-byte limit for message sizes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 17 15:45:01 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4HMXRV04102 for ipng-dist; Wed, 17 May 2000 15:33:27 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4HMXG704095 for ; Wed, 17 May 2000 15:33:17 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e4HMXHh315524; Wed, 17 May 2000 15:33:17 -0700 (PDT) Date: Wed, 17 May 2000 15:32:27 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Infrastructure TLDs: .ARPA should be used To: Bill Manning Cc: Steve Deering , narten@raleigh.ibm.com, ipng@sunroof.eng.sun.com, hinden@iprg.nokia.com, Erik.Nordmark@eng.sun.com In-Reply-To: "Your message with ID" <200005170922.CAA19741@boreas.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > % >a bit naive to claim "negligable deployment or operational impact" > % > % Bill, > % > % >From the email discussion in February, we were led to believe that there > % was not yet any significant deployment or use of the *bitstring-based* > % reverse DNS lookup code, and therefore it would be possible to change the > % hardcoded string used by that *new* code without serious deployment or > % operational impact. Was that incorrect or has it since become incorrect? > > I beleive that there is limited deployment of the *bitstring-based* > DNS code. None the less, the impact is in splitting the lookup. Operationally > this will lead to substantial confusion since it will be unclear in which > tree the lable is anchored, ip6.int or ip6.arpa. I expect that there will > be a call to try and syncronize these two trees, which will fail. The > confusion will impact the deployment of IP6. I think similar issues of consistency would be present just because the binary labels are different than the nibble-at-a-time text labels, even if we had kept the binary labels in ip6.int. I don't see how using ip6.arpa for binary labels and ip6.int for the nibble text labels makes maintaining consistency any harder. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 17 17:41:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4I0RfZ04178 for ipng-dist; Wed, 17 May 2000 17:27:41 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4I0RP704171 for ; Wed, 17 May 2000 17:27:27 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA24417 for ; Wed, 17 May 2000 17:27:19 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA22865 for ; Wed, 17 May 2000 18:27:16 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id JAA12150; Thu, 18 May 2000 09:27:02 +0900 (JST) To: Greg Maxwell cc: "Vitali A. Chipitsyn" , IPNG WG In-reply-to: gmaxwell's message of Wed, 17 May 2000 13:05:10 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Infrastructure TLDs: .ARPA should be used From: itojun@iijlab.net Date: Thu, 18 May 2000 09:27:02 +0900 Message-ID: <12148.958609622@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >[snip] >> adding another level of indirection brings us closer to the 512 bytes limit. I know that >> there have been attempts to solve this limit, but I am outdated on their status. >[snip] >I would imagine that the large minimum MTU with IPv6 would the 512 byte >limit even less of an issue. the point is that the DNS server needs to know the client's maximum buffer size. it looks to me that IPv6 transport-ready resolvers is mandatory to support EDNS0 (RFC2671), and attach EDNS0 additional records as necessary. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 17 22:56:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4I5TAH04270 for ipng-dist; Wed, 17 May 2000 22:29:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4I5Sv704263 for ; Wed, 17 May 2000 22:28:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA13244 for ; Wed, 17 May 2000 22:28:55 -0700 (PDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA07613 for ; Wed, 17 May 2000 23:28:55 -0600 (MDT) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id WAA14331; Wed, 17 May 2000 22:28:15 -0700 (PDT) From: Bill Manning Message-Id: <200005180528.WAA14331@zephyr.isi.edu> Subject: Re: Infrastructure TLDs: .ARPA should be used To: gmaxwell@martin.fl.us (Greg Maxwell) Date: Wed, 17 May 2000 22:28:15 -0700 (PDT) Cc: vchipitsyn@acm.org (Vitali A. Chipitsyn), ipng@sunroof.eng.sun.com (IPNG WG) In-Reply-To: from "Greg Maxwell" at May 17, 2000 01:05:10 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % % On Wed, 17 May 2000, Vitali A. Chipitsyn wrote: % % [snip] % > adding another level of indirection brings us closer to the 512 bytes limit. I know that % > there have been attempts to solve this limit, but I am outdated on their status. % [snip] % % I would imagine that the large minimum MTU with IPv6 would the 512 byte % limit even less of an issue. % actually no, the MTU is ~1280 bytes, which turns out to not be quite large enough. :( -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 18 04:24:13 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4IAtGv04416 for ipng-dist; Thu, 18 May 2000 03:55:16 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4IAt4704409 for ; Thu, 18 May 2000 03:55:06 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA08023 for ; Thu, 18 May 2000 03:55:03 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA06601 for ; Thu, 18 May 2000 04:55:02 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02231; Thu, 18 May 2000 06:55:00 -0400 (EDT) Message-Id: <200005181055.GAA02231@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-dns-lookups-08.txt Date: Thu, 18 May 2000 06:54:56 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : DNS Extensions to Support IPv6 Address Aggregation and Renumbering Author(s) : M. Crawford, . Huitema, S. Thomson Filename : draft-ietf-ipngwg-dns-lookups-08.txt Pages : 20 Date : 17-May-00 This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. The changes include a new resource record type to store an IPv6 address in a manner which expedites network renumbering and updated definitions of existing query types that return Internet addresses as part of additional section processing. For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new zone structure which allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-lookups-08.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-dns-lookups-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-dns-lookups-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000517114153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-lookups-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-lookups-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000517114153.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 18 07:07:15 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4IDoex04523 for ipng-dist; Thu, 18 May 2000 06:50:40 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4IDoQ704516 for ; Thu, 18 May 2000 06:50:26 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA01075 for ; Thu, 18 May 2000 06:50:25 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA28673 for ; Thu, 18 May 2000 06:50:23 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id IAA14958; Thu, 18 May 2000 08:50:23 -0500 (CDT) Message-Id: <200005181350.IAA14958@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com cc: namedroppers@ops.ietf.org From: "Matt Crawford" Subject: Re: I-D ACTION:draft-ietf-ipngwg-dns-lookups-08.txt In-reply-to: Your message of Thu, 18 May 2000 06:54:56 EDT. <200005181055.GAA02231@ietf.org> Date: Thu, 18 May 2000 08:50:23 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Differences between -07 and -08 are: IP6.INT -> IP6.ARPA for new style (bit based rather than nibble based) reverse lookups. + Implementers are reminded of the necessity to limit the + amount of work a resolver will perform in response to a + client request. This principle MUST be extended to also + limit the generation of DNS requests in response to one + name-to-address (or address-to-name) lookup request. Fixed a misformatted references. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 18 12:19:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4IJ5ou04879 for ipng-dist; Thu, 18 May 2000 12:05:50 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4IJ5k704872 for ; Thu, 18 May 2000 12:05:46 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id MAA06795 for ipng@sunroof.eng.sun.com; Thu, 18 May 2000 12:05:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4IJ3I704843 for ; Thu, 18 May 2000 12:03:18 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA18109 for ; Thu, 18 May 2000 12:03:17 -0700 (PDT) Received: from baynet.baynetworks.com (ns1.BayNetworks.COM [134.177.3.20]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06553 for ; Thu, 18 May 2000 12:03:15 -0700 (PDT) Received: from mailhost.BayNetworks.COM (h016b.s86b1.BayNetworks.COM [134.177.1.107]) by baynet.baynetworks.com (8.9.1/8.9.1) with ESMTP id MAA01847 for ; Thu, 18 May 2000 12:01:46 -0700 (PDT) Received: from pobox.engeast.BayNetworks.COM (pobox.engeast.baynetworks.com [192.32.61.6]) by mailhost.BayNetworks.COM (8.9.1/8.8.8) with ESMTP id MAA06518 for ; Thu, 18 May 2000 12:01:43 -0700 (PDT) Received: from skibum.engeast (skibum [192.32.138.69]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id PAA05167; Thu, 18 May 2000 15:03:12 -0400 for Received: from localhost by skibum.engeast (SMI-8.6/SMI-SVR4) id PAA27216; Thu, 18 May 2000 15:03:13 -0400 Date: Thu, 18 May 2000 15:03:12 -0400 (EDT) From: Hamayon Mujeeb X-Sender: hmujeeb@skibum To: ipng@sunroof.eng.sun.com Subject: TCPng Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Is there any work being done in the working group on TCP for IPv6 ? Any RFCs or drafts on that ? Thanks Hamayon -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 18 18:31:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4J1GkS05407 for ipng-dist; Thu, 18 May 2000 18:16:46 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4J1GQ705400 for ; Thu, 18 May 2000 18:16:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA16573 for ; Thu, 18 May 2000 18:16:05 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA18015 for ; Thu, 18 May 2000 18:15:48 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA27567; Fri, 19 May 2000 10:15:39 +0900 (JST) To: Hamayon Mujeeb cc: ipng@sunroof.eng.sun.com In-reply-to: hmujeeb's message of Thu, 18 May 2000 15:03:12 -0400. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: TCPng From: itojun@iijlab.net Date: Fri, 19 May 2000 10:15:39 +0900 Message-ID: <27565.958698939@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Is there any work being done in the working group on TCP for >IPv6 ? >Any RFCs or drafts on that ? "TCP on IPv6" is just normal TCP, with pseudo header checksum computation revised. RFC2460 section 8 talks about pseudo header checksum. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 18 23:07:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4J5cmt05473 for ipng-dist; Thu, 18 May 2000 22:38:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4J5cY705466 for ; Thu, 18 May 2000 22:38:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id WAA01834 for ; Thu, 18 May 2000 22:38:29 -0700 (PDT) Received: from plaza.snu.ac.kr (plaza.snu.ac.kr [147.46.10.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27372 for ; Thu, 18 May 2000 23:38:25 -0600 (MDT) Received: from dorm914204 ([147.46.204.90]) by plaza.snu.ac.kr (8.9.3/8.9.3) with SMTP id OAA101704; Fri, 19 May 2000 14:39:05 +0900 Message-ID: <000601bfc154$667328e0$5acc2e93@snu.ac.kr> From: "Oh Chang Hyonsok" To: Cc: References: <27565.958698939@coconut.itojun.org> Subject: Re: TCPng Date: Fri, 19 May 2000 14:38:01 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Then how about the Domain Name? Is there any work being done on the improvement of the Domain Name for IPv6? ----- Original Message ----- From: To: Hamayon Mujeeb Cc: Sent: Friday, May 19, 2000 10:15 AM Subject: Re: TCPng > > >Is there any work being done in the working group on TCP for > >IPv6 ? > >Any RFCs or drafts on that ? > > "TCP on IPv6" is just normal TCP, with pseudo header checksum > computation revised. RFC2460 section 8 talks about pseudo header > checksum. > > itojun > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 19 05:30:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4JBvj405638 for ipng-dist; Fri, 19 May 2000 04:57:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4JBvU705631 for ; Fri, 19 May 2000 04:57:31 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA25235 for ; Fri, 19 May 2000 04:57:26 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA21684 for ; Fri, 19 May 2000 04:56:22 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4JBtsx29988; Fri, 19 May 2000 13:55:54 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id NAA13849; Fri, 19 May 2000 13:55:53 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id NAA16471; Fri, 19 May 2000 13:57:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005191157.NAA16471@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Cc: David Johnson Subject: Duplicate address detection Date: Fri, 19 May 2000 13:57:02 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I need to know if you (mainly implementors) agree with this statement: if the source address of a neighbor solicitation is the unspecified address, this implies that the solicitation is from a node performing DAD for the target address of the solicitation. Regards Francis.Dupont@enst-bretagne.fr PS: reference are RFC 2461 and 2462 (ND and autoconf). PPS: the real question is to know if the procedure proposed in the I-D 12 (last) about mobile IPv6 when a mobile returns at home and doesn't know the link-layer address of the home agent is a DAD or not. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 19 05:52:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4JCPD105649 for ipng-dist; Fri, 19 May 2000 05:25:13 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4JCP3705642 for ; Fri, 19 May 2000 05:25:04 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA15961 for ; Fri, 19 May 2000 05:25:03 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA01820 for ; Fri, 19 May 2000 05:25:03 -0700 (PDT) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id B0C4F5B6A; Fri, 19 May 2000 08:25:02 -0400 (EDT) Received: from yquarry.zk3.dec.com (oquarry.zk3.dec.com [16.140.112.6]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 75D1D38C2; Fri, 19 May 2000 08:25:02 -0400 (EDT) Received: from whitestar.zk3.dec.com by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id IAA0000015871; Fri, 19 May 2000 08:23:01 -0400 (EDT) Received: from localhost by whitestar.zk3.dec.com (5.65v4.0/1.1.19.2/21Apr98-1212PM) id AA08059; Fri, 19 May 2000 08:21:41 -0400 Message-Id: <392531D5.F55E5791@zk3.dec.com> Date: Fri, 19 May 2000 08:21:41 -0400 From: Vladislav Yasevich Organization: Compaq Computer Corporation X-Mailer: Mozilla 4.7 [en] (X11; U; OSF1 V4.0 alpha) X-Accept-Language: en Mime-Version: 1.0 To: Oh Chang Hyonsok Cc: ipng@sunroof.eng.sun.com Subject: Re: TCPng References: <27565.958698939@coconut.itojun.org> <000601bfc154$667328e0$5acc2e93@snu.ac.kr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If you mean DNS, check out draft-ietf-ipngwg-dns-lookups-08 for IPv6 specific resource records. -vlad Oh Chang Hyonsok wrote: > > Then how about the Domain Name? > Is there any work being done on the improvement > of the Domain Name for IPv6? > > ----- Original Message ----- > From: > To: Hamayon Mujeeb > Cc: > Sent: Friday, May 19, 2000 10:15 AM > Subject: Re: TCPng > > > > > >Is there any work being done in the working group on TCP for > > >IPv6 ? > > >Any RFCs or drafts on that ? > > > > "TCP on IPv6" is just normal TCP, with pseudo header checksum > > computation revised. RFC2460 section 8 talks about pseudo header > > checksum. > > > > itojun > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 19 06:49:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4JDXWS05713 for ipng-dist; Fri, 19 May 2000 06:33:32 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4JDXK705706 for ; Fri, 19 May 2000 06:33:21 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA27353 for ; Fri, 19 May 2000 06:33:17 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11365 for ; Fri, 19 May 2000 07:33:13 -0600 (MDT) Received: from nominum.com (shell.nominum.com [204.152.187.59]) by shell.nominum.com (Postfix) with ESMTP id 449F231905; Fri, 19 May 2000 06:32:56 -0700 (PDT) Message-ID: <39254285.5F4AD3DC@nominum.com> Date: Fri, 19 May 2000 06:32:53 -0700 From: "David R. Conrad" Organization: Nominum, Inc. X-Mailer: Mozilla 4.72 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en,ja MIME-Version: 1.0 To: Vladislav Yasevich Cc: Oh Chang Hyonsok , ipng@sunroof.eng.sun.com Subject: Re: TCPng References: <27565.958698939@coconut.itojun.org> <000601bfc154$667328e0$5acc2e93@snu.ac.kr> <392531D5.F55E5791@zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Or bindv9 for an implementation of supporting v6, A6 & DNAME http://www.isc.org/products/BIND/bind9.html Rgds, -drc Vladislav Yasevich wrote: > > If you mean DNS, check out draft-ietf-ipngwg-dns-lookups-08 for > IPv6 specific resource records. > > -vlad > > Oh Chang Hyonsok wrote: > > > > Then how about the Domain Name? > > Is there any work being done on the improvement > > of the Domain Name for IPv6? > > > > ----- Original Message ----- > > From: > > To: Hamayon Mujeeb > > Cc: > > Sent: Friday, May 19, 2000 10:15 AM > > Subject: Re: TCPng > > > > > > > > >Is there any work being done in the working group on TCP for > > > >IPv6 ? > > > >Any RFCs or drafts on that ? > > > > > > "TCP on IPv6" is just normal TCP, with pseudo header checksum > > > computation revised. RFC2460 section 8 talks about pseudo header > > > checksum. > > > > > > itojun > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: http://playground.sun.com/ipng > > > FTP archive: ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > -- > ++++++++++++++++++++++++++++++++++++++++++++++++++++ > Vladislav Yasevich Tel: (603) 884-1079 > Compaq Computer Corp. Fax: (435) 514-6884 > 110 Spit Brook Rd ZK03-3/T07 > Nashua, NH 03062 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 19 11:22:42 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4JIAOk06023 for ipng-dist; Fri, 19 May 2000 11:10:24 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4JIAI706015 for ; Fri, 19 May 2000 11:10:19 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id LAA07329 for ipng@sunroof.eng.sun.com; Fri, 19 May 2000 11:09:37 -0700 (PDT) Received: from locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4JI3l706002 for ; Fri, 19 May 2000 11:03:48 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id e4JI39A26936; Fri, 19 May 2000 11:03:09 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200005191803.e4JI39A26936@locked.eng.sun.com> Subject: Re: Duplicate address detection In-Reply-To: <200005191157.NAA16471@givry.rennes.enst-bretagne.fr> from Francis Dupont at "May 19, 2000 01:57:02 pm" To: Francis Dupont Date: Fri, 19 May 2000 11:03:09 -0700 (PDT) CC: ipng@sunroof.eng.sun.com, David Johnson X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I need to know if you (mainly implementors) agree with this statement: > if the source address of a neighbor solicitation is the unspecified > address, this implies that the solicitation is from a node performing DAD > for the target address of the solicitation. > Agreed. > > PS: reference are RFC 2461 and 2462 (ND and autoconf). > PPS: the real question is to know if the procedure proposed in the > I-D 12 (last) about mobile IPv6 when a mobile returns at home and > doesn't know the link-layer address of the home agent is a DAD > or not. It will be considered as a DAD. Why can't the MN send out a unsolicited neighbor advertisement with the over-ride flag set so that everybody including the home agent can update their caches ? If it is a proxy entry it could even delete the entry. Then learning home agents link layer address is simple. -mohan > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 19 13:33:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4JKJKb06149 for ipng-dist; Fri, 19 May 2000 13:19:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4JKJA706142 for ; Fri, 19 May 2000 13:19:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA16381 for ; Fri, 19 May 2000 13:19:06 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA24177 for ; Fri, 19 May 2000 14:19:05 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 19 May 2000 13:18:51 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Fri, 19 May 2000 13:18:51 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA220C4@RED-MSG-50> From: Richard Draves To: "'Francis Dupont'" , ipng@sunroof.eng.sun.com Cc: David Johnson Subject: RE: Duplicate address detection Date: Fri, 19 May 2000 13:18:47 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I need to know if you (mainly implementors) agree with this statement: > if the source address of a neighbor solicitation is the unspecified > address, this implies that the solicitation is from a node > performing DAD > for the target address of the solicitation. Looking at a receiver's behavior, if the receiver of such a NS is performing DAD for the target address then it will assume that the sending node is performing DAD concurrently and so the receiver will put the target address in the duplicate state. Otherwise the main effect is to cause the NA reply to be multicast to the all-nodes-on-link address. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 19 16:01:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4JMmtU06484 for ipng-dist; Fri, 19 May 2000 15:48:55 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4JMmn706477 for ; Fri, 19 May 2000 15:48:49 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id PAA07591 for ipng@sunroof.eng.sun.com; Fri, 19 May 2000 15:48:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4JM3v706425 for ; Fri, 19 May 2000 15:03:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA04159 for ; Fri, 19 May 2000 15:03:56 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA03091 for ; Fri, 19 May 2000 16:03:53 -0600 (MDT) Received: from penelope.ecs.soton.ac.uk (penelope.ecs.soton.ac.uk [152.78.68.135]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id XAA15099; Fri, 19 May 2000 23:03:52 +0100 (BST) Received: from penelope (penelope [152.78.68.135]) by penelope.ecs.soton.ac.uk (8.9.1a/8.9.1) with ESMTP id XAA04107; Fri, 19 May 2000 23:03:51 +0100 (BST) Date: Fri, 19 May 2000 23:03:51 +0100 (BST) From: Tim Chown To: members@ipv6forum.com cc: ipng@sunroof.eng.sun.com, members@6init.org Subject: Birmingham IPv6 Forum event presentations online Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, The presentations from last week's one-day IPv6 Forum event at Birmingham, England are now online on the IPv6 Forum web site at http://www.ipv6forum.com. In most cases, HTML, Powerpoint and PDF versions of each talk are available. Cheers, Tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 20 08:33:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4KEnxP06845 for ipng-dist; Sat, 20 May 2000 07:49:59 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4KEnm706838 for ; Sat, 20 May 2000 07:49:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA27662; Sat, 20 May 2000 07:49:34 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00167; Sat, 20 May 2000 08:49:32 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4KEnQx55073; Sat, 20 May 2000 16:49:27 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA25625; Sat, 20 May 2000 16:49:25 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id QAA23309; Sat, 20 May 2000 16:50:41 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005201450.QAA23309@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Mohan Parthasarathy cc: ipng@sunroof.eng.sun.com, David Johnson Subject: Re: Duplicate address detection In-reply-to: Your message of Fri, 19 May 2000 11:03:09 PDT. <200005191803.e4JI39A26936@locked.eng.sun.com> Date: Sat, 20 May 2000 16:50:41 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I need to know if you (mainly implementors) agree with this statement: > if the source address of a neighbor solicitation is the unspecified > address, this implies that the solicitation is from a node performing DAD > for the target address of the solicitation. > Agreed. => I've looked at KAME sources and comments show KAME people should agree too. > PS: reference are RFC 2461 and 2462 (ND and autoconf). > PPS: the real question is to know if the procedure proposed in the > I-D 12 (last) about mobile IPv6 when a mobile returns at home and > doesn't know the link-layer address of the home agent is a DAD > or not. It will be considered as a DAD. Why can't the MN send out a unsolicited neighbor advertisement with the over-ride flag set so that everybody including the home agent can update their caches ? => I can see two objections : - the home agent doesn't update its cache (ie this is not in the semantics of unsolicited/overriding NAs (*)) - the mobile MUST send it after home deregistration (end of page 95) If it is a proxy entry it could even delete the entry. Then learning home agents link layer address is simple. => (*) there is a security issue there, home registration is authenticated and should not be partially undone by a simple neighbor discovery packet. I don't believe there is an agreement about changeing the proxy advertisement mechanism in order to make this (overriding of proxy entries by a suitable NA) works but I agree it is a simple solution... Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 22 13:02:54 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4MJmGu08216 for ipng-dist; Mon, 22 May 2000 12:48:16 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4MJmB708209 for ; Mon, 22 May 2000 12:48:11 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id MAA08230 for ipng@sunroof.eng.sun.com; Mon, 22 May 2000 12:47:28 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4LIL1707377 for ; Sun, 21 May 2000 11:21:02 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA25702 for ; Sun, 21 May 2000 11:20:55 -0700 (PDT) Received: from chiark.greenend.org.uk (chiark.greenend.org.uk [195.224.76.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01909 for ; Sun, 21 May 2000 12:20:54 -0600 (MDT) Received: from 392828e9.e0d90.2539.6.bsmtp.davenant.greenend.org.uk by chiark.greenend.org.uk with local-bsmtp (Exim 2.05 #1) id 12taLL-0002VY-00 (Debian); Sun, 21 May 2000 19:20:51 +0100 Received: from ian by davenant.greenend.org.uk with local (Exim 2.125 #2) id 12tZld-00062E-00 (Debian); Sun, 21 May 2000 18:43:57 +0100 From: Ian Jackson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14632.8285.2004.793466@davenant.relativity.greenend.org.uk> Date: Sun, 21 May 2000 18:43:57 +0100 (BST) To: ipng@sunroof.eng.sun.com Subject: IPv6, resolv.conf, RFC2133, etc. X-Mailer: VM 6.62 under Emacs 19.34.1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm working on an alternative resolver library, which is currently in beta (www.chiark.greenend.org.uk/~ian/adns/). I want to add IPv6 support, but it's not entirely clear to me what the appropriate behaviour is in all cases. This mailing list probably isn't quite the right place for my query, but comp.protocols.dns.bind doesn't seem much better, so I hope the WG will forgive the intrusion. If not then please feel free to tell me where else to go. Thanks. I have basically two sets of issues: one is what the syntax of resolv.conf should be (and what extensions in it I should understand); the other is what the resolver behaviour should be in various circumstances. My resolver can parse an additional configuration file, so if it's absolutely necessary the sysadmin can configure adns and libresolv differently, but this involves the admin writing two config files and keeping them in step, so it seems like a bad idea to rely on it. The `easy' part is querying a nameserver via IPv6: if I can parse the resolv.conf to have an IPv6 address in it then I can just open IPv6 UDP and TCP sockets and use them. However, it's not clear to me what syntax I should accept in resolv.conf for this. Should I simply accept the form `nameserver ' ? Supposing IPv6-capable resolvers should use an IPv6-addressable nameserver, but there is an IPv4-addressable nameserver for non-IPv6-capable resolvers, will the sysadmin be able to write something appropriate in the resolv.conf ? What will libresolv do ? If I support IPv6 transport, am I required to support the various DNS extensions (which I don't currently) ? The next most easy thing is querying for AAAA records when the caller explicitly asks for them. The only question there is what order to sort them in. Can I expect the `sortlist' directive to contain both IPv4 and IPv6 addresses, or should I look for a separate `sortlist6' directive or some such ? The hardest thing is when the caller just wants `an address' and I have to decide whether to query for A and/or AAAA, and whether to return IPv4 results as IPv6-mapped. RFC2133 says what libresolv does (or is supposed to do), so I should do something vaguely similar. I'll describe what my current plan is, and you people can tell me whether that's a good idea: By default, unless the programmer specifies IPv6 support when they instantiate adns (or start a query), address lookups will only look for A records and will return them as AF_INET. If the programmer passes the IPv6 flag at init time (or for each query) they are advertising that they're using the IPv6 socket API in RFC2133. adns will then do lookups for AAAA records first, and failing that for A records. If there are no AAAAs but only As, it will return the As as AF_INET6. Additionally, this flag makes queries for A records return them IPv6-mapped too. Optionally, the programmer can choose on a per-query basis never to have IPv4 addresses returned IPv6-mapped; this will mean that A queries always return AF_INET addresses, and that general address queries may return either AF_INET6 or AF_INET addresses (but never both). There has to be some mechanism for the sysadmin to say whether applications which are _compiled_ with IPv6 support should do AAAA lookups and try to use IPv6. Otherwise either applications need to be recompiled according to whether a host has IPv6 connectivity, or they will try to make IPv6 connections when there isn't any and need explicit fallback code (which is tedious, and it's error prone to have every application author implement this). Therefore I propose to have adns never do AAAA queries for general address lookups unless there's a particular option set in resolv.conf, eg `options ipv6capable'. NB that this is _not_ the same as the RES_USE_INET6 option (`options inet6') which is contemplated in RFC2133; I think that the behaviour of that option is so pathological that it can't be used safely. It might be useful to have a system-wide option to do A lookups _as well as_ AAAA lookups, for hosts which are known to have `weird' connectivity. This option shouldn't be set by default, because it effectively requires an extra check for IPv4 addresses for every transaction for ever more. The end result is that I expect a program which just wants to connect to a service would do a lookup for addresses for a name (or a lookup for SRV records, which returns a list of names with a list of addresses for each). They then simply call socket(), connect() on each one until they find one that works. If the application is not IPv6 capable then it will only see IPv4 addresses. If the application is it sets the IPv6 adns initialisation option and it will then see IPv6 addresses if the sysadmin has configured `options ipv6capable' and IPv6-mapped IPv4 addresses otherwise. Comments ? The API I'm thinking of can be seen in the file adns.h on the branch branch-2000-05-07-ipv6 in my cvsweb, which is at http://www.chiark.greenend.org.uk/ucgi/~ijackson/cvsweb/adns/src/adns.h I've included below the diff from the base of that branch. Thanks for any input. Ian. Index: src/adns.h =================================================================== RCS file: /usr/src/CVS/adns/src/adns.h,v retrieving revision 1.77 retrieving revision 1.77.2.1 diff -u -r1.77 -r1.77.2.1 --- src/adns.h 2000/03/20 03:24:25 1.77 +++ src/adns.h 2000/05/07 13:50:08 1.77.2.1 @@ -51,7 +51,7 @@ * Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. * * - * $Id: adns.h,v 1.77 2000/03/20 03:24:25 ian Exp $ + * $Id: adns.h,v 1.77.2.1 2000/05/07 13:50:08 ian Exp $ */ #ifndef ADNS_H_INCLUDED @@ -68,6 +68,10 @@ #include #include +#ifndef AF_INET6 +#include "adns-in6fake.h" +#endif + /* All struct in_addr anywhere in adns are in NETWORK byte order. */ typedef struct adns__state *adns_state; @@ -84,6 +88,7 @@ adns_if_nosigpipe= 0x0040, /* applic has SIGPIPE set to SIG_IGN, do not protect */ adns_if_checkc_entex= 0x0100, /* do consistency checks on entry/exit to adns funcs */ adns_if_checkc_freq= 0x0300 /* do consistency checks very frequently (slow!) */ + adns_if_ip6= 0x1000 /* make default be adns_qf_ip6 */ } adns_initflags; typedef enum { @@ -96,9 +101,44 @@ adns_qf_quotefail_cname= 0x00000080, /* refuse if quote-req chars in CNAME we go via */ adns_qf_cname_loose= 0x00000100, /* allow refs to CNAMEs - without, get _s_cname */ adns_qf_cname_forbid= 0x00000200, /* don't follow CNAMEs, instead give _s_cname */ + adns_qf_ip6= 0x00001000, /* return addrs as AF_INET6 in all cases */ + adns_qf_ip6mixed= 0x00002000, /* return mixture of AF_INET and AF_INET6 */ + adns_qf_ip4= 0x00003000, /* never return AF_INET6, even with _if_ip6 */ adns__qf_internalmask= 0x0ff00000 } adns_queryflags; +/* IPv6 support: + * adns_if_ip6 has the effect of changing the default from + * adns_qf_ip4 to adns_qf_ip6. + * + * query type _qf__ip4 _qf_ip6mixed _qf_ip6 + * + * _r_addr A? => AF_INET AAAA? => AF_INET6 AAAA? => AF_INET6 + * else fail else A? => AF_INET else A? => AF_INET6 + * + * _r_a A => AF_INET A => AF_INET A => AF_INET6 + * + * _r_aaaa AAAA => AF_INET6 AAAA => AF_INET6 AAAA => AF_INET6 + * + * Ie, + * _ip4: only A lookups will be done, and everything is + * returned as AF_INET addresses; + * _ip6mixed: will look for AAAA records first, and if there + * are any, return them as AF_INET6, otherwise like _ip4. + * _ip6: like _ip6mixed, but will return even IPv4 addresses in + * IPv6-mapped form inside AF_INET6, for all query types. + * + * Furthermore, there are configuration options which can prevent the + * use of either AAAA or A records for _r_addr; so it is safe to use + * _qf_ip6 and _r_addr without checking explicitly whether the host + * has IPv6 connectivity. + * + * Applications which do not support IPv4 should set none of these + * flags. Applications which have been `naively' converted to use + * AF_INET6 throughout should set adns_if_ip6. Applications which + * know what they are doing should know which flags to set :-). + */ + typedef enum { adns__rrt_typemask= 0x0ffff, adns__qtf_deref= 0x10000, /* dereference domains and perhaps produce extra data */ @@ -129,6 +169,11 @@ adns_r_rp_raw= 17, adns_r_rp= adns_r_rp_raw|adns__qtf_mail822, + adns_r_aaaa= 28, + + adns_r_srv_raw= 33, + adns_r_srv= adns_r_srv_raw|adns__qtf_deref, + adns_r_addr= adns_r_a|adns__qtf_deref } adns_rrtype; @@ -251,6 +296,7 @@ union { struct sockaddr sa; struct sockaddr_in inet; + struct sockaddr_in6 inet6; } addr; } adns_rr_addr; @@ -290,6 +336,20 @@ } adns_rr_soa; typedef struct { + unsigned short priority; + unsigned short weight; + unsigned short port; + adns_rr_hostaddr ha; +} adns_rr_srv; + +typedef struct { + unsigned short priority; + unsigned short weight; + unsigned short port; + char *target; +} adns_rr_srvraw; + +typedef struct { adns_status status; char *cname; /* always NULL if query was for CNAME records */ char *owner; /* only set if requested in query flags, and may be 0 on error anyway */ @@ -303,12 +363,15 @@ adns_rr_intstr *(*manyistr); /* txt (list of strings ends with i=-1, str=0) */ adns_rr_addr *addr; /* addr */ struct in_addr *inaddr; /* a */ + struct in6_addr *inaddr6; /* aaaa */ adns_rr_hostaddr *hostaddr; /* ns */ adns_rr_intstrpair *intstrpair; /* hinfo */ adns_rr_strpair *strpair; /* rp, rp_raw */ adns_rr_inthostaddr *inthostaddr; /* mx */ adns_rr_intstr *intstr; /* mx_raw */ adns_rr_soa *soa; /* soa, soa_raw */ + adns_rr_srv *srv; /* srv */ + adns_rr_srvraw *srvraw; /* srv_raw */ } rrs; } adns_answer; @@ -424,6 +487,13 @@ * Changes the consistency checking frequency; this overrides the * setting of adns_if_check_entex, adns_if_check_freq, or neither, * in the flags passed to adns_init. + * + * in6only + * in4only + * Return only IPv6, respectively only IPv4 addresses, in + * _rr_addr's. This may result in an adns_s_nodata error, if the + * application only supports, or the remote host only has, the wrong + * kind of address. * * There are a number of environment variables which can modify the * behaviour of adns. They take effect only if adns_init is used, and @@ -508,7 +578,32 @@ void *context, adns_query *query_r); /* type must be _r_ptr or _r_ptr_raw. _qf_search is ignored. - * addr->sa_family must be AF_INET or you get ENOSYS. + * addr->sa_family must be AF_INET or AF_INET6 you get ENOSYS. + */ + +int adns_getaddrinfo(adns_state ads, + const char *name, /* Eg, "www.example.coom" */ + const char *service, /* Eg, "http" */ + const char *protocol, /* Eg, "tcp" */ + unsigned short defaultport, /* Eg, 80 */ + adns_queryflags flags, + adns_answer **answer_r, int *invented_r); +/* Does an SRV lookup (RFC2052). If this fails, tries an AAAA or A + * lookup instead, and if found uses getservbyname to find the port + * number (or failing that, uses defaultport). In the `fallback' + * case, will invent an SRV record with have priority and weight == 0 + * and set *invented_r to 1; if real SRV records were found, will set + * *invented_r to 0. invented_r may be null but answer_r may not be. + * If _getaddrinfo returns nonzero, *answer_r and/or *invented_r may + * or may not have been overwritten and should not be used. + * + * NB, like adns_synchronous, can fail either by returning an errno + * value, or by returning an adns_answer with ->nrrs==0 and + * ->status!=0. + * + * You have to write two loops when using the returned value, an outer + * one to loop over the returned SRV's, and an inner one to loop over + * the addresses for each one. */ int adns_submit_reverse_any(adns_state ads, -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 23 10:29:09 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4NHHuY08769 for ipng-dist; Tue, 23 May 2000 10:17:56 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4NHHq708762 for ; Tue, 23 May 2000 10:17:52 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.3+Sun/8.9.3) id KAA09211 for ipng@sunroof.eng.sun.com; Tue, 23 May 2000 10:17:07 -0700 (PDT) Received: from locked.eng.sun.com (locked [129.146.85.189]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4N1MK708386 for ; Mon, 22 May 2000 18:22:20 -0700 (PDT) Received: (from mohanp@localhost) by locked.eng.sun.com (8.10.1+Sun/8.10.1) id e4N1LgC28822; Mon, 22 May 2000 18:21:42 -0700 (PDT) From: Mohan Parthasarathy Message-Id: <200005230121.e4N1LgC28822@locked.eng.sun.com> Subject: Re: Duplicate address detection In-Reply-To: <200005201450.QAA23309@givry.rennes.enst-bretagne.fr> from Francis Dupont at "May 20, 2000 04:50:41 pm" To: Francis Dupont Date: Mon, 22 May 2000 18:21:41 -0700 (PDT) CC: ipng@sunroof.eng.sun.com, David Johnson X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > PS: reference are RFC 2461 and 2462 (ND and autoconf). > > PPS: the real question is to know if the procedure proposed in the > > I-D 12 (last) about mobile IPv6 when a mobile returns at home and > > doesn't know the link-layer address of the home agent is a DAD > > or not. > It will be considered as a DAD. Why can't the MN send out a > unsolicited neighbor advertisement with the over-ride flag > set so that everybody including the home agent can update > their caches ? > > => I can see two objections : > - the home agent doesn't update its cache (ie this is not in the > semantics of unsolicited/overriding NAs (*)) RFC2461 section 7.2.6 does talk about unsolicited/overriding NAs. Why would not the home agent update its cache entry ? > - the mobile MUST send it after home deregistration (end of page 95) > > If it is a proxy entry it could even delete the entry. Then learning > home agents link layer address is simple. > > => (*) there is a security issue there, home registration is authenticated > and should not be partially undone by a simple neighbor discovery packet. > I don't believe there is an agreement about changeing the proxy advertisement > mechanism in order to make this (overriding of proxy entries by a suitable NA) > works but I agree it is a simple solution... > Ok. If the mobile node solicits for the home agents link layer address with a proper source address (not unspecified) i.e its home address, why would the home agent consider it as a duplicate ? The draft seems to mention that HA will consider it as a duplicate as it is defending for the mobile node. But, unless the source is unspecified this should not happen. -mohan > Regards > > Francis.Dupont@enst-bretagne.fr > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 23 19:40:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4O2J2H09124 for ipng-dist; Tue, 23 May 2000 19:19:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4O2Im709117 for ; Tue, 23 May 2000 19:18:48 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA00418 for ; Tue, 23 May 2000 19:18:46 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA27166 for ; Tue, 23 May 2000 19:18:44 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id LAA15543; Wed, 24 May 2000 11:15:57 +0900 (JST) To: bound@zk3.dec.com cc: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: rfc2553bis-00: NI_NUMERICSCOPE From: itojun@iijlab.net Date: Wed, 24 May 2000 11:15:57 +0900 Message-ID: <15541.959134557@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk in rfc2553bis-00, NI_NUMERICSCOPE is missing from netdb.h decls. the attached diff will correct it. itojun --- draft-ietf-ipngwg-rfc2553bis-00.txt- Wed May 24 11:13:41 2000 +++ draft-ietf-ipngwg-rfc2553bis-00.txt Wed May 24 11:14:12 2000 @@ -1993,6 +1993,7 @@ NI_NOFQDN NI_NUMERICHOST NI_NUMERICSERV + NI_NUMERICSCOPE struct addrinfo{}; IN6ADDR_ANY_INIT -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 02:11:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4O8eGZ09345 for ipng-dist; Wed, 24 May 2000 01:40:16 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4O8e3709338 for ; Wed, 24 May 2000 01:40:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA27722 for ; Wed, 24 May 2000 01:40:00 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA04255 for ; Wed, 24 May 2000 01:39:53 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id RAA23417 for ; Wed, 24 May 2000 17:39:46 +0900 (JST) To: ipng@sunroof.eng.sun.com X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: rfc2292bis: interaction with home address option From: itojun@iijlab.net Date: Wed, 24 May 2000 17:39:46 +0900 Message-ID: <23415.959157586@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, while thinking about interaction between mobile-ip6 and BSD APIs, I came up with the following questions. I still do not have the answer. If you have any working practice I would like to know that. They can be related to future revisions of rfc2292bis. itojun -- when a node A received packet from mobile node B: packet will carry home address of B in home address option (destination options header, and care-of address in IPv6 source - which address should getpeername() return? home address, or care-of? home address sounds like a good default pick, however, some apps may need to look at care-of. - which address should recvfrom() return? ditto. - can we get home address option in IPV6_RECVDSTOPTS? it seems like so. it will have home address of B, not care-of. - then, how can we get care-of address of the peer? (1) new IPV6_RECVxx in rfc2292 advanced API? (2) new system call? -> unacceptable when a mobile node A sends packet to a node B: A may want to control the use of mobile-ip6. examples: (1) if A would like to talk to ubiquitous services like DNS, A may want to use care-of address, not the home address. (2) IKE (to establish key for mobile-ip6) requires it. - how can we avoid use of home address? 1-bit flag in setsockopt? - what is the relationship/interaction with IPV6_PKTINFO? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 03:51:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OAQor09416 for ipng-dist; Wed, 24 May 2000 03:26:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OAQY709409 for ; Wed, 24 May 2000 03:26:36 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA09909 for ; Wed, 24 May 2000 03:26:29 -0700 (PDT) Received: from lychee.itojun.org (dhcp0.itojun.org [210.160.95.106]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA00038 for ; Wed, 24 May 2000 04:26:27 -0600 (MDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.10.0/3.7W) with ESMTP id e4OAP0N12076; Wed, 24 May 2000 19:25:00 +0900 (JST) To: msa@hemuli.tte.vtt.fi (Markku Savela) cc: ipng@sunroof.eng.sun.com In-reply-to: msa's message of Wed, 24 May 2000 13:18:02 +0300. <200005241018.NAA06679@anise.tte.vtt.fi> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: rfc2292bis: interaction with home address option From: Jun-ichiro itojun Hagino Date: Wed, 24 May 2000 19:25:00 +0900 Message-ID: <12074.959163900@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Just some quick answers about what our code would do now... >> - then, how can we get care-of address of the peer? >receive UDP in raw mode and dig in? :) (however, the raw mode is hard >to apply to TCP...) ?? with RFC2292 IPv6 raw socket, this is not possible. (if you pass IPv6 header to the userland, that is not RFC2292 conformant) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 03:51:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OAIdi09406 for ipng-dist; Wed, 24 May 2000 03:18:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OAIM709399 for ; Wed, 24 May 2000 03:18:23 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id DAA03173 for ; Wed, 24 May 2000 03:18:16 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA08856 for ; Wed, 24 May 2000 03:18:13 -0700 (PDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id NAA06679; Wed, 24 May 2000 13:18:02 +0300 (EET DST) Date: Wed, 24 May 2000 13:18:02 +0300 (EET DST) From: Markku Savela Message-Id: <200005241018.NAA06679@anise.tte.vtt.fi> To: itojun@iijlab.net CC: ipng@sunroof.eng.sun.com In-reply-to: <23415.959157586@coconut.itojun.org> Subject: Re: rfc2292bis: interaction with home address option Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just some quick answers about what our code would do now... > when a node A received packet from mobile node B: > packet will carry home address of B in home address option (destination > options header, and care-of address in IPv6 source > - which address should getpeername() return? home address, or care-of? returns home address > - which address should recvfrom() return? returns home address > - then, how can we get care-of address of the peer? receive UDP in raw mode and dig in? :) (however, the raw mode is hard to apply to TCP...) > when a mobile node A sends packet to a node B: > A may want to control the use of mobile-ip6. examples: (1) if A would like > to talk to ubiquitous services like DNS, A may want to use care-of address, > not the home address. (2) IKE (to establish key for mobile-ip6) requires it. > - how can we avoid use of home address? 1-bit flag in setsockopt? > - what is the relationship/interaction with IPV6_PKTINFO? Still open issue for me. Eventually, I too need an answer to this. HTTP is another protocol where one might want to decide whether to use care- or home-address. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 04:45:43 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OBDMG09485 for ipng-dist; Wed, 24 May 2000 04:13:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OBD9709478 for ; Wed, 24 May 2000 04:13:11 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA12786 for ; Wed, 24 May 2000 04:13:09 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA14584 for ; Wed, 24 May 2000 05:12:59 -0600 (MDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id OAA06893; Wed, 24 May 2000 14:11:55 +0300 (EET DST) Date: Wed, 24 May 2000 14:11:55 +0300 (EET DST) From: Markku Savela Message-Id: <200005241111.OAA06893@anise.tte.vtt.fi> To: itojun@iijlab.net CC: ipng@sunroof.eng.sun.com In-reply-to: <12074.959163900@lychee.itojun.org> (message from Jun-ichiro itojun Hagino on Wed, 24 May 2000 19:25:00 +0900) Subject: Re: rfc2292bis: interaction with home address option Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ?? with RFC2292 IPv6 raw socket, this is not possible. > (if you pass IPv6 header to the userland, that is not RFC2292 > conformant) ... promts me to make a query concerning dual IPv4/IPv6 stacks: has anyone given any thoughts about mapping IPv4 into RFC2292 (+bis)? One should be able to write new applications using this API alone (also for IPv4 connections), without any concern about IPv4 or IPv6 (where it is not explicitly required)? For example, some UDP based services (IKE for example), need to know the actual destination address that was used in the incoming UDP packet. In IPv4, the only way to get this was to enable raw mode and dig it out from the packet. I guess for this special need, the packet information of RFC2292bis should work for both IPv4 and IPv6? ..which gets me back to original query: wouldn't the source address packet information contain the care-address in the described scenario? -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 07:47:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OETpP09592 for ipng-dist; Wed, 24 May 2000 07:29:51 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OETf709585 for ; Wed, 24 May 2000 07:29:42 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA29132 for ; Wed, 24 May 2000 07:29:41 -0700 (PDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22627 for ; Wed, 24 May 2000 07:29:41 -0700 (PDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 6D38C786; Wed, 24 May 2000 09:29:40 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id E54DE4D6; Wed, 24 May 2000 09:29:39 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id KAA0000939760; Wed, 24 May 2000 10:29:38 -0400 (EDT) From: Jim Bound Message-Id: <200005241429.KAA0000939760@anw.zk3.dec.com> To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2553bis-00: NI_NUMERICSCOPE In-reply-to: Your message of "Wed, 24 May 2000 11:15:57 +0900." <15541.959134557@coconut.itojun.org> Date: Wed, 24 May 2000 10:29:38 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thanks Itojun.......... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 09:14:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OG3hd09681 for ipng-dist; Wed, 24 May 2000 09:03:43 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OG3T709674 for ; Wed, 24 May 2000 09:03:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA15336 for ; Wed, 24 May 2000 09:03:28 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04553 for ; Wed, 24 May 2000 10:03:27 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id JAA29781; Wed, 24 May 2000 09:02:25 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <23415.959157586@coconut.itojun.org> References: <23415.959157586@coconut.itojun.org> Date: Wed, 24 May 2000 09:04:27 -0700 To: itojun@iijlab.net From: Steve Deering Subject: Re: rfc2292bis: interaction with home address option Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:39 PM +0900 5/24/00, itojun@iijlab.net wrote: >when a node A received packet from mobile node B: >packet will carry home address of B in home address option (destination >options header, and care-of address in IPv6 source >- which address should getpeername() return? home address, or care-of? > home address sounds like a good default pick, however, some apps > may need to look at care-of. Itojun, On the correspondent node, getpeername() should return the home address of the mobile node. This is so most apps can be oblivious to the mobility of the node to which they are speaking. Can you give some examples of why an app on the correspondent node would want or need to know the current care-of address of its peer? >- which address should recvfrom() return? > ditto. The home address. >- can we get home address option in IPV6_RECVDSTOPTS? > it seems like so. it will have home address of B, not care-of. If you really need to receive both addresses for some reason, the care-of address is the one that should be obtainable only via IPV6_RECVDSTOPTS. Logically, the IP layer in the correspondent host should swap the received home address and care-of address before passing the packet to an upper layer. >when a mobile node A sends packet to a node B: >A may want to control the use of mobile-ip6. examples: (1) if A would like >to talk to ubiquitous services like DNS, A may want to use care-of address, >not the home address. (2) IKE (to establish key for mobile-ip6) requires it. >- how can we avoid use of home address? 1-bit flag in setsockopt? This is just another example of the source-address selection problem (as discussed in Rich's draft). When initiating communication, the mobile host must select one of its valid addresses to use as source address. The default behavior, if the application or user doesn't care, would be to use the home address (or one of the home addresses, if there are more than one). But an application, such as the ones you mentioned, can choose to use a different source address, i.e., the temporary care-of address. We should already have whatever API function is needed for the app to specify the source address, so no new flags ought to be needed. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 09:38:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OGRn509713 for ipng-dist; Wed, 24 May 2000 09:27:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OGRc709706 for ; Wed, 24 May 2000 09:27:38 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA23813 for ; Wed, 24 May 2000 09:27:37 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22957 for ; Wed, 24 May 2000 10:27:34 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id BAA00391; Thu, 25 May 2000 01:27:28 +0900 (JST) To: Steve Deering cc: ipng@sunroof.eng.sun.com In-reply-to: deering's message of Wed, 24 May 2000 09:04:27 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: rfc2292bis: interaction with home address option From: itojun@iijlab.net Date: Thu, 25 May 2000 01:27:28 +0900 Message-ID: <389.959185648@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>- which address should getpeername() return? home address, or care-of? >> home address sounds like a good default pick, however, some apps >> may need to look at care-of. >Itojun, >On the correspondent node, getpeername() should return the home address >of the mobile node. This is so most apps can be oblivious to the mobility >of the node to which they are speaking. >Can you give some examples of why an app on the correspondent node would >want or need to know the current care-of address of its peer? >>- which address should recvfrom() return? >> ditto. >The home address. >>- can we get home address option in IPV6_RECVDSTOPTS? >> it seems like so. it will have home address of B, not care-of. >If you really need to receive both addresses for some reason, the care-of >address is the one that should be obtainable only via IPV6_RECVDSTOPTS. >Logically, the IP layer in the correspondent host should swap the received >home address and care-of address before passing the packet to an upper >layer. Yes, I agree that by default only home address should be visible, so getpeername() and recvfrom() should see home address only. Your suggestion, - Swapping received home address option and care-of (in ip6 header) in ip6 layer and - Present care-of address in IPV6_RECVDSTOPTS is a good candidate (this was one of scenario in my mind), however, we need to document it at least. Otherwise we will get low portability. There always are certain applications that needs to peek, or use care-of address. From my limited experience "transparent mobility" is not usually useful, and we need "mobility awareness" in many cases. The best example is IKE traffic used for mobile-ip6 IPsec key. >>when a mobile node A sends packet to a node B: >>A may want to control the use of mobile-ip6. examples: (1) if A would like >>to talk to ubiquitous services like DNS, A may want to use care-of address, >>not the home address. (2) IKE (to establish key for mobile-ip6) requires it. >>- how can we avoid use of home address? 1-bit flag in setsockopt? >This is just another example of the source-address selection problem (as >discussed in Rich's draft). When initiating communication, the mobile >host must select one of its valid addresses to use as source address. >The default behavior, if the application or user doesn't care, would be >to use the home address (or one of the home addresses, if there are >more than one). But an application, such as the ones you mentioned, >can choose to use a different source address, i.e., the temporary >care-of address. We should already have whatever API function is needed >for the app to specify the source address, so no new flags ought to be >needed. Do you suggest that bind(2) should affect the use of home address option? I'm not 100% sure if bind(2) does enough thing for us. If we can assume that we have "home address flag" on every interface address we have, then yes, we can do this: - If we are in home network, use whatever the user have specified with bind(2). - If we are in remote network, - If the address specified by bind(2) is marked as home address, use it with mobile-ip6 dance (attach home address option, use some care-of address in IPv6 source) - If the address is marked as non-home address, emit packet without mobile-ip6. If we take this route, we need a portable way to identify which interface address is home address, and which are not. this should be documented somewhere in 2292bis. Interaction with IPV6_PKTINFO still confuses me. I'm unsure about interaction between IPV6_PKTINFO and bind(2) if we use both (it is not documented in 2292bis-01). I'm even more unsure about its interaction with mobile-ip6. Another example of confusion: interface selection. We have so many ways to specify outgoing interface, or scope zone, when we throw packet to outside: 1. sin6_scope_id field in sendto(2)/sendmsg(2) 2. sin6_scope_id field in connect(2) 3. sin6_scope_id field in bind(2) 4. IPV6_PKTINFO sticky option 5. IPV6_PKTINFO on sendmsg(2) (3) to (5) specify source, but if we use link-local source they would affect the outgoing interface selection. we know (1) overrides (2) in IPv4. other interactions are not defined. FYI, KAME uses the following order (we know this is not in standrd, but this was the best we could come up with): - IPV6_PKTINFO on sendmsg(2) is the strongest - IPV6_PKTINFO on sticky option - address specified by basic API on transmission (one-time option, like sendto) - address put into pcb struct (sticky, like bind/connect) is the weakest itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 10:08:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OH0he09787 for ipng-dist; Wed, 24 May 2000 10:00:43 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OH0V709775 for ; Wed, 24 May 2000 10:00:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA25419 for ; Wed, 24 May 2000 10:00:30 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA20306 for ; Wed, 24 May 2000 11:00:23 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id JAA03108; Wed, 24 May 2000 09:59:26 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <389.959185648@coconut.itojun.org> References: <389.959185648@coconut.itojun.org> Date: Wed, 24 May 2000 10:01:28 -0700 To: itojun@iijlab.net From: Steve Deering Subject: Re: rfc2292bis: interaction with home address option Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:27 AM +0900 5/25/00, itojun@iijlab.net wrote: > Your suggestion, > - Swapping received home address option and care-of (in ip6 header) > in ip6 layer and > - Present care-of address in IPV6_RECVDSTOPTS > is a good candidate (this was one of scenario in my mind), however, we > need to document it at least. Otherwise we will get low portability. I thought that was documented in the Mobile IPv6 spec (but it's been a long time since I read it, so I may just be imagining what is supposed to be there.) > There always are certain applications that needs to peek, or use > care-of address. From my limited experience "transparent mobility" > is not usually useful, and we need "mobility awareness" in many cases. > The best example is IKE traffic used for mobile-ip6 IPsec key. Clearly, the apps on the mobile host itself often need to be aware of their own mobility. But why should apps on the correspondent node have to know anything? And if they do, they should be informed by via their application-layer protocols, not by polling the IP layer about each peer to see if it happens to be mobile. > Do you suggest that bind(2) should affect the use of home address > option? bind should affect the choice of source address. The IP layer is expected to know which of its addresses are home address. Sending a packet on a socket that is bound to a home address, when away from home, should cause the home address option to be added to the packet before transmission. (Note: need to worry about PMTU discovery consequences of inserting options without application's knowledge.) > I'm not 100% sure if bind(2) does enough thing for us. > If we can assume that we have "home address flag" on every interface > address we have, then yes, we can do this: > - If we are in home network, use whatever the user have specified with > bind(2). > - If we are in remote network, > - If the address specified by bind(2) is marked as home address, > use it with mobile-ip6 dance (attach home address option, > use some care-of address in IPv6 source) > - If the address is marked as non-home address, emit packet > without mobile-ip6. > If we take this route, we need a portable way to identify which > interface address is home address, and which are not. this should be > documented somewhere in 2292bis. Yes, the IP layer certainly needs to know which of its addresses are home addresses. I've talked about this a couple times at WG meetings, e.g., see http://playground.sun.com/ipng/presentations/Sep99/PDF/deering-plugnplay.PDF. One approach is to have some sort of user interface (command, button, or whatever is appropriate for the type of device) to tell a node "You are now on your home subnet. Remember these addresses." Another approach might be to have a node look up its own DNS name (which it keeps stored in non-volatile memory) and consider any addresses that come back that don't belong to the currently attached subnet(s) to be its home addresses. This definitely needs to be thought through and written down. I don't have quick answers to the rest of your questions. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 10:08:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OGvYK09748 for ipng-dist; Wed, 24 May 2000 09:57:34 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OGvN709741 for ; Wed, 24 May 2000 09:57:23 -0700 (PDT) Received: from blixten (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e4OGvMh316812; Wed, 24 May 2000 09:57:22 -0700 (PDT) Date: Wed, 24 May 2000 09:56:29 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: rfc2292bis: interaction with home address option To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <23415.959157586@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - which address should getpeername() return? home address, or care-of? > home address sounds like a good default pick, however, some apps > may need to look at care-of. home address Do you have an example application that may need to see the COA? > - which address should recvfrom() return? > ditto. home address > - can we get home address option in IPV6_RECVDSTOPTS? > it seems like so. it will have home address of B, not care-of. We've had some discussion a while back on the topic to what extent the protocol stack must remove options and not pass them up to the application. The main issue back then was the jumbogram option. I think we decided to leave this implementation defined i.e. the stack might choose to remove the jumbogram option or leave it in place. So I think in general 2292bis doesn't state (clarly) what happens to hbh and destination options which the stack actually does some processing on - are they passed to the application or not; and if they are passed to the application must the stack leave the option content exactly in the form it arrived on the wire. > - then, how can we get care-of address of the peer? > (1) new IPV6_RECVxx in rfc2292 advanced API? > (2) new system call? -> unacceptable Seems like first we should decide whether it is a requirement of the API to be able to return this information. Then we can decide what the mechanism should be. > when a mobile node A sends packet to a node B: > A may want to control the use of mobile-ip6. examples: (1) if A would like > to talk to ubiquitous services like DNS, A may want to use care-of address, > not the home address. (2) IKE (to establish key for mobile-ip6) requires it. > - how can we avoid use of home address? 1-bit flag in setsockopt? > - what is the relationship/interaction with IPV6_PKTINFO? Just to clarify: are you talking about the case when A wants to use A's COA as the source instead of A's home address? I assume the bind() socket call can be used to specify the source address to use. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 10:08:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OGxfb09760 for ipng-dist; Wed, 24 May 2000 09:59:41 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OGxR709750 for ; Wed, 24 May 2000 09:59:27 -0700 (PDT) Received: from blixten (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e4OGxPh317055; Wed, 24 May 2000 09:59:25 -0700 (PDT) Date: Wed, 24 May 2000 09:58:32 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: rfc2292bis: interaction with home address option To: Markku Savela Cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200005241111.OAA06893@anise.tte.vtt.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > For example, some UDP based services (IKE for example), need to know > the actual destination address that was used in the incoming UDP > packet. In IPv4, the only way to get this was to enable raw mode and > dig it out from the packet. I guess for this special need, the packet > information of RFC2292bis should work for both IPv4 and IPv6? In IPv4 you can get this with the IP_RECVDESTADDR(sp?) socket option which uses ancillary data just like the IPv6 advanced API options. So it seems like overkill to use the IPv6 API mechanisms in this case. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 10:24:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OHGAI09894 for ipng-dist; Wed, 24 May 2000 10:16:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OHFY709887 for ; Wed, 24 May 2000 10:15:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA29288; Wed, 24 May 2000 10:15:16 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02190; Wed, 24 May 2000 11:15:13 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id CAA01224; Thu, 25 May 2000 02:15:11 +0900 (JST) To: Erik Nordmark cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Wed, 24 May 2000 09:56:29 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: rfc2292bis: interaction with home address option From: itojun@iijlab.net Date: Thu, 25 May 2000 02:15:11 +0900 Message-ID: <1222.959188511@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> - then, how can we get care-of address of the peer? >> (1) new IPV6_RECVxx in rfc2292 advanced API? >> (2) new system call? -> unacceptable >Seems like first we should decide whether it is a requirement of the API >to be able to return this information. >Then we can decide what the mechanism should be. hmm I see. >> when a mobile node A sends packet to a node B: >> A may want to control the use of mobile-ip6. examples: (1) if A would like >> to talk to ubiquitous services like DNS, A may want to use care-of address, >> not the home address. (2) IKE (to establish key for mobile-ip6) requires it. >> - how can we avoid use of home address? 1-bit flag in setsockopt? >> - what is the relationship/interaction with IPV6_PKTINFO? >Just to clarify: are you talking about the case when A wants to use >A's COA as the source instead of A's home address? >I assume the bind() socket call can be used to specify the source address >to use. yes, it was about source address selection (and use of mobile-ip6 options) on node A. see reply to Steve for details. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 10:32:21 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OHMpw09912 for ipng-dist; Wed, 24 May 2000 10:22:51 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OHMd709905 for ; Wed, 24 May 2000 10:22:40 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA05515 for ; Wed, 24 May 2000 10:22:34 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA16816 for ; Wed, 24 May 2000 10:22:32 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id CAA01527; Thu, 25 May 2000 02:22:23 +0900 (JST) To: Steve Deering cc: ipng@sunroof.eng.sun.com In-reply-to: deering's message of Wed, 24 May 2000 10:01:28 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: rfc2292bis: interaction with home address option From: itojun@iijlab.net Date: Thu, 25 May 2000 02:22:23 +0900 Message-ID: <1525.959188943@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Your suggestion, >> - Swapping received home address option and care-of (in ip6 header) >> in ip6 layer and >> - Present care-of address in IPV6_RECVDSTOPTS >> is a good candidate (this was one of scenario in my mind), however, we >> need to document it at least. Otherwise we will get low portability. >I thought that was documented in the Mobile IPv6 spec (but it's been a >long time since I read it, so I may just be imagining what is supposed >to be there.) I don't think there's mention about swapping home and care-of addresses. mobile-ipv6-12 page 12 and 32 have some description, but they uses "substitute" or "replace", which looks to me to overwrite care-of by home address (or the document does not suggest the gory dteail). >> There always are certain applications that needs to peek, or use >> care-of address. From my limited experience "transparent mobility" >> is not usually useful, and we need "mobility awareness" in many cases. >> The best example is IKE traffic used for mobile-ip6 IPsec key. >Clearly, the apps on the mobile host itself often need to be aware of >their own mobility. But why should apps on the correspondent node have >to know anything? And if they do, they should be informed by via their >application-layer protocols, not by polling the IP layer about each peer >to see if it happens to be mobile. hmm, I understood. I may have been confused. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 10:59:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OHo6C09989 for ipng-dist; Wed, 24 May 2000 10:50:06 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OHnt709982 for ; Wed, 24 May 2000 10:49:55 -0700 (PDT) Received: from blixten (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e4OHnrh328755; Wed, 24 May 2000 10:49:53 -0700 (PDT) Date: Wed, 24 May 2000 10:49:00 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: rfc2292bis: interaction with home address option To: itojun@iijlab.net Cc: Steve Deering , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <389.959185648@coconut.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The best example is IKE traffic used for mobile-ip6 IPsec key. Itojun, I don't understand what the requirements are for this case. On a correspondent IKE can just use the home address of the mobile during the IKE exchange, right? (The packets will go to the home agent and be tunneled to be mobile node.) Is this an issue for the IKE exchange between the home agent and the MN? > Do you suggest that bind(2) should affect the use of home address > option? I'm not 100% sure if bind(2) does enough thing for us. > If we can assume that we have "home address flag" on every interface > address we have, then yes, we can do this: You can do it even without an added flag. If the application has bound to a specific IP address (and not in6addr_any) then that address will be used as the source address (and for TCP connections there is an implicit "binding" that occurs when the SYN is sent or received - nothing new here). Thus if app bound (explictly or implicitly) to a home address and the MN is not at home, the home address option would be added by the stack. Otherwise there is no need add it. This does require that the stack distinguishes between its home address(es) and COA(s), but I suspect it needs to make that distinction in any case. > Interaction with IPV6_PKTINFO still confuses me. I'm unsure about > interaction between IPV6_PKTINFO and bind(2) if we use both (it is > not documented in 2292bis-01). I'm even more unsure about its > interaction with mobile-ip6. My assumptions have always been that IPV6_PKTINFO has the same semantics as bind() in this respect. I guess it would make sense to make that explicit in 2292bis. > Another example of confusion: interface selection. We have so many > ways to specify outgoing interface, or scope zone, when we throw packet > to outside: > 1. sin6_scope_id field in sendto(2)/sendmsg(2) > 2. sin6_scope_id field in connect(2) > 3. sin6_scope_id field in bind(2) > 4. IPV6_PKTINFO sticky option > 5. IPV6_PKTINFO on sendmsg(2) > (3) to (5) specify source, but if we use link-local source they > would affect the outgoing interface selection. > we know (1) overrides (2) in IPv4. other interactions are not defined. > FYI, KAME uses the following order (we know this is not in standrd, > but this was the best we could come up with): > - IPV6_PKTINFO on sendmsg(2) is the strongest > - IPV6_PKTINFO on sticky option > - address specified by basic API on transmission (one-time option, like > sendto) > - address put into pcb struct (sticky, like bind/connect) is the weakest Should I just put this order as the recommended order in 2292bis? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 11:29:58 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OIIrs10065 for ipng-dist; Wed, 24 May 2000 11:18:53 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OIIh710058 for ; Wed, 24 May 2000 11:18:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA17363 for ; Wed, 24 May 2000 11:18:42 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA23714 for ; Wed, 24 May 2000 12:18:37 -0600 (MDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 May 2000 11:16:28 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58) id ; Wed, 24 May 2000 11:16:27 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA220F6@RED-MSG-50> From: Richard Draves To: "'itojun@iijlab.net'" , Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: RE: rfc2292bis: interaction with home address option Date: Wed, 24 May 2000 11:16:19 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some comments on this thread... I agree that by default applications should see home addresses not care-of addresses. This is especially true on correspondent nodes. The mobility draft has at various points or times talked about swapping the source address in the IPv6 header and the address in the home address option. This is OK conceptually and I understand that some implementations actually work that way. But at least in our implementation, we treat packet data as read-only. I would not like to see specifications that assumed the swapping really does happen. There is a source address selection problem on mobile nodes: when do you use a home address vs a care-of address? The default source address selection rules as currently specified don't always produce the desired results. (There aren't any special rules or provisions for mobility.) Considering the case of a mobile node initiating a TCP connection to a global address, with a choice of a global home address and a global care-of address, I think the desirable default behavior to use the global home address for the TCP endpoint and insert the home address option (and a binding-update option in the SYN). I think this is the desirable default even if the care-of address and the destination address appear to be topologically closer than the home address and the destination address. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 11:43:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OITH510083 for ipng-dist; Wed, 24 May 2000 11:29:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OIT7710076 for ; Wed, 24 May 2000 11:29:08 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id LAA23073 for ; Wed, 24 May 2000 11:29:06 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA29205 for ; Wed, 24 May 2000 11:29:05 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id LAA09004; Wed, 24 May 2000 11:28:10 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101CA220F6@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101CA220F6@RED-MSG-50> Date: Wed, 24 May 2000 11:30:12 -0700 To: Richard Draves From: Steve Deering Subject: RE: rfc2292bis: interaction with home address option Cc: "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:16 AM -0700 5/24/00, Richard Draves wrote: >The mobility draft has at various points or times talked about swapping the >source address in the IPv6 header and the address in the home address >option. This is OK conceptually and I understand that some implementations >actually work that way. But at least in our implementation, we treat packet >data as read-only. I would not like to see specifications that assumed the >swapping really does happen. There is precedent for address swapping while a packet is in transit: the Routing Header works that way. Granted, no swapping happens at the source or final destination node, in that case. >Considering the case of a mobile node initiating a TCP connection to a >global address, with a choice of a global home address and a global care-of >address, I think the desirable default behavior to use the global home >address for the TCP endpoint and insert the home address option (and a >binding-update option in the SYN). I think this is the desirable default >even if the care-of address and the destination address appear to be >topologically closer than the home address and the destination address. I agree. That way the TCP won't break if and when the mobile moves, which is one of the main reasons for doing mobile IP in the first place. It would also be good if common apps made it very easy for the user to override the default behavior and force use of the COA address as the source, for those cases when the user (a) knows that the destination is "close" and (b) doesn't plan to move before the session ends or doesn't care if a move breaks the session. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 13:21:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OK6Ld10209 for ipng-dist; Wed, 24 May 2000 13:06:21 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OK6B710202 for ; Wed, 24 May 2000 13:06:12 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA18750 for ; Wed, 24 May 2000 13:06:09 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA17764 for ; Wed, 24 May 2000 14:06:07 -0600 (MDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 May 2000 13:05:22 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58) id ; Wed, 24 May 2000 13:05:20 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA220FC@RED-MSG-50> From: Richard Draves To: "'Steve Deering'" Cc: "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: RE: rfc2292bis: interaction with home address option Date: Wed, 24 May 2000 13:05:12 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Considering the case of a mobile node initiating a TCP > connection to a > >global address, with a choice of a global home address and a > global care-of > >address, I think the desirable default behavior to use the > global home > >address for the TCP endpoint and insert the home address > option (and a > >binding-update option in the SYN). I think this is the > desirable default > >even if the care-of address and the destination address appear to be > >topologically closer than the home address and the > destination address. > > I agree. That way the TCP won't break if and when the mobile moves, > which is one of the main reasons for doing mobile IP in the > first place. > > It would also be good if common apps made it very easy for the user to > override the default behavior and force use of the COA address as the > source, for those cases when the user (a) knows that the > destination is > "close" and (b) doesn't plan to move before the session ends > or doesn't > care if a move breaks the session. I can imagine having a "this is short-lived" socket option, and if the app sets the option then the stack would prefer care-of addresses over home addresses instead of the other way around. This is the app telling the stack that your condition (b) holds. I don't see the importance of condition (a). Assuming you send a binding-update in the SYN, then communication using the home address will be relatively efficient - just a little more overhead in the packets, but no extra packets and no packets going through the home agent. The main exception would be when you are dealing with a server that handles lots of short-lived connections - it's binding cache might not work well. So for your short-lived connections to such a server, you'd want to use your care-of address instead of your home address. If this option is going to be useful, it needs to be something that the app can decide - having UI for this would not be good. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 13:33:10 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OKLre10267 for ipng-dist; Wed, 24 May 2000 13:21:53 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OKLe710260 for ; Wed, 24 May 2000 13:21:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA21777 for ; Wed, 24 May 2000 13:21:38 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA29263 for ; Wed, 24 May 2000 14:21:31 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id NAA15916; Wed, 24 May 2000 13:20:36 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101CA220FC@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101CA220FC@RED-MSG-50> Date: Wed, 24 May 2000 13:22:38 -0700 To: Richard Draves From: Steve Deering Subject: RE: rfc2292bis: interaction with home address option Cc: "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 1:05 PM -0700 5/24/00, Richard Draves wrote: > > It would also be good if common apps made it very easy for the user to > > override the default behavior and force use of the COA address as the > > source, for those cases when the user (a) knows that the > > destination is "close" and (b) doesn't plan to move before the session > > ends or doesn't care if a move breaks the session. > >I can imagine having a "this is short-lived" socket option, and if the app >sets the option then the stack would prefer care-of addresses over home >addresses instead of the other way around. This is the app telling the stack >that your condition (b) holds. That sounds like a promising idea. > I don't see the importance of condition (a). I presume another UI option that would be desirable on a mobile node is a "privacy" switch that prevents binding updates from being sent, and also tunnels mobile->correspondent packets via the home agent, so as not to reveal the current (network) location to correspondents. When operating in such a mode, the performance impact of having all of one's packets dogleg-routed through the home agent might be very undesirable, especially when the mobile and correspondent are on one continent and the home agent is on another. Another possible reason for user-specified use of the COA address instead of the home address is to be able to communicate even when the the user's home agent(s) are down or unreachable for whatever reason. I'm not adamant about this, but I think it's worth considering. >If this option is going to be useful, it needs to be something that the app >can decide - having UI for this would not be good. Where the app can make a good enough decision, it should. But I think there should also be a way for users (perhaps only geek users) to override. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 13:57:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OKk4C10368 for ipng-dist; Wed, 24 May 2000 13:46:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OKjj710361 for ; Wed, 24 May 2000 13:45:46 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id NAA16996 for ; Wed, 24 May 2000 13:45:43 -0700 (PDT) Received: from orchard.arlington.ma.us (sommerfeld.ne.mediaone.net [24.147.212.81]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16206 for ; Wed, 24 May 2000 14:45:41 -0600 (MDT) Received: from thunk.hamachi.org (orchard.hamachi.org [4.255.0.98]) by orchard.arlington.ma.us (8.8.8/8.8.8) with ESMTP id QAA05153; Wed, 24 May 2000 16:45:39 -0400 (EDT) Received: from thunk (localhost [[UNIX: localhost]]) by thunk.hamachi.org (8.10.1/8.8.8) with ESMTP id e4OKWV803150; Wed, 24 May 2000 16:32:31 -0400 (EDT) Message-Id: <200005242032.e4OKWV803150@thunk.hamachi.org> From: Bill Sommerfeld To: Steve Deering cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis: interaction with home address option In-Reply-To: Message from Steve Deering of "Wed, 24 May 2000 09:04:27 PDT." Reply-to: sommerfeld@orchard.arlington.ma.us Date: Wed, 24 May 2000 16:32:30 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If you really need to receive both addresses for some reason, the care-of > address is the one that should be obtainable only via IPV6_RECVDSTOPTS. > Logically, the IP layer in the correspondent host should swap the received > home address and care-of address before passing the packet to an upper > layer. This sort of thing gives us security types hives.. Particularly when it comes to knowing which address is which, if, for instance, rfc2401-style policy checks could conceivably happen either before, or after, the swapping... - Bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 14:31:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OLLFw10432 for ipng-dist; Wed, 24 May 2000 14:21:15 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OLL5710425 for ; Wed, 24 May 2000 14:21:06 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA05967 for ; Wed, 24 May 2000 14:21:06 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA12656 for ; Wed, 24 May 2000 14:21:05 -0700 (PDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id OAA19477; Wed, 24 May 2000 14:20:38 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <200005242032.e4OKWV803150@thunk.hamachi.org> References: <200005242032.e4OKWV803150@thunk.hamachi.org> Date: Wed, 24 May 2000 14:22:41 -0700 To: sommerfeld@orchard.arlington.ma.us From: Steve Deering Subject: Re: rfc2292bis: interaction with home address option Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:32 PM -0400 5/24/00, Bill Sommerfeld wrote: > > If you really need to receive both addresses for some reason, the care-of > > address is the one that should be obtainable only via IPV6_RECVDSTOPTS. > > Logically, the IP layer in the correspondent host should swap the received > > home address and care-of address before passing the packet to an upper > > layer. > >This sort of thing gives us security types hives.. Yeah, it gives even us aesthetically-sensitive, non-security types hives. The architecturally clean way to do what Mobile IPv6 does would be for the mobile host to generate an IPv6 packet with source = home addr, dest = correspondent addr, and then encapsulate that in another IPv6 header with source = care-of addr, dest = correspondent addr, in order to get it past the ingress filters at the foreign site. Just another example of tunneling. If it were done that way, the PMTU discovery issue I parenthetically mentioned earlier would become a non-issue (we already know how to make PMTU discovery work through tunnels), and at the receiving correspondent host, the outer header would stripped off (normal tunnel endpoint decapsulation) and the original packet with the home address as source would be delivered to the receiving upper layer. I presume the Mobile IP WG decided to do it differently to avoid the overhead of a full encapsulating header. But perhaps we can think of the required process as doing an encapsulation, as described above, and then performing a weird, mobile-IP-specific type of header compression (inserting an option, moving some addresses, discarding the outer header) at the sender, and then reversing the process at the receiver. Does that help? I didn't think so. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 14:31:23 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OLJOG10417 for ipng-dist; Wed, 24 May 2000 14:19:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OLJE710408 for ; Wed, 24 May 2000 14:19:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA26404 for ; Wed, 24 May 2000 14:19:14 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA11232 for ; Wed, 24 May 2000 15:19:12 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 May 2000 14:18:37 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Wed, 24 May 2000 14:18:36 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA22101@RED-MSG-50> From: Richard Draves To: "'Steve Deering'" Cc: "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: RE: rfc2292bis: interaction with home address option Date: Wed, 24 May 2000 14:18:33 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I presume another UI option that would be desirable on a > mobile node is > a "privacy" switch that prevents binding updates from being sent, and > also tunnels mobile->correspondent packets via the home agent, so as > not to reveal the current (network) location to correspondents. When > operating in such a mode, the performance impact of having > all of one's > packets dogleg-routed through the home agent might be very > undesirable, > especially when the mobile and correspondent are on one continent and > the home agent is on another. This is a good idea, but I don't recall any text in the mobility spec that talks about the mobile sending packets to the correspondent by tunneling to the home agent. (The tunneling right now is in the other direction.) I think it would be a simple addition. > Another possible reason for user-specified use of the COA > address instead > of the home address is to be able to communicate even when > the the user's > home agent(s) are down or unreachable for whatever reason. Certainly, I would hate to be in a position where I can't talk to a local service because my home agent happens be to unreachable at the moment. But if the binding cache on the local server is working well enough to maintain the binding, and the mobile node sends a binding-update proactively with its SYN, then the home agent won't be needed. This should be the common case when the mobile node is initiating the communication. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 14:56:29 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4OLjDH10509 for ipng-dist; Wed, 24 May 2000 14:45:13 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4OLj4710502 for ; Wed, 24 May 2000 14:45:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA19718 for ; Wed, 24 May 2000 14:45:04 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.18.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA00684 for ; Wed, 24 May 2000 15:45:03 -0600 (MDT) Received: from [10.19.130.188] (deering-dsl3.cisco.com [10.19.130.188]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id OAA20987; Wed, 24 May 2000 14:44:35 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8101CA22101@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8101CA22101@RED-MSG-50> Date: Wed, 24 May 2000 14:46:38 -0700 To: Richard Draves From: Steve Deering Subject: RE: rfc2292bis: interaction with home address option Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 2:18 PM -0700 5/24/00, Richard Draves wrote: >This is a good idea, but I don't recall any text in the mobility spec that >talks about the mobile sending packets to the correspondent by tunneling to >the home agent. (The tunneling right now is in the other direction.) I think >it would be a simple addition. I recall this issue coming up for the IPv4 version of mobile IP, and assumed it would apply just a much to IPv6. I really must start reading more specs, rather than just assuming they contain what they ought to contain. :-) I trust the Mobile IPv6 spec authors are on this mailing list and will enlighten us at some point. >But if the binding cache on the local server is working well enough to >maintain the binding, and the mobile node sends a binding-update >proactively with its SYN, then the home agent won't be needed. This >should be the common case when the mobile node is initiating the >communication. A-ha, now I get it. Yes, that would work, subject to the correspondent's willingness and ability to store the binding, as you mentioned before. But I would expect (not knowing for sure because I haven't read the spec) that there is no obligation on the correspondent to store all, or even any, of the bindings it receives. Obviously, we hope most correspondents will do the helpful thing, but particlarly dumb, lazy, or overworked ones would be within their rights to ignore binding updates and always just send via the home agent. But I guess the point you were making was: if most correspondents do the right thing, there will be many fewer occasions when a user-override would be necessary. That I can agree with. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 16:46:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4ONZAo10776 for ipng-dist; Wed, 24 May 2000 16:35:10 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4ONZ0710769 for ; Wed, 24 May 2000 16:35:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA29737 for ; Wed, 24 May 2000 16:35:00 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id RAA10063 for ; Wed, 24 May 2000 17:34:58 -0600 (MDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 May 2000 16:34:40 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2651.58) id ; Wed, 24 May 2000 16:34:40 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA22109@RED-MSG-50> From: Richard Draves To: "'Steve Deering'" Cc: ipng@sunroof.eng.sun.com Subject: RE: rfc2292bis: interaction with home address option Date: Wed, 24 May 2000 16:34:34 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >But if the binding cache on the local server is working well > enough to > >maintain the binding, and the mobile node sends a binding-update > >proactively with its SYN, then the home agent won't be needed. This > >should be the common case when the mobile node is initiating the > >communication. > > A-ha, now I get it. Yes, that would work, subject to the > correspondent's > willingness and ability to store the binding, as you mentioned before. > But I would expect (not knowing for sure because I haven't > read the spec) > that there is no obligation on the correspondent to store > all, or even any, > of the bindings it receives. Obviously, we hope most > correspondents will > do the helpful thing, but particlarly dumb, lazy, or overworked ones > would be within their rights to ignore binding updates and always just > send via the home agent. > > But I guess the point you were making was: if most > correspondents do the > right thing, there will be many fewer occasions when a user-override > would be necessary. That I can agree with. Exactly. The situations where having the app use a "this is short-lived" socket option make the most sense are when the correspondent's binding cache is likely to be ineffective, like non-persistent HTTP connections or DNS (UDP or TCP) queries. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 18:34:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4P1FE611052 for ipng-dist; Wed, 24 May 2000 18:15:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4P1Ex711045 for ; Wed, 24 May 2000 18:15:01 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA19163 for ; Wed, 24 May 2000 18:14:56 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA10485 for ; Wed, 24 May 2000 18:14:55 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA06695; Thu, 25 May 2000 10:14:39 +0900 (JST) To: Richard Draves cc: "'Steve Deering'" , ipng@sunroof.eng.sun.com In-reply-to: richdr's message of Wed, 24 May 2000 13:05:12 MST. <4D0A23B3F74DD111ACCD00805F31D8101CA220FC@RED-MSG-50> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: rfc2292bis: interaction with home address option From: itojun@iijlab.net Date: Thu, 25 May 2000 10:14:39 +0900 Message-ID: <6693.959217279@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I can imagine having a "this is short-lived" socket option, and if the app >sets the option then the stack would prefer care-of addresses over home >addresses instead of the other way around. This is the app telling the stack >that your condition (b) holds. I don't see the importance of condition (a). > >Assuming you send a binding-update in the SYN, then communication using the >home address will be relatively efficient - just a little more overhead in >the packets, but no extra packets and no packets going through the home >agent. Mobile-ip6 requires only one thing to correspondent node: honor home address option. Spec does not require every correspondent node to have binding cache, so binding update in SYN may not work and result in triangle routing. Therefore, I still think this is valuable for mobile node to be able to use care-of as TCP/UDP source address, for short-lived sessions. For me, short-lived sessions include: - local services in remote site the mobile node is visiting access to web cache in remote site it visits, access to printer - use ubiquitous services in remote site (DNS) >The main exception would be when you are dealing with a server that handles >lots of short-lived connections - it's binding cache might not work well. So >for your short-lived connections to such a server, you'd want to use your >care-of address instead of your home address. I suspect that busy web servers will not have (or will not use) the binding cache. The server will not be able to maintain it. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 24 19:00:08 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4P1dJV11087 for ipng-dist; Wed, 24 May 2000 18:39:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4P1d8711080 for ; Wed, 24 May 2000 18:39:08 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA00632; Wed, 24 May 2000 18:39:01 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA07416; Wed, 24 May 2000 19:38:59 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id KAA07210; Thu, 25 May 2000 10:38:58 +0900 (JST) To: Erik Nordmark cc: Steve Deering , ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Wed, 24 May 2000 10:49:00 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: rfc2292bis: interaction with home address option From: itojun@iijlab.net Date: Thu, 25 May 2000 10:38:58 +0900 Message-ID: <7208.959218738@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> The best example is IKE traffic used for mobile-ip6 IPsec key. >I don't understand what the requirements are for this case. >On a correspondent IKE can just use the home address of the mobile during >the IKE exchange, right? (The packets will go to the home agent and >be tunneled to be mobile node.) >Is this an issue for the IKE exchange between the home agent and the MN? sorry again I was confused. IKE traffic for mobile-ip6 key does not carry home address option. this is mobile node who needs to use care-of as source. correspondent node do not need tricks. (mobile-ipv6-12 10.2) >> Do you suggest that bind(2) should affect the use of home address >> option? I'm not 100% sure if bind(2) does enough thing for us. >> If we can assume that we have "home address flag" on every interface >> address we have, then yes, we can do this: >You can do it even without an added flag. >If the application has bound to a specific IP address (and not in6addr_any) >then that address will be used as the source address (and for TCP connections >there is an implicit "binding" that occurs when the SYN is sent or received - >nothing new here). >Thus if app bound (explictly or implicitly) to a home address and the MN >is not at home, the home address option would be added by the stack. >Otherwise there is no need add it. >This does require that the stack distinguishes between its home >address(es) and COA(s), but I suspect it needs to make that >distinction in any case. I meant kernel internal flag by "home address flag", which may or may not be exposed through the API. kernel needs to somehow distinguish its home address from its care-of. I think my wording was not clear enough. >> Another example of confusion: interface selection. We have so many >> ways to specify outgoing interface, or scope zone, when we throw packet >> to outside: >> 1. sin6_scope_id field in sendto(2)/sendmsg(2) >> 2. sin6_scope_id field in connect(2) >> 3. sin6_scope_id field in bind(2) >> 4. IPV6_PKTINFO sticky option >> 5. IPV6_PKTINFO on sendmsg(2) >> (3) to (5) specify source, but if we use link-local source they >> would affect the outgoing interface selection. >> we know (1) overrides (2) in IPv4. other interactions are not defined. >> FYI, KAME uses the following order (we know this is not in standrd, >> but this was the best we could come up with): >> - IPV6_PKTINFO on sendmsg(2) is the strongest >> - IPV6_PKTINFO on sticky option >> - address specified by basic API on transmission (one-time option, like >> sendto) >> - address put into pcb struct (sticky, like bind/connect) is the weakest >Should I just put this order as the recommended order in 2292bis? if there's no conflicting opinion on this, I'm happy with that. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 25 02:56:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4P9I9f11311 for ipng-dist; Thu, 25 May 2000 02:18:09 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4P9Ht711304 for ; Thu, 25 May 2000 02:17:58 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA11532; Thu, 25 May 2000 02:17:52 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA23523; Thu, 25 May 2000 02:17:49 -0700 (PDT) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA12884; Thu, 25 May 2000 18:04:05 +0900 (JST) Date: Thu, 25 May 2000 18:14:36 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: rfc2292bis: outgoing interface selection(Re: rfc2292bis: interaction with home address option) In-Reply-To: In your message of "Wed, 24 May 2000 10:49:00 -0700 (PDT)" References: <389.959185648@coconut.itojun.org> User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 77 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Note: I changed the subject. >>>>> On Wed, 24 May 2000 10:49:00 -0700 (PDT), >>>>> Erik Nordmark said: >> Interaction with IPV6_PKTINFO still confuses me. I'm unsure about >> interaction between IPV6_PKTINFO and bind(2) if we use both (it is >> not documented in 2292bis-01). I'm even more unsure about its >> interaction with mobile-ip6. > My assumptions have always been that IPV6_PKTINFO has the same semantics as > bind() in this respect. I think you two are actually comparing the semantics of sin6_scope_id and the semantics of IPV6_PKTINFO, right? Then, I think that those two are different, at least based on the model described in draft-ipngwg-scoping-arch-01.txt (or draft-ietf-ipngwg-scoping-arch-00.txt...01 seems to be officialy unpublished). Since links are broader scope than interfaces, IPV6_PKTINFO (conceptually) imposes stronger restriction than sin6_scope_id. For example, suppose that two interfaces ne0 and ne1 belong to a same link (and the link only consists of those two interfaces). Then consider the following combinations: 1. sin6_scope_id = 1, without IPV6_PKTINFO (where 1 is the link identifier that contains ne0 and ne1) 2. sin6_scope_id = 0, with IPV6_PKTINFO(ne0) 3. sin6_scope_id = 0, with IPV6_PKTINFO(ne1) In my understanding, the outgoing interface for each case is as follows: 1. ne0 or ne1. It would depend on implementation, or the status of runtime routing table. 2. ne0 3. ne1 >> Another example of confusion: interface selection. We have so many >> ways to specify outgoing interface, or scope zone, when we throw packet >> to outside: >> 1. sin6_scope_id field in sendto(2)/sendmsg(2) >> 2. sin6_scope_id field in connect(2) >> 3. sin6_scope_id field in bind(2) >> 4. IPV6_PKTINFO sticky option >> 5. IPV6_PKTINFO on sendmsg(2) >> (3) to (5) specify source, but if we use link-local source they >> would affect the outgoing interface selection. To make sure: conceptually, all scoped sources (including site-locals) would affect the outgoing interface, when the node is multi-zoned. >> we know (1) overrides (2) in IPv4. other interactions are not defined. >> FYI, KAME uses the following order (we know this is not in standrd, >> but this was the best we could come up with): >> - IPV6_PKTINFO on sendmsg(2) is the strongest >> - IPV6_PKTINFO on sticky option >> - address specified by basic API on transmission (one-time option, like >> sendto) >> - address put into pcb struct (sticky, like bind/connect) is the weakest Basically agreed (actually I implemented the above order :-), but I think we need some additional restrictions. For example, if a scoped address is specified by bind(2) and the outgoing interface specified by IPV6_PKTINFO does not belong to the zone determined by the bound address' sin6_scope_id field, the kernel should not send the packet and return an error. However, I'm not sure these additional rules should be noted in rfc2292bis. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 25 02:56:31 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4P9P9K11321 for ipng-dist; Thu, 25 May 2000 02:25:09 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4P9Ox711314 for ; Thu, 25 May 2000 02:25:00 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id CAA05199; Thu, 25 May 2000 02:24:40 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA13349; Thu, 25 May 2000 03:24:29 -0600 (MDT) Received: from localhost ([3ffe:501:100f:10c1:250:4ff:fefe:d85f]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id SAA12909; Thu, 25 May 2000 18:10:40 +0900 (JST) Date: Thu, 25 May 2000 18:21:11 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: erik.nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: Resend: permission control for IPV6_REACHCONF User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: multipart/mixed; boundary="Multipart_Thu_May_25_18:21:11_2000-1" X-Dispatcher: imput version 980905(IM100) Lines: 65 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Multipart_Thu_May_25_18:21:11_2000-1 Content-Type: text/plain; charset=US-ASCII Hello, I apologize in advance if this email bothers you, but I've not seen any responses to the attached mail. If you don't mind, could you tell us your opinion (or if you have an opinion at all) on this? Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Thu_May_25_18:21:11_2000-1 Content-Type: message/rfc822 Date: Mon, 17 Apr 2000 16:12:10 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: erik.nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: permission control for IPV6_REACHCONF User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Hello, According to draft-ietf-ipngwg-rfc2292bis-01.txt, it seems to me that any users can set IPV6_REACHCONF cmsg type for an outgoing UDP/raw-IPv6 packet. However, this option might be dangerous in some situations. Consider the following scenario: - A node "A" resolves the link-layer address of another node "B", and then starts communicating with B. - After starting the communication, a malicious user opens a UDP socket to B, and continuously sends packets to B with the IPV6_REACHCONF option. - Then the neighbor cache entry for B will never be stale, and NUD will never occur even if B is down. I'm not sure if we should regard such a scenario as a threat, but it would be much safer to limit use of the option to privileged users. I'd like to know your (and other implementors') opinion this. Thanks. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. KAME's latest implementation has (experimentally) introduced the restriction. --Multipart_Thu_May_25_18:21:11_2000-1-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 25 05:52:14 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4PCKi011403 for ipng-dist; Thu, 25 May 2000 05:20:44 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4PCKR711396 for ; Thu, 25 May 2000 05:20:30 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA22717 for ; Thu, 25 May 2000 05:20:26 -0700 (PDT) Received: from monza.broadswitch.com ([195.178.164.73]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA24742 for ; Thu, 25 May 2000 05:20:25 -0700 (PDT) Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD28A544@monza.broadswitch.com> From: Thomas Eklund To: "'Steve Deering'" , Richard Draves Cc: "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: RE: rfc2292bis: interaction with home address option Date: Thu, 25 May 2000 14:20:16 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steve, > It would also be good if common apps made it very easy for the user to > override the default behavior and force use of the COA address as the > source, for those cases when the user (a) knows that the > destination is > "close" and (b) doesn't plan to move before the session ends > or doesn't > care if a move breaks the session. How can you decide that? Seems to me that the only sessions that fit into that category is the local services like "UDP based sessions" to DNS etc... I can imagine that sessions that are close could use a special sitelocal src address... I see this as beeing part of the anycast addressing that is yet to be solved within a site and global scope... I assume that the routing protocol has to distribute the site local info within the site in order to make the anycasting work... So perhaps define the anycast model and see how you can use a special site local src address for anycast services... Regards Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 25 06:21:28 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4PCr2E11427 for ipng-dist; Thu, 25 May 2000 05:53:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4PCqj711420 for ; Thu, 25 May 2000 05:52:46 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id FAA17393 for ; Thu, 25 May 2000 05:52:43 -0700 (PDT) Received: from monza.broadswitch.com (monzaext.broadswitch.com [195.178.164.73]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA08001 for ; Thu, 25 May 2000 05:52:41 -0700 (PDT) Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD28A545@monza.broadswitch.com> From: Thomas Eklund To: "'Steve Deering'" , Richard Draves Cc: "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: RE: rfc2292bis: interaction with home address option Date: Thu, 25 May 2000 14:52:38 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steve and others, just a short comment. > -----Original Message----- > From: Steve Deering [mailto:deering@cisco.com] > Sent: Wednesday, May 24, 2000 10:23 PM > To: Richard Draves > Cc: 'itojun@iijlab.net'; ipng@sunroof.eng.sun.com > Subject: RE: rfc2292bis: interaction with home address option > I presume another UI option that would be desirable on a > mobile node is > a "privacy" switch that prevents binding updates from being sent, and > also tunnels mobile->correspondent packets via the home agent, so as > not to reveal the current (network) location to correspondents. When > operating in such a mode, the performance impact of having > all of one's > packets dogleg-routed through the home agent might be very > undesirable, > especially when the mobile and correspondent are on one continent and > the home agent is on another. This breaks much of the nice feature with route optimazation and we are back to the less nice mobile ipv4 solution... And I dont see why it is needed? This would only eat up more of the operators available network bandwidth ... What is location privacy - I said it on the mobile IP list and I say it again that I would argue that it is not something we want... If you are willing to let the packet take a longer route via its home network what do you achieve...? This also leads to Itojun question when a CN wanted to know the CoA of the mobile node... Why do the application (and the BSD API) need to have any knowledge about this...? And if the API dont have any way to get the CoA then this would not be a problem and the home address option would work as its suppose to work (using the HA) - to hide everything to the transport layers... In ipv6 you have the address diveded into two parts and it is only of interest to a "spoofer" what your lower 64 bits are (i.e. your interface id or EUI-64).. And there is a draft how you add privacy to the interface part (http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-01.t xt*) That means that you cant be tracked... Eventhough a spoofer sees where the packets comes from he cant reveil from who it is originated... In other words there are already a solution to the privacy issue... So the privacy issue is not an valid for having the BU turned off... this solves the privacy for the user but do you ever want to have location privacy?? Thomas Eklund -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 25 08:37:37 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4PFKIt11559 for ipng-dist; Thu, 25 May 2000 08:20:18 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.89.31] (may be forged)) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4PFK7711552 for ; Thu, 25 May 2000 08:20:08 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e4PFK78465420; Thu, 25 May 2000 08:20:07 -0700 (PDT) Date: Thu, 25 May 2000 08:19:57 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: permission control for IPV6_REACHCONF To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: erik.nordmark@eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for the delay in responding - I've had it on my todo list for quite a while. > According to draft-ietf-ipngwg-rfc2292bis-01.txt, it seems to me that > any users can set IPV6_REACHCONF cmsg type for an outgoing > UDP/raw-IPv6 packet. > > However, this option might be dangerous in some situations. Consider > the following scenario: > > - A node "A" resolves the link-layer address of another node "B", and > then starts communicating with B. > - After starting the communication, a malicious user opens a UDP > socket to B, and continuously sends packets to B with the > IPV6_REACHCONF option. > - Then the neighbor cache entry for B will never be stale, and NUD > will never occur even if B is down. > > I'm not sure if we should regard such a scenario as a threat, but it > would be much safer to limit use of the option to privileged users. I agree that there is a risk for somewhat of a Denial of Service attack here. But it is a fairly small possibility; not only do the attacking application need to run on the same machine, it also has no effect until there is actually a reachability problem. So I don't know how serious problem this is. Restricting its use to priviledged users means that e.g. the resolver library (when invoked by a non-priviledged process) can't provide reachability confirmation over UDP. I think that would be unfortunate. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 25 10:39:34 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4PHRpD11701 for ipng-dist; Thu, 25 May 2000 10:27:51 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4PHRg711694 for ; Thu, 25 May 2000 10:27:43 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id KAA27297; Thu, 25 May 2000 10:27:26 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA21671; Thu, 25 May 2000 11:27:23 -0600 (MDT) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.9.1+3.1W/8.9.1) with ESMTP id CAA14537; Fri, 26 May 2000 02:13:43 +0900 (JST) Date: Fri, 26 May 2000 02:24:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: Re: permission control for IPV6_REACHCONF In-Reply-To: In your message of "Thu, 25 May 2000 08:19:57 -0700 (PDT)" References: User-Agent: Wanderlust/2.2.15 (More Than Words) Emacs/20.6 Mule/4.0 (HANANOEN) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 22 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 25 May 2000 08:19:57 -0700 (PDT), >>>>> Erik Nordmark said: > I agree that there is a risk for somewhat of a Denial of Service attack here. > But it is a fairly small possibility; not only do the attacking application > need to run on the same machine, it also has no effect until there is > actually a reachability problem. > So I don't know how serious problem this is. > Restricting its use to priviledged users means that e.g. the resolver library > (when invoked by a non-priviledged process) can't provide reachability > confirmation over UDP. > I think that would be unfortunate. Right, and I feel this is a tradeoff issue. I personally think it is okay not to restrict the use of the option as long as comments on the possible attacks are stated. What do others think? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 25 12:14:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4PJCTN11819 for ipng-dist; Thu, 25 May 2000 12:12:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4PJCG711812 for ; Thu, 25 May 2000 12:12:16 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id MAA29284 for ; Thu, 25 May 2000 12:12:16 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA10730 for ; Thu, 25 May 2000 12:12:14 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18163; Thu, 25 May 2000 15:12:12 -0400 (EDT) Message-Id: <200005251912.PAA18163@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: Router Renumbering for IPv6 to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 25 May 2000 15:12:12 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider Router Renumbering for IPv6 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by June 8, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-router-renum-10.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 25 15:58:45 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4PMvIP11935 for ipng-dist; Thu, 25 May 2000 15:57:18 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4PMv7711928 for ; Thu, 25 May 2000 15:57:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA23937 for ; Thu, 25 May 2000 15:57:07 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA00704 for ; Thu, 25 May 2000 16:57:05 -0600 (MDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id HAA23759; Fri, 26 May 2000 07:56:59 +0900 (JST) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com In-reply-to: jinmei's message of Fri, 26 May 2000 02:24:12 JST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: permission control for IPV6_REACHCONF From: itojun@iijlab.net Date: Fri, 26 May 2000 07:56:59 +0900 Message-ID: <23757.959295419@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I agree that there is a risk for somewhat of a Denial of Service attack here. >> But it is a fairly small possibility; not only do the attacking application >> need to run on the same machine, it also has no effect until there is >> actually a reachability problem. >> So I don't know how serious problem this is. > >> Restricting its use to priviledged users means that e.g. the resolver library >> (when invoked by a non-priviledged process) can't provide reachability >> confirmation over UDP. >> I think that would be unfortunate. > >Right, and I feel this is a tradeoff issue. I personally think it is >okay not to restrict the use of the option as long as comments on the >possible attacks are stated. What do others think? I think it is unfortunate, but I vote for restrictive way (i.e. require root privilege). another way may be to interpret, in the kernel, like this: - consider IPV6_REACHCONF from privileged user as very trustworthy - consider IPV6_REACHCONF from normal user as less trustworthy information, just as hint. do not 100% rely upon reachability confirmation came from normal user. not sure how to implement the latter. let me think. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 25 20:18:44 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4Q3HIf12069 for ipng-dist; Thu, 25 May 2000 20:17:18 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4Q3H9712062 for ; Thu, 25 May 2000 20:17:09 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id UAA27256 for ; Thu, 25 May 2000 20:17:09 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA29523 for ; Thu, 25 May 2000 20:17:08 -0700 (PDT) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id BDC1986F; Thu, 25 May 2000 23:17:07 -0400 (EDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 95BE3B49; Thu, 25 May 2000 23:17:07 -0400 (EDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id XAA0000723596; Thu, 25 May 2000 23:17:06 -0400 (EDT) From: Jim Bound Message-Id: <200005260317.XAA0000723596@anw.zk3.dec.com> To: Richard Draves Cc: "'Steve Deering'" , "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis: interaction with home address option In-reply-to: Your message of "Wed, 24 May 2000 14:18:33 PDT." <4D0A23B3F74DD111ACCD00805F31D8101CA22101@RED-MSG-50> Date: Thu, 25 May 2000 23:17:05 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Certainly, I would hate to be in a position where I can't talk to a local >service because my home agent happens be to unreachable at the moment. But >if the binding cache on the local server is working well enough to maintain >the binding, and the mobile node sends a binding-update proactively with its >SYN, then the home agent won't be needed. This should be the common case >when the mobile node is initiating the communication. This has been my implementation assumption and design center and the deployment model for MIPv6. In fact I think when the coresponding app speaks the mobile node this should be the default given the binding update is current. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 26 07:43:18 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4QEfjw12290 for ipng-dist; Fri, 26 May 2000 07:41:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4QEfY712283 for ; Fri, 26 May 2000 07:41:34 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA20228 for ; Fri, 26 May 2000 07:41:34 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08174 for ; Fri, 26 May 2000 07:41:33 -0700 (PDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id RAA09555; Fri, 26 May 2000 17:41:32 +0300 (EET DST) Date: Fri, 26 May 2000 17:41:32 +0300 (EET DST) From: Markku Savela Message-Id: <200005261441.RAA09555@anise.tte.vtt.fi> To: ipng@sunroof.eng.sun.com Subject: Resolving names, AAAA and A query Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I suppose following has been discussed to the death in the dawn of IPNG, but ... When an application is presented with a domain name, it cannot know whether it maps to IPv6 or IPv4 address. Thus the resolver library needs to make a query for both A and AAAA records. (Right?) Just writing a resolver based on reading the RFC-1035, the first idea was: hey! you can put both queries into same message, just have the QDCOUNT=2... ... but, we quickly found that apparently nobody supports such thing. Anyone care to comment the background of this: why the multiple query feature of RFC-1035 is not implemented? The KAME resolver appears to first send an AAAA query, and if that results an error, it then sends A query. Another idea is to send both AAAA and A in parallel and then use the first good answer, if any arrives. And, when A6 is added, we have 3 queries to send? -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 26 08:00:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4QExI912351 for ipng-dist; Fri, 26 May 2000 07:59:18 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4QEx3712333 for ; Fri, 26 May 2000 07:59:03 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA08665 for ; Fri, 26 May 2000 07:59:03 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17958 for ; Fri, 26 May 2000 07:59:01 -0700 (PDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA28744; Fri, 26 May 2000 09:58:50 -0500 (CDT) Message-Id: <200005261458.JAA28744@gungnir.fnal.gov> To: msa@hemuli.tte.vtt.fi (Markku Savela) Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Resolving names, AAAA and A query In-reply-to: Your message of Fri, 26 May 2000 17:41:32 +0300. <200005261441.RAA09555@anise.tte.vtt.fi> Date: Fri, 26 May 2000 09:58:50 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Just writing a resolver based on reading the RFC-1035, the first idea > was: hey! you can put both queries into same message, just have the > QDCOUNT=2... > > ... but, we quickly found that apparently nobody supports such thing. > > Anyone care to comment the background of this: why the multiple query > feature of RFC-1035 is not implemented? I thought it was lazy implementors of BIND when I first noticed that lack of support. But they instantly convinced me that the problem is in the spec: what's the right RCODE when you can answer one query but not the other? What do you do if you have the answer to one in the cache? And so on. draft-ietf-dnsind-edns1-NN.txt addresses this. > The KAME resolver appears to first send an AAAA query, and if that > results an error, it then sends A query. > > Another idea is to send both AAAA and A in parallel and then use the > first good answer, if any arrives. And, when A6 is added, we have 3 > queries to send? Other suggested reading: RFC 1933 draft-ietf-ipngwg-dns-lookups-08.txt (recently passed by IESG): On the client side, when looking up and IPv6 address, the order of A6 and AAAA queries MAY be configurable to be one of: A6, then AAAA; AAAA, then A6; A6 only; or both in parallel. The default order (or only order, if not configurable) MUST be to try A6 first, then AAAA. If and when the AAAA becomes deprecated a new document will change the default. The guidelines and options for precedence between IPv4 and IPv6 addresses are specified in [TRANS]. All mentions of AAAA records in that document are henceforth to be interpreted as meaning A6 and/or AAAA records in the order specified in the previous paragraph. Where [TRANS] = 1933. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 26 08:36:35 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4QFZ7t12408 for ipng-dist; Fri, 26 May 2000 08:35:07 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4QFYx712401 for ; Fri, 26 May 2000 08:34:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA24701 for ; Fri, 26 May 2000 08:34:58 -0700 (PDT) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA14102 for ; Fri, 26 May 2000 09:34:58 -0600 (MDT) Received: by sentry.gw.tislabs.com; id LAA29054; Fri, 26 May 2000 11:36:52 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma029048; Fri, 26 May 00 11:36:42 -0400 Received: from english (clipper.gw.tislabs.com [10.33.1.2]) by clipper.gw.tislabs.com (8.9.3/8.9.1) with SMTP id LAA07030; Fri, 26 May 2000 11:33:05 -0400 (EDT) Message-Id: <4.1.20000526111748.00bc17d0@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 26 May 2000 11:36:43 -0400 To: msa@hemuli.tte.vtt.fi (Markku Savela), ipng@sunroof.eng.sun.com From: Olafur Gudmundsson Subject: Re: Resolving names, AAAA and A query In-Reply-To: <200005261441.RAA09555@anise.tte.vtt.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:41 AM 5/26/00 , Markku Savela wrote: >I suppose following has been discussed to the death in the dawn of >IPNG, but ... > >When an application is presented with a domain name, it cannot know >whether it maps to IPv6 or IPv4 address. Thus the resolver library >needs to make a query for both A and AAAA records. (Right?) Correct > >Just writing a resolver based on reading the RFC-1035, the first idea >was: hey! you can put both queries into same message, just have the >QDCOUNT=2... > >... but, we quickly found that apparently nobody supports such thing. > >Anyone care to comment the background of this: why the multiple query >feature of RFC-1035 is not implemented? There is no specification on the relationship of the queries is it first match, match all that apply, or some other one. Then there is the issue of error reporting, if there is a query for first A6 and secondly A, and A6 does not exist is but A does is this an error or not ? > >The KAME resolver appears to first send an AAAA query, and if that >results an error, it then sends A query. > >Another idea is to send both AAAA and A in parallel and then use the >first good answer, if any arrives. And, when A6 is added, we have 3 >queries to send? > There has been a suggestion to use a META query for IPv6 address records but that was shot down as AAAA records are supposed to die soon. If your host does not care if the connection is IPv4 or IPv6 then doing the queries in parallel does not seem such a bad idea. But us DNS people are going to scream as it doubles the number of queries. If your host has preference query for that type first. If I recall correctly you support A6 you MUST try that first before issuing AAAA queries. Thus there will never be more than two queries in parallel. It is not likely that multiple queries will be standardized in the near term. Olafur -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 27 08:08:19 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4RF6rT13072 for ipng-dist; Sat, 27 May 2000 08:06:53 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4RF6i713064 for ; Sat, 27 May 2000 08:06:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA24109 for ; Sat, 27 May 2000 08:06:44 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA05124 for ; Sat, 27 May 2000 08:06:42 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4RF5jE36885; Sat, 27 May 2000 17:05:48 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA19018; Sat, 27 May 2000 17:05:44 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id RAA77914; Sat, 27 May 2000 17:07:39 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005271507.RAA77914@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis: interaction with home address option In-reply-to: Your message of Wed, 24 May 2000 17:39:46 +0900. <23415.959157586@coconut.itojun.org> Date: Sat, 27 May 2000 17:07:39 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Hello, while thinking about interaction between mobile-ip6 and BSD APIs, I came up with the following questions. I still do not have the answer. If you have any working practice I would like to know that. => I have both! when a node A received packet from mobile node B: packet will carry home address of B in home address option (destination options header, and care-of address in IPv6 source - which address should getpeername() return? home address, or care-of? home address sounds like a good default pick, however, some apps may need to look at care-of. => home address with a getsockopt() (or a new system call) which returns the real destination address. Same for getsockname() because IKE needs a way to know the real source address, ie ID-12: - The mobile node MUST use its care-of address as the Source Address of all packets it sends as part of the key management protocol (without use of Mobile IP for these packets, as suggested in Section 10.1). For the correspondent node things should be more transparent but: - home agents are correspondents - symetry argument then I'd like to get both getsockopt() in the new standard, of course results should be sockaddr_in6 structures and be the same than from `genuine system calls when there is no mobility stuff. - which address should recvfrom() return? ditto. => same problem but it is enough to have a getsockopt() for connected/bound sockets because the mobility stuff uses addresses only. The answer is the home address. - can we get home address option in IPV6_RECVDSTOPTS? it seems like so. it will have home address of B, not care-of. => if the new I-D or RFC is clear enough about processing of home address option processing then we'll know the answer. If per instance it asks for an address swap (my favourite) then the destination address in the header will be the home address and the address in the option the care-of, recvfrom() will return the home address (good) and the care-of will be accessible with IPV6_RECVDSTOPTS (good again). As a side effect we'll know how to compute the AH message digest (:-). - then, how can we get care-of address of the peer? (1) new IPV6_RECVxx in rfc2292 advanced API? (2) new system call? -> unacceptable when a mobile node A sends packet to a node B: A may want to control the use of mobile-ip6. examples: (1) if A would like to talk to ubiquitous services like DNS, A may want to use care-of address, not the home address. (2) IKE (to establish key for mobile-ip6) requires it. => (2) IKE is why I've already added a getsockopt() for this. For (1) I have a configuration flag in the mobility management tool in order to consider local nodes (ie nodes on the same link/sharing same prefixes) as correspondents or not: - with the first option all new communications will go through the home (remote) agent - with the second option open connections with local nodes will be broken by movements. There is no good choice then users can say what they like. I believe you'd like a way to override the first choice for "smart" applications (this is fine for me). - how can we avoid use of home address? 1-bit flag in setsockopt? => see above - what is the relationship/interaction with IPV6_PKTINFO? => I believe only special getsockopt() should look at what really happens with mobility stuff. Other parts of the API should be as transparent as possible. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 27 08:30:20 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4RFSrj13103 for ipng-dist; Sat, 27 May 2000 08:28:53 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4RFSi713096 for ; Sat, 27 May 2000 08:28:44 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id IAA24706 for ; Sat, 27 May 2000 08:28:44 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09064 for ; Sat, 27 May 2000 08:28:42 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4RFRwE35697; Sat, 27 May 2000 17:27:59 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA19138; Sat, 27 May 2000 17:27:52 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id RAA77990; Sat, 27 May 2000 17:29:47 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005271529.RAA77990@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Steve Deering cc: itojun@iijlab.net, ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis: interaction with home address option In-reply-to: Your message of Wed, 24 May 2000 09:04:27 PDT. Date: Sat, 27 May 2000 17:29:47 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: At 5:39 PM +0900 5/24/00, itojun@iijlab.net wrote: >when a node A received packet from mobile node B: >packet will carry home address of B in home address option (destination >options header, and care-of address in IPv6 source >- which address should getpeername() return? home address, or care-of? > home address sounds like a good default pick, however, some apps > may need to look at care-of. On the correspondent node, getpeername() should return the home address of the mobile node. This is so most apps can be oblivious to the mobility of the node to which they are speaking. => I agree! Can you give some examples of why an app on the correspondent node would want or need to know the current care-of address of its peer? => I know no example but there is at least one (IKE) on the mobile node which would need to know the current care-of address. >- can we get home address option in IPV6_RECVDSTOPTS? > it seems like so. it will have home address of B, not care-of. If you really need to receive both addresses for some reason, the care-of address is the one that should be obtainable only via IPV6_RECVDSTOPTS. Logically, the IP layer in the correspondent host should swap the received home address and care-of address before passing the packet to an upper layer. => Logically but not (yet?) written down in the IPv6 mobility document! This is just another example of the source-address selection problem (as discussed in Rich's draft). When initiating communication, the mobile host must select one of its valid addresses to use as source address. The default behavior, if the application or user doesn't care, would be to use the home address (or one of the home addresses, if there are more than one). But an application, such as the ones you mentioned, can choose to use a different source address, i.e., the temporary care-of address. We should already have whatever API function is needed for the app to specify the source address, so no new flags ought to be needed. => Itojun's concern a bit different, he asked how the application can get the care-of address. Today racoon (KAME IKE deamon) does: - open a new UDP socket - connect it to the destination - get the selected source address by getsockname() - use it (ie in bind() system call) for IKE exchange with the remote party with security processing disabled (ie. IKE has its own protection). I have changed it into: - open a new UDP socket - connect it to the destination - get the selected real source address by a new getsockopt() which gives the care-of address (not the home address) on a mobile node in visit and the same answer than getsockname() in other cases. And for IKE exchange I disable mobility processing (ie home address stuff) and security processing. Then only things I use are: - interaction between source selection and mobility (ie use the home address) - a way to get the current care-of address Regards Francis.Dupont@enst-bretagne.fr PS: the rationate (according to draft-ietf-mobileip-ipv6-12.txt) again: - The mobile node MUST use its care-of address as the Source Address of all packets it sends as part of the key management protocol (without use of Mobile IP for these packets, as suggested in Section 10.1). Example: the mobile node boots in visit and needs to send an authenticated binding update for home registration to the home agent. (boots -> no established security association, authenticated -> needs to setup a security association before, home registration -> the home agent doesn't know the binding and can't reply to the home address) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 27 09:22:04 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4RGKeZ13136 for ipng-dist; Sat, 27 May 2000 09:20:40 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4RGKU713129 for ; Sat, 27 May 2000 09:20:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA20743 for ; Sat, 27 May 2000 09:20:30 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27499 for ; Sat, 27 May 2000 10:20:27 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4RGJHE31503; Sat, 27 May 2000 18:19:17 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA19391; Sat, 27 May 2000 18:19:15 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA78184; Sat, 27 May 2000 18:21:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005271621.SAA78184@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Richard Draves cc: "'itojun@iijlab.net'" , Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis: interaction with home address option In-reply-to: Your message of Wed, 24 May 2000 11:16:19 PDT. <4D0A23B3F74DD111ACCD00805F31D8101CA220F6@RED-MSG-50> Date: Sat, 27 May 2000 18:21:11 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: The mobility draft has at various points or times talked about swapping the source address in the IPv6 header and the address in the home address option. This is OK conceptually and I understand that some implementations actually work that way. But at least in our implementation, we treat packet data as read-only. I would not like to see specifications that assumed the swapping really does happen. => I understand your concern but: - routing header processing already specifies a real swap (then if home agent option has the symmetrical effect it may use the same way to do it) - current specifications don't say if I (real swap) or you (don't swap data but only swap pointers) do the right thing and only one is correct (because AH won't give the same message digest in both cases). This must be fixed! There is a source address selection problem on mobile nodes: when do you use a home address vs a care-of address? The default source address selection rules as currently specified don't always produce the desired results. (There aren't any special rules or provisions for mobility.) => this (no rule/provision for mobility) is a well-known open issue in your I-D about source address selection. This thread will help us to see what we need for it... Considering the case of a mobile node initiating a TCP connection to a global address, with a choice of a global home address and a global care-of address, I think the desirable default behavior to use the global home address for the TCP endpoint and insert the home address option (and a binding-update option in the SYN). => I agree I think this is the desirable default even if the care-of address and the destination address appear to be topologically closer than the home address and the destination address. => this is less clear, for instance if you use mobility IPv6 in a nomadic case (ie. you are in visit somewhere, you'd like to use the home facility (with your hostname, addresses, ...) and the local facility (the local printer for instance) and you'll shutdown your box before moving) then you'd like to use the care-of address for local communications. If you are moving rather fast in a cellular network you'd never want to use the care-of address (the opposite case). I believe we need a rule for local usage of the care-of with some levels of locallity (node / link / site ?) and give the choice/control to users. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 27 09:40:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4RGdJI13156 for ipng-dist; Sat, 27 May 2000 09:39:19 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4RGd9713149 for ; Sat, 27 May 2000 09:39:10 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA24993 for ; Sat, 27 May 2000 09:39:09 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02376 for ; Sat, 27 May 2000 10:39:07 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4RGc8E47946; Sat, 27 May 2000 18:38:08 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA19523; Sat, 27 May 2000 18:38:06 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA78249; Sat, 27 May 2000 18:40:02 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005271640.SAA78249@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Richard Draves cc: "'Steve Deering'" , "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis: interaction with home address option In-reply-to: Your message of Wed, 24 May 2000 13:05:12 PDT. <4D0A23B3F74DD111ACCD00805F31D8101CA220FC@RED-MSG-50> Date: Sat, 27 May 2000 18:40:02 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Assuming you send a binding-update in the SYN, then communication using the home address will be relatively efficient - just a little more overhead in the packets, but no extra packets and no packets going through the home agent. => even the idea of a binding-update in the SYN seems nice this will not work like this a the real word because the binding-update must be authentic ie a security association must be established before. If you use IKE with certificates then this can be more expensive than to go through the tunnel and can add a delay before the connection set up. Then your argument is not as good as we'd like and I agree with the (missing) rationate of "correspondent detection": In particular, the mobile node SHOULD return a Binding Update in response to receiving a packet that meets all of the following tests: - The packet was tunneled using IPv6 encapsulation. - ... (some sanity checks on outer and inner addresses) The main exception would be when you are dealing with a server that handles lots of short-lived connections - it's binding cache might not work well. So for your short-lived connections to such a server, you'd want to use your care-of address instead of your home address. If this option is going to be useful, it needs to be something that the app can decide - having UI for this would not be good. => is my answer (a getsockopt() which returned the selected address in the general case and the (suitable) care-of address in the mobile node case) enough for you? Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 27 09:57:33 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4RGu8613183 for ipng-dist; Sat, 27 May 2000 09:56:08 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4RGtx713176 for ; Sat, 27 May 2000 09:55:59 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA08957 for ; Sat, 27 May 2000 09:55:59 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA06432 for ; Sat, 27 May 2000 10:55:42 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4RGmeE39409; Sat, 27 May 2000 18:48:40 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA19587; Sat, 27 May 2000 18:48:39 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA78293; Sat, 27 May 2000 18:50:35 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005271650.SAA78293@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Richard Draves cc: "'Steve Deering'" , "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis: interaction with home address option In-reply-to: Your message of Wed, 24 May 2000 14:18:33 PDT. <4D0A23B3F74DD111ACCD00805F31D8101CA22101@RED-MSG-50> Date: Sat, 27 May 2000 18:50:35 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > I presume another UI option that would be desirable on a > mobile node is > a "privacy" switch that prevents binding updates from being sent, and > also tunnels mobile->correspondent packets via the home agent, so as > not to reveal the current (network) location to correspondents. When > operating in such a mode, the performance impact of having > all of one's > packets dogleg-routed through the home agent might be very > undesirable, > especially when the mobile and correspondent are on one continent and > the home agent is on another. This is a good idea, but I don't recall any text in the mobility spec that talks about the mobile sending packets to the correspondent by tunneling to the home agent. (The tunneling right now is in the other direction.) I think it would be a simple addition. => this kind of reversed tunnelling can be used for multicast packets sent by the mobile node (see section 10.18) then a half of the text is already there... > Another possible reason for user-specified use of the COA > address instead > of the home address is to be able to communicate even when > the the user's > home agent(s) are down or unreachable for whatever reason. Certainly, I would hate to be in a position where I can't talk to a local service because my home agent happens be to unreachable at the moment. But if the binding cache on the local server is working well enough to maintain the binding, and the mobile node sends a binding-update proactively with its SYN, then the home agent won't be needed. This should be the common case when the mobile node is initiating the communication. => as I have already explained this (proactive BU with SYN) is not a good idea and it is better to rely on traffic in the HA->MN tunnel (which is the traffic which has to "pay" for no binding). Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 28 06:43:50 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4SDdGb13584 for ipng-dist; Sun, 28 May 2000 06:39:16 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4SDd6713577 for ; Sun, 28 May 2000 06:39:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA05211 for ; Sun, 28 May 2000 06:39:07 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA08905 for ; Sun, 28 May 2000 07:39:04 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4SDbZE51088; Sun, 28 May 2000 15:37:36 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA01887; Sun, 28 May 2000 15:37:26 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id PAA82155; Sun, 28 May 2000 15:39:25 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005281339.PAA82155@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: itojun@iijlab.net cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , ipng@sunroof.eng.sun.com Subject: Re: permission control for IPV6_REACHCONF In-reply-to: Your message of Fri, 26 May 2000 07:56:59 +0900. <23757.959295419@coconut.itojun.org> Date: Sun, 28 May 2000 15:39:25 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >Right, and I feel this is a tradeoff issue. I personally think it is >okay not to restrict the use of the option as long as comments on the >possible attacks are stated. What do others think? => I believe this is the best solution. I think it is unfortunate, but I vote for restrictive way (i.e. require root privilege). another way may be to interpret, in the kernel, like this: - consider IPV6_REACHCONF from privileged user as very trustworthy - consider IPV6_REACHCONF from normal user as less trustworthy information, just as hint. do not 100% rely upon reachability confirmation came from normal user. not sure how to implement the latter. let me think. => I think the word is more complex than root and normal users, there are in modern OSs more than two levels of privileges then please keep the door open, ie. a comment is enough. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 28 06:56:06 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4SDsBq13603 for ipng-dist; Sun, 28 May 2000 06:54:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4SDs0713596 for ; Sun, 28 May 2000 06:54:00 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id GAA17848 for ; Sun, 28 May 2000 06:54:00 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03802 for ; Sun, 28 May 2000 06:53:59 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W) with ESMTP id WAA29036; Sun, 28 May 2000 22:53:45 +0900 (JST) To: Ian Jackson cc: ipng@sunroof.eng.sun.com In-reply-to: ian's message of Sun, 21 May 2000 18:43:57 +0100. <14632.8285.2004.793466@davenant.relativity.greenend.org.uk> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6, resolv.conf, RFC2133, etc. From: itojun@iijlab.net Date: Sun, 28 May 2000 22:53:45 +0900 Message-ID: <29034.959522025@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I have basically two sets of issues: one is what the syntax of >resolv.conf should be (and what extensions in it I should understand); >the other is what the resolver behaviour should be in various >circumstances. about resolv.conf syntax: the easiest way is to have "nameserver ". BIND4/8 resolver code (res_init.c) simply ignore unparsable lines, as well as unparsable address portion in "nameserver foo" line. so this should be safe to put "nameserver " line into resolv.conf, even if old binary may look at the file. about behavior: there are various APIs visible to the userland programmers. I think you may want to honor API definition in RFCs and X/Open documents, and behave as necessary. for example: - gethostbyname() - IPv4 only -> A query - gethostbyname2(AF_INET) - if af == AF_INET, IPv4 only -> A query - gethostbyname2(AF_INET6) - see RFC2133 - getipnodebyname(AF_INET) - see RFC2553, IPv4 only -> A query - getipnodebyname(AF_INET6) - see RFC2553 (not sure if the answer is relevant for your library suite) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 29 04:23:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4TBMOp14048 for ipng-dist; Mon, 29 May 2000 04:22:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4TBMD714041 for ; Mon, 29 May 2000 04:22:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id EAA11745 for ; Mon, 29 May 2000 04:22:12 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA23060 for ; Mon, 29 May 2000 05:22:11 -0600 (MDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id OAA03420; Mon, 29 May 2000 14:22:04 +0300 (EET DST) Date: Mon, 29 May 2000 14:22:04 +0300 (EET DST) From: Markku Savela Message-Id: <200005291122.OAA03420@anise.tte.vtt.fi> To: ogud@tislabs.com CC: ipng@sunroof.eng.sun.com In-reply-to: <4.1.20000526111748.00bc17d0@localhost> (message from Olafur Gudmundsson on Fri, 26 May 2000 11:36:43 -0400) Subject: Re: Resolving names, AAAA and A query Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is no specification on the relationship of the queries is it > first match, match all that apply, or some other one. > > Then there is the issue of error reporting, if there is a query for > first A6 and secondly A, and A6 does not exist is but A does is this > an error or not ? If there are no deployed software that implements the multiple query feature, would there be a window for actually specifying some working semantics for it now? The goals being - detection the old servers that don't support multiple query ("format error" seems to be a tell tale from some?) - minimise the transactions for AAAA,A,A6 (it would be such a neat package, with one hostname appearing only once using the DNS compression...) - define rules how to reply in case not all queries succeed (the particular goal being the needs of IPv4/IPv6 transition). Can think few starters - if all are in cache, return all - if some are in cache, return them separately, but proceed with query - if some name results error, and some not, perhaps return a separate error reply for them? - wouldn't multiple queries be more clean for some other purposes too? Query A or MX? (instead of messy "addional section..." :-) -- Markku Savela (msa@hemuli.tte.vtt.fi), Technical Research Centre of Finland Multimedia Systems, P.O.Box 1203,FIN-02044 VTT,http://www.vtt.fi/tte/staff/msa/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 30 14:03:55 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4UL26e15097 for ipng-dist; Tue, 30 May 2000 14:02:06 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4UL1w715090 for ; Tue, 30 May 2000 14:01:58 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA09914 for ; Tue, 30 May 2000 14:01:56 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id PAA13258 for ; Tue, 30 May 2000 15:01:49 -0600 (MDT) Received: from 157.54.9.101 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 30 May 2000 13:59:22 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2651.58) id ; Tue, 30 May 2000 13:59:21 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8101CA22145@RED-MSG-50> From: Richard Draves To: "'Francis Dupont'" Cc: "'Steve Deering'" , "'itojun@iijlab.net'" , ipng@sunroof.eng.sun.com Subject: RE: rfc2292bis: interaction with home address option Date: Tue, 30 May 2000 13:59:14 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Assuming you send a binding-update in the SYN, then > communication using the > home address will be relatively efficient - just a little > more overhead in > the packets, but no extra packets and no packets going > through the home > agent. > > => even the idea of a binding-update in the SYN seems nice > this will not > work like this a the real word because the binding-update must be > authentic ie a security association must be established before. > If you use IKE with certificates then this can be more expensive than > to go through the tunnel and can add a delay before the connection > set up. Well, that's a good point - I'd forgotten about the security overhead of protecting the binding update. But I still think the default should be for a mobile node to use a home address instead of a care-of address, unless there is app or user guidance (like the "this is a short-lived socket" option). Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 30 15:36:12 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4UMYO315160 for ipng-dist; Tue, 30 May 2000 15:34:24 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4UMYF715153 for ; Tue, 30 May 2000 15:34:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id PAA03409 for ; Tue, 30 May 2000 15:34:16 -0700 (PDT) Received: from sentry.gw.tislabs.com (sentry.gw.tislabs.com [192.94.214.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA18362 for ; Tue, 30 May 2000 16:34:15 -0600 (MDT) Received: by sentry.gw.tislabs.com; id SAA03025; Tue, 30 May 2000 18:36:10 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma003021; Tue, 30 May 00 18:36:05 -0400 Received: from english (clipper.gw.tislabs.com [10.33.1.2]) by clipper.gw.tislabs.com (8.9.3/8.9.1) with SMTP id SAA20411; Tue, 30 May 2000 18:31:53 -0400 (EDT) Message-Id: <4.1.20000530121746.048aa460@localhost> X-Sender: ogud@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 30 May 2000 18:36:22 -0400 To: msa@hemuli.tte.vtt.fi (Markku Savela), ogud@tislabs.com From: Olafur Gudmundsson Subject: Re: Resolving names, AAAA and A query Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200005291122.OAA03420@anise.tte.vtt.fi> References: <4.1.20000526111748.00bc17d0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 07:22 AM 5/29/00 , Markku Savela wrote: > >> There is no specification on the relationship of the queries is it >> first match, match all that apply, or some other one. >> >> Then there is the issue of error reporting, if there is a query for >> first A6 and secondly A, and A6 does not exist is but A does is this >> an error or not ? > >If there are no deployed software that implements the multiple query >feature, would there be a window for actually specifying some working >semantics for it now? Yes and NO. DNS implementations are just starting to catch up with the many new features that have been added in the last few years, Dynamic Update, Incremental Zone transfer, IPv6 support (AAAA, A6, DNAME and bit string labels) and DNSSec. There is going to be a lag in deployment any new features. >......The goals being > > - detection the old servers that don't support multiple query > ("format error" seems to be a tell tale from some?) > There is discussion going on how to find out in general what features a particular server supports. > - minimise the transactions for AAAA,A,A6 (it would be such a neat > package, with one hostname appearing only once using the DNS > compression...) > > - define rules how to reply in case not all queries succeed (the > particular goal being the needs of IPv4/IPv6 transition). Can think > few starters > > - if all are in cache, return all > - if some are in cache, return them separately, but > proceed with query > - if some name results error, and some not, perhaps return a > separate error reply for them? > > - wouldn't multiple queries be more clean for some other purposes > too? Query A or MX? (instead of messy "addional section..." :-) > Multiple queries have certain attractiveness to them but once you think the issue through, things get quite complicated. If your client does not care what version of IP is used, then ask in parallel, if it has preference express it in query ordering. Saving bits on the wire with compression in query is not a factor, getting back a truncated answer in response to a multiple question request is a bigger issue. Olafur -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 30 22:09:39 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4V583V15336 for ipng-dist; Tue, 30 May 2000 22:08:03 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.87.31] (may be forged)) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4V57q715329 for ; Tue, 30 May 2000 22:07:52 -0700 (PDT) Received: from lillen (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with SMTP id e4V57oB107901; Tue, 30 May 2000 22:07:50 -0700 (PDT) Date: Tue, 30 May 2000 22:07:49 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: rfc2292bis: interaction with home address option To: Francis Dupont Cc: Richard Draves , "'itojun@iijlab.net'" , Steve Deering , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200005271621.SAA78184@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich Draves wrote: > The mobility draft has at various points or times talked about swapping > the > source address in the IPv6 header and the address in the home address > option. This is OK conceptually and I understand that some implementations > actually work that way. But at least in our implementation, we treat > packet > data as read-only. I would not like to see specifications that assumed the > swapping really does happen. Fancis Dupont wrote: > => I understand your concern but: > - routing header processing already specifies a real swap (then if home > agent option has the symmetrical effect it may use the same way to do it) > - current specifications don't say if I (real swap) or you (don't swap > data but only swap pointers) do the right thing and only one is correct > (because AH won't give the same message digest in both cases). > This must be fixed! In terms of the API (and IP_RECVDSTOPTS in particular) we can presumably satisfy both of you by saying that the content of the IP_RECVDSTOPTS ancillary data item, when it contains is a home address option, has the address field in the home address option set to the care of address i.e. the source address of the packet when it arrived. This doesn't require modifying the packet when it arrived (Rich's concern as I understand it) - instead it requires some care when constructing the IP_RECVDSTOPTS ancillary data item. Of course, implementations that process the home address option by doing a swap have less work to perform when constructing the ancillary data item. Should we put this in rfc2292bis? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 30 23:24:00 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4V6MOl15428 for ipng-dist; Tue, 30 May 2000 23:22:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4V6MD715421 for ; Tue, 30 May 2000 23:22:13 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id XAA15687; Tue, 30 May 2000 23:22:13 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA06289; Tue, 30 May 2000 23:22:12 -0700 (PDT) Received: from kiwi.itojun.org (localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.2W/3.7W/smtpfeed 1.06) with ESMTP id PAA01842; Wed, 31 May 2000 15:22:07 +0900 (JST) To: Erik Nordmark cc: Francis Dupont , Richard Draves , Steve Deering , ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Tue, 30 May 2000 22:07:49 MST. X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: rfc2292bis: interaction with home address option From: itojun@iijlab.net Date: Wed, 31 May 2000 15:22:06 +0900 Message-ID: <1840.959754126@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >In terms of the API (and IP_RECVDSTOPTS in particular) we can presumably >satisfy both of you by saying that the content of the IP_RECVDSTOPTS ancillary >data item, when it contains is a home address option, has the address >field in the home address option set to the care of address i.e. the >source address of the packet when it arrived. > >This doesn't require modifying the packet when it arrived (Rich's concern >as I understand it) - instead it requires some care when constructing >the IP_RECVDSTOPTS ancillary data item. >Of course, implementations that process the home address option by >doing a swap have less work to perform when constructing the ancillary data >item. > >Should we put this in rfc2292bis? I personally think the above proposal is okay for me, and solves my original question. as passing home address option as-is does not add any information at all (you can get the home address by getpeername) it is better. (it is a bit twisted, I admit) itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 31 00:41:32 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4V7dVR15497 for ipng-dist; Wed, 31 May 2000 00:39:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4V7dK715490 for ; Wed, 31 May 2000 00:39:20 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id AAA06440 for ; Wed, 31 May 2000 00:39:19 -0700 (PDT) Received: from anise.tte.vtt.fi (anise.tte.vtt.fi [130.188.52.29]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA05848 for ; Wed, 31 May 2000 00:39:19 -0700 (PDT) Received: (from msa@localhost) by anise.tte.vtt.fi (8.8.5/8.8.5) id KAA12103; Wed, 31 May 2000 10:39:08 +0300 (EET DST) Date: Wed, 31 May 2000 10:39:08 +0300 (EET DST) From: Markku Savela Message-Id: <200005310739.KAA12103@anise.tte.vtt.fi> To: itojun@iijlab.net CC: ipng@sunroof.eng.sun.com In-reply-to: <1840.959754126@coconut.itojun.org> Subject: Re: rfc2292bis: interaction with home address option Reply-to: msa@hemuli.tte.vtt.fi (Markku Savela) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: itojun@iijlab.net > (it is a bit twisted, I admit) Too many of these "twists" in specification is worrysome. I can go with the "swap" specification, but it still feels itchy to read "get destination options", but hey, remember you are not getting the true original destination options, but a twisted version ... But, as I have not been involved implementing that thing, it is just the feeling, no serious objection from me. I assume other people know what they do. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 31 01:09:16 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4V87Xr15533 for ipng-dist; Wed, 31 May 2000 01:07:33 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4V87O715526 for ; Wed, 31 May 2000 01:07:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id BAA23217; Wed, 31 May 2000 01:07:22 -0700 (PDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA11431; Wed, 31 May 2000 02:07:21 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4V87IE51278; Wed, 31 May 2000 10:07:18 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA07550; Wed, 31 May 2000 10:07:17 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id KAA01236; Wed, 31 May 2000 10:07:21 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005310807.KAA01236@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: Richard Draves , "'itojun@iijlab.net'" , Steve Deering , ipng@sunroof.eng.sun.com Subject: Re: rfc2292bis: interaction with home address option In-reply-to: Your message of Tue, 30 May 2000 22:07:49 PDT. Date: Wed, 31 May 2000 10:07:21 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: In terms of the API (and IP_RECVDSTOPTS in particular) we can presumably satisfy both of you by saying that the content of the IP_RECVDSTOPTS ancillary data item, when it contains is a home address option, has the address field in the home address option set to the care of address i.e. the source address of the packet when it arrived. => the API is fine but the mobility draft doesn't specify how to compute the AH message digest (mandatory if there is a binding update too). Should we put this in rfc2292bis? => It should be in the mobility RFC but if it is not in it then RFC 2292bis is a good place. Note that in fact there is no real usage for it for common correspondents (ie. this has a low priority). Thanks Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 31 07:16:59 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4VEEw415663 for ipng-dist; Wed, 31 May 2000 07:14:58 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4VEEl715656 for ; Wed, 31 May 2000 07:14:47 -0700 (PDT) Received: from venus.Sun.COM (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA16688 for ; Wed, 31 May 2000 07:14:47 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA15410 for ; Wed, 31 May 2000 07:14:45 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11014; Wed, 31 May 2000 10:14:38 -0400 (EDT) Message-Id: <200005311414.KAA11014@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: Protocol Action: DNS Extensions to Support IP Version 6 to Proposed Standard Date: Wed, 31 May 2000 10:14:38 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'DNS Extensions to Support IP Version 6' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This document defines changes to the Domain Name System to support renumberable and aggregatable IPv6 addressing. The changes include a new resource record type (called A6) to store an IPv6 address in a manner that expedites network renumbering and updated definitions of existing query types that return Internet addresses as part of additional section processing. A6 records can hold all or part of an address, with pointers to other DNS names holding the remaining part of the address. For lookups keyed on IPv6 addresses (often called reverse lookups), this document defines a new zone structure that allows a zone to be used without modification for parallel copies of an address space (as for a multihomed provider or site) and across network renumbering events. Working Group Summary This document was discussed extensively in both the IPNG and DNSIND working groups. Although concern has been raised that use of the A6 records will increase the demands placed on the DNS when resolving names to addresses, the goal of easing site renumbering was deemed important and the mechanism described in this document was viewed as the best approach. Protocol Quality This document has been reviewed for the IESG by Thomas Narten and Erik Nordmark. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 31 07:48:40 2000 Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) id e4VElE615703 for ipng-dist; Wed, 31 May 2000 07:47:14 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.10.1+Sun/8.10.1.Beta0) with ESMTP id e4VEl3715696 for ; Wed, 31 May 2000 07:47:03 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id HAA13777 for ; Wed, 31 May 2000 07:47:03 -0700 (PDT) Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA10374 for ; Wed, 31 May 2000 08:46:59 -0600 (MDT) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.9.1/8.9.1) with ESMTP id JAA26113; Wed, 31 May 2000 09:46:55 -0500 (CDT) Message-Id: <200005311446.JAA26113@gungnir.fnal.gov> To: The IESG Cc: RFC Editor , Internet Architecture Board , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: Protocol Action: DNS Extensions to Support IP Version 6 to Proposed Standard In-reply-to: Your message of Wed, 31 May 2000 10:14:38 EDT. <200005311414.KAA11014@ietf.org> Date: Wed, 31 May 2000 09:46:55 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The IESG has approved the Internet-Draft 'DNS Extensions to Support IP > Version 6' as a Proposed Right draft, wrong title. DNS Extensions to Support IPv6 Address Aggregation and Renumbering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------