From owner-ipng@sunroof.eng.sun.com Wed Jun 2 02:26:38 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA17274 for ipng-dist; Wed, 2 Jun 1999 02:23:44 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17267 for ; Wed, 2 Jun 1999 02:23:36 -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 CAA01686 for ; Wed, 2 Jun 1999 02:23:36 -0700 (PDT) Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA16737 for ; Wed, 2 Jun 1999 03:23:34 -0600 (MDT) Received: (from richier@localhost) by horus.imag.fr (8.8.5/8.8.5) id LAA27132 for ipng@sunroof.eng.sun.com; Wed, 2 Jun 1999 11:23:32 +0200 (MET DST) Date: Wed, 2 Jun 1999 11:23:32 +0200 (MET DST) From: Jean-Luc Richier Message-Id: <199906020923.LAA27132@horus.imag.fr> Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 7576) Multicast Listener Discovery Question Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a question about draft-ietf-ipngwg-mld-01.txt about source address selection for messages. RFC2461 and RFC2462 state that when a new address is added, a node must join the sollicited node multicast group very early, in order to be able to perform Duplicate address detection. Joining means, according to draft-ietf-ipngwg-mld-01.txt, that the node performs the Multicast Listener Discovery protocol, that is (cf. paragraph 4, Protocol Description) : MLD messages ARE sent for multicast addresses whose scope is 2 (link- local), including Solicited-Node multicast addresses [ADDR-ARCH], except for the link-scope, all-nodes address (FF02::1). When a node starts listening to a multicast address on an interface, it should immediately transmit an unsolicited Report for that address on that interface, in case it is the first listener on the link. To cover the possibility of the initial Report being lost or damaged, it is recommended that it be repeated once or twice after short delays [Unsolicited Report Interval]. (A simple way to accomplish this is to send the initial Report and then act as if a Multicast-Address-Specific Query was received for that address, and set a timer appropriately). Also the node should reply to any Multicast query. I suppose the rationale is that even though multicast addresses whose scope is 2 should not be routed, there can be level 2 bridge/switch which are performing multicast selective forwarding, and thus engage in the mld protocol But now I think that there is a problem at the initialisation of an interface: Consider a node that start IPv6 on an interface X; it computes the Link-local address (llX) of the interface and start Duplicate address detection. So the node set the tentative address llX on interface X, and therefore enter on X the sollicited multicast group (maX) associated with llX. Therefore the node ``should immediately transmit an unsolicited Report'' for maX. MY QUESTION IS: What is the IPv6 source address for this Report? The interface X has not yet any valid IPv6 address, and using the tentative address llX seems dangerous: In the duplicate address discussion in RFC2462, it is stated that: If a node begins using an address in parallel with Duplicate Address Detection, and another node is already using the address, the node performing Duplicate Address Detection will erroneously process traffic intended for the other node, resulting in such possible negative consequences ... For example DUD messages use :: as source address. Delaying transmission of report is not allowed by the draft So perheaps a correct source address for these messages is :: ? Or is using the tentative IPv6 address as IPv6 source harmless ? -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 72, F-38402 St Martin d'Heres Cedex Tel : +33 4 76 82 72 32 Fax : +33 4 76 82 72 87 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 2 02:43:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA17305 for ipng-dist; Wed, 2 Jun 1999 02:39:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17298 for ; Wed, 2 Jun 1999 02:39:31 -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 CAA02367 for ; Wed, 2 Jun 1999 02:39:31 -0700 (PDT) Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA19499 for ; Wed, 2 Jun 1999 02:39:29 -0700 (PDT) Received: (from richier@localhost) by horus.imag.fr (8.8.5/8.8.5) id LAA28524 for ipng@sunroof.eng.sun.com; Wed, 2 Jun 1999 11:39:28 +0200 (MET DST) Date: Wed, 2 Jun 1999 11:39:28 +0200 (MET DST) From: Jean-Luc Richier Message-Id: <199906020939.LAA28524@horus.imag.fr> In-Reply-To: Jean-Luc Richier's message as of Jun 2, 11:23. Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 7577) Multicast Listener Discovery timing question Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a question about draft-ietf-ipngwg-mld-01.txt about timing considerations. As I said in a previous mail, I suppose the rationale for using MLD on sollicited node multicast groups is that even though multicast addresses whose scope is 2 should not be routed, there can be level 2 bridges/switches which are performing multicast selective forwarding, and thus engage in the mld protocol. draft-ietf-ipngwg-mld-01.txt states: When a node starts listening to a multicast address on an interface, it should immediately transmit an unsolicited Report for that address on that interface, in case it is the first listener on the link. To cover the possibility of the initial Report being lost or damaged, it is recommended that it be repeated once or twice after short delays [Unsolicited Report Interval]. (A simple way to accomplish this is to send the initial Report and then act as if a Multicast-Address-Specific Query was received for that address, and set a timer appropriately). The Unsolicited Report Interval is the time between repetitions of a node's initial report of interest in a multicast address. Default: 10 seconds. But RFC2461 and RFC2462 state: DupAddrDetectTransmits Default: 1, but may be overridden by a link-type specific value in the document that covers issues related to the transmission of IP over a particular link type (e.g., [IPv6-ETHER]). Autoconfiguration also assumes the presence of the variable RetransTimer as defined in [DISCOVERY]. For autoconfiguration purposes, RetransTimer specifies the delay between consecutive Neighbor Solicitation transmissions performed during Duplicate Address Detection (if DupAddrDetectTransmits is greater than 1), as well as the time a node waits after sending the last Neighbor Solicitation before ending the Duplicate Address Detection process. RetransTimer The time between retransmissions of Neighbor Solicitation messages to a neighbor when resolving the address or when probing the reachability of a neighbor. Default: RETRANS_TIMER milliseconds RETRANS_TIMER 1,000 milliseconds Therefore, even if one sets DupAddrDetectTransmits to 2 or 3, the Duplicate address detection algorithm will end before the retransmission of an ``initial Report being lost or damaged''. Is it not a reliability problem ? -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 72, F-38402 St Martin d'Heres Cedex Tel : +33 4 76 82 72 32 Fax : +33 4 76 82 72 87 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 2 06:12:07 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA17406 for ipng-dist; Wed, 2 Jun 1999 06:08:40 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17399 for ; Wed, 2 Jun 1999 06:08:30 -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 GAA11283 for ; Wed, 2 Jun 1999 06:08:29 -0700 (PDT) Received: from itojun.org (ny-ppp017.iij-us.net [216.98.99.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24660; Wed, 2 Jun 1999 07:08:24 -0600 (MDT) Received: from kiwi.itojun.org (localhost [127.0.0.1]) by itojun.org (8.8.8/3.7W) with ESMTP id GAA07037; Wed, 2 Jun 1999 06:06:25 -0700 (PDT) To: ipng@sunroof.eng.sun.com To: charles.perkins@Sun.COM, dbj@cs.cmu.edu X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 7578) mobile-ipv6 and ipsec From: Jun-ichiro itojun Hagino Date: Wed, 02 Jun 1999 06:06:25 -0700 Message-ID: <7035.928328785@lychee.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I may be confused, but if possible could someone please clarify. These question really related to processing order between IPsec and mobile-ipv6. It is not very clear to me (please give me pointer if there are). 1. IPsec SAD to be used for mobile-ipv6 mobile-ipv6 requires (MUST) IPsec in some places, like: 1. packets with Binding update mobile node --> home agent mobile node --> corresponding node 2. packets with Binding acknowledgement home agent --> mobile node correspondent node --> mobile node 3. packets tunneled by home agent correspondent node --> home agent --> mobile node ^this packet For each of those packets, should we use care-of address of mobile node, or home address of mobile node, for looking up SAD (security association database) for IPsec? It looks that (3) case should use care-of address for SAD lookup, as the packet will be like this: outer IPv6: src=home agent, dst=mobile node(care-of) inner IPv6: src=correspondent node, dst=mobile node(home) payload IPsec should protect outer IPv6 header and it should be transport-mode IPsec SAD between (home agent, care-of for mobile node). However, for (2) and (1), it is not very clear for me. For example, in case of (1), if mobile node transmits the following packet, both possibility is there. IPv6: src=mobile node(care-of) dst=corresponding node home addr option: mobile node(home) payload If we are to lookup (care-of for mobile node, corresponding node), IPsec can never get benefit from mobile-ipv6 (mobility is not transparent to IPsec). IKE must be re-executed every time mobile node moves. If we are to lookup (home for mobile node, corresponding node), IPsec can benefit from mobile-ipv6 (mobility is transparent to IPsec). You run IKE just once (between corresponding node, and home address of mobile node) and use that even after moving to other subnet. 2. location of mobile-ipv6 destination options RFC2460 4.1 shows two places to attach destination headers. IP hbh dst1 rt frag ah esp dst2 payload Should I insert mobile-ipv6 options into dst1, or dst2? I'm more convinced to insert to dst2, because: - mobile-ipv6 document suggests that ESP can be used for protecting mobile-ipv6 destination options. Only dst2 is covered by ESP. - mobile-ipv6 destination options are for use on final destination, not intermediate hops. However, if we insert home address option to dst2, we can never look up SAD like (home for mobile node, corresponding node) because home address option itself can be encrypted. 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 Jun 2 07:26:14 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA17462 for ipng-dist; Wed, 2 Jun 1999 07:19:20 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17455 for ; Wed, 2 Jun 1999 07:18:41 -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 HAA20173 for ; Wed, 2 Jun 1999 07:18:10 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22111; Wed, 2 Jun 1999 07:18:08 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id QAA09037; Wed, 2 Jun 1999 16:18:02 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id QAA31590; Wed, 2 Jun 1999 16:18:00 +0200 (MET DST) Message-Id: <199906021418.QAA31590@givry.inria.fr> From: Francis Dupont To: Jun-ichiro itojun Hagino cc: ipng@sunroof.eng.sun.com, charles.perkins@sun.com, dbj@cs.cmu.edu cc: Patrice Romand Subject: (IPng 7579) Re: mobile-ipv6 and ipsec In-reply-to: Your message of Wed, 02 Jun 1999 06:06:25 PDT. <7035.928328785@lychee.itojun.org> Date: Wed, 02 Jun 1999 16:17:58 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: 2. location of mobile-ipv6 destination options RFC2460 4.1 shows two places to attach destination headers. IP hbh dst1 rt frag ah esp dst2 payload Should I insert mobile-ipv6 options into dst1, or dst2? => obviously "dst2" because the mobile host is the final destination, not an intermediate router (hoem address option is clearly a real end-to-end parameter as the source address). I have reversed the two sections because this one has strong consequences. 1. IPsec SAD to be used for mobile-ipv6 mobile-ipv6 requires (MUST) IPsec in some places, like: 1. packets with Binding update mobile node --> home agent mobile node --> corresponding node => this case is "dst2" header from the mobile. 2. packets with Binding acknowledgement home agent --> mobile node correspondent node --> mobile node => this case is with a routing header "rt" to the mobile. 3. packets tunneled by home agent correspondent node --> home agent --> mobile node ^this packet => this last case is for the inner packet (the idea is to avoid forged router advertisement from the home agent to the mobile node, cf 9.7 in I-D 7). For each of those packets, should we use care-of address of mobile node, or home address of mobile node, for looking up SAD (security association database) for IPsec? => in case 1 the SA is in the from mobile way then a wildcard source SAD entry will work (SA is supposed to be destination based then wildcard source selector is legal, cf RFC 2401 4.4.2 second selector in the list). In case 2 we know the real destination (ie. the home address) and we can use it. The case 3 is similar if we only deal with the inner packet which has the home address as the destination. My proposal is to consider routing to the mobile host as a wrapping which is near ignored by security. Both reasonning seems to be valid (or invalid :-) for not mobility bound security too. It looks that (3) case should use care-of address for SAD lookup, as the packet will be like this: outer IPv6: src=home agent, dst=mobile node(care-of) inner IPv6: src=correspondent node, dst=mobile node(home) payload IPsec should protect outer IPv6 header and it should be transport-mode IPsec SAD between (home agent, care-of for mobile node). => tunnel mode is attractive for mobility because it gives the routing stuff without an extra overhead. If we are to lookup (home for mobile node, corresponding node), IPsec can benefit from mobile-ipv6 (mobility is transparent to IPsec). You run IKE just once (between corresponding node, and home address of mobile node) and use that even after moving to other subnet. => the I-D 7 says nothing about this or about what happens for bootstrap in visit (for instance you need IKE with IPv6 transport...). Implementations should help for that but unfortunately most of them have no/not yet support for security today (like mine :-). Regards Francis.Dupont@inria.fr PS: I have added a cc for an exception to my last statement. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 2 07:45:38 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA17493 for ipng-dist; Wed, 2 Jun 1999 07:42:38 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17486 for ; Wed, 2 Jun 1999 07:42:27 -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 HAA22117 for ; Wed, 2 Jun 1999 07:42:27 -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 HAA00424; Wed, 2 Jun 1999 07:42:25 -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.00) with ESMTP id XAA08064; Wed, 2 Jun 1999 23:42:18 +0900 (JST) To: Francis Dupont cc: ipng@sunroof.eng.sun.com, charles.perkins@sun.com, dbj@cs.cmu.edu, Patrice Romand In-reply-to: Francis.Dupont's message of Wed, 02 Jun 1999 16:17:58 +0200. <199906021418.QAA31590@givry.inria.fr> 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: (IPng 7580) Re: mobile-ipv6 and ipsec From: itojun@iijlab.net Date: Wed, 02 Jun 1999 23:42:18 +0900 Message-ID: <8062.928334538@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It looks that (3) case should use care-of address for SAD lookup, > as the packet will be like this: > outer IPv6: src=home agent, dst=mobile node(care-of) > inner IPv6: src=correspondent node, dst=mobile node(home) > payload > IPsec should protect outer IPv6 header and it should be transport-mode > IPsec SAD between (home agent, care-of for mobile node). >=> tunnel mode is attractive for mobility because it gives the routing stuff >without an extra overhead. IPsec tunnel mode has very strict requirement in outer header generation (RFC2401 5.1.2.2). Will mobile-ipv6 work happily with it? You can insert no extension headers between outer IPv6 and inner IPv6. > If we are to lookup (home for mobile node, corresponding node), > IPsec can benefit from mobile-ipv6 (mobility is transparent to IPsec). > You run IKE just once (between corresponding node, and home address of > mobile node) and use that even after moving to other subnet. >=> the I-D 7 says nothing about this or about what happens for bootstrap >in visit (for instance you need IKE with IPv6 transport...). we have IKE works on IPv6 UDP port 500 :-) >Implementations should help for that but unfortunately most of them have >no/not yet support for security today (like mine :-). We already have IPsec in code base and having hard time thinking how should we integrate mobile-ipv6 into it. Maybe I should forget about security for a while... :-( 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 Jun 2 08:03:34 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA17515 for ipng-dist; Wed, 2 Jun 1999 07:57:30 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17508 for ; Wed, 2 Jun 1999 07:57:21 -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 HAA27502 for ; Wed, 2 Jun 1999 07:57:21 -0700 (PDT) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05708; Wed, 2 Jun 1999 07:57:19 -0700 (PDT) Received: from bogey by east.isi.edu (8.8.5/5.61+local-24) id ; Wed, 2 Jun 1999 14:57:07 GMT Message-ID: <001101bead09$51167610$634cf526@east.isi.edu> From: "Aaron Griggs" To: , , , "Jun-ichiro itojun Hagino" References: <7035.928328785@lychee.itojun.org> Subject: (IPng 7581) Re: mobile-ipv6 and ipsec Date: Wed, 2 Jun 1999 11:05:11 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I may be confused, but if possible could someone please clarify. > These question really related to processing order between IPsec and > mobile-ipv6. It is not very clear to me (please give me pointer if > there are). > > 1. IPsec SAD to be used for mobile-ipv6 > mobile-ipv6 requires (MUST) IPsec in some places, like: > 1. packets with Binding update > mobile node --> home agent > mobile node --> corresponding node > 2. packets with Binding acknowledgement > home agent --> mobile node > correspondent node --> mobile node > 3. packets tunneled by home agent > correspondent node --> home agent --> mobile node > ^this packet > For each of those packets, should we use care-of address of mobile > node, or home address of mobile node, for looking up SAD (security > association database) for IPsec? > > It looks that (3) case should use care-of address for SAD lookup, > as the packet will be like this: > outer IPv6: src=home agent, dst=mobile node(care-of) > inner IPv6: src=correspondent node, dst=mobile node(home) > payload > IPsec should protect outer IPv6 header and it should be transport-mode > IPsec SAD between (home agent, care-of for mobile node). > > However, for (2) and (1), it is not very clear for me. > For example, in case of (1), if mobile node transmits the following > packet, both possibility is there. > IPv6: src=mobile node(care-of) dst=corresponding node > home addr option: mobile node(home) > payload > If we are to lookup (care-of for mobile node, corresponding node), > IPsec can never get benefit from mobile-ipv6 (mobility is not > transparent to IPsec). IKE must be re-executed every time mobile > node moves. > If we are to lookup (home for mobile node, corresponding node), > IPsec can benefit from mobile-ipv6 (mobility is transparent to IPsec). > You run IKE just once (between corresponding node, and home address of > mobile node) and use that even after moving to other subnet. > We haven't finished implementing this and I think a discussion would help. My problem is from the SPD perspective, which are usually manually configured. On the correspondent node send side, the home address could be used as the main lookup and IPSec performed for that packet. Once the care-of address is discovered (node is mobile), a second lookup is performed to see if there is any other IPSec for the destination address. An example from the Correspondent Node's view: HomeAddr ----------- HomeSG --------- Internet ------------ CorrespondentNode MobileNode ---------- MobileSG -----| The correspondent node's SPD may have the policy that says for traffic from me to the home address do AH transport to HomeAddr. A care-of address is discovered and the second lookup says do ESP tunnel to MobileSG: IP(CN->MSG)_ESP_IP(CN->MN)_RH(HA)_AH_Data. So in this case, everything works fine. However what if the SPD entries for the HomeAddr was an SA bundle that says do AH transport to HomeAddr and ESP tunnel to HomeSG: IP(CN->HSG)_ESP_IP(CN->HA)_AH_Data When the node is mobile and a care-of address is cached, the ESP tunnel to HomeSG is wrong because the packet is not sent to the home network. One way to handle this is to make sure the SPD doesn't have an SA bundle with HomeSG but then you sacrifice not doing tunnel mode to the home security gateway. Another is to recognize the IPSec tunnel is not to the end station (HomeAddr) but to an intermediate gateway (HomeSG). The IPSec send side processing doesn't complete the bundle processing and does the second lookup using the care-of address. The verification of the proper IPSec (receive side processing) is also affected since the normal SA bundle will cause the packet to be dropped. So, IPSec has to know about the mobile node. Basically, this is doable and not too complicated but IPSec is definitely aware of the mobility. > 2. location of mobile-ipv6 destination options > RFC2460 4.1 shows two places to attach destination headers. > IP hbh dst1 rt frag ah esp dst2 payload > Should I insert mobile-ipv6 options into dst1, or dst2? > > I'm more convinced to insert to dst2, because: > - mobile-ipv6 document suggests that ESP can be used for protecting > mobile-ipv6 destination options. Only dst2 is covered by ESP. > - mobile-ipv6 destination options are for use on final destination, > not intermediate hops. > However, if we insert home address option to dst2, we can never > look up SAD like (home for mobile node, corresponding node) because > home address option itself can be encrypted. > I just read Francis response and the wildcarded source seems the best solution. Here is how our SP entry and corresponding SA entry would look on the correspondent node: SP: RemoteAddr LocalAddr OtherSelectors IPSecProto Direction HomeAddr * * ESP BIDIRECTION SA: SPI SADestAddr IPSecProto DestAddr SourceAddr Direction 2000 HomeAddr ESP POLICY POLICY OUTBOUND 2001 CorrAddr ESP POLICY POLICY INBOUND SA entry with SPI 2001 is still found without knowing the actual home address. After the destination option is processed, the SP verification passes since the remote address is the home address now. Currently MSR, does the destination options for mobility before the IPSec. It sounds like we need to probably change that. Aaron > 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 Wed Jun 2 10:29:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA17694 for ipng-dist; Wed, 2 Jun 1999 10:25:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17687 for ; Wed, 2 Jun 1999 10:25:43 -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 KAA13797 for ; Wed, 2 Jun 1999 10:25:42 -0700 (PDT) Received: from pss-imc-01.microsoft.com (pss-imc-01.microsoft.com [131.107.3.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26866 for ; Wed, 2 Jun 1999 11:25:41 -0600 (MDT) Received: from mail1.microsoft.com (INET-IMC-01 [157.54.9.125]) by pss-imc-01.microsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2591.0) id L5TSN656; Wed, 2 Jun 1999 10:25:30 -0700 Received: by INET-IMC-01 with Internet Mail Service (5.5.2524.0) id ; Wed, 2 Jun 1999 10:25:30 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145151C9@RED-MSG-50> From: Richard Draves To: "'Jean-Luc Richier'" , ipng@sunroof.eng.sun.com Subject: (IPng 7582) RE: Multicast Listener Discovery timing question Date: Wed, 2 Jun 1999 10:25:23 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As I said in a previous mail, I suppose the rationale for using MLD > on sollicited node multicast groups is that even though > multicast addresses > whose scope is 2 should not be routed, there can be level 2 > bridges/switches > which are performing multicast selective forwarding, and thus > engage in the > mld protocol. Gosh, I thought that MLD should *not* be used for link-local multicast addresses. Our implementation does not send MLD messages when it joins solicited-node multicast groups. 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 Jun 2 11:10:07 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA17761 for ipng-dist; Wed, 2 Jun 1999 11:04:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17754 for ; Wed, 2 Jun 1999 11:04:18 -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 LAA28755 for ; Wed, 2 Jun 1999 11:04:17 -0700 (PDT) Received: from horus.imag.fr (horus.imag.fr [129.88.38.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA12077 for ; Wed, 2 Jun 1999 12:04:15 -0600 (MDT) Received: (from richier@localhost) by horus.imag.fr (8.8.5/8.8.5) id UAA09614; Wed, 2 Jun 1999 20:04:08 +0200 (MET DST) Date: Wed, 2 Jun 1999 20:04:08 +0200 (MET DST) From: Jean-Luc Richier Message-Id: <199906021804.UAA09614@horus.imag.fr> In-Reply-To: Richard Draves's message as of Jun 2, 10:25. Organization: IMAG, Grenoble, France X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Richard Draves , ipng@sunroof.eng.sun.com Subject: (IPng 7583) Re: Multicast Listener Discovery timing question Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dans votre courrier du 2 Jun 10:25 vous ecrivez : >> As I said in a previous mail, I suppose the rationale for using MLD >> on sollicited node multicast groups is that even though >> multicast addresses >> whose scope is 2 should not be routed, there can be level 2 >> bridges/switches >> which are performing multicast selective forwarding, and thus >> engage in the >> mld protocol. > >Gosh, I thought that MLD should *not* be used for link-local multicast >addresses. Our implementation does not send MLD messages when it joins >solicited-node multicast groups. > Is my hypothese on the reason for doing MLD for link scope multicast correct? Is there an other reason for the following draft text ? MLD messages ARE sent for multicast addresses whose scope is 2 (link- local), including Solicited-Node multicast addresses [ADDR-ARCH], except for the link-scope, all-nodes address (FF02::1). What is the behaviour for a router if it receives a multicast with scope = 2? Always drop it, or forward it in some cases? and if so, what case(s)? -- Jean-Luc RICHIER (Jean-Luc.Richier@Imag.Fr richier@imag.fr) Laboratoire Logiciels, Systemes et Reseaux (LSR-IMAG) IMAG-CAMPUS, BP 72, F-38402 St Martin d'Heres Cedex Tel : +33 4 76 82 72 32 Fax : +33 4 76 82 72 87 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 2 11:28:22 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA17811 for ipng-dist; Wed, 2 Jun 1999 11:21:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17804 for ; Wed, 2 Jun 1999 11:21:47 -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 LAA26156 for ; Wed, 2 Jun 1999 11:21:47 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25803 for ; Wed, 2 Jun 1999 11:21:45 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id LAA07615; Wed, 2 Jun 1999 11:21:32 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id LAA27732; Wed, 2 Jun 1999 11:21:31 -0700 (PDT) Received: from tdc97-cyndi.tdc.3com.com (tdc63pc.tdc.3com.com [139.87.12.219] (may be forged)) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id LAA29485; Wed, 2 Jun 1999 11:21:30 -0700 (PDT) Message-Id: <3.0.32.19990602111630.00f78860@pop.nsd.3com.com> X-Sender: cmj@pop.nsd.3com.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 02 Jun 1999 11:16:31 -0700 To: Richard Draves , "'Jean-Luc Richier'" , ipng@sunroof.eng.sun.com From: Cyndi Jung Subject: (IPng 7584) Re: Multicast Listener Discovery timing question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:25 AM 6/2/99 -0700, Richard Draves wrote: >> As I said in a previous mail, I suppose the rationale for using MLD >> on sollicited node multicast groups is that even though >> multicast addresses >> whose scope is 2 should not be routed, there can be level 2 >> bridges/switches >> which are performing multicast selective forwarding, and thus >> engage in the >> mld protocol. > >Gosh, I thought that MLD should *not* be used for link-local multicast >addresses. Our implementation does not send MLD messages when it joins >solicited-node multicast groups. > >Rich This has been the source of problems in the IPv4 multicasting. The IGMP specs - right from the beginning - have stated that the membership report be issued for all but the 224.0.0.1 address, even though any address 224.0.0.X is not to be forwarded off the local subnet. The intent was to facilitate efficient forwarding - and filtering - by the layer 2 devices that comprise the local subnet, though this was not explicitly mentioned in the spec. Unfortunately, some people felt it was unnecessary to send membership reports out for those other 224.0.0.X group addresses, and others read the spec and believed everyone else was implementing per the spec, so some of the recent switches with IGMP "snooping" features don't work for some of the routing protocols that use these 224.0.0.X protocols (OSPF, RIPv2, PIM!), because they expect to see a membership report before they forward the packets anywhere. I'm sure the intelligent "layer 3 aware" layer 2 devices will be with us for a long time, and the Users really like the effect of IGMP snooping switches in the IPv4 networks. If the MLD protocol is even *better* at keeping the layer 2 devices informed of group membership - even of groups constrained to the local subnet - it would be an improvement on the current relationship that these devices have multicast in the IPv4 environment. Cyndi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 2 12:03:03 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA17863 for ipng-dist; Wed, 2 Jun 1999 11:40:58 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17856 for ; Wed, 2 Jun 1999 11:40:45 -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 LAA00886 for ; Wed, 2 Jun 1999 11:40:45 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03461 for ; Wed, 2 Jun 1999 11:40:45 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id LAA17372; Wed, 2 Jun 1999 11:39:05 -0700 (PDT) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id LAA06946; Wed, 2 Jun 1999 11:39:04 -0700 (PDT) Received: from tdc97-cyndi.tdc.3com.com (tdc63pc.tdc.3com.com [139.87.12.219] (may be forged)) by chicago.nsd.3com.com (8.8.8/8.8.8) with SMTP id LAA29885; Wed, 2 Jun 1999 11:39:04 -0700 (PDT) Message-Id: <3.0.32.19990602113404.00ae65ac@pop.nsd.3com.com> X-Sender: cmj@pop.nsd.3com.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 02 Jun 1999 11:34:05 -0700 To: Jean-Luc Richier , Richard Draves , ipng@sunroof.eng.sun.com From: Cyndi Jung Subject: (IPng 7585) Re: Multicast Listener Discovery timing question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Is my hypothese on the reason for doing MLD for link scope multicast correct? >Is there an other reason for the following draft text ? > > MLD messages ARE sent for multicast addresses whose scope is 2 (link- > local), including Solicited-Node multicast addresses [ADDR-ARCH], except > for the link-scope, all-nodes address (FF02::1). > >What is the behaviour for a router if it receives a multicast with scope = 2? >Always drop it, or forward it in some cases? and if so, what case(s)? > I believe the router should silently discard these MLD messages, and if it has no local client for scope=2 multicast discard those too. The current behavior for the switches that watch the IGMP messages is to send all IPv4 multicast *data* packets to the router - using a variety of methods to determine which ports have a router attached. Cyndi -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 2 12:04:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA17895 for ipng-dist; Wed, 2 Jun 1999 11:53:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17887 for ; Wed, 2 Jun 1999 11:53:24 -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 LAA03634 for ; Wed, 2 Jun 1999 11:53:24 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01631 for ; Wed, 2 Jun 1999 12:53:23 -0600 (MDT) Received: from [171.68.179.134] ([171.70.127.18]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA07096; Wed, 2 Jun 1999 11:53:19 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <199906020923.LAA27132@horus.imag.fr> References: <199906020923.LAA27132@horus.imag.fr> Date: Wed, 2 Jun 1999 11:53:20 -0700 To: Jean-Luc Richier From: Steve Deering Subject: (IPng 7586) Re: Multicast Listener Discovery Question Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:23 AM +0200 6/2/99, Jean-Luc Richier wrote: >I suppose the rationale is that even though multicast addresses whose scope >is 2 should not be routed, there can be level 2 bridge/switch which are >performing multicast selective forwarding, and thus engage in the mld protocol Approximately right. The reason for requiring listener reports for multicast addresses of link-local scope is to facilitate "MLD snooping" by layer 2 bridges. The way that's currently done (for IPv4), the bridges don't fully "engage" in the protocol, e.g., they don't issue queries, but they do understand the protocol and act on messages they observe. >But now I think that there is a problem at the initialisation of an interface: > >Consider a node that start IPv6 on an interface X; it computes the Link-local >address (llX) of the interface and start Duplicate address detection. So the >node set the tentative address llX on interface X, and therefore enter on X >the sollicited multicast group (maX) associated with llX. Therefore the node >``should immediately transmit an unsolicited Report'' for maX. > >MY QUESTION IS: What is the IPv6 source address for this Report? Good question! >So perheaps a correct source address for these messages is :: ? >Or is using the tentative IPv6 address as IPv6 source harmless ? In this particular case, using the tentative address as the source of the report would be harmless, I think. But for "correctness", I would prefer to see the all-zeros address used as the source address of any packets sent before DAD completes. 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 Jun 2 12:04:49 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA17912 for ipng-dist; Wed, 2 Jun 1999 11:54:34 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA17904 for ; Wed, 2 Jun 1999 11:54:23 -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 LAA12713 for ; Wed, 2 Jun 1999 11:54:19 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA01997 for ; Wed, 2 Jun 1999 12:54:19 -0600 (MDT) Received: from [171.68.179.134] ([171.70.127.18]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id LAA07194; Wed, 2 Jun 1999 11:54:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D810145151C9@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D810145151C9@RED-MSG-50> Date: Wed, 2 Jun 1999 11:54:17 -0700 To: Richard Draves From: Steve Deering Subject: (IPng 7587) Re: Multicast Listener Discovery timing question Cc: "'Jean-Luc Richier'" , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:25 AM -0700 6/2/99, Richard Draves wrote: >Gosh, I thought that MLD should *not* be used for link-local multicast >addresses. Our implementation does not send MLD messages when it joins >solicited-node multicast groups. Tsk, tsk. You should read the spec more carefully. 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 Jun 2 12:26:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA18035 for ipng-dist; Wed, 2 Jun 1999 12:19:03 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18021 for ; Wed, 2 Jun 1999 12:18:38 -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 MAA08803 for ; Wed, 2 Jun 1999 12:18:32 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12198 for ; Wed, 2 Jun 1999 13:18:31 -0600 (MDT) Received: from [171.68.179.134] ([171.70.127.18]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id MAA09522; Wed, 2 Jun 1999 12:18:29 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <199906021804.UAA09614@horus.imag.fr> References: <199906021804.UAA09614@horus.imag.fr> Date: Wed, 2 Jun 1999 12:18:29 -0700 To: Jean-Luc Richier From: Steve Deering Subject: (IPng 7588) Re: Multicast Listener Discovery timing question Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:04 PM +0200 6/2/99, Jean-Luc Richier wrote: >What is the behaviour for a router if it receives a multicast with scope = 2? >Always drop it, or forward it in some cases? and if so, what case(s)? If the router is itself a listener to the destination multicast address, it passes it to the appropriate upper-layer protocol(s) on the router; otherwise, it drops it. It never forwards it. If an upper-layer protocol on the router itself originates a multicast packet with link-local scope, the router transmits that packet on the appropriate link. 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 Jun 2 14:23:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA18215 for ipng-dist; Wed, 2 Jun 1999 14:14:50 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18208 for ; Wed, 2 Jun 1999 14:14:42 -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 OAA07729 for ; Wed, 2 Jun 1999 14:14:41 -0700 (PDT) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA29035 for ; Wed, 2 Jun 1999 15:14:40 -0600 (MDT) Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id RAA38498 for ; Wed, 2 Jun 1999 17:14:38 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id RAA28126 for ; Wed, 2 Jun 1999 17:14:39 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id RAA07390 for ; Wed, 2 Jun 1999 17:14:37 -0400 (EDT) Message-Id: <199906022114.RAA07390@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: (IPng 7590) ipng list maintenance request Date: Wed, 02 Jun 1999 17:14:36 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I like to request a small change in how this list is run. Currently, sequence numbers are added to the subject field of each message sent to the list. My recollection is that this was done to allow folks to easily determine whether they were getting all the messages that were being posted. I personally have not found this to be useful, and I don't recall any other mailing list that does this. On the downside, the sequence number makes it pretty much impossible for mail readers to (sensibly) sort folders based on the subject. This is a moderate pain for those with large folders. Would the list be favorably inclined to dropping the automatic insertion of sequence numbers to the subject field? Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 2 14:41:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA18271 for ipng-dist; Wed, 2 Jun 1999 14:36:12 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18264 for ; Wed, 2 Jun 1999 14:36:03 -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 OAA04058 for ; Wed, 2 Jun 1999 14:36:03 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id OAA10198 for ; Wed, 2 Jun 1999 14:36:01 -0700 (PDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Wed Jun 2 17:34:55 EDT 1999 Received: from dnrc.bell-labs.com (gjapc [135.180.130.101]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id RAA11758; Wed, 2 Jun 1999 17:34:53 -0400 (EDT) Message-ID: <3755A3A2.62F59039@dnrc.bell-labs.com> Date: Wed, 02 Jun 1999 17:35:30 -0400 From: Grenville Armitage Reply-To: gja@dnrc.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten , ipng@sunroof.eng.sun.com Subject: (IPng 7591) Re: ipng list maintenance request References: <199906022114.RAA07390@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: [..] > Would the list be favorably inclined to dropping the automatic > insertion of sequence numbers to the subject field? Yes, please lets drop those sequence numbers! cheers, gja ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs, Lucent Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 2 15:28:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA18327 for ipng-dist; Wed, 2 Jun 1999 15:23:46 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18320 for ; Wed, 2 Jun 1999 15:23:35 -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 PAA22435 for ; Wed, 2 Jun 1999 15:23:34 -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 ESMTP id QAA27172 for ; Wed, 2 Jun 1999 16:23:33 -0600 (MDT) Received: by mail4.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Wed, 2 Jun 1999 15:23:23 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145151CD@RED-MSG-50> From: Richard Draves To: "'Steve Deering'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 7593) Re: Multicast Listener Discovery timing question Date: Wed, 2 Jun 1999 15:23:14 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >Gosh, I thought that MLD should *not* be used for link-local > multicast > >addresses. Our implementation does not send MLD messages > when it joins > >solicited-node multicast groups. > > Tsk, tsk. You should read the spec more carefully. Or in this case, read the spec at least once :-) I didn't work on our MLD implementation so I hadn't looked it. I'll fix this bug. I wonder if many other implementations have fallen into this same trap? I don't recall every seeing an MLD report for a solicited-node multicast address in network traces, although I haven't specifically looked for them either. Might be a good thing for UNH to check for. 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 Jun 2 15:46:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA18354 for ipng-dist; Wed, 2 Jun 1999 15:43:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18347 for ; Wed, 2 Jun 1999 15:42:57 -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 PAA21374 for ; Wed, 2 Jun 1999 15:42:56 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA03782 for ; Wed, 2 Jun 1999 15:42:56 -0700 (PDT) Received: by mail4.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Wed, 2 Jun 1999 15:42:46 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D810145151CF@RED-MSG-50> From: Richard Draves To: "'Aaron Griggs'" , charles.perkins@Sun.COM, dbj@cs.cmu.edu, Jun-ichiro itojun Hagino Cc: ipng@sunroof.eng.sun.com Subject: (IPng 7594) Re: mobile-ipv6 and ipsec Date: Wed, 2 Jun 1999 15:42:44 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would like to followup on Aaron's mail with a quick example that shows how complex the IPsec & mobility interaction can be. We had a discussion a few months ago about all this, but it didn't really resolve the issues. Suppose you initiate a TCP connection with a host MH. Your SPD says to use transport-mode AH when communicating with the home address. So the TCP connection is protected with transport-mode AH. All is well. Then the host MH moves. In fact it moves behind a security gateway SG and assumes a care-of address. Your SPD tells you to use tunnel-mode ESP to SG when communicating with the care-of address. In this case your SPD says to use transport-mode AH for the home address and tunnel-mode ESP for the care-of address. I think the desired result is that you send packets protected both ways - the outer headers are tunnel-mode (to SG) ESP, the inner headers are transport-mode AH. 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 Jun 2 15:52:01 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA18372 for ipng-dist; Wed, 2 Jun 1999 15:48:44 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18365 for ; Wed, 2 Jun 1999 15:48:35 -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 PAA17893 for ; Wed, 2 Jun 1999 15:48:34 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA07311 for ; Wed, 2 Jun 1999 16:48:32 -0600 (MDT) Received: from new (satsuma.iprg.nokia.com [205.226.1.120]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id PAA18637; Wed, 2 Jun 1999 15:47:59 -0700 (PDT) Message-Id: <3.0.5.32.19990602154517.032b8210@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 02 Jun 1999 15:45:17 -0700 To: Thomas Narten From: Bob Hinden Subject: (IPng 7595) Re: ipng list maintenance request Cc: ipng@sunroof.eng.sun.com In-Reply-To: <199906022114.RAA07390@cichlid.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, I will what can be done. Maybe the sequence numbers could be moved to the end of the subject line. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 3 12:16:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA19295 for ipng-dist; Thu, 3 Jun 1999 12:10:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19288 for ; Thu, 3 Jun 1999 12:10:03 -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 MAA02129 for ; Thu, 3 Jun 1999 12:10:03 -0700 (PDT) Received: from rs.arin.net (rs1.arin.net [192.149.252.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id MAA14202 for ; Thu, 3 Jun 1999 12:10:02 -0700 (PDT) Received: (qmail 11831 invoked from network); 3 Jun 1999 19:10:01 -0000 Received: from ops.arin.net (192.149.252.141) by rs1.arin.net with SMTP; 3 Jun 1999 19:10:01 -0000 Received: from orr.arin.net (orr.arin.net [192.149.252.201]) by ops.arin.net (8.9.0/8.9.0) with ESMTP id PAA25139; Thu, 3 Jun 1999 15:10:00 -0400 (EDT) Received: from localhost by orr.arin.net (8.9.3/8.9.0) with SMTP id PAA04317; Thu, 3 Jun 1999 15:10:00 -0400 (EDT) X-Authentication-Warning: orr.arin.net: raminr owned process doing -bs Date: Thu, 3 Jun 1999 15:09:59 -0400 (EDT) From: Ramin Sepehr Rad Reply-To: Ramin Sepehr Rad To: Thomas Narten cc: ipng@sunroof.eng.sun.com Subject: Re: (IPng 7590) ipng list maintenance request In-Reply-To: <199906022114.RAA07390@cichlid.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 2 Jun 1999, Thomas Narten wrote: > Currently, sequence numbers are added to the subject field of each > message sent to the list. My recollection is that this was done to > allow folks to easily determine whether they were getting all the > messages that were being posted. I personally have not found this to > be useful, and I don't recall any other mailing list that does this. Thomas, I believe there is a more significant reason for having the sequence numbers and that is referring to certain postings by their numbers. As Mr. Hinden suggested in his posting (IPng 7595 :), perhaps the sequence number can be added to the end of the subject line. Furthermore, it would be nice to see followup messages increment the number after the decimal point. Something like this: Subject : ipng list maintenance request (IPng 7590) Subject : ipng list maintenance request (IPng 7590.1) Subject : ipng list maintenance request (IPng 7590.2) etc. Should be fairly simple to implement. -ramin ps: Please don't send me any flames on ARIN's ticket system. :) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 3 13:20:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA19408 for ipng-dist; Thu, 3 Jun 1999 13:10:18 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19401 for ; Thu, 3 Jun 1999 13:10: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 NAA11623 for ; Thu, 3 Jun 1999 13:10:04 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id NAA06356 for ; Thu, 3 Jun 1999 13:10:02 -0700 (PDT) Received: from zubin.dnrc.bell-labs.com ([135.180.130.56]) by dirty; Thu Jun 3 16:09:45 EDT 1999 Received: from dnrc.bell-labs.com (gja000.lra.lucent.com [135.17.250.232]) by zubin.dnrc.bell-labs.com (8.8.8/8.8.8) with ESMTP id QAA04026; Thu, 3 Jun 1999 16:09:40 -0400 (EDT) Message-ID: <3756E09A.6EB8F95C@dnrc.bell-labs.com> Date: Thu, 03 Jun 1999 16:07:54 -0400 From: Grenville Armitage Reply-To: gja@dnrc.bell-labs.com Organization: Bell Laboratories, Lucent Technologies X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ramin Sepehr Rad CC: Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: (IPng 7590) ipng list maintenance request References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ramin, Sequence numbers are a pain for subject-threaded emailers, and you can refer to past email by date and time if its really necessary for context. Sorting by send date within a subject-threaded list also provides intra-thread sequencing. I'll be thrilled to see them gone. cheers, gja Ramin Sepehr Rad wrote: > > On Wed, 2 Jun 1999, Thomas Narten wrote: > > > Currently, sequence numbers are added to the subject field of each > > message sent to the list. My recollection is that this was done to > > allow folks to easily determine whether they were getting all the > > messages that were being posted. I personally have not found this to > > be useful, and I don't recall any other mailing list that does this. > > Thomas, > > I believe there is a more significant reason for having the sequence numbers > and that is referring to certain postings by their numbers. > > As Mr. Hinden suggested in his posting (IPng 7595 :), perhaps the sequence > number can be added to the end of the subject line. > > Furthermore, it would be nice to see followup messages increment the > number after the decimal point. Something like this: > > Subject : ipng list maintenance request (IPng 7590) > Subject : ipng list maintenance request (IPng 7590.1) > Subject : ipng list maintenance request (IPng 7590.2) > > etc. > > Should be fairly simple to implement. > > -ramin > > ps: Please don't send me any flames on ARIN's ticket system. :) > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- ________________________________________________________________________ Grenville Armitage http://mh005.infi.net/~gja Bell Labs, Lucent Technologies -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 3 14:33:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA19477 for ipng-dist; Thu, 3 Jun 1999 14:28:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19469 for ; Thu, 3 Jun 1999 14:28:08 -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 OAA00162 for ; Thu, 3 Jun 1999 14:28:07 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27372 for ; Thu, 3 Jun 1999 15:28:07 -0600 (MDT) Received: from new (satsuma.iprg.nokia.com [205.226.1.120]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id OAA21400; Thu, 3 Jun 1999 14:28:06 -0700 (PDT) Message-Id: <3.0.5.32.19990603142750.033dddd0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 03 Jun 1999 14:27:50 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPng List Change In-Reply-To: <3756E09A.6EB8F95C@dnrc.bell-labs.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPng w.g. chairs have asked the IPng list maintainer to remove the sequence numbers from subject lines. As you can see from this email the sequence numbers are now gone. We investigated moving the sequence numbers elsewhere, but concluded it was not worth the effort to implement. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 4 03:56:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA20110 for ipng-dist; Fri, 4 Jun 1999 03:53:33 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20103 for ; Fri, 4 Jun 1999 03:53:24 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id DAA02234 for ; Fri, 4 Jun 1999 03:53:24 -0700 (PDT) Received: from digi-data.com (ns.digi-data.com [209.94.197.193]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA15093 for ; Fri, 4 Jun 1999 04:53:22 -0600 (MDT) Received: by odin.digi-data.com id <15234>; Fri, 4 Jun 1999 06:49:51 -0400 Message-Id: <99Jun4.064951gmt-0400.15234@odin.digi-data.com> Date: Fri, 4 Jun 1999 06:55:56 -0400 From: Robert Honore Reply-To: robert@digi-data.com Organization: Digi-Data Systems Limited X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten , IPng@sunroof.eng.sun.com Subject: Re: (IPng 7590) ipng list maintenance request References: <199906022114.RAA07390@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Thomas, Yes, I would be in favour of dropping the IPng sequence number from the subject line. Yours sincerely, Robert Honore. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 4 17:20:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA20845 for ipng-dist; Fri, 4 Jun 1999 17:13:31 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20838 for ; Fri, 4 Jun 1999 17:13:23 -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 RAA12279 for ; Fri, 4 Jun 1999 17:13:18 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA19308 for ; Fri, 4 Jun 1999 18:13:17 -0600 (MDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA08745; Fri, 4 Jun 1999 17:12:40 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <19990511013053.E33E841F16@SIGABA.research.att.com> References: <19990511013053.E33E841F16@SIGABA.research.att.com> Date: Fri, 4 Jun 1999 17:12:38 -0700 To: "Steven M. Bellovin" From: Steve Deering Subject: Re: (IPng 7503) Re: Last Call: IPv6 Jumbograms to Proposed Standard Cc: Craig Metz , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Very belated comment: At 9:30 PM -0400 5/10/99, Steven M. Bellovin wrote: >Bump in the wire is fine -- it's AH that's the problem. No. Bump-in-the-wire (or anything else that inserts extension headers into IPv6 packets, unknown to the originating upper-layer protocol) breaks other things as well as AH, for example fragmentation-avoidance through MTU discovery, and the TCP MSS mechanism. The safe way to add info to a packet en-route (i.e., anywhere past the originating upper-layer protocol) is by encapsulation, not header-insertion. If the IPsec specs allow or encourage en-route header-insertion, they are incompatible with the rest of the IP architecture (both versions), and ought to be fixed. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 4 17:39:00 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA20877 for ipng-dist; Fri, 4 Jun 1999 17:34:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20870 for ; Fri, 4 Jun 1999 17:34:30 -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 RAA17342 for ; Fri, 4 Jun 1999 17:34:29 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA23139 for ; Fri, 4 Jun 1999 18:34:29 -0600 (MDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id RAA10254; Fri, 4 Jun 1999 17:34:09 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <19990513223042.BCBC241F16@SIGABA.research.att.com> References: <19990513223042.BCBC241F16@SIGABA.research.att.com> Date: Fri, 4 Jun 1999 17:34:07 -0700 To: "Steven M. Bellovin" From: Steve Deering Subject: Re: (IPng 7527) Re: Last Call: IPv6 Jumbograms to Proposed Standa rd Cc: Bill Sommerfeld , Craig Metz , Richard Draves , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 6:30 PM -0400 5/13/99, Steven M. Bellovin wrote: >I don't know what to do about the flow-id. RFC 2460 is explicitly vague >about how flow-ids are to be used, and is silent on one crucial point -- can >routers change the flow-id en route? We asked the ipsec WG to exclude the Flow Label from the AH computation, to leave open the possibility of routers changing it en-route. > But my >conclusion -- that we had not established any particular benefit to AH's >semantics -- remains. For IPv6 end-system options, my personal preference >it to put those after the ESP (with null encryption) header. For hop-by-hop >options, AH can't help; again, such options are by definition of interest >to routers, and routers can't verify the AH checksum. I don't think that's entirely true. The Routing header is of interest to routers, but the ability for the final destination to verify the authenticity of the Routing header was deemed crucial. The same may be true of yet-to-be-defined hop-by-hop options or "segment-by-segment" options (i.e., options in a Destination Options header that precede a Routing header). Though the data fields of some options may be mutable en-route, others may not. And in all cases, the Type and Length fields of an option are immutable and may need to be authenticated end-to-end (and are not necessarily derivable by knowing the SPI). And someone else may have also mentioned this: the Next Header field of the IPv6 header is not necessarily derivable/authenticatable just by knowing the SPI -- SPIs are supposed to be able to work at a number of granularities, including basic node-to-node, in which all traffic between a pair of nodes is covered by a single SPI, regardless of protocol/next-header type. Or has the ipsec working group broken that too? Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 4 17:58:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA20956 for ipng-dist; Fri, 4 Jun 1999 17:55:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA20949 for ; Fri, 4 Jun 1999 17:55:31 -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 RAA19892 for ; Fri, 4 Jun 1999 17:55:32 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA26492 for ; Fri, 4 Jun 1999 18:55:32 -0600 (MDT) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Fri, 4 Jun 1999 17:55:21 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515213@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: replying to anycast address Date: Fri, 4 Jun 1999 17:55:18 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I recently came across this question while doing some interop testing. Our MSR IPv6 implementation was failing to reply to ICMP Echo Requests. It turns out the Echo Requests were sent with a source address that was a reserved subnet anycast address, eg of the form a:b:c:d::. Obviously the sending implementation was in error, because you shouldn't send packets with an anycast source address. (RFC 2373, section 2.6) However was our implementation behaving correctly by refusing to send a reply to the anycast address? RFC2463 section 2.4 calls out this case for ICMP errors, saying that errors must not be sent to addresses known not to be unique. But this was an ICMP Echo Reply, not an error. Any opinions? Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 4 18:27:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA20991 for ipng-dist; Fri, 4 Jun 1999 18:22:37 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA20984 for ; Fri, 4 Jun 1999 18:22:29 -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 SAA29611 for ; Fri, 4 Jun 1999 18:22:30 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA24806 for ; Fri, 4 Jun 1999 18:22:30 -0700 (PDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id SAA13593; Fri, 4 Jun 1999 18:22:29 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014515213@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D81014515213@RED-MSG-50> Date: Fri, 4 Jun 1999 18:22:27 -0700 To: Richard Draves From: Steve Deering Subject: Re: replying to anycast address Cc: "'IPng List'" Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 5:55 PM -0700 6/4/99, Richard Draves wrote: >I recently came across this question while doing some interop testing. Our >MSR IPv6 implementation was failing to reply to ICMP Echo Requests. It turns >out the Echo Requests were sent with a source address that was a reserved >subnet anycast address, eg of the form a:b:c:d::. > >Obviously the sending implementation was in error, because you shouldn't >send packets with an anycast source address. (RFC 2373, section 2.6) > >However was our implementation behaving correctly by refusing to send a >reply to the anycast address? In my opinion, yes, it was correct behavior to refuse to reply to an illegal source address (same would be true if the address were multicast or all-zeros, and for any upper-layer protocol, whether TCP, UDP, or ICMP Echo). Note, however, that a node cannot always tell that the source address of a received packet is an anycast address, so we cannot insist that a node never reply to such a packet. Therefore, I would not consider a node that *did* reply to a packet from an anycast source to be faulty. As you said, the fault was on the part of the original sender of the packet with the anycast source address. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 4 19:38:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA21046 for ipng-dist; Fri, 4 Jun 1999 19:33:49 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21039 for ; Fri, 4 Jun 1999 19:33:37 -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 TAA03924 for ; Fri, 4 Jun 1999 19:33:39 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA04884 for ; Fri, 4 Jun 1999 19:33:38 -0700 (PDT) Received: from hermes.research.att.com (hermes.research.att.com [135.207.16.38]) by mail-blue.research.att.com (Postfix) with ESMTP id B30654CE03; Fri, 4 Jun 1999 22:33:37 -0400 (EDT) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by hermes.research.att.com (8.8.7/8.8.7) with ESMTP id WAA28949; Fri, 4 Jun 1999 22:33:35 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id D7D4541F16; Fri, 4 Jun 1999 22:33:35 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id C8DC2400B4; Fri, 4 Jun 1999 22:33:30 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: Steve Deering Cc: Craig Metz , ipng@sunroof.eng.sun.com Subject: Re: (IPng 7503) Re: Last Call: IPv6 Jumbograms to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Jun 1999 22:33:30 -0400 From: "Steven M. Bellovin" Message-Id: <19990605023335.D7D4541F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Steve Deering writes: > Very belated comment: > > At 9:30 PM -0400 5/10/99, Steven M. Bellovin wrote: > >Bump in the wire is fine -- it's AH that's the problem. > > No. Bump-in-the-wire (or anything else that inserts extension headers > into IPv6 packets, unknown to the originating upper-layer protocol) > breaks other things as well as AH, for example fragmentation-avoidance > through MTU discovery, and the TCP MSS mechanism. I thought you had said, in a note to me on another topic, that header insertion was ok as long as the inserted header was removed before it got to the same protocol layer at the other end. That notwithstanding, I agree with your basic point. If you're going to use a peripheral to insert AH, instead of doing it on-host, you have to configure your device driver appropriately, and therefore reduce the MTU. (This suggests that drivers SHOULD allow a delta to their natural MTU, if any.) An IPSEC box that handles multiple hosts is using tunnel mode, and hence encapsulation, in any event. But perhaps the real question here is whether or not transport mode is appropriate. > > The safe way to add info to a packet en-route (i.e., anywhere past the > originating upper-layer protocol) is by encapsulation, not header-insertion. > > If the IPsec specs allow or encourage en-route header-insertion, they > are incompatible with the rest of the IP architecture (both versions), > and ought to be fixed. IPsec says "put a header *here* for transport mode". It says nothing about how you implement that; however, much cryptographic gear is done in outboard units for quite a number of reasons. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 4 19:53:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA21076 for ipng-dist; Fri, 4 Jun 1999 19:47:51 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21069 for ; Fri, 4 Jun 1999 19:47:42 -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 TAA04602 for ; Fri, 4 Jun 1999 19:47:40 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA09974 for ; Fri, 4 Jun 1999 20:47:39 -0600 (MDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id TAA17581; Fri, 4 Jun 1999 19:47:13 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: In-Reply-To: <19990605023335.D7D4541F16@SIGABA.research.att.com> References: <19990605023335.D7D4541F16@SIGABA.research.att.com> Date: Fri, 4 Jun 1999 19:47:10 -0700 To: "Steven M. Bellovin" From: Steve Deering Subject: Re: (IPng 7503) Re: Last Call: IPv6 Jumbograms to Proposed Standard Cc: Craig Metz , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:33 PM -0400 6/4/99, Steven M. Bellovin wrote: >I thought you had said, in a note to me on another topic, that header >insertion was ok as long as the inserted header was removed before it >got to the same protocol layer at the other end. That's true, or more generally, any transformation en-route is permitted as long as it is undone before delivery, even translation to Swahili. Note however, that that may have a serious performance impact if, for example, it causes packets that would otherwise have fit in the path MTU to now require fragmentation. The problem with bump-in-the-stack header-insertion is that there is no way to know that the destination has a corresponding bump that will remove the inserted header before delivery. > >That notwithstanding, I agree with your basic point. If you're going to >use a peripheral to insert AH, instead of doing it on-host, you have to >configure your device driver appropriately, and therefore reduce the MTU. >(This suggests that drivers SHOULD allow a delta to their natural MTU, if >any.) I don't think that's sufficient to deal with the MSS problem. > An IPSEC box that handles multiple hosts is using tunnel mode, and >hence encapsulation, in any event. But perhaps the real question here >is whether or not transport mode is appropriate. It's appropriate when the transport protocol knows it's happening. It's not appropriate to do without the knowledge of the transport layer. Outboard implementation usually implies that the transport layer will not know it's happening. (Sorry for re-starting a thread that I won't be able to continue with: I am departing for a week's mostly-laptop-free vacation early tomorrow morning.) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 4 20:01:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA21105 for ipng-dist; Fri, 4 Jun 1999 19:58:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA21098 for ; Fri, 4 Jun 1999 19:58:34 -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 TAA05425 for ; Fri, 4 Jun 1999 19:58:36 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA08238 for ; Fri, 4 Jun 1999 19:58:35 -0700 (PDT) Received: from hermes.research.att.com (hermes.research.att.com [135.207.16.38]) by mail-green.research.att.com (Postfix) with ESMTP id EC27B1E017; Fri, 4 Jun 1999 22:58:34 -0400 (EDT) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by hermes.research.att.com (8.8.7/8.8.7) with ESMTP id WAA29085; Fri, 4 Jun 1999 22:58:32 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id 81B1941F16; Fri, 4 Jun 1999 22:58:33 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id 72AF5400B4; Fri, 4 Jun 1999 22:58:28 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: Steve Deering Cc: Bill Sommerfeld , Craig Metz , Richard Draves , ipng@sunroof.eng.sun.com Subject: Re: (IPng 7527) Re: Last Call: IPv6 Jumbograms to Proposed Standa rd Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 04 Jun 1999 22:58:27 -0400 From: "Steven M. Bellovin" Message-Id: <19990605025833.81B1941F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , Steve Deering writes: > At 6:30 PM -0400 5/13/99, Steven M. Bellovin wrote: > >I don't know what to do about the flow-id. RFC 2460 is explicitly vague > >about how flow-ids are to be used, and is silent on one crucial point -- can > >routers change the flow-id en route? > > We asked the ipsec WG to exclude the Flow Label from the AH computation, > to leave open the possibility of routers changing it en-route. OK -- in that case, AH can't protect it. > > > But my > >conclusion -- that we had not established any particular benefit to AH's > >semantics -- remains. For IPv6 end-system options, my personal preference > >it to put those after the ESP (with null encryption) header. For hop-by-hop > >options, AH can't help; again, such options are by definition of interest > >to routers, and routers can't verify the AH checksum. > > I don't think that's entirely true. The Routing header is of interest > to routers, but the ability for the final destination to verify the > authenticity of the Routing header was deemed crucial. Yes and no. The authenticity of a route matters today only for programs that do address-based authentication. That's a broken concept (always has been, in fact), and is made obsolete by IPsec. But there's a more fundamental problem. A signed source route is merely proof that the route hasn't been tampered with after it left the signing host. It does not mean that it is valid, in the sense that it is authorized. That is, suppose I want to spoof your source address. Today, with IPv4, I can use source routing in the header, thus overriding the routing system on the return packet. The intent of using AH here is to prevent that, by having the source route authenticated. But I can authenticate it, by claiming to be me via IPsec, rather than you. The AH check will find that the checksum is valid, and that the source route is therefore good. I can hear the objection now -- that the IPsec certificate should identify the legitimate owner of that address, thus preventing the spoof. Precisely -- but if it can do that, it doesn't need to verify the route if the concern is address-spoofing. There may be some desire to prevent an enemy from rerouting a packet. Sorry; you can't do that this way. Either the enemy can't intercept the packet, in which case they can't touch it anyway, or they can, in which case they can send it whereever they want. Without security associations with the routers, you can't control what they do. Routes can have security significance in only three ways. First, there's simply service guarantees -- you want the packets to be delivered. But the routers can't interpret the AH header, so that doesn't work. Second, there's address-spoofing, a subject I hope I've disposed of above. Third, there's the desire for secrecy. Apart from the obvious -- if I can insert a fake routing header at some point, I can do my eavesdropping then, too -- the right way to achieve secrecy is by using ESP. > The same may be > true of yet-to-be-defined hop-by-hop options or "segment-by-segment" > options (i.e., options in a Destination Options header that precede > a Routing header). Though the data fields of some options may be > mutable en-route, others may not. And in all cases, the Type and Length > fields of an option are immutable and may need to be authenticated > end-to-end (and are not necessarily derivable by knowing the SPI). Mumble. It's rather hard to analyze the security properties of something that isn't invented yet; I don't think I'll try to. > > And someone else may have also mentioned this: the Next Header field > of the IPv6 header is not necessarily derivable/authenticatable just > by knowing the SPI -- SPIs are supposed to be able to work at a number > of granularities, including basic node-to-node, in which all traffic > between a pair of nodes is covered by a single SPI, regardless of > protocol/next-header type. Or has the ipsec working group broken > that too? The Next Header field will be pointing to the AH or ESP header; their packet formats in turn contain the original Next Header value. I'm not sure what the word "too" is supposed to imply, but your statement of the desired granularities of the SPI was a fundamental design goal of all of IPsec. My basic conclusion remains: AH isn't particularly useful. If you really need to protect the header, use encapsulation (which you preferred in your other message tonight in this thread....). Ironically, there is one thing that AH is good for, Steve, but I don't think it's a use you'd approve of. Because a listener can tell that AH is used, and hence can see a plaintext packet (as opposed to null ESP, where without either context or heuristics you can't know that), it's possible for it to peek at TCP port numbers, the sequence and ACK fields, etc. In other words, AH permits all the layer violations that the TF-ESP header would permit and that you so strenuously opposed... > > Steve Ditto... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 5 05:29:01 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA21505 for ipng-dist; Sat, 5 Jun 1999 05:16:20 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA21498 for ; Sat, 5 Jun 1999 05:16:09 -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 FAA11000 for ; Sat, 5 Jun 1999 05:16:04 -0700 (PDT) Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA09247 for ; Sat, 5 Jun 1999 05:16:04 -0700 (PDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.0.Beta5/8.8.5) id IAA03206; Sat, 5 Jun 1999 08:15:53 -0400 (EDT) Date: Sat, 5 Jun 1999 08:15:53 -0400 (EDT) From: Scott Bradner Message-Id: <199906051215.IAA03206@newdev.harvard.edu> To: deering@cisco.com, smb@research.att.com Subject: Re: (IPng 7503) Re: Last Call: IPv6 Jumbograms to Proposed Standard Cc: cmetz@inner.net, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve sez: > That's true, or more generally, any transformation en-route is permitted > as long as it is undone before delivery, even translation to Swahili. > Note however, that that may have a serious performance impact if, for > example, it causes packets that would otherwise have fit in the path > MTU to now require fragmentation. but isn't this true for tunneling? i.e. not a header insertion specific performance poblem? So the problem is the same if the header is inserted or prepended, as in an ipsec tunnel Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 5 10:31:47 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA21596 for ipng-dist; Sat, 5 Jun 1999 10:26:11 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21589 for ; Sat, 5 Jun 1999 10:26:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id KAA22713 for ; Sat, 5 Jun 1999 10:26:00 -0700 (PDT) Received: from om2.gto.net.om (om2.gto.net.om [206.49.101.42]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA10073 for ; Sat, 5 Jun 1999 11:25:53 -0600 (MDT) Received: from peterdd.gto.net.om([209.58.12.112]) (2655 bytes) by om2.gto.net.om via sendmail with P:smtp/R:inet_hosts/T:smtp (sender: ) id for ; Sat, 5 Jun 1999 18:01:35 +0400 (OMAN) (Smail-3.2.0.102 1998-Aug-2 #21 built 1998-Aug-20) Message-ID: <37592DC3.82C4D8A9@gto.net.om> Date: Sat, 05 Jun 1999 18:01:42 +0400 From: Peter Dawson X-Mailer: Mozilla 4.0 [en] (Win95; I) MIME-Version: 1.0 To: Bob Fink CC: IPng Subject: Re: (ngtrans) new ngtrans archive X-Priority: 3 (Normal) References: <4.1.19990604203001.00bbff00@imap2.es.net> Content-Type: multipart/alternative; boundary="------------BE79300CC12F581AFB70D3F7" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------BE79300CC12F581AFB70D3F7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bob, It would be nice to have the IPng mail also a threaded archive ! just a thought.. /Pete Bob Fink wrote: > > > Thanks to Grant Miller of WWU, we now have a nice threaded mail > list archive for the ngtrans list: > > > > He has been able to thread the last 12 months of email (July 98 > thru June 99). > > > This pointer can also be found on the ngtrans web pages along > with the regular IETF flat file mail archive at: > > > > > Also, remember that the ngtrans pages are pointed to from the > 6bone home page. > > > Thanks, > > Bob > > PS: and again a big thankyou to Grant Miller. He also maintains > the threaded mail list for the 6bone. --------------BE79300CC12F581AFB70D3F7 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bob,

It would be nice to have the IPng mail also a threaded archive !
just a thought..

/Pete

Bob Fink wrote:

 

Thanks to Grant Miller of WWU, we now have a nice threaded mail list archive for the ngtrans list:

 <http://www.wcug.wwu.edu/lists/ngtrans>

He has been able to thread the last 12 months of email (July 98 thru June 99).
 

This pointer can also be found on the ngtrans web pages along with the regular IETF flat file mail archive at:

 <http://www.6bone.net/ngtrans.html>
 

Also, remember that the ngtrans pages are pointed to from the 6bone home page.
 

Thanks,

Bob

PS: and again a big thankyou to Grant Miller. He also maintains the threaded mail list for the 6bone.

  --------------BE79300CC12F581AFB70D3F7-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 5 19:11:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA22049 for ipng-dist; Sat, 5 Jun 1999 19:03:37 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22042 for ; Sat, 5 Jun 1999 19:03:25 -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 TAA20456 for ; Sat, 5 Jun 1999 19:03:25 -0700 (PDT) Received: from wcug.wwu.edu (sloth.wcug.wwu.edu [140.160.164.200]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id TAA01651 for ; Sat, 5 Jun 1999 19:03:25 -0700 (PDT) Received: (qmail 9047 invoked by uid 1008); 6 Jun 1999 02:03:24 -0000 Date: Sat, 5 Jun 1999 19:03:24 -0700 (PDT) From: Grant Miller X-Sender: grant@sloth To: Peter Dawson cc: Bob Fink , IPng Subject: Re: (ngtrans) new ngtrans archive In-Reply-To: <37592DC3.82C4D8A9@gto.net.om> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 5 Jun 1999, Peter Dawson wrote: > Bob, > > It would be nice to have the IPng mail also a threaded archive ! > just a thought.. > > /Pete > One step ahead of you: http://www.wcug.wwu.edu/lists/ipng/ It's missing May 99 and the first few days of this month, but other than that, it has all the messages since August 94. Once the flat-files for those two months show up on playground.sun.com, I'll import them. --Grant Miller Western Computer User Group, Western Washington University www.wcug.wwu.edu/clubs/wcug -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 5 22:11:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA22113 for ipng-dist; Sat, 5 Jun 1999 22:01:58 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA22106 for ; Sat, 5 Jun 1999 22:01:47 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA20324; Sat, 5 Jun 1999 22:01:46 -0700 (PDT) Date: Sat, 5 Jun 1999 21:59:48 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: (IPng 7503) Re: Last Call: IPv6 Jumbograms to Proposed Standard To: Scott Bradner Cc: deering@cisco.com, smb@research.att.com, cmetz@inner.net, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199906051215.IAA03206@newdev.harvard.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Steve sez: > > That's true, or more generally, any transformation en-route is permitted > > as long as it is undone before delivery, even translation to Swahili. > > Note however, that that may have a serious performance impact if, for > > example, it causes packets that would otherwise have fit in the path > > MTU to now require fragmentation. > > but isn't this true for tunneling? i.e. not a header insertion specific > performance poblem? So the problem is the same if the header is inserted or > prepended, as in an ipsec tunnel No. The difference is that with encapsulation the source address refers to the encapsulator. Thus it should be able to interpret the ICMP packet too big and do the right thing. It is header insertion without modifying the source address that causes problems. Any ICMP packet to big is sent to the source but the source doesn't know that the packets "grew" along the path. The node respondible for increasing the packet size might never see the ICMP "packet too big" errors (even if it is snooping all packets - assymetric routing might send the errors some other path). 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 Sun Jun 6 01:29:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA22246 for ipng-dist; Sun, 6 Jun 1999 01:25:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22239 for ; Sun, 6 Jun 1999 01:25:42 -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 BAA28547 for ; Sun, 6 Jun 1999 01:25:37 -0700 (PDT) Received: from munnari.OZ.AU (munnari.OZ.AU [128.250.1.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id BAA19679 for ; Sun, 6 Jun 1999 01:25:35 -0700 (PDT) Received: from mundamutti.cs.mu.OZ.AU ([128.250.1.5]) by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.59) id IA10432; Sun, 6 Jun 1999 18:25:23 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: "Steven M. Bellovin" Cc: ipng@sunroof.eng.sun.com Subject: Re: (IPng 7527) Re: Last Call: IPv6 Jumbograms to Proposed Standa rd In-Reply-To: Your message of "Fri, 04 Jun 1999 22:58:27 -0400." <19990605025833.81B1941F16@SIGABA.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 06 Jun 1999 18:25:21 +1000 Message-Id: <19501.928657521@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 04 Jun 1999 22:58:27 -0400 From: "Steven M. Bellovin" Message-ID: <19990605025833.81B1941F16@SIGABA.research.att.com> | Routes can have security significance in only three ways. Your list might be accurate for direct security significance, but I don't think that's the end of the story. Eg: one possible for future use of routing headers is related to charging. The routes that packets use might have all kinds of implications to charging, from a service provider charging at different rates based upon the path that was used (charging more to clients who request an expensive high bandwidth path perhaps). Clearly this can't work unless the route can be authenticated (at least that it represents what the originator wanted to be there). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Jun 6 05:27:01 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA22331 for ipng-dist; Sun, 6 Jun 1999 05:24:00 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA22324 for ; Sun, 6 Jun 1999 05:23:49 -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 FAA07845; Sun, 6 Jun 1999 05:23:43 -0700 (PDT) Received: from newdev.harvard.edu (newdev.harvard.edu [128.103.65.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA19232; Sun, 6 Jun 1999 06:23:43 -0600 (MDT) Received: (from sob@localhost) by newdev.harvard.edu (8.9.0.Beta5/8.8.5) id IAA04448; Sun, 6 Jun 1999 08:23:28 -0400 (EDT) Date: Sun, 6 Jun 1999 08:23:28 -0400 (EDT) From: Scott Bradner Message-Id: <199906061223.IAA04448@newdev.harvard.edu> To: Erik.Nordmark@eng.sun.com Subject: Re: (IPng 7503) Re: Last Call: IPv6 Jumbograms to Proposed Standard Cc: cmetz@inner.net, deering@cisco.com, ipng@sunroof.eng.sun.com, smb@research.att.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > No. The difference is that with encapsulation the source address refers > to the encapsulator. Thus it should be able to interpret the ICMP packet too > big and do the right thing. but the actual source will still have to shrink the MTU and the encapsulator has to return a packet too big to the actual source (or next level in encapsulator) with the correct - corected for encapsulation - mtu I seem to be missing something because that seems like the same thing that header inserters have to do Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 07:13:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA22361 for ipng-dist; Sun, 6 Jun 1999 07:10:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA22354 for ; Sun, 6 Jun 1999 07:09:55 -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 HAA05379 for ; Sun, 6 Jun 1999 07:09:54 -0700 (PDT) Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12321 for ; Sun, 6 Jun 1999 07:09:53 -0700 (PDT) Received: from hermes.research.att.com (hermes.research.att.com [135.207.16.38]) by mail-green.research.att.com (Postfix) with ESMTP id BA3B01E00F; Sun, 6 Jun 1999 10:09:51 -0400 (EDT) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by hermes.research.att.com (8.8.7/8.8.7) with ESMTP id KAA10978; Sun, 6 Jun 1999 10:09:48 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id 9940041F16; Sun, 6 Jun 1999 10:09:50 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id 8A41C400B4; Sun, 6 Jun 1999 10:09:45 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: (IPng 7527) Re: Last Call: IPv6 Jumbograms to Proposed Standa rd Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 06 Jun 1999 10:09:45 -0400 From: "Steven M. Bellovin" Message-Id: <19990606140950.9940041F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <19501.928657521@munnari.OZ.AU>, Robert Elz writes: > Date: Fri, 04 Jun 1999 22:58:27 -0400 > From: "Steven M. Bellovin" > Message-ID: <19990605025833.81B1941F16@SIGABA.research.att.com> > > | Routes can have security significance in only three ways. > > Your list might be accurate for direct security significance, but I > don't think that's the end of the story. Eg: one possible for future > use of routing headers is related to charging. The routes that packets > use might have all kinds of implications to charging, from a service > provider charging at different rates based upon the path that was used > (charging more to clients who request an expensive high bandwidth path > perhaps). Clearly this can't work unless the route can be authenticated > (at least that it represents what the originator wanted to be there). Fair enough, but... First, of course, routers still can't verify the authenticity of the packets. End systems can, however. But -- in a world where one has to use cryptography to defend against threats, one can't (or at any rate, shouldn't) charge on the basis of unauthenticated data. Thus, charging has to be based on the certificate id, not the source IP address as represented in the packets. Without AH, an attacker can, in principle, intercept packets in flight, modify them to have a phony source route, and reinject them into the net. And the sole purpose of doing so it to run up your enemy's bill. Such attacks are certainly possible; they're also rather hard to do. And it's strictly easier to simply delete packets, which tends to annoy people more. (One can't copy packets, and reinject them later; IPsec includes a sequence number that prevents replays.) There's also the question of billing disputes -- can a server use cryptography to show that the client did send the packets, and that they didn't invent the packets and hence the charges. That's called non-repudiation, and it can only be achieved with public key cryptography, which we can't afford on every packet. I should mention one thing -- it's not that I disagree with the goals of AH; rather, I don't think they're achievable, and I think that the cost of AH is quite high. It's difficult to implement, because it involves a layered module looking ahead at lower-layer headers. Furthermore, the rules on how to determine what fields in what headers are mutable, and how to handle them, are quite complex. The only comparable thing I can think of is the suggestion in RFC 791 that TCP should set the IP id field, so that a retransmitted packet will, when fragmented in the same fashion, be usable to fill in holes in the receipt of the original packet. But even that is much simpler than this. I think that part of the confusion today stems from early mutual misunderstanding of the security goals for IPv6. In the IPng directorate, we all agreed that because of renumbering and routing headers, cryptographic authentication should be mandatory. To me, as a security person who had written in 1989 on the dangers of source routing because of how easy it made address-spoofing, it meant that we could again use source routing because no one would do address-based authentication any more. To others, it meant that the routing headers would be protected, and that we could therefore continue to use addresses-based mechanisms. I don't recall any explicit discussion of this distinction. And it's possible that we wouldn't have understood the problems as clearly then as we do today. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 6 11:10:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA22436 for ipng-dist; Sun, 6 Jun 1999 11:07:23 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22429 for ; Sun, 6 Jun 1999 11:07:13 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA13727; Sun, 6 Jun 1999 11:07:10 -0700 (PDT) Date: Sun, 6 Jun 1999 11:05:14 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: (IPng 7503) Re: Last Call: IPv6 Jumbograms to Proposed Standard To: Scott Bradner Cc: Erik.Nordmark@eng.sun.com, cmetz@inner.net, deering@cisco.com, ipng@sunroof.eng.sun.com, smb@research.att.com In-Reply-To: "Your message with ID" <199906061223.IAA04448@newdev.harvard.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > but the actual source will still have to shrink the MTU and the > encapsulator has to return a packet too big to the actual source > (or next level in encapsulator) with the correct - corected for > encapsulation - mtu Yes, and it does this because it is receiving an ICMP packet to big from the encapsulator specifying what packet the source should use. Thus it is up to the encapsulator to ensure that the tunnel behaves like a pt-pt link with a limited MTU. This is done by taking the ICMP "packet too big" messages arriving from routers inside the tunnel and using those to determine the tunnel MTU. Then the tunnel MTU will be reflected in the ICMP packet too big that the encapsulator sends to source of the packets. The mechanism is decribed in section 8.1 in rfc 2473. > I seem to be missing something because that seems like the same > thing that header inserters have to do An example might help. 1. The sender A sends packets that are 1400 bytes large. 2. The node B in the network inserts an additional 200 bytes of IPv6 extension headers. 3. This causes a router (C) where the mtu is only 1500 bytes to send back an ICMP packet to big to ***A*** saying 'max mtu is 1500 bytes'. 4. A receives this and records the path mtu as 1500 bytes. 5. A continues to send the 1400 byte packets since they are smaller than the path mtu. Since the header inserter (B) doesn't receive the ICMP packet too big it can't modify its content. In contrast with tunneling you get: 1. The sender A sends packets that are 1400 bytes large. 2. The node B in the network adds a outer IPv6 header with additional 200 bytes of IPv6 extension headers for a total of 240 bytes. The source address of the outer header is B. 3. This causes a router (C) where the mtu is only 1500 bytes to send back an ICMP packet to big to ***B*** saying 'max mtu is 1500 bytes'. (NEW) 4. B receives this and records the tunnel path mtu as 1500 bytes. I knows it added 240 bytes thus it sends an ICMP packet too big back to A with the mtu being 1500-240. 5. A receives this and records the path mtu as 1260 bytes. 6. A limits the size of packets to 1260 bytes. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 7 02:32:01 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA22740 for ipng-dist; Mon, 7 Jun 1999 02:29:03 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA22733 for ; Mon, 7 Jun 1999 02:28:54 -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 CAA27046 for ; Mon, 7 Jun 1999 02:28:52 -0700 (PDT) Received: from ygmail.kt.co.kr (ygmail_kt.kotel.co.kr [147.6.3.33]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA12820 for ; Mon, 7 Jun 1999 03:28:49 -0600 (MDT) Received: from kt.co.kr ([147.6.65.78]) by ygmail.kt.co.kr (8.8.8/8.8.8) with ESMTP id SAA26248; Mon, 7 Jun 1999 18:31:31 +0900 (KST) Message-ID: <375B9123.C8A43E66@kt.co.kr> Date: Mon, 07 Jun 1999 18:30:11 +0900 From: ksb Reply-To: ksbn@kt.co.kr Organization: kt X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: 6Bone(WIDE) <6bone-jp@wide.ad.jp>, IETF ipng , =?EUC-KR?B?sbnBpg==?= 6Bone <6bone@isi.edu> Subject: v6 application Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear members: I'm looking for some applications, services, web server addresses and so on for IPv6. I have a FreeBSD router(with KAME code) and a Solaris 7 host(with SUN's IPv6 prototype). WIll you send me some information? Thank you. -- Kim, Sahng-Beom / Korea Telecom TEL : +82-42-870-8322 FAX : +82-42-870-8329 E-mail : ksbn@kt.co.kr -- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 7 07:22:37 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA23024 for ipng-dist; Mon, 7 Jun 1999 07:18:48 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23017 for ; Mon, 7 Jun 1999 07:18:14 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id HAA01159 for ; Mon, 7 Jun 1999 07:18:13 -0700 (PDT) Received: from monza.broadswitch.se ([195.178.164.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA24013 for ; Mon, 7 Jun 1999 08:18:10 -0600 (MDT) Received: by MONZA with Internet Mail Service (5.5.2448.0) id ; Mon, 7 Jun 1999 16:16:41 +0200 Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD08DAB0@MONZA> From: Thomas Eklund To: "'ipng@sunroof.eng.sun.com'" Subject: rfc 1888 status? Date: Mon, 7 Jun 1999 16:16:39 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk What is the latest status of RFC 1888? Is it obsolete, or? Is there any attention to adapt it to the new address architechure? Or have I missed it? /Thomas Eklund, SwitchCore -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 7 07:53:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA23085 for ipng-dist; Mon, 7 Jun 1999 07:50:55 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23078 for ; Mon, 7 Jun 1999 07:50:44 -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 HAA04095 for ; Mon, 7 Jun 1999 07:50:40 -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 HAA23841 for ; Mon, 7 Jun 1999 07:50:38 -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 XAA29942; Mon, 7 Jun 1999 23:50:02 +0900 (JST) To: ksbn@kt.co.kr cc: 6Bone (WIDE) <6bone-jp@wide.ad.jp>, IETF ipng , =?EUC-KR?B?sbnBpg==?= 6Bone <6bone@ISI.EDU> In-reply-to: ksbn's message of Mon, 07 Jun 1999 18:30:11 JST. <375B9123.C8A43E66@kt.co.kr> 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: v6 application From: itojun@iijlab.net Date: Mon, 07 Jun 1999 23:50:02 +0900 Message-ID: <29940.928767002@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I'm looking for some applications, services, web server >addresses and so on for IPv6. >I have a FreeBSD router(with KAME code) and a Solaris 7 >host(with SUN's IPv6 prototype). do you need some IPv6-ready web servers to try with? www.kame.net and ftp.kame.net are IPv4/v6 ready. There are more IPv6-capable web servers listed on www.ipv6.org. If you are asking about server program (such as apache) that is capable of handling IPv6 conneciton, they are also listed on www.ipv6.org. 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 Jun 7 07:58:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA23110 for ipng-dist; Mon, 7 Jun 1999 07:57:00 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23103 for ; Mon, 7 Jun 1999 07:56:51 -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 HAA15884 for ; Mon, 7 Jun 1999 07:56:51 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26034 for ; Mon, 7 Jun 1999 07:56:50 -0700 (PDT) Received: from new (Ihinden-3.iprg.nokia.com [205.226.22.76]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id HAA04306; Mon, 7 Jun 1999 07:56:47 -0700 (PDT) Message-Id: <3.0.5.32.19990607075626.0347ec10@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 07 Jun 1999 07:56:26 -0700 To: Thomas Eklund From: Bob Hinden Subject: Re: rfc 1888 status? Cc: ipng@sunroof.eng.sun.com In-Reply-To: <45AFD48D077ED211BB4700A0C9DCE8FD08DAB0@MONZA> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, At 04:16 PM 6/7/99 +0200, Thomas Eklund wrote: >What is the latest status of RFC 1888? Is it obsolete, or? Is there any >attention to adapt it to the new address architechure? Or have I missed it? RFC1888 status is Experimental. I am not aware of any current work in this area. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 7 08:02:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA23136 for ipng-dist; Mon, 7 Jun 1999 08:00:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23126 for ; Mon, 7 Jun 1999 08:00:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA05151 for ; Mon, 7 Jun 1999 08:00:32 -0700 (PDT) Received: from om2.gto.net.om (om2.gto.net.om [206.49.101.42]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id JAA10671 for ; Mon, 7 Jun 1999 09:00:31 -0600 (MDT) Received: from peterdd.gto.net.om([209.58.12.88]) (1617 bytes) by om2.gto.net.om via sendmail with P:esmtp/R:inet_hosts/T:smtp (sender: ) id for ; Mon, 7 Jun 1999 18:58:27 +0400 (OMAN) (Smail-3.2.0.102 1998-Aug-2 #21 built 1998-Aug-20) Message-ID: <375BDE2E.B566CF92@gto.net.om> Date: Mon, 07 Jun 1999 18:58:54 +0400 From: Peter Dawson X-Mailer: Mozilla 4.0 [en] (Win95; I) MIME-Version: 1.0 To: Erik Nordmark CC: Scott Bradner , cmetz@inner.net, deering@cisco.com, ipng@sunroof.eng.sun.com, smb@research.att.com Subject: Re: (IPng 7503) Re: Last Call: IPv6 Jumbograms to Proposed Standard X-Priority: 3 (Normal) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik and all, Erik Nordmark wrote: > Since the header inserter (B) doesn't receive the ICMP packet > too big > it can't modify its content. > > In contrast with tunneling you get: > 1. The sender A sends packets that are 1400 bytes large. > ...... > 5. A receives this and records the path mtu as 1260 bytes. > 6. A limits the size of packets to 1260 bytes. > Sorry for this dumb question. but do I understand that , 1) the packetization layers instance gets notified of the decreased PMTU. 2) and A retranismitts the packet to Destination (say D) *Now * 3) D responds with a new MSS which is > PMTU. Question(s) 1) Does A continue sending packets at the size of cached PMTU or at new MSS ? 2) Frenqency that A will take to check increase of PMTU ? /pete -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 7 09:51:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA23325 for ipng-dist; Mon, 7 Jun 1999 09:40:09 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23318 for ; Mon, 7 Jun 1999 09:40:05 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA19561 for ipng@sunroof.eng.sun.com; Mon, 7 Jun 1999 09:38:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22812 for ; Mon, 7 Jun 1999 04:34:22 -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 EAA00892 for ; Mon, 7 Jun 1999 04:34:21 -0700 (PDT) Received: from farley.cisco.com (farley.cisco.com [171.71.17.21]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA03024 for ; Mon, 7 Jun 1999 04:34:21 -0700 (PDT) Received: from kiwi.cisco.com (kiwi.cisco.com [171.71.17.73]) by farley.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id EAA21614 for ; Mon, 7 Jun 1999 04:34:20 -0700 (PDT) Received: from fred-pc (rtp-dial-1-8.cisco.com [161.44.116.8]) by kiwi.cisco.com (8.8.5-Cisco.1/CISCO.WS.1.2) with SMTP id EAA25489 for ; Mon, 7 Jun 1999 04:34:40 -0700 (PDT) Message-Id: <4.1.19990607073348.01507a00@flipper.cisco.com> X-Sender: fred@flipper.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 07 Jun 1999 07:34:01 -0400 To: ipng@sunroof.eng.sun.com From: "h.a.aalderink" (by way of Fred Baker ) Subject: Question RFC 2460 IPv6 Next Header values Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am studying the RFC 2460 IPng as a part of my master thesis. I understand the Hop-by-hop options Next header value and the destination options Next Header value are the same (zero). Is this right? If so, it would not be possible to have destination options without using other extension headers. Since it would be the first extension header and therefore processed as hop-by-hop options. Is this how it is meant to be? _______________________________________________________________________________ Henri -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 7 14:45:58 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA23844 for ipng-dist; Mon, 7 Jun 1999 14:39:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23837 for ; Mon, 7 Jun 1999 14:39:28 -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 OAA09064 for ; Mon, 7 Jun 1999 14:39:27 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA08625 for ; Mon, 7 Jun 1999 14:39:27 -0700 (PDT) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Mon, 7 Jun 1999 14:39:18 -0700 Message-ID: <4FD6422BE942D111908D00805F3158DF1547EB56@RED-MSG-52> From: Brian Zill To: "'h.a.aalderink'" , ipng@sunroof.eng.sun.com Subject: RE: Question RFC 2460 IPv6 Next Header values Date: Mon, 7 Jun 1999 14:39:11 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Henri Aalderlink writes: > I am studying the RFC 2460 IPng as a part of my master thesis. > > I understand the Hop-by-hop options Next header value and the > destination options Next Header value are the same (zero). > Is this right? No, the preceeding header will have a Next Header value of 60 (decimal) to indicate that it is followed by a destination options header. It is only for hop-by-hop options that the preceeding header will have a Next Header value of 0. See the first paragraph of Section 4.6 in RFC 2460. Hope this eliminates the confusion. --Brian > If so, it would not be possible to have destination options without > using other extension headers. Since it would be the first extension > header and therefore processed as hop-by-hop options. > > Is this how it is meant to be? > > ______________________________________________________________ > _________________ > Henri -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 8 13:27:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA25059 for ipng-dist; Tue, 8 Jun 1999 13:21:24 -0700 (PDT) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25052 for ; Tue, 8 Jun 1999 13:21:11 -0700 (PDT) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id NAA20798 for ipng@sunroof.eng.sun.com; Tue, 8 Jun 1999 13:19:50 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24281 for ; Mon, 7 Jun 1999 22:47:07 -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 WAA02823 for ; Mon, 7 Jun 1999 22:47:07 -0700 (PDT) Received: from ban-server.banyan.tenet.res.in ([203.197.129.150]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA15694 for ; Mon, 7 Jun 1999 22:47:00 -0700 (PDT) Received: from localhost (murali@localhost) by ban-server.banyan.tenet.res.in (8.8.7/8.8.3) with SMTP id LAA26822; Tue, 8 Jun 1999 11:05:45 +0530 Date: Tue, 8 Jun 1999 11:05:45 +0530 (IST) From: Murali Krishna To: "h.a.aalderink" cc: ipng@sunroof.eng.sun.com Subject: Re: Question RFC 2460 IPv6 Next Header values In-Reply-To: <4.1.19990607073348.01507a00@flipper.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thats wrong. Hop-by-hop option header is identified by value 0 in the preceding header's next header field. similarly for destination options it is 60. murali. On Mon, 7 Jun 1999, h.a.aalderink wrote: > I am studying the RFC 2460 IPng as a part of my master thesis. > > I understand the Hop-by-hop options Next header value and the > destination options Next Header value are the same (zero). Is this > right? > If so, it would not be possible to have destination options without > using other extension headers. Since it would be the first extension > header and therefore processed as hop-by-hop options. > > Is this how it is meant to be? > > _______________________________________________________________________________ > Henri > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Jun 8 23:26:36 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA25548 for ipng-dist; Tue, 8 Jun 1999 23:16:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA25541 for ; Tue, 8 Jun 1999 23:16:02 -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 XAA15018 for ; Tue, 8 Jun 1999 23:16:02 -0700 (PDT) Received: from lycoris.hoshino.tahi.org (oxalis.nezu.wide.ad.jp [203.178.142.208]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA27434 for ; Wed, 9 Jun 1999 00:15:18 -0600 (MDT) Received: from localhost (localhost.tahi.org [127.0.0.1]) by lycoris.hoshino.tahi.org (8.8.8/8.8.8) with ESMTP id PAA18495 for ; Wed, 9 Jun 1999 15:15:08 +0900 (JST) (envelope-from hoshino@tahi.org) To: ipng@sunroof.eng.sun.com Subject: TAHI IPv6 Conformance Test Packages and reports From: Hiroshi_Hoshino@yokogawa.co.jp Reply-To: contact@tahi.org X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990609151508D.hoshino@tahi.org> Date: Wed, 09 Jun 1999 15:15:08 +0900 X-Dispatcher: imput version 980905(IM100) Lines: 34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi there, TAHI Project has opened the IPv6 Conformance Test Packages and test reports about KAME IPv6 network code (http://www.kame.net/) at the following web site: http://www.tahi.org/report/ Changes from the previous release of the IPv6 Conformance Test Packages: The Test Tool (Release-0.2): - The Test Tool automatically records packets during test with tcpdump. - The Test Tool supports the definition of Tunnel Encapsulation Limit Option in a Destination Options extension header. - The Test Tool supports the definition of Redirected Header Option in a ICMP Redirect. The Test Program (Release-0.2): - ND: RS/RA tests for hosts - Stateless Address Autoconf: Address Lifetime tests, almost done - Path MTU Discovery: almost done The following test reports done with the Release-0.2 Test Package were opened: - kame-freebsd228-snap-19990531 - kame-freebsd32-snap-19990607 ---- TAHI Project is ... the joint effort to provide verification technology for IPv6, working with KAME project and WIDE project. http://www.tahi.org/ ----hoshino, TAHI Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 04:33:38 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA25798 for ipng-dist; Wed, 9 Jun 1999 04:30:08 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA25791 for ; Wed, 9 Jun 1999 04:29:58 -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 EAA23589 for ; Wed, 9 Jun 1999 04:29:57 -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 EAA05293 for ; Wed, 9 Jun 1999 04:29:57 -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 HAA23303; Wed, 9 Jun 1999 07:29:54 -0400 (EDT) Message-Id: <199906091129.HAA23303@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-mld-02.txt Date: Wed, 09 Jun 1999 07:29:53 -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 : Multicast Listener Discovery (MLD) for IPv6 Author(s) : S. Deering, B. Fenner, B. Haberman Filename : draft-ietf-ipngwg-mld-02.txt Pages : 23 Date : 08-Jun-99 This document specifies the protocol used by an IPv6 router to discover the presence of multicast listeners (that is, nodes wishing to receive multicast packets) on its directly attached links, and to discover specifically which multicast addresses are of interest to those neighboring nodes. This protocol is referred to as Multicast Listener Discovery or MLD. MLD is derived from version 2 of IPv4's Internet Group Management Protocol, IGMPv2. One important difference to note is that MLD uses ICMPv6 (IP Protocol 58) message types, rather than IGMP (IP Protocol 2) message types. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-02.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-mld-02.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-mld-02.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: <19990608100612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-mld-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-mld-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990608100612.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 9 06:22:46 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA25914 for ipng-dist; Wed, 9 Jun 1999 06:16:29 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25907; Wed, 9 Jun 1999 06:16:20 -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 GAA21404; Wed, 9 Jun 1999 06:16:20 -0700 (PDT) Received: from jazz.viagenie.qc.ca (jazz.viagenie.qc.ca [206.123.31.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05222; Wed, 9 Jun 1999 07:16:17 -0600 (MDT) Received: from classic (modemcable022.138-200-24.que.mc.videotron.net [24.200.138.22]) by jazz.viagenie.qc.ca (Viagenie/8.8.8) with SMTP id JAA23451; Wed, 9 Jun 1999 09:07:38 -0400 (EDT) Prefer-Language: fr, en Message-Id: <4.1.19990609083647.00d47770@mail.viagenie.qc.ca> X-Sender: blanchet@mail.viagenie.qc.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 09 Jun 1999 09:10:24 -0400 To: Randy Bush , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com From: Marc Blanchet Subject: Re: (ngtrans) what pieces are actually missing In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy, This is a good short list and a good food of thoughts. I would like to make a small comment about application support, where the iesg is saying "essentially non-existent". Well, it is true that in the MS world, it is "essentially non-existent", but if you look at the ports done by the Kame people, it has everything you need and more! you can run a complete IPv6 unix workstation or server with about everything you need: web, mail, telnet, ssh, multicast tool, even a MP3 player and server! here is an abstract of a recent kame ports directory: Makefile ethereal inn mrt python squid11 v6tun XFree86 fetchmail kaffe ncftp3 qmail ssh vat6 altq fwtk6 libident6 newbie rev_v6_address tcp_wrapper vnc apache12 gated-ipv6 lynx perl5 rsync tcpd6 wbd apache13 geta mediator pident6d ruby tcptrace wget bind8 heimdal mozilla popper sendmail6 ucd-snmp wu-ftpd ct icecast mpg123 ppp socks64 v6eval zebra so I would propose to change the iesg statement to: "application support: very good on some platforms, essentially non-existent on others". Regards, Marc. At 23:43 99-06-08 -0700, Randy Bush wrote: >in an iesg discussion, we started to wonder what pieces were missing if one >wanted to do widescale ipv6 deployment. we came up with some guesses which >are appended. > >we also thought about what would happen if we merely wanted to make an ietf >terminal room ipv6-only. > >wg comments on both would be appreciated. > >randy > > >IPv6 - what it does, and what does moving forward without deployment mean >- IPv6 is at draft >- IPv6 addressing is at Proposed >- Sequence of what we need > 1 DNS AAAA - Proposed > A6 - I-D > 2 IP > - IPV6 - Draft > (TCP, UDP) > - ICMP - Draft > - Neighour Discovery - Draft > - Path MTU - Draft > - Stateless Addr Autocfg - Draft > 3 IP over foo - Proposed > 4 MIBs - Proposed > 5 Routing > - BGP extensions - Proposed (but run on IPv4) > - RIPng - Proposed > - OSPF extensions - I-D > - IBGP - > - ISIS - ?? > 6 IPsec - Proposed > Kerberos no (carries addresses) > 7 SNMP mostly > 8 Applications > FTP - Proposed > domain/address Literals - ??? > Fax > 9 DHCPv6 ?? > 10 Multicast ?? (PIM spec I-D??) > >- Implementation status > - Host - IP stack support > available for some 30 platforms (not many as product) > - Router - CPE equipment avilable off-the-shelf > (obsolete equipment/code, code is not off-the-shelf) > no 7500-class router available > viable to route IPv6 using MPLS? > - Application support > essentially not existent > - RDNS support (Bind 8.2 - AAAA - over v4 only) > - SNMP support (none) > - Ping and Traceroute exist > ----------------------------------------------------------- Marc Blanchet | Marc.Blanchet@viagenie.qc.ca Viagénie inc. | http://www.viagenie.qc.ca 3107 des hôtels | tél.: 418-656-9254 Ste-Foy, Québec | fax.: 418-656-0183 Canada, G1W 4W5 | radio: VA2-JAZ ------------------------------------------------------------ Internet Engineering Standards/Normes d'ingénierie Internet http://www.normos.org ------------------------------------------------------------ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 06:46:24 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA25967 for ipng-dist; Wed, 9 Jun 1999 06:36:55 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA25960; Wed, 9 Jun 1999 06:36:46 -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 GAA23180; Wed, 9 Jun 1999 06:36:46 -0700 (PDT) Received: from papai (as400nt.cefetba.br [200.254.245.15] (may be forged)) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA05267; Wed, 9 Jun 1999 06:36:42 -0700 (PDT) Received: from habilidoso (genio.cefetba.br [200.254.245.65] (may be forged)) by papai (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with ESMTP id KAA00032; Wed, 09 Jun 1999 10:23:46 GMT Message-Id: <199906091023.KAA00032@papai> From: "Allan Edgard Silva Freitas" To: "Randy Bush" , , Subject: Re: (ngtrans) what pieces are actually missing Date: Wed, 9 Jun 1999 10:32:55 -0300 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk and what about Linux IPv6 stack support? I've seen that there are a lot of application for UNIX BSD enviroments, but few applications that works with IPv6 native format... I known only ports made by Craig Mertz and a few others... ---------- > De: Marc Blanchet > Para: Randy Bush ; ngtrans@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > Assunto: Re: (ngtrans) what pieces are actually missing > Data: Wednesday, June 09, 1999 10:10 AM > > Randy, > This is a good short list and a good food of thoughts. > > I would like to make a small comment about application support, where the > iesg is saying "essentially non-existent". Well, it is true that in the MS > world, it is "essentially non-existent", but if you look at the ports done > by the Kame people, it has everything you need and more! you can run a > complete IPv6 unix workstation or server with about everything you need: > web, mail, telnet, ssh, multicast tool, even a MP3 player and server! > here is an abstract of a recent kame ports directory: > > Makefile ethereal inn mrt python > squid11 v6tun > XFree86 fetchmail kaffe ncftp3 qmail > ssh vat6 > altq fwtk6 libident6 newbie > rev_v6_address tcp_wrapper vnc > apache12 gated-ipv6 lynx perl5 rsync > tcpd6 wbd > apache13 geta mediator pident6d ruby > tcptrace wget > bind8 heimdal mozilla popper sendmail6 > ucd-snmp wu-ftpd > ct icecast mpg123 ppp socks64 > v6eval zebra > > so I would propose to change the iesg statement to: "application support: > very good on some platforms, essentially non-existent on others". > > Regards, Marc. > > > At 23:43 99-06-08 -0700, Randy Bush wrote: > >in an iesg discussion, we started to wonder what pieces were missing if one > >wanted to do widescale ipv6 deployment. we came up with some guesses which > >are appended. > > > >we also thought about what would happen if we merely wanted to make an ietf > >terminal room ipv6-only. > > > >wg comments on both would be appreciated. > > > >randy > > > > > >IPv6 - what it does, and what does moving forward without deployment mean > >- IPv6 is at draft > >- IPv6 addressing is at Proposed > >- Sequence of what we need > > 1 DNS AAAA - Proposed > > A6 - I-D > > 2 IP > > - IPV6 - Draft > > (TCP, UDP) > > - ICMP - Draft > > - Neighour Discovery - Draft > > - Path MTU - Draft > > - Stateless Addr Autocfg - Draft > > 3 IP over foo - Proposed > > 4 MIBs - Proposed > > 5 Routing > > - BGP extensions - Proposed (but run on IPv4) > > - RIPng - Proposed > > - OSPF extensions - I-D > > - IBGP - > > - ISIS - ?? > > 6 IPsec - Proposed > > Kerberos no (carries addresses) > > 7 SNMP mostly > > 8 Applications > > FTP - Proposed > > domain/address Literals - ??? > > Fax > > 9 DHCPv6 ?? > > 10 Multicast ?? (PIM spec I-D??) > > > >- Implementation status > > - Host - IP stack support > > available for some 30 platforms (not many as product) > > - Router - CPE equipment avilable off-the-shelf > > (obsolete equipment/code, code is not off-the-shelf) > > no 7500-class router available > > viable to route IPv6 using MPLS? > > - Application support > > essentially not existent > > - RDNS support (Bind 8.2 - AAAA - over v4 only) > > - SNMP support (none) > > - Ping and Traceroute exist > > > > > ----------------------------------------------------------- > Marc Blanchet | Marc.Blanchet@viagenie.qc.ca > Viagénie inc. | http://www.viagenie.qc.ca > 3107 des hôtels | tél.: 418-656-9254 > Ste-Foy, Québec | fax.: 418-656-0183 > Canada, G1W 4W5 | radio: VA2-JAZ > ------------------------------------------------------------ > Internet Engineering Standards/Normes d'ingénierie Internet > http://www.normos.org > ------------------------------------------------------------ > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 9 07:58:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA26090 for ipng-dist; Wed, 9 Jun 1999 07:52:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26083; Wed, 9 Jun 1999 07:52:03 -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 HAA01934; Wed, 9 Jun 1999 07:51:56 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04890; Wed, 9 Jun 1999 08:51:46 -0600 (MDT) Received: from cauchy.cs.uni-bonn.de (cauchy [131.220.4.169]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id QAA03335; Wed, 9 Jun 1999 16:50:40 +0200 (MET DST) Received: (from ignatios@localhost) by cauchy.cs.uni-bonn.de (8.8.8/8.8.8) id QAA26040; Wed, 9 Jun 1999 16:50:29 +0200 (MET DST) Message-ID: <19990609165028.D25501@cs.uni-bonn.de> Date: Wed, 9 Jun 1999 16:50:28 +0200 From: Ignatios Souvatzis To: Allan Edgard Silva Freitas , Randy Bush , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) what pieces are actually missing References: <199906091023.KAA00032@papai> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.2i In-Reply-To: <199906091023.KAA00032@papai>; from Allan Edgard Silva Freitas on Wed, Jun 09, 1999 at 10:32:55AM -0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, Jun 09, 1999 at 10:32:55AM -0300, Allan Edgard Silva Freitas wrote: > and what about Linux IPv6 stack support? I've seen that there are a lot of > application for UNIX BSD enviroments, but few applications that works with > IPv6 native format... I known only ports made by Craig Mertz and a few > others... What's non-native about BSD environments? -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 9 08:42:31 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA26155 for ipng-dist; Wed, 9 Jun 1999 08:35:50 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26148; Wed, 9 Jun 1999 08:35:41 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA04500; Wed, 9 Jun 1999 08:35:40 -0700 (PDT) Received: from papai (as400nt.cefetba.br [200.254.245.15] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21869; Wed, 9 Jun 1999 09:35:33 -0600 (MDT) Received: from habilidoso (genio.cefetba.br [200.254.245.65] (may be forged)) by papai (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with ESMTP id MAA00044; Wed, 09 Jun 1999 12:21:53 GMT Message-Id: <199906091221.MAA00044@papai> From: "Allan Edgard Silva Freitas" To: "Ignatios Souvatzis" , "Randy Bush" , , Subject: Re: (ngtrans) what pieces are actually missing Date: Wed, 9 Jun 1999 12:31:02 -0300 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1161 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk sorry I missed a word... I 'd like to say IPv6 native format in Linux, nothing about BSD enviroments ---------- > De: Ignatios Souvatzis > Para: Allan Edgard Silva Freitas ; Randy Bush ; ngtrans@sunroof.eng.sun.com; ipng@sunroof.eng.sun.com > Assunto: Re: (ngtrans) what pieces are actually missing > Data: Wednesday, June 09, 1999 11:50 AM > > On Wed, Jun 09, 1999 at 10:32:55AM -0300, Allan Edgard Silva Freitas wrote: > > and what about Linux IPv6 stack support? I've seen that there are a lot of > > application for UNIX BSD enviroments, but few applications that works with > > IPv6 native format... I known only ports made by Craig Mertz and a few > > others... > > What's non-native about BSD environments? > -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 9 09:07:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA26237 for ipng-dist; Wed, 9 Jun 1999 09:02:16 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26230; Wed, 9 Jun 1999 09:02:01 -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 JAA02196; Wed, 9 Jun 1999 09:02:00 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA03156; Wed, 9 Jun 1999 10:02:00 -0600 (MDT) Received: from localhost (738 bytes) by rip.psg.com via sendmail with P:stdio/R:inet_resolve/T:smtp (sender: ) (ident using unix) id for ; Wed, 9 Jun 1999 09:02:00 -0700 (PDT) (Smail-3.2.0.101 1997-Dec-17 #1 built 1999-Apr-1) Message-Id: Date: Wed, 9 Jun 1999 09:02:00 -0700 (PDT) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Marc Blanchet Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) what pieces are actually missing References: <4.1.19990609083647.00d47770@mail.viagenie.qc.ca> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > if you look at the ports done by the Kame people, it has everything you > need and more! you can run a complete IPv6 unix workstation or server with > about everything you need: web, mail, telnet, ssh, multicast tool, even a > MP3 player and server! excellent! thanks marc. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 09:27:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA26337 for ipng-dist; Wed, 9 Jun 1999 09:20:13 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26329 for ; Wed, 9 Jun 1999 09:19:54 -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 JAA15309 for ; Wed, 9 Jun 1999 09:19:42 -0700 (PDT) Received: from mail-gw.hursley.ibm.com (mail-gw.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA10838 for ; Wed, 9 Jun 1999 10:19:40 -0600 (MDT) Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id RAA73418; Wed, 9 Jun 1999 17:19:38 +0100 Received: from hursley.ibm.com (lig32-239-198-203.emea.lig-dial.ibm.com [32.239.198.203]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id RAA32136; Wed, 9 Jun 1999 17:19:19 +0100 (BST) Message-ID: <375E24A1.232A2B67@hursley.ibm.com> Date: Wed, 09 Jun 1999 03:24:01 -0500 From: Brian E Carpenter Organization: IBM Internet Division X-Mailer: Mozilla 4.04 [en] (Win95; I) MIME-Version: 1.0 To: Bob Hinden CC: Thomas Eklund , ipng@sunroof.eng.sun.com Subject: Re: rfc 1888 status? References: <3.0.5.32.19990607075626.0347ec10@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am not aware of any implementations or any serious interest. Brian Bob Hinden wrote: > > Thomas, > > At 04:16 PM 6/7/99 +0200, Thomas Eklund wrote: > >What is the latest status of RFC 1888? Is it obsolete, or? Is there any > >attention to adapt it to the new address architechure? Or have I missed it? > > RFC1888 status is Experimental. I am not aware of any current work in this > area. > > Bob > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM Internet Div As of May 24, 1999: on assignment for IBM at http://www.iCAIR.org Non-IBM email: brian@icair.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 14:28:40 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA26865 for ipng-dist; Wed, 9 Jun 1999 14:11:26 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26858 for ; Wed, 9 Jun 1999 14:11:12 -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 OAA19979 for ; Wed, 9 Jun 1999 14:11:09 -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 PAA09165 for ; Wed, 9 Jun 1999 15:11:07 -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 RAA03589; Wed, 9 Jun 1999 17:11:01 -0400 (EDT) Message-Id: <199906092111.RAA03589@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: Multicast Listener Discovery (MLD) for IPv6 to Proposed Standard Reply-to: iesg@ietf.org Date: Wed, 09 Jun 1999 17:11:01 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider Multicast Listener Discovery (MLD) 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 23, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-mld-02.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 9 19:25:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA27362 for ipng-dist; Wed, 9 Jun 1999 19:19:41 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA27355 for ; Wed, 9 Jun 1999 19:19:28 -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 TAA11343 for ; Wed, 9 Jun 1999 19:18:50 -0700 (PDT) Received: from ms.info.sh.cn. ([203.95.7.153]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA08124 for ; Wed, 9 Jun 1999 20:18:45 -0600 (MDT) Received: from [172.16.50.168] by ms.info.sh.cn. (5.65v4.0/1.1.19.2/23Apr99-0839PM) id AA01950; Thu, 10 Jun 1999 10:15:55 +0800 Message-Id: <375F2058.465F49B@info.sh.cn> Date: Thu, 10 Jun 1999 10:18:00 +0800 From: lpshen X-Mailer: Mozilla 4.06 [en] (Win98; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: security in mobile-ipv6 Content-Type: multipart/alternative; boundary="------------BA3664530C52222BF9BB04A0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------BA3664530C52222BF9BB04A0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,everybody: I am a graduate studying ipng rescently........Security services for mobile-ipv6 is my major interest.According to the I-D draft-ietf-mobileip-ipsec-use-00.txt: The ptotection of the foreign network resources can be acquired with the presence of FA,but how can we meet this security requirement of the foreign subnet when visited by mobile nodes implemented by mobile-ipv6 that there aren't Foreign Agents around? if we still retain the Foreign Agents,then we can see little advantage of the ipv6 stateless address autoconfiguration.......I wonder whether we can merge the accesss control into the DHCPv6 server?I need your enlightenment and help. Thanks in advance. lisa shen --------------BA3664530C52222BF9BB04A0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hello,everybody:
 I am a graduate studying ipng rescently........Security services for mobile-ipv6 is my major interest.According to the I-D draft-ietf-mobileip-ipsec-use-00.txt:
    The ptotection of the foreign network resources can be acquired with the presence of FA,but how can we meet this security requirement of the foreign subnet when visited by mobile nodes implemented by mobile-ipv6 that there aren't Foreign Agents around?
     if we still retain the Foreign Agents,then we can see little advantage of the ipv6 stateless address autoconfiguration.......I wonder whether we can merge the accesss control into the DHCPv6 server?I need your enlightenment and help.

Thanks in advance.

lisa shen --------------BA3664530C52222BF9BB04A0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 9 23:34:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA27466 for ipng-dist; Wed, 9 Jun 1999 23:28:01 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA27459; Wed, 9 Jun 1999 23:27:51 -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 XAA06109; Wed, 9 Jun 1999 23:27:52 -0700 (PDT) Received: from Yellow.japan-telecom.co.jp (Yellow.japan-telecom.co.jp [210.146.35.35]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA16041; Wed, 9 Jun 1999 23:27:51 -0700 (PDT) Received: from Green.japan-telecom.co.jp (Green.japan-telecom.co.jp [210.146.35.36]) by Yellow.japan-telecom.co.jp (3.7W-Yellow) with ESMTP id PAA12967; Thu, 10 Jun 1999 15:32:41 +0900 (JST) Received: from japan-telecom.co.jp (localhost [127.0.0.1]) by Green.japan-telecom.co.jp (3.7W-Green) with ESMTP id PAA25874; Thu, 10 Jun 1999 15:24:06 +0900 (JST) Received: from pcnagashima ([172.18.82.164]) by japan-telecom.co.jp (3.7W-SP340201) with SMTP id PAA20792; Thu, 10 Jun 1999 15:22:38 +0900 (JST) From: "=?iso-8859-1?B?kreTh4FAlfyJcA==?=" To: , Subject: RE: (ngtrans) what pieces are actually missing Date: Thu, 10 Jun 1999 15:28:11 +0900 Message-ID: <000701beb30a$69b58060$a45212ac@pcnagashima> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <4.1.19990609083647.00d47770@mail.viagenie.qc.ca> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would like to make a small comment about application > support, where the > iesg is saying "essentially non-existent". Well, it is true that in the MS > world, it is "essentially non-existent", but if you look at the ports done > by the Kame people, it has everything you need and more! you can run a > complete IPv6 unix workstation or server with about everything you need: > web, mail, telnet, ssh, multicast tool, even a MP3 player and server! I think there are some projects in MS world.For example, Hitachi supplies Toolnet6 by which we can run IPv4 application to IPv6 . For more infomation, http://www.hitachi.co.jp/Prod/comp/network/pexv6-e.htm . Thanks. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 10 14:54:50 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA28950 for ipng-dist; Thu, 10 Jun 1999 14:50:42 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28943 for ; Thu, 10 Jun 1999 14:50:33 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA00698 for ; Thu, 10 Jun 1999 14:50:32 -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 PAA12506 for ; Thu, 10 Jun 1999 15:50:31 -0600 (MDT) Received: from 157.54.9.125 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 10 Jun 1999 14:50:03 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2524.0) id ; Thu, 10 Jun 1999 13:42:27 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515280@RED-MSG-50> From: Richard Draves To: "'IPng List'" Subject: UNH problems Date: Thu, 10 Jun 1999 11:32:49 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Reviewing our latest UNH test results, there are a couple failures reported where it looks to me like the test is wrong. I believe we've already discussed one of them. The NUT (node under test) is sending a packet via a default router, but the packet is queued while the NUT performs Neighbor Discovery to resolve the router's link-layer address. When the NUT receives the Neighbor Advertisement for the router, it discovers that the router is actually not a router any more (IsRouter is false). This causes the router to be removed from the NUT's default router list. However our implementation proceeds to send the packet that was pending ND. UNH says this is wrong. The other failure concerns section 6.3.5 in the ND spec. The NUT has a prefix in the on-link prefix list, and it has created a Destination Cache Entry based on the on-link prefix. When the on-link prefix is removed (either because its lifetime goes to zero, or because an RA is received setting its lifetime to zero), can the Destination Cache Entry immediately be purged, so subsequent packets to the destination will create a new DCE using a default router? Section 6.3.5 notes that the DCE "need not" be purged, because NUD will correct the situation if the destination address is in fact no longer on-link. However there is no MUST in section 6.3.5 to mandate this behavior. It happens to be convenient for our implementation to purge the DCE immediately but UNH says this is wrong. Any comments on these tests? Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 10 16:00:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA29095 for ipng-dist; Thu, 10 Jun 1999 15:53:48 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29088 for ; Thu, 10 Jun 1999 15:53:37 -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 PAA23700 for ; Thu, 10 Jun 1999 15:53:36 -0700 (PDT) Received: from roll.mentat.com ([192.88.122.129]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA03375 for ; Thu, 10 Jun 1999 16:53:34 -0600 (MDT) Received: from feller.mentat.com (feller [192.88.122.144]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with SMTP id PAA22213; Thu, 10 Jun 1999 15:52:34 -0700 (PDT) Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id PAA06229; Thu, 10 Jun 1999 15:53:03 -0700 Date: Thu, 10 Jun 1999 15:53:03 -0700 From: tim@mentat.com (Tim Hartrick) Message-Id: <199906102253.PAA06229@feller.mentat.com> To: richdr@microsoft.com Subject: Re: UNH problems Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From owner-ipng@sunroof.eng.sun.com Thu Jun 10 14:54:27 1999 > Received: from roll.mentat.com (roll [192.88.122.129]) > by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA28466 > for ; Thu, 10 Jun 1999 14:54:23 -0700 (PDT) > Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) > by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id OAA22037 > for ; Thu, 10 Jun 1999 14:54:21 -0700 (PDT) > Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) > by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA17013; > Thu, 10 Jun 1999 14:55:11 -0700 (PDT) > Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) > by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA01602; > Thu, 10 Jun 1999 14:55:09 -0700 (PDT) > Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA28950 > for ipng-dist; Thu, 10 Jun 1999 14:50:42 -0700 (PDT) > Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) > by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28943 > for ; Thu, 10 Jun 1999 14:50:33 -0700 (PDT) > Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) > by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id OAA00698 > for ; Thu, 10 Jun 1999 14:50:32 -0700 (PDT) Rich, > The other failure concerns section 6.3.5 in the ND spec. The NUT has a > prefix in the on-link prefix list, and it has created a Destination Cache > Entry based on the on-link prefix. When the on-link prefix is removed > (either because its lifetime goes to zero, or because an RA is received > setting its lifetime to zero), can the Destination Cache Entry immediately > be purged, so subsequent packets to the destination will create a new DCE > using a default router? Section 6.3.5 notes that the DCE "need not" be > purged, because NUD will correct the situation if the destination address is > in fact no longer on-link. However there is no MUST in section 6.3.5 to > mandate this behavior. It happens to be convenient for our implementation to > purge the DCE immediately but UNH says this is wrong. > Our implementation will do the same as yours for precisely the same reason. It is convenient to clean up everything associated with the prefix at the same time. Unless it says MUST NOT it isn't a requirement that the neighbor/ destination cache entry for the node be preserved. I am with you. I don't have a comment about the former test other than I wasn't aware that the specification required that a node remove a router from its router list if it receives a neighber advertisement with the IsRouter flag clear. I thought it only required that the neighbor cache entry for the "router" be marked to indicate that it is not a router any longer. I don't have the spec handy or I would check this point myself..... tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Jun 11 01:29:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA29603 for ipng-dist; Fri, 11 Jun 1999 01:23:49 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA29596 for ; Fri, 11 Jun 1999 01:23:40 -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 BAA25500 for ; Fri, 11 Jun 1999 01:23:40 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA01440 for ; Fri, 11 Jun 1999 01:23:39 -0700 (PDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id KAA06317; Fri, 11 Jun 1999 10:23:37 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id KAA18289; Fri, 11 Jun 1999 10:23:36 +0200 (MET DST) Message-Id: <199906110823.KAA18289@givry.inria.fr> From: Francis Dupont To: Richard Draves cc: "'IPng List'" Subject: Re: UNH problems In-reply-to: Your message of Thu, 10 Jun 1999 11:32:49 PDT. <4D0A23B3F74DD111ACCD00805F31D81014515280@RED-MSG-50> Date: Fri, 11 Jun 1999 10:23:36 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Any comments on these tests? => I believe MSR IPv6 behavior is correct even not optimal (ie. problems lay between SHOULD and MAY). I don't know if there is a Neighbor Discovery perfect implementation somewhere, especially for marginal events. Francis.Dupont@inria.fr PS: look at Richard's message for the description of the two issues. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 14 13:57:11 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA00904 for ipng-dist; Mon, 14 Jun 1999 13:53:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00897 for ; Mon, 14 Jun 1999 13:52:53 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id NAA01233 for ; Mon, 14 Jun 1999 13:52:54 -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 OAA11444 for ; Mon, 14 Jun 1999 14:52:54 -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 QAA22461; Mon, 14 Jun 1999 16:52:50 -0400 (EDT) Message-Id: <199906142052.QAA22461@ietf.org> To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: DNS Extensions to Support IP Version 6 to Proposed Standard Reply-to: iesg@ietf.org Date: Mon, 14 Jun 1999 16:52:50 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IPNG Working Group to consider DNS Extensions to Support IP Version 6 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 28, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-lookups-04.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 15 06:44:09 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA01454 for ipng-dist; Tue, 15 Jun 1999 06:38:33 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA01447 for ; Tue, 15 Jun 1999 06:38:01 -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 GAA14896 for ; Tue, 15 Jun 1999 06:37:13 -0700 (PDT) Received: from iol.unh.edu (mars.iol.unh.edu [132.177.121.222]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11802 for ; Tue, 15 Jun 1999 07:37:09 -0600 (MDT) Received: from localhost (jfl@localhost) by iol.unh.edu (8.9.3/8.9.3) with ESMTP id JAA19079; Tue, 15 Jun 1999 09:35:11 -0400 (EDT) Date: Tue, 15 Jun 1999 09:35:10 -0400 From: "John F. Leser" To: Richard Draves cc: "'IPng List'" Subject: Re: UNH problems In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D81014515280@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 10 Jun 1999, Richard Draves wrote: > Reviewing our latest UNH test results, there are a couple failures reported > where it looks to me like the test is wrong. > > I believe we've already discussed one of them. The NUT (node under test) is > sending a packet via a default router, but the packet is queued while the > NUT performs Neighbor Discovery to resolve the router's link-layer address. > When the NUT receives the Neighbor Advertisement for the router, it > discovers that the router is actually not a router any more (IsRouter is > false). This causes the router to be removed from the NUT's default router > list. However our implementation proceeds to send the packet that was > pending ND. UNH says this is wrong. > > The other failure concerns section 6.3.5 in the ND spec. The NUT has a > prefix in the on-link prefix list, and it has created a Destination Cache > Entry based on the on-link prefix. When the on-link prefix is removed > (either because its lifetime goes to zero, or because an RA is received > setting its lifetime to zero), can the Destination Cache Entry immediately > be purged, so subsequent packets to the destination will create a new DCE > using a default router? Section 6.3.5 notes that the DCE "need not" be > purged, because NUD will correct the situation if the destination address is > in fact no longer on-link. However there is no MUST in section 6.3.5 to > mandate this behavior. It happens to be convenient for our implementation to > purge the DCE immediately but UNH says this is wrong. > > Any comments on these tests? > > Thanks, > Rich These tests check for optimal behavior, above and beyond what is strictly required by the specifications. Failure does not indicate a failure to conform to the specification or to interoperate with other implementations; it does indicate that there is another, possibly better way to handle the test situation. I say possibly because there may be a cost associated with an optimization that makes it not worthwhile. We will be making changes to how we report test results to indicate the requirement level for each test, in order to eliminate this kind of confusion. ***************************************************************** John Leser InterOperability Lab IP/Routing Consortium Engineer University of New Hampshire 7 Leavitt Lane, Room 106 Tel: (603) 862-0090 Durham, NH 03824-3525 Fax: (603) 862-4181 Email: jfl@iol.unh.edu Web: http://www.iol.unh.edu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 21 11:45:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA01372 for ipng-dist; Mon, 21 Jun 1999 11:26:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01365 for ; Mon, 21 Jun 1999 11:26:00 -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 LAA07456 for ; Mon, 21 Jun 1999 11:25:58 -0700 (PDT) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27517 for ; Mon, 21 Jun 1999 12:25:57 -0600 (MDT) Received: from bogey by east.isi.edu (8.8.5/5.61+local-24) id ; Mon, 21 Jun 1999 18:25:48 GMT Message-ID: <014201bebc14$d1895a00$634cf526@east.isi.edu> From: "Aaron Griggs" To: "Markku Savela" Cc: , References: <199906211145.OAA29341@anise.tte.vtt.fi> Subject: Re: IPSEC, IPv6 and mobile IP Date: Mon, 21 Jun 1999 14:35:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > CASE A: Receiving packet from mobile (Home Address option) > ---------------------------------------------------------- > What is the correct processing of a received packet that includes home > address option and IPSEC. The packet arrives from a mobile host HA to > non-mobile (to keep example simple) host B. > > Before destination option processing (Home Address) it looks > > (1) IP(CA->B),DOP(HA),.... > > and after processing it will look > > (2) IP(HA->B),DOP(HA),... > > The simple question is: which of the following alternatives are taken > by other implementors? > > a) Process IPSEC at point (1), e.g. look for matchins SA based on > triplet and check header against IP(CA->X), > > b) Process IPSEC at point (2), e.g. look for matching SA based on > triplet and check header against IP(HA->X), > > c) Try both (a) and (b), and drop packet if neither passes > > Because I don't like "trial and error solutions", I would prefer > either (a) or (b), and to preserve at least some of the IPv6 > sequenctial processing of extension headers, one could perhaps give > the preference to (b)? [disregarding at the moment the potential > complexities in actually generating this packet in the source end...]. > The MSRIPv6 stack does (b). > > CASE B: Receiving packet on the mobile host (routing header) > ------------------------------------------------------------ > The next issue is when the mobile host HA receives a routed packet > from B (B uses routing header to direct the packet to HA): > > Before processing the routing header > > (1) IP(B->CA),RTH(HA),.... > > and after processing the Routing header (RTH) > > (2) IP(B->HA),RTH(CA),.... > > Here the situation is simple, because (2) is the only possible choice > [IPSEC specifies that routing header should be in the "final > state"]. Thus, one should look for > Number 2 in this case for the reason you state. > > PROBLEM? > -------- > Both seem to lead into solution where associations are between home > address(es). > I feel the association should be between the home address since mobility is suppose to be transparent. However when a mobile node visits another network and gets a care-of address, additional IPSec may be required. Note I say additional and not alternative. The IPSec with the home address is still done. The mobile network may have a security gateway protecting the network. I don't think you'd see IPSec done to the actual care-of address because that means the mobile node needs to reconfigure the security policies when it goes mobile. I look at it this way from the correspondent node's view point: Sending: 1. Do IPSec for traffic destined to the home address 2. Discover the care-of address 3. Do IPSec for traffic destined to the care-of address (most likely a security gateway) Receiving: 1. Do IPSec for traffic from the care-of address (security gateway) 2. Discover home address 3. Do IPSec for traffic from the home address 4. Validate IPSec Two problems exist in this example: 1. What happens if there was an SA bundle for the home network 2. Validating the IPSec on the correspondent node to account for the care-of address Both are discussed in "(IPng 7578) mobile-ipv6 and ipsec" 6/2/99, on ipngwg list. > What is the arrangement of extension headers that would allow IPSEC > associations between the care address(es) (a connection to the issues > addressed by some posts from Richard Draves, concerning a mobile host > moving into area where care address needs to use security gateways). > > Especially case B is "nasty". There is no way you can run IPSEC > "legally" at stage (1), but even with case A it would require the > "trial and error approach": to try both (1) and remove "layer of ipsec > headers", if it succeeds. > If there is additional IPSec to the actual care-of address, the problem is the security policies. IPSec can be done but should be tunnel mode to the care-of address. The headers must be processed sequentially so tunnel mode is required to do IPSec before the routing header. An earlier discussion on ipngwg list "(IPng 7193) RE: Last Call: Mobility Support in IPv6 to Proposed Standard" 2/18/99, looked at why tunnel mode is needed for routing headers. Again, I think you would see the IPSec for the care-of address to a security gateway and not the actual node. But if it is to the actual node, then the validation needs to know about the care-of address like my correspondent node example. Basically when mobility is involved, two IPSec lookups are done on the send side (first for the home address second for the care-of address) and the IPSec validation on the receive side needs to account for the care-of address. > Binding Update issues > --------------------- > Mobile wants IPSEC to protect the binding updates. As these are > destination options, it almost appears if I need to allow destionation > options as selectors, so that the IPSEC policy could be properly > specified for those too. [without making mobile IP an ugly special > cast wart on the IPSEC]. > I would just do AH or ESP for all traffic from the mobile node to the correspondent node. Yes if you just wanted the binding updates to undergo IPSec, you would need some selector to indicate this. > > There was some discussion on ipngwg mailing list recently, but > > there seem to be no consensus about it. There'll be mobile-ipv6 > > connectivity test workshop in September so we'll see... > > Hmm.. I suppose the announcement has gone at time when I was not yet > too keenly aware of my need of mobile IP integration. Where and when? > About three weeks ago: "mobile-ipv6 and ipsec" thread starting on 6/2/99 on ipngwg list. I hope this helps. Aaron -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 21 12:57:10 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA01496 for ipng-dist; Mon, 21 Jun 1999 12:32:04 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01489 for ; Mon, 21 Jun 1999 12:31:50 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA18160 for ; Mon, 21 Jun 1999 12:31:49 -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 NAA00991 for ; Mon, 21 Jun 1999 13:31:48 -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 OAA24514 for ; Mon, 21 Jun 1999 14:31:47 -0500 (CDT) Message-Id: <199906211931.OAA24514@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: ICMPv6 Node Information Queries (aka Who-Are-You) Date: Mon, 21 Jun 1999 14:31:47 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just sent in revised draft which includes the choice of inquiring about a name rather than an address. I tentatively invented a multicast address space to send such queries to, forming the address by concatenating FF02:0:0:0:0:2::/96 and the CRC-32 of the first component of the DNS name being queried about. Many other choices are possible, most notably FF02:0:0:0:0:1:FE00::/104 plus a CRC-24 or a truncated CRC-32. Discussion? 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 Mon Jun 21 13:31:31 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA01616 for ipng-dist; Mon, 21 Jun 1999 13:13:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01609 for ; Mon, 21 Jun 1999 13:13:50 -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 NAA17854 for ; Mon, 21 Jun 1999 13:13:48 -0700 (PDT) Received: from inner.net (avarice.inner.net [199.33.248.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA05961 for ; Mon, 21 Jun 1999 13:13:46 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id UAA09864; Mon, 21 Jun 1999 20:08:33 GMT Message-Id: <199906212008.UAA09864@inner.net> To: "Matt Crawford" cc: ipng@sunroof.eng.sun.com Subject: Re: ICMPv6 Node Information Queries (aka Who-Are-You) In-reply-to: Your message of "Mon, 21 Jun 1999 14:31:47 CDT." <199906211931.OAA24514@gungnir.fnal.gov> X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Mon, 21 Jun 1999 16:12:50 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199906211931.OAA24514@gungnir.fnal.gov>, you write: >I just sent in revised draft which includes the choice of inquiring >about a name rather than an address. I tentatively invented a >multicast address space to send such queries to, forming the address >by concatenating FF02:0:0:0:0:2::/96 and the CRC-32 of the first >component of the DNS name being queried about. Many other choices >are possible, most notably FF02:0:0:0:0:1:FE00::/104 plus a CRC-24 or >a truncated CRC-32. It'd be nice if you used the internet checksum or some other function that would need to already exist on the system rather than pulling in a new function. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 21 13:33:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA01662 for ipng-dist; Mon, 21 Jun 1999 13:27:27 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01655 for ; Mon, 21 Jun 1999 13:27:08 -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 NAA27900 for ; Mon, 21 Jun 1999 13:27:07 -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 OAA01147 for ; Mon, 21 Jun 1999 14:27:06 -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 PAA24832 for ; Mon, 21 Jun 1999 15:27:05 -0500 (CDT) Message-Id: <199906212027.PAA24832@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: ICMPv6 Node Information Queries (aka Who-Are-You) In-reply-to: Your message of Mon, 21 Jun 1999 16:12:50 EDT. <199906212008.UAA09864@inner.net> Date: Mon, 21 Jun 1999 15:27:05 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It'd be nice if you used the internet checksum or some other function that > would need to already exist on the system rather than pulling in a new > function. I agree in principle, but I don't think 16 bits is enough for this purpose. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 21 13:45:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA01819 for ipng-dist; Mon, 21 Jun 1999 13:39:39 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01812 for ; Mon, 21 Jun 1999 13:39:26 -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 NAA13429 for ; Mon, 21 Jun 1999 13:39:24 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA07752 for ; Mon, 21 Jun 1999 14:39:18 -0600 (MDT) Received: from hermes.research.att.com (hermes.research.att.com [135.207.16.38]) by mail-blue.research.att.com (Postfix) with ESMTP id E0A844CE07; Mon, 21 Jun 1999 16:39:06 -0400 (EDT) Received: from SIGABA.research.att.com (sigaba.research.att.com [135.207.23.169]) by hermes.research.att.com (8.8.7/8.8.7) with ESMTP id QAA11120; Mon, 21 Jun 1999 16:39:04 -0400 (EDT) Received: by SIGABA.research.att.com (Postfix, from userid 54047) id DA54A41F16; Mon, 21 Jun 1999 16:39:05 -0400 (EDT) Received: from roc (localhost [127.0.0.1]) by SIGABA.research.att.com (Postfix) with ESMTP id CB5B1400B4; Mon, 21 Jun 1999 16:39:00 -0400 (EDT) X-Mailer: exmh version 2.0.2 2/24/98 To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com Subject: Re: ICMPv6 Node Information Queries (aka Who-Are-You) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Jun 1999 16:39:00 -0400 From: "Steven M. Bellovin" Message-Id: <19990621203905.DA54A41F16@SIGABA.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199906212027.PAA24832@gungnir.fnal.gov>, "Matt Crawford" writes: > > It'd be nice if you used the internet checksum or some other function tha > t > > would need to already exist on the system rather than pulling in a new > > function. > > I agree in principle, but I don't think 16 bits is enough for this > purpose. How about (truncated) MD5? Its strength is overkill for this purpose, but if any machine with IPSEC (i.e., any IPv6 machine) will have the code in the kernel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 21 13:46:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA01855 for ipng-dist; Mon, 21 Jun 1999 13:43:05 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01848 for ; Mon, 21 Jun 1999 13:42:54 -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 NAA14291 for ; Mon, 21 Jun 1999 13:42:53 -0700 (PDT) Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA17838 for ; Mon, 21 Jun 1999 13:42:52 -0700 (PDT) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id UAA25537; Mon, 21 Jun 1999 20:42:10 GMT Message-Id: <199906212042.UAA25537@orchard.arlington.ma.us> To: Craig Metz cc: "Matt Crawford" , ipng@sunroof.eng.sun.com Subject: Re: ICMPv6 Node Information Queries (aka Who-Are-You) In-Reply-To: Message from Craig Metz of "Mon, 21 Jun 1999 16:12:50 EDT." <199906212008.UAA09864@inner.net> Date: Mon, 21 Jun 1999 16:42:10 -0400 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It'd be nice if you used the internet checksum or some other function that > would need to already exist on the system rather than pulling in a new > function. Agreed. Those of us building stacks for small boxes will like you better for it. Either the internet checksum if 16 bits is enough, or a truncated MD5/SHA1 (because the latter is already in use by ipsec) comes to mind. - 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 Jun 22 04:21:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA02900 for ipng-dist; Tue, 22 Jun 1999 04:14:23 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02893 for ; Tue, 22 Jun 1999 04:14:12 -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 EAA10593 for ; Tue, 22 Jun 1999 04:14:11 -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 FAA20330 for ; Tue, 22 Jun 1999 05:14:10 -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 HAA01618; Tue, 22 Jun 1999 07:14:07 -0400 (EDT) Message-Id: <199906221114.HAA01618@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-hbh-ext-csi-00.txt Date: Tue, 22 Jun 1999 07:14:07 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Connection/Link Status Investigation (CSI) for IPv6 IPv6 Hop-by-Hop option and ICMPv6 messages Extension Author(s) : H. Kitamura Filename : draft-ietf-ipngwg-hbh-ext-csi-00.txt Pages : 31 Date : 21-Jun-99 This document proposes a new mechanism whereby status information is collected for nodes along both the outgoing and incoming paths. This mechanism is called 'Connection/Link Status Investigation (CSI).' In order to realize the CSI mechanism, one new IPv6 Hop-by-Hop option and three new ICMPv6 messages are proposed as extensions. The CSI mechanism is as simple as the 'ping' mechanism and is also efficient, because ideally the status information of the nodes is collected with a pair of 'request/reply' ICMPv6 messages. By using the CSI mechanism, more efficient and reliable 'traceroute' type functions can be realized. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-hbh-ext-csi-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-hbh-ext-csi-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-hbh-ext-csi-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: <19990621101416.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-hbh-ext-csi-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-hbh-ext-csi-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990621101416.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 22 09:55:14 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA03205 for ipng-dist; Tue, 22 Jun 1999 09:46:31 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03198 for ; Tue, 22 Jun 1999 09:46:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA16202 for ; Tue, 22 Jun 1999 09:46:19 -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 KAA24073 for ; Tue, 22 Jun 1999 10:46:18 -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 LAA00242; Tue, 22 Jun 1999 11:46:16 -0500 (CDT) Message-Id: <199906221646.LAA00242@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com Cc: namedroppers@internic.net From: "Matt Crawford" Subject: draft-ietf-ipngwg-dns-lookups-04.txt Date: Tue, 22 Jun 1999 11:46:16 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Our area dissectors would like to have the A6 document specify just how the resolver is supposed to act with respect to requesting AAAA or A6 records when an IPv6 address lookup is needed. Down the road a short (?) way, the option will exist of using multiple questions in a single query, with the choice of requesting answers to all, or the first which gets a non-empty answer. I can't find a document which outlaws or deprecates multiple questions today, but we all know that they don't work. As soon as the A6 draft is implemented, I expect to see A6 records appear in zone files. And when they are in zone files, I hope to see A6-aware resolvers looking for them. But for some period, A6 records will be rarer than AAAA records. The rules for A6 processing in the server specify that A and AAAA are returned as additional data. So requesting A6 from an A6-aware server which holds no A6 records won't waste a round-trip. Aside from using multiple questions in one UDP packet, the following possibilities exist. 1* Use a TCP connection to make successive queries if needed. Multiple queries and replies on one connection is allowed, and encouraged at least for the case of SOA+AXFR. (Are there real- world implementation facts that would preclude this?) 2* Ask for both A6 and AAAA in separate UDP packets, without waiting for an answer in between. 3* Ask for A6, then for AAAA if RCODE=0 and ANCOUNT=0 and no AAAA records are returned as additional information. 4* Ask for AAAA, then for A6 if RCODE=0 and ANCOUNT=0. 5* Only ask for A6, never AAAA. 6* Only ask for AAAA, never A6. The last of these is today's state, and we want to transition to some other, possibly number 5. 1, 2, and 3 are all plausible intermediate states, each with its own drawback. An orthogonal but important question is that of how to cause the resolver to alter its behavior without extra redeployment steps. It could pick up its instruction from some magic word in a configuration file (or environment or registry entry), or some special cue in a zone file (but then some implementations may have to make a query for that cue in every new process). As a starting point for discussion, I propose the following text to be added to section 7 ("Transition from AAAA Records") Applications or libraries implementing the function of looking up IPv6 addresses by means of either A6 or AAAA records MUST be configurable to operate in at least the following modes: requesting A6 records before AAAA, AAAA before A6, and A6 only. The default mode SHOULD be to request A6 before AAAA. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 22 11:39:03 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA03423 for ipng-dist; Tue, 22 Jun 1999 11:29:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03416 for ; Tue, 22 Jun 1999 11:29:24 -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 LAA21431 for ; Tue, 22 Jun 1999 11:29:24 -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 MAA23210 for ; Tue, 22 Jun 1999 12:29:22 -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 OAA12248; Tue, 22 Jun 1999 14:29:18 -0400 (EDT) Message-Id: <199906221829.OAA12248@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-ipv6router-alert-05.txt Date: Tue, 22 Jun 1999 14:29:18 -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 : IPv6 Router Alert Option Author(s) : D. Katz, C. Partridge, A. Jackson Filename : draft-ietf-ipngwg-ipv6router-alert-05.txt Pages : 5 Date : 21-Jun-99 This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-ipv6router-alert-05.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-ipv6router-alert-05.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-ipv6router-alert-05.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: <19990621135406.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-ipv6router-alert-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-ipv6router-alert-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990621135406.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 22 19:36:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA04231 for ipng-dist; Tue, 22 Jun 1999 19:32:27 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA04224 for ; Tue, 22 Jun 1999 19:32:18 -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 TAA24396 for ; Tue, 22 Jun 1999 19:32:18 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA23941 for ; Tue, 22 Jun 1999 20:32:16 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id MAA01018; Wed, 23 Jun 1999 12:32:05 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Wed, 23 Jun 1999 12:32:05 +1000 (EST) From: Peter Tattam To: Matt Crawford cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-Reply-To: <199906221646.LAA00242@gungnir.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am close to beginning an A6 implementation in my DNS server. I raised the question some time ago about A6 -> AAAA translation for efficiency reasons, but was howled down. Is this still a possible topic for discussion? Peter On Tue, 22 Jun 1999, Matt Crawford wrote: > Our area dissectors would like to have the A6 document specify just > how the resolver is supposed to act with respect to requesting AAAA > or A6 records when an IPv6 address lookup is needed. > > Down the road a short (?) way, the option will exist of using > multiple questions in a single query, with the choice of requesting > answers to all, or the first which gets a non-empty answer. I can't > find a document which outlaws or deprecates multiple questions today, > but we all know that they don't work. > > As soon as the A6 draft is implemented, I expect to see A6 records > appear in zone files. And when they are in zone files, I hope to see > A6-aware resolvers looking for them. But for some period, A6 records > will be rarer than AAAA records. > > The rules for A6 processing in the server specify that A and AAAA > are returned as additional data. So requesting A6 from an A6-aware > server which holds no A6 records won't waste a round-trip. > > Aside from using multiple questions in one UDP packet, the > following possibilities exist. > > 1* Use a TCP connection to make successive queries if needed. > Multiple queries and replies on one connection is allowed, and > encouraged at least for the case of SOA+AXFR. (Are there real- > world implementation facts that would preclude this?) > > 2* Ask for both A6 and AAAA in separate UDP packets, without waiting > for an answer in between. > > 3* Ask for A6, then for AAAA if RCODE=0 and ANCOUNT=0 and no AAAA > records are returned as additional information. > > 4* Ask for AAAA, then for A6 if RCODE=0 and ANCOUNT=0. > > 5* Only ask for A6, never AAAA. > > 6* Only ask for AAAA, never A6. > > The last of these is today's state, and we want to transition to > some other, possibly number 5. 1, 2, and 3 are all plausible > intermediate states, each with its own drawback. > > An orthogonal but important question is that of how to cause the > resolver to alter its behavior without extra redeployment steps. It > could pick up its instruction from some magic word in a configuration > file (or environment or registry entry), or some special cue in a > zone file (but then some implementations may have to make a query for > that cue in every new process). > > As a starting point for discussion, I propose the following text to > be added to section 7 ("Transition from AAAA Records") > > Applications or libraries implementing the function of looking up > IPv6 addresses by means of either A6 or AAAA records MUST be > configurable to operate in at least the following modes: > requesting A6 records before AAAA, AAAA before A6, and A6 only. > The default mode SHOULD be to request A6 before AAAA. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 22 20:14:39 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA04327 for ipng-dist; Tue, 22 Jun 1999 20:11:20 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA04320 for ; Tue, 22 Jun 1999 20:11:11 -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 UAA26978 for ; Tue, 22 Jun 1999 20:11:11 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA08426 for ; Tue, 22 Jun 1999 21:11:10 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id NAA03577 for ; Wed, 23 Jun 1999 13:11:09 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Wed, 23 Jun 1999 13:11:09 +1000 (EST) From: Peter Tattam To: ipng@sunroof.eng.sun.com Subject: Other mechanisms for DNS server discovery. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As a developer of client TCP/IP stack software, we experience a very common issue relating to automatic configuration of the client, and that is defining the DNS server. While BOOTP/DHCP is the defined protocol for conveying such information, in our experience it is not the most reliable of solutions as it interacts with other items such as the IP address and the leasing concept of DHCP sometimes breaks things. In light of the fact that DNS is absolutely essential for a working stack these days and that there are mechanisms built in to IPv6 for automatic address and network configuration, is there any merit in providing some sure fire way of seeding a DNS server list for a host with a mechanism that is different from DHCP? Perhaps including it in Router advertisements. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 22 20:38:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA04407 for ipng-dist; Tue, 22 Jun 1999 20:34:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA04400 for ; Tue, 22 Jun 1999 20:34:46 -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 UAA09630 for ; Tue, 22 Jun 1999 20:34:48 -0700 (PDT) Received: from inner.net (avarice.inner.net [199.33.248.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA22419 for ; Tue, 22 Jun 1999 20:34:45 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id DAA11320; Wed, 23 Jun 1999 03:29:07 GMT Message-Id: <199906230329.DAA11320@inner.net> To: Peter Tattam cc: ipng@sunroof.eng.sun.com Subject: Re: Other mechanisms for DNS server discovery. In-reply-to: Your message of "Wed, 23 Jun 1999 13:11:09 +1000." X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 22 Jun 1999 23:34:04 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , you write: >In light of the fact that DNS is absolutely essential for a working stack thes >days and that there are mechanisms built in to IPv6 for automatic address and >network configuration, is there any merit in providing some sure fire way of >seeding a DNS server list for a host with a mechanism that is different from >DHCP? Perhaps including it in Router advertisements. Sending this sort of information in router advertisements is bad. What about locating printers, file servers, mail servers, web servers, authentication servers... eventually, the size of "router advertisements" explodes due to all the baggage. There is a service location protocol on the standards track. That sort of approach -- client goes and looks for services it needs and the network provides some mechanism for finding the service -- seems to be a better overall approach. There was some talk of using anycasting for this purpose, but I think that a multicast approach would be better. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 22 20:41:38 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA04425 for ipng-dist; Tue, 22 Jun 1999 20:39:59 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA04418 for ; Tue, 22 Jun 1999 20:39:51 -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 UAA26386 for ; Tue, 22 Jun 1999 20:39:52 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA18880 for ; Tue, 22 Jun 1999 21:39:49 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id NAA05277; Wed, 23 Jun 1999 13:39:31 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Wed, 23 Jun 1999 13:39:31 +1000 (EST) From: Peter Tattam To: Craig Metz cc: ipng@sunroof.eng.sun.com Subject: Re: Other mechanisms for DNS server discovery. In-Reply-To: <199906230329.DAA11320@inner.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 22 Jun 1999, Craig Metz wrote: > In message , you > write: > >In light of the fact that DNS is absolutely essential for a working stack thes > >days and that there are mechanisms built in to IPv6 for automatic address and > >network configuration, is there any merit in providing some sure fire way of > >seeding a DNS server list for a host with a mechanism that is different from > >DHCP? Perhaps including it in Router advertisements. > > Sending this sort of information in router advertisements is bad. What about > locating printers, file servers, mail servers, web servers, authentication > servers... eventually, the size of "router advertisements" explodes due to all > the baggage. > > There is a service location protocol on the standards track. That sort of > approach -- client goes and looks for services it needs and the network > provides some mechanism for finding the service -- seems to be a better overall > approach. > > There was some talk of using anycasting for this purpose, but I think that a > multicast approach would be better. > > -Craig > > I'm open to ideas. I just felt that DNS was such a special case that it needs individual treatment. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 22 22:38:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA04518 for ipng-dist; Tue, 22 Jun 1999 22:22:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04511 for ; Tue, 22 Jun 1999 22:22:33 -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 WAA16423 for ; Tue, 22 Jun 1999 22:22:33 -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 WAA17083 for ; Tue, 22 Jun 1999 22: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 OAA07741; Wed, 23 Jun 1999 14:22:03 +0900 (JST) To: Craig Metz cc: Peter Tattam , ipng@sunroof.eng.sun.com In-reply-to: cmetz's message of Tue, 22 Jun 1999 23:34:04 -0400. <199906230329.DAA11320@inner.net> 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: Other mechanisms for DNS server discovery. From: itojun@iijlab.net Date: Wed, 23 Jun 1999 14:22:03 +0900 Message-ID: <7739.930115323@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Sending this sort of information in router advertisements is bad. What about >locating printers, file servers, mail servers, web servers, authentication >servers... eventually, the size of "router advertisements" explodes due to all >the baggage. > There is a service location protocol on the standards track. That sort of >approach -- client goes and looks for services it needs and the network >provides some mechanism for finding the service -- seems to be a better overall >approach. > There was some talk of using anycasting for this purpose, but I think that a >multicast approach would be better. Some of my folks wished to use anycast address for DNS server (you'll write anycast address into /etc/resolv.conf and nearest DNS srever will give you the reply). But it has been impossible because DNS server cannot reply using anycast address in the source... itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 22 23:08:49 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA04570 for ipng-dist; Tue, 22 Jun 1999 22:51:14 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04560 for ; Tue, 22 Jun 1999 22:50:52 -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 WAA18196 for ; Tue, 22 Jun 1999 22:50:53 -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 WAA24585 for ; Tue, 22 Jun 1999 22:50:52 -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 OAA08136; Wed, 23 Jun 1999 14:50:45 +0900 (JST) To: Assar Westerlund cc: ipng@sunroof.eng.sun.com In-reply-to: assar's message of 23 Jun 1999 07:49:08 +0200. <5l7lov1n6z.fsf@assaris.sics.se> 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: Other mechanisms for DNS server discovery. From: itojun@iijlab.net Date: Wed, 23 Jun 1999 14:50:45 +0900 Message-ID: <8134.930117045@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Some of my folks wished to use anycast address for DNS server (you'll >> write anycast address into /etc/resolv.conf and nearest DNS srever >> will give you the reply). >> But it has been impossible because DNS server cannot reply using >> anycast address in the source... >Why can't the DNS server send the reply from (one of) its unicast >address? many of the resolvers don't like that (due to security reasons, obviously). also, tcp-based query/reply is impossible. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 22 23:09:24 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA04558 for ipng-dist; Tue, 22 Jun 1999 22:49:27 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04551 for ; Tue, 22 Jun 1999 22:49:14 -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 WAA05215 for ; Tue, 22 Jun 1999 22:49:03 -0700 (PDT) Received: from assaris.sics.se (assaris.sics.se [193.10.66.108]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA24237 for ; Tue, 22 Jun 1999 22:49:02 -0700 (PDT) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.7.3) id HAA67704; Wed, 23 Jun 1999 07:49:10 +0200 (CEST) To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: Other mechanisms for DNS server discovery. References: <7739.930115323@coconut.itojun.org> Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 23 Jun 1999 07:49:08 +0200 In-Reply-To: itojun@iijlab.net's message of "Wed, 23 Jun 1999 14:22:03 +0900" Message-ID: <5l7lov1n6z.fsf@assaris.sics.se> Lines: 11 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > Some of my folks wished to use anycast address for DNS server (you'll > write anycast address into /etc/resolv.conf and nearest DNS srever > will give you the reply). > But it has been impossible because DNS server cannot reply using > anycast address in the source... Why can't the DNS server send the reply from (one of) its unicast address? /assar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 22 23:16:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA04579 for ipng-dist; Tue, 22 Jun 1999 22:58:13 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04572 for ; Tue, 22 Jun 1999 22:58:00 -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 WAA07295 for ; Tue, 22 Jun 1999 22:58:00 -0700 (PDT) Received: from assaris.sics.se (assaris.sics.se [193.10.66.108]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA09427 for ; Tue, 22 Jun 1999 23:57:59 -0600 (MDT) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.7.3) id HAA67714; Wed, 23 Jun 1999 07:58:14 +0200 (CEST) To: itojun@iijlab.net Cc: ipng@sunroof.eng.sun.com Subject: Re: Other mechanisms for DNS server discovery. References: <8134.930117045@coconut.itojun.org> Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 23 Jun 1999 07:58:14 +0200 In-Reply-To: itojun@iijlab.net's message of "Wed, 23 Jun 1999 14:50:45 +0900" Message-ID: <5l7lovpifd.fsf@assaris.sics.se> Lines: 13 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk itojun@iijlab.net writes: > many of the resolvers don't like that (due to security reasons, > obviously). fix the resolver(s). > also, tcp-based query/reply is impossible. The resolver usually tries first with a udp-based query, getting back an error if the reply is too large to fit. Then it knows the (unicast) address of the name server and can do a TCP query-reply. /assar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 00:25:14 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id AAA04720 for ipng-dist; Wed, 23 Jun 1999 00:16:23 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA04713 for ; Wed, 23 Jun 1999 00:16:13 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id AAA13410 for ; Wed, 23 Jun 1999 00:16:13 -0700 (PDT) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA04112 for ; Wed, 23 Jun 1999 01:16:05 -0600 (MDT) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id QAA02557; Wed, 23 Jun 1999 16:15:52 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (splash.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id QAA22191; Wed, 23 Jun 1999 16:15:51 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (masahiro@grayswandir.isl.rdc.toshiba.co.jp [133.196.16.161]) by isl.rdc.toshiba.co.jp (8.9.3/8.9.3/8.2) with ESMTP id QAA04843; Wed, 23 Jun 1999 16:15:51 +0900 (JST) Date: Wed, 23 Jun 1999 16:15:42 +0900 Message-ID: <14192.35230.218133.58712V@grayswandir.isl.rdc.toshiba.co.jp> From: Masahiro =Rhythm Drive= Ishiyama To: assar@sics.se Cc: ipng@sunroof.eng.sun.com Subject: Re: Other mechanisms for DNS server discovery. In-Reply-To: In your message of "23 Jun 1999 07:49:08 +0200" <5l7lov1n6z.fsf@assaris.sics.se> References: <7739.930115323@coconut.itojun.org> <5l7lov1n6z.fsf@assaris.sics.se> User-Agent: Wanderlust/2.0.0 (Mmmbop) SEMI/1.13.4 (Terai) Chao/1.13.0 (JR Fujinomori) Emacs/20.3.90 (i386-pc-bsdi3.1) MULE/4.0 (HANANOEN) Organization: Toshiba Corp. R&D Center. MIME-Version: 1.0 (generated by SEMI 1.13.4 - "Terai") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 13 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On 23 Jun 1999 07:49:08 +0200, Assar Westerlund said: > Why can't the DNS server send the reply from (one of) its unicast > address? That seems to be reasonable, but I think that the querying host might want to know that the replying host is really the one that the host asked. The problem is that there is no way to know that the source unicast address in the reply is associated with the anycast address(the replying host really has the anycast address). masahiro -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 00:39:24 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id AAA04755 for ipng-dist; Wed, 23 Jun 1999 00:31:09 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA04748 for ; Wed, 23 Jun 1999 00:30:43 -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 AAA23600 for ; Wed, 23 Jun 1999 00:30:26 -0700 (PDT) Received: from assaris.sics.se (assaris.sics.se [193.10.66.108]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA17729 for ; Wed, 23 Jun 1999 00:30:24 -0700 (PDT) Received: (from assar@localhost) by assaris.sics.se (8.9.3/8.7.3) id JAA67841; Wed, 23 Jun 1999 09:30:36 +0200 (CEST) To: Masahiro =Rhythm Drive= Ishiyama Cc: ipng@sunroof.eng.sun.com Subject: Re: Other mechanisms for DNS server discovery. References: <7739.930115323@coconut.itojun.org> <5l7lov1n6z.fsf@assaris.sics.se> <14192.35230.218133.58712V@grayswandir.isl.rdc.toshiba.co.jp> Mime-Version: 1.0 (generated by tm-edit 7.68) Content-Type: text/plain; charset=US-ASCII From: Assar Westerlund Date: 23 Jun 1999 09:30:36 +0200 In-Reply-To: Masahiro =Rhythm Drive= Ishiyama's message of "Wed, 23 Jun 1999 16:15:42 +0900" Message-ID: <5ln1xrwezn.fsf@assaris.sics.se> Lines: 15 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Masahiro =Rhythm Drive= Ishiyama writes: > That seems to be reasonable, but I think that the querying host > might want to know that the replying host is really the one that > the host asked. The problem is that there is no way to know > that the source unicast address in the reply is associated with > the anycast address(the replying host really has the anycast > address). Make sure you have the correct data by verifying the SIG records in the data or with TSIG. In the first case you can verify that you have the correct data and you don't care very much about where it came from. In the second case you know it's the correct server because it has the correct key. /assar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 05:43:51 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA04915 for ipng-dist; Wed, 23 Jun 1999 03:00:17 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04908 for ; Wed, 23 Jun 1999 03:00:03 -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 CAA18376 for ; Wed, 23 Jun 1999 02:59:16 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA21762 for ; Wed, 23 Jun 1999 02:59:12 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id TAA28838 for ; Wed, 23 Jun 1999 19:59:10 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Wed, 23 Jun 1999 19:59:09 +1000 (EST) From: Peter Tattam To: ipng@sunroof.eng.sun.com Subject: Re: Other mechanisms for DNS server discovery. In-Reply-To: <5ln1xrwezn.fsf@assaris.sics.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Interestingly the discussion of this thread heads in the security direction for later messages. Also a comment has been made to me privately that DNS is not a special case so why should it be treated specially. The implication of the thread delving into the security aspects of DNS indicates that DNS may actually still be a special case and could well benefit from having such information conveyed via directly connected routers, i.e. only the next known router can be trusted as having the desired information. The similarity to ND concepts may not be coincidental to the drive to make sure that DNS transactions have a level of security attached to them. Hence my suggestion that something akin to ND or RA may still be the right place to look for a solution. This does not mean that DNS servers should be directly connected, but rather that the nearest router should be trusted to know where the nearest one is. It in turn could use the same mechanism to query it's neighboring routers and so forth. Conveyance of reliable and accurate information on DNS servers is essential to so many higher layer protocols, and I believe that it does deserve some special treatment. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 05:43:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA04940 for ipng-dist; Wed, 23 Jun 1999 03:18:45 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04933 for ; Wed, 23 Jun 1999 03:18:31 -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 DAA00520 for ; Wed, 23 Jun 1999 03:18:30 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA05491 for ; Wed, 23 Jun 1999 04:18:29 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id UAA00156 for ; Wed, 23 Jun 1999 20:18:27 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Wed, 23 Jun 1999 20:18:27 +1000 (EST) From: Peter Tattam To: ipng@sunroof.eng.sun.com Subject: Reality check (was Re: Other mechanisms for DNS server discovery.) 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, 23 Jun 1999, Peter Tattam wrote: > As a developer of client TCP/IP stack software, we experience a very common > issue relating to automatic configuration of the client, and that is defining > the DNS server. > > While BOOTP/DHCP is the defined protocol for conveying such information, in our > experience it is not the most reliable of solutions as it interacts with other > items such as the IP address and the leasing concept of DHCP sometimes breaks > things. > > In light of the fact that DNS is absolutely essential for a working stack these > days and that there are mechanisms built in to IPv6 for automatic address and > network configuration, is there any merit in providing some sure fire way of > seeding a DNS server list for a host with a mechanism that is different from > DHCP? Perhaps including it in Router advertisements. > > Peter > > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > As an addendum to this, could I make a gentle hint that some consideration be given in relation to setting up first time users of the Internet. Many of us have had years of experience with computers and find many setup tasks trivial, but the number of people experiencing a computer for the first time by connecting to the Internet is becoming a more common occurence daily. You just have to ask my tech support team and they could rattle out story after story. I would say that the lion's share of these users would be using the Windows platform but the representation of developers on this list for that platform is relatively low. If you sideline some of the key developers in the process the only result will be the establishment of proprietary protocols and nobody wants that to happen. Please try to keep this in mind in the design process. Remember Murphy's Law works *really* well in the actual ISP world :) Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 06:42:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA04989 for ipng-dist; Wed, 23 Jun 1999 05:02:42 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04982 for ; Wed, 23 Jun 1999 05:02:24 -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 FAA04604 for ; Wed, 23 Jun 1999 05:02:23 -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 FAA15923 for ; Wed, 23 Jun 1999 05:02: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 IAA26174; Wed, 23 Jun 1999 08:02:19 -0400 (EDT) Message-Id: <199906231202.IAA26174@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-icmp-name-lookups-04.txt Date: Wed, 23 Jun 1999 08:02:18 -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 : IPv6 Node Information Queries Author(s) : M. Crawford Filename : draft-ietf-ipngwg-icmp-name-lookups-04.txt Pages : 11 Date : 22-Jun-99 This document describes an experimental protocol for asking an IPv6 node to supply certain network information, such as its fully- qualified domain name. IPv6 implementation experience has shown that direct queries for FQDN are useful, and a direct query mechanism for other information has been requested. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-04.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-icmp-name-lookups-04.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-icmp-name-lookups-04.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: <19990622132031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-name-lookups-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-name-lookups-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990622132031.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 23 06:42:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA04980 for ipng-dist; Wed, 23 Jun 1999 04:55:41 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA04973 for ; Wed, 23 Jun 1999 04:54:10 -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 EAA23010 for ; Wed, 23 Jun 1999 04:53:25 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA13844 for ; Wed, 23 Jun 1999 04:53:24 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id HAA04680; Wed, 23 Jun 1999 07:57:16 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id HAA0000006216; Wed, 23 Jun 1999 07:53:17 -0400 (EDT) From: Jim Bound Message-Id: <199906231153.HAA0000006216@quarry.zk3.dec.com> To: "Matt Crawford" cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net, bindv9@isc.org, bind-workers@isc.org Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of "Tue, 22 Jun 1999 11:46:16 CDT." <199906221646.LAA00242@gungnir.fnal.gov> Date: Wed, 23 Jun 1999 07:53:17 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, I have added BIND V9 mail list and BIND workers as this affects our IPv6 A6 rollout and any fixes to 8.1.2 which is about ready to go into production and in kits for IPv6 Customers; who by the way have not widely deployed A6 records quite yet :--). I would also like to hear Bob Halley's take on this too. > Our area dissectors would like to have the A6 document specify just >how the resolver is supposed to act with respect to requesting AAAA >or A6 records when an IPv6 address lookup is needed. Why for the record and so its in the archives for future reference OK? > Down the road a short (?) way, the option will exist of using >multiple questions in a single query, with the choice of requesting >answers to all, or the first which gets a non-empty answer. I can't >find a document which outlaws or deprecates multiple questions today, >but we all know that they don't work. Yes this will be part of BIND v9 for that code base which will be about in 6 months long before massive IPv6 deployment? The meta query has been a BIND vendor request for some time and should be here real soon. So why the urgency with BIND v9 so close? > As soon as the A6 draft is implemented, I expect to see A6 records >appear in zone files. And when they are in zone files, I hope to see >A6-aware resolvers looking for them. But for some period, A6 records >will be rarer than AAAA records. Agreed. > The rules for A6 processing in the server specify that A and AAAA >are returned as additional data. So requesting A6 from an A6-aware >server which holds no A6 records won't waste a round-trip. I want this to happen but for the record I always have thought this was a bad idea as a MUST requirement and should be able to be overriden by some code to the server. A client may not want the A or AAAA records back and we want to be able to permit that behavior for the future when A and AAAA records are very rare. But I just thought of that so sorry but I will now check this for last call. Or before DS happens. > Aside from using multiple questions in one UDP packet, the >following possibilities exist. The meta query will be able to do this fyi. > 1* Use a TCP connection to make successive queries if needed. > Multiple queries and replies on one connection is allowed, and > encouraged at least for the case of SOA+AXFR. (Are there real- > world implementation facts that would preclude this?) This increases the packets to the server for every request and why we use UDP in the first place. At least that is what current thinking suggests for intensive client server processing should use UDP. Of course I don't agree with that current thinking. > 2* Ask for both A6 and AAAA in separate UDP packets, without waiting > for an answer in between. Yuck. That puts more state in the resolver awaiting to reply to the application. > 3* Ask for A6, then for AAAA if RCODE=0 and ANCOUNT=0 and no AAAA > records are returned as additional information. This sounds like the solution but we need a way as I said above to shut this down to not return add'l section records too. > 4* Ask for AAAA, then for A6 if RCODE=0 and ANCOUNT=0. This should be permitted. > 5* Only ask for A6, never AAAA. This should be permitted. > 6* Only ask for AAAA, never A6. This should be permitted. > The last of these is today's state, and we want to transition to >some other, possibly number 5. 1, 2, and 3 are all plausible >intermediate states, each with its own drawback. We should permit 5 and 6 for "transition" and 5 gives us 3 by default. > An orthogonal but important question is that of how to cause the >resolver to alter its behavior without extra redeployment steps. It >could pick up its instruction from some magic word in a configuration >file (or environment or registry entry), or some special cue in a >zone file (but then some implementations may have to make a query for >that cue in every new process). This is where the BIND v9 and BIND workers need to discuss this because it is an important point. I am not sure the spec should get into specifying this because then we would have to assume we know all the ways products will provide deployment of resolvers. The best we can do is provide an example abstraction. I would like to see us stay away from environment variables and config files, as this type of fix can cause release number problems for product sets. So I think that is a bad idea but will defer to ISC and folks there. But as a vendor I have gotten burned messing with config files for DNS parts. I need to think on this one a bit more and get back to you. But its an important point and very critical. > As a starting point for discussion, I propose the following text to >be added to section 7 ("Transition from AAAA Records") > Applications or libraries implementing the function of looking up > IPv6 addresses by means of either A6 or AAAA records MUST be > configurable to operate in at least the following modes: > requesting A6 records before AAAA, AAAA before A6, and A6 only. ???? I think you have a logic error in the above sentence ??? > The default mode SHOULD be to request A6 before AAAA. When asking a user if they are using IPv6 on their node I envision asking them are you ready for A6 records. If they say yes then I could use the default above but I would ask them if they wanted the default and they should not if they know there are no A6 records deployed. So your SHOULD above is OK I think. But as I said above if a site has gotten rid of AAAA records or simply does not want them don't want to see them in the hostent structure or the A records but that is an API function I think we have covered in 2553. /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 Jun 23 06:57:38 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA05132 for ipng-dist; Wed, 23 Jun 1999 06:40:45 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05125 for ; Wed, 23 Jun 1999 06:40:24 -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 GAA27915 for ; Wed, 23 Jun 1999 06:39:42 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA13526 for ; Wed, 23 Jun 1999 06:39:41 -0700 (PDT) Received: from localhost (725 bytes) by rip.psg.com via sendmail with P:stdio/R:inet_resolve/T:smtp (sender: ) (ident using unix) id for ; Wed, 23 Jun 1999 06:39:41 -0700 (PDT) (Smail-3.2.0.101 1997-Dec-17 #1 built 1999-Apr-1) Message-Id: Date: Wed, 23 Jun 1999 06:39:41 -0700 (PDT) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-04.txt References: <199906231202.IAA26174@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Upon receiving an NI Query, the Responder must check the Query's IPv6 destination address and discard the Query without further processing if it is not one of the Responder's unicast or anycast addresses. A Responder must also silently discard a Query whose subject address or name (in the Data field) does belong to that node. /does belong/does not belong/? randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 06:57:48 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA05176 for ipng-dist; Wed, 23 Jun 1999 06:50:04 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05169 for ; Wed, 23 Jun 1999 06:49:30 -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 GAA09917 for ; Wed, 23 Jun 1999 06:49:29 -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 GAA16386 for ; Wed, 23 Jun 1999 06:49:29 -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 IAA06451; Wed, 23 Jun 1999 08:49:22 -0500 (CDT) Message-Id: <199906231349.IAA06451@gungnir.fnal.gov> To: Peter Tattam Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net From: "Matt Crawford" Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of Wed, 23 Jun 1999 12:32:05 +1000. Date: Wed, 23 Jun 1999 08:49:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I raised the question some time ago about A6 -> AAAA translation > for efficiency reasons, but was howled down. Is this still a > possible topic for discussion? You read section 7, yes? Or are you talking not about a transition aid, but a regular, long-term strategy? 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 Jun 23 07:22:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA05322 for ipng-dist; Wed, 23 Jun 1999 07:19:44 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05315 for ; Wed, 23 Jun 1999 07:19:32 -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 HAA06712 for ; Wed, 23 Jun 1999 07:19:32 -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 HAA26561 for ; Wed, 23 Jun 1999 07:19:32 -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 JAA06655; Wed, 23 Jun 1999 09:12:35 -0500 (CDT) Message-Id: <199906231412.JAA06655@gungnir.fnal.gov> To: Jim Bound Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net, bindv9@isc.org, bind-workers@isc.org From: "Matt Crawford" Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of Wed, 23 Jun 1999 07:53:17 EDT. <199906231153.HAA0000006216@quarry.zk3.dec.com> Date: Wed, 23 Jun 1999 09:12:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Our area dissectors would like to have the A6 document specify just > >how the resolver is supposed to act with respect to requesting AAAA > >or A6 records when an IPv6 address lookup is needed. > > Why for the record and so its in the archives for future reference OK? I will not answer for them, as I am not convinced of the necessity myself, except in the sense that's it's necesary to play ball with the ADs if we want this to go though. > > Down the road a short (?) way, the option will exist of using > >multiple questions in a single query, ... > > So why the urgency with BIND v9 so close? I don't know what's to be in BINDv9; I never heard of the bindv9 list before, but I do know that the multi-question feature is spec'd in EDNS1, and given the velocity of the much simpler EDNS0, (to say nothing of A6) I'm not going to pin anything on EDNS1 if I can help it. > > The rules for A6 processing in the server specify that A and AAAA > >are returned as additional data. So requesting A6 from an A6-aware > >server which holds no A6 records won't waste a round-trip. > > I want this to happen but for the record I always have thought this was > a bad idea as a MUST requirement and should be able to be overriden by > some code to the server. A client may not want the A or AAAA records... And the server knows this by what, ESP? Remember, additional data is included only to the extent that it (a) fits in the packet and (b) is available in the responding server. > > Applications or libraries implementing the function of looking up > > IPv6 addresses by means of either A6 or AAAA records MUST be > > configurable to operate in at least the following modes: > > requesting A6 records before AAAA, AAAA before A6, and A6 only. > ???? I think you have a logic error in the above sentence ??? > > The default mode SHOULD be to request A6 before AAAA. Explain the error, please; I don't see it. 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 Jun 23 07:24:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA05340 for ipng-dist; Wed, 23 Jun 1999 07:23:37 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05333 for ; Wed, 23 Jun 1999 07:23:25 -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 HAA08635 for ; Wed, 23 Jun 1999 07:23:24 -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 IAA00367 for ; Wed, 23 Jun 1999 08:23:24 -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 JAA06749; Wed, 23 Jun 1999 09:23:22 -0500 (CDT) Message-Id: <199906231423.JAA06749@gungnir.fnal.gov> To: Randy Bush Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-04.txt In-reply-to: Your message of Wed, 23 Jun 1999 06:39:41 PDT. Date: Wed, 23 Jun 1999 09:23:21 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > /does belong/does not belong/? > > randy Right. That's one. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 07:36:10 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA05386 for ipng-dist; Wed, 23 Jun 1999 07:33:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05379 for ; Wed, 23 Jun 1999 07:33:18 -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 HAA11396 for ; Wed, 23 Jun 1999 07:33:17 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01218 for ; Wed, 23 Jun 1999 07:33:16 -0700 (PDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id KAA27024; Wed, 23 Jun 1999 10:33:13 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000028114; Wed, 23 Jun 1999 10:33:12 -0400 (EDT) From: Jim Bound Message-Id: <199906231433.KAA0000028114@quarry.zk3.dec.com> To: "Matt Crawford" cc: Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net, bindv9@isc.org, bind-workers@isc.org Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of "Wed, 23 Jun 1999 09:12:30 CDT." <199906231412.JAA06655@gungnir.fnal.gov> Date: Wed, 23 Jun 1999 10:33:11 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I will not answer for them, as I am not convinced of the necessity >myself, except in the sense that's it's necesary to play ball with >the ADs if we want this to go though. Hmmm. Then they should tell us on the list I think. Tom or Erik??? Please.................. >> > Down the road a short (?) way, the option will exist of using >> >multiple questions in a single query, ... >> >> So why the urgency with BIND v9 so close? > >I don't know what's to be in BINDv9; I never heard of the bindv9 list >before, but I do know that the multi-question feature is spec'd in >EDNS1, and given the velocity of the much simpler EDNS0, (to say >nothing of A6) I'm not going to pin anything on EDNS1 if I can help >it. BINDv9 is the next major arch release of BIND with lots of good stuff like SMP. A group of us vendors and some other folks are paying ISC to deliver an NGN BIND that will eat gremlins so to speak. The multiquery will be there we need it for IPv6, regardless of the velocity of some spec. But we can move forward I see your point now. >> > The rules for A6 processing in the server specify that A and AAAA >> >are returned as additional data. So requesting A6 from an A6-aware >> >server which holds no A6 records won't waste a round-trip. >> >> I want this to happen but for the record I always have thought this was >> a bad idea as a MUST requirement and should be able to be overriden by >> some code to the server. A client may not want the A or AAAA records... > >And the server knows this by what, ESP? Remember, additional data is >included only to the extent that it (a) fits in the packet and (b) is >available in the responding server. I am thinking we need to tell the server about the transition issue. >> > Applications or libraries implementing the function of looking up >> > IPv6 addresses by means of either A6 or AAAA records MUST be >> > configurable to operate in at least the following modes: >> > requesting A6 records before AAAA, AAAA before A6, and A6 only. >> ???? I think you have a logic error in the above sentence ??? >> > The default mode SHOULD be to request A6 before AAAA. > >Explain the error, please; I don't see it. If I ask for A6 records before AAAA then why would I ask for AAAA records before A6. Its one way or the other? A6 ONLY is good and something I think we should be able to do per the above. 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 Wed Jun 23 07:55:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA05451 for ipng-dist; Wed, 23 Jun 1999 07:51:24 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05444 for ; Wed, 23 Jun 1999 07:51:15 -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 HAA04530 for ; Wed, 23 Jun 1999 07:51:15 -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 IAA14310 for ; Wed, 23 Jun 1999 08:51:09 -0600 (MDT) Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47]) by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id KAA07880; Wed, 23 Jun 1999 10:48:32 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id KAA31478; Wed, 23 Jun 1999 10:48:33 -0400 Received: from localhost.raleigh.ibm.com (localhost.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (AIX4.3/UCB 8.7/8.7/RTP-ral-1.0) with SMTP id KAA07464; Wed, 23 Jun 1999 10:48:30 -0400 (EDT) Message-Id: <199906231448.KAA07464@cichlid.raleigh.ibm.com> X-Authentication-Warning: cichlid.raleigh.ibm.com: Host localhost.raleigh.ibm.com [127.0.0.1] didn't use HELO protocol To: Jim Bound cc: "Matt Crawford" , ipng@sunroof.eng.sun.com, namedroppers@internic.net, bindv9@isc.org, bind-workers@isc.org Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of "Wed, 23 Jun 1999 07:53:17 EDT." <199906231153.HAA0000006216@quarry.zk3.dec.com> Date: Wed, 23 Jun 1999 10:48:29 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Our area dissectors would like to have the A6 document specify just > >how the resolver is supposed to act with respect to requesting AAAA > >or A6 records when an IPv6 address lookup is needed. > Why for the record and so its in the archives for future reference OK? Once A6 records are specified, there would be two ways of doing the same thing (i.e., query the DNS for v6 addresses). Implementers need some guidance as to which of these two approaches to implement. Moreover, AAAA records are deployed today, while A6 records are not. Thus, a transition strategy for migrating from AAAA to A6 is necessary. If this stuff isn't specified in an RFC, vendors will likely not know what to do and make choices that aren't well thought out (e.g, ship resolvers that do AAAA only or A6 only). Thus, some guidance is needed to insure that once folks actually start deploying A6, it can be made to work in a sensible fashion. This is akin to an applicability statement stating in what context some new feature should be used and how it relates to an existing feature that it conflicts/overlaps with. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 23 07:56:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA05467 for ipng-dist; Wed, 23 Jun 1999 07:53:17 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05453 for ; Wed, 23 Jun 1999 07:53: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 HAA16039 for ; Wed, 23 Jun 1999 07:53:01 -0700 (PDT) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA15337 for ; Wed, 23 Jun 1999 08:53:01 -0600 (MDT) Received: from localhost (1569 bytes) by rip.psg.com via sendmail with P:stdio/R:inet_resolve/T:smtp (sender: ) (ident using unix) id for ; Wed, 23 Jun 1999 07:52:52 -0700 (PDT) (Smail-3.2.0.101 1997-Dec-17 #1 built 1999-Apr-1) Message-Id: Date: Wed, 23 Jun 1999 07:52:52 -0700 (PDT) From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Matt Crawford" Cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-04.txt References: <199906231423.JAA06749@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk the nWord and nSkip stuff seems to add complexity to the protocol and hence the code. it can not break-even until there are more than 96 qtypes, and there are currently only four. so this all seems to be an escape for user- defined etc. qtypes. is this *really* worth the complexity? in 5.3.1. Discussion Because a node can only answer a FQDN Request when it is up and reachable, it may be useful to create a proxy responder for a group of nodes, for example a subnet or a site. Such a mechanism is not addressed here. in fact, it would seem to be specifically precluded by A Responder must also silently discard a Query whose subject address or name (in the Data field) does belong to that node. ^ not in 5.4. Node Addresses there seems to be no way to indicate that the reply set of addresses is incomplete for reasons other than space, e.g. security through obscurity. in 5.4.A, i am having trouble parsing the plurality of the last part of If 0, only those addresses are requested which belong to the interface (or any one interface) which has the Subject Address. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 07:56:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA05469 for ipng-dist; Wed, 23 Jun 1999 07:53:26 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05461 for ; Wed, 23 Jun 1999 07:53:10 -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 HAA16070 for ; Wed, 23 Jun 1999 07:53:09 -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 IAA15380 for ; Wed, 23 Jun 1999 08:53:08 -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 JAA06975; Wed, 23 Jun 1999 09:46:31 -0500 (CDT) Message-Id: <199906231446.JAA06975@gungnir.fnal.gov> To: Jim Bound Cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net, bindv9@isc.org, bind-workers@isc.org From: "Matt Crawford" Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of Wed, 23 Jun 1999 10:33:11 EDT. <199906231433.KAA0000028114@quarry.zk3.dec.com> Date: Wed, 23 Jun 1999 09:46:31 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I am thinking we need to tell the server about the transition issue. And there are already notes in the draft about transition issues for the server side. The directive from the ADs concerns the client side. > >> > Applications or libraries implementing the function of looking up > >> > IPv6 addresses by means of either A6 or AAAA records MUST be > >> > configurable to operate in at least the following modes: > >> > requesting A6 records before AAAA, AAAA before A6, and A6 only. > >> ???? I think you have a logic error in the above sentence ??? > >> > The default mode SHOULD be to request A6 before AAAA. > > > >Explain the error, please; I don't see it. > > If I ask for A6 records before AAAA then why would I ask for AAAA > records before A6. Its one way or the other? A6 ONLY is good and > something I think we should be able to do per the above. Read it this way: "... MUST be configurable to operate in at least the following modes: Foo, Bar and Baz, where Foo=(A6 before AAAA), Bar=(AAAA before A6) and Baz=(A6 only)." The sample text says all three modes must be available to choose among. (I can't send to the two lists you added, so a moderator is getting work, and any readers there will get this out-of-order.) 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 Jun 23 08:43:50 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA05595 for ipng-dist; Wed, 23 Jun 1999 08:40:22 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA05588 for ; Wed, 23 Jun 1999 08:40:13 -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 IAA21136 for ; Wed, 23 Jun 1999 08:40:13 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA28725 for ; Wed, 23 Jun 1999 08:40:11 -0700 (PDT) Received: from 157.54.9.125 by mail1.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 23 Jun 1999 08:04:07 -0700 (Pacific Daylight Time) Received: by INET-IMC-01 with Internet Mail Service (5.5.2524.0) id ; Wed, 23 Jun 1999 08:04:05 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515382@RED-MSG-50> From: Richard Draves To: "'Peter Tattam'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Reality check (was Re: Other mechanisms for DNS server discov ery.) Date: Wed, 23 Jun 1999 08:03:58 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think a service discovery protocol like SSDP or SLP is the right approach for discovering DNS servers. > -----Original Message----- > From: Peter Tattam [mailto:peter@jazz-1.trumpet.com.au] > Sent: Wednesday, June 23, 1999 3:18 AM > To: ipng@sunroof.eng.sun.com > Subject: Reality check (was Re: Other mechanisms for DNS server > discovery.) > > > On Wed, 23 Jun 1999, Peter Tattam wrote: > > > As a developer of client TCP/IP stack software, we > experience a very common > > issue relating to automatic configuration of the client, > and that is defining > > the DNS server. > > > > While BOOTP/DHCP is the defined protocol for conveying such > information, in our > > experience it is not the most reliable of solutions as it > interacts with other > > items such as the IP address and the leasing concept of > DHCP sometimes breaks > > things. > > > > In light of the fact that DNS is absolutely essential for a > working stack these > > days and that there are mechanisms built in to IPv6 for > automatic address and > > network configuration, is there any merit in providing some > sure fire way of > > seeding a DNS server list for a host with a mechanism that > is different from > > DHCP? Perhaps including it in Router advertisements. > > > > Peter > > > > -- > > Peter R. Tattam peter@trumpet.com > > Managing Director, Trumpet Software International Pty Ltd > > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > > > As an addendum to this, could I make a gentle hint that some > consideration > be given in relation to setting up first time users of the Internet. > > Many of us have had years of experience with computers and > find many setup > tasks trivial, but the number of people experiencing a > computer for the first > time by connecting to the Internet is becoming a more common > occurence daily. > You just have to ask my tech support team and they could > rattle out story after > story. > > I would say that the lion's share of these users would be > using the Windows > platform but the representation of developers on this list > for that platform is > relatively low. If you sideline some of the key developers > in the process the > only result will be the establishment of proprietary > protocols and nobody wants > that to happen. > > Please try to keep this in mind in the design process. > Remember Murphy's Law > works *really* well in the actual ISP world :) > > Peter > > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 23 09:55:00 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA05718 for ipng-dist; Wed, 23 Jun 1999 09:50:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05708 for ; Wed, 23 Jun 1999 09:50: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 JAA05422 for ; Wed, 23 Jun 1999 09:50:40 -0700 (PDT) Received: from polaris-xch.sisa.samsung.com ([209.111.66.250]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19450 for ; Wed, 23 Jun 1999 10:50:40 -0600 (MDT) Received: by polaris-xch.ssi.samsung.com with Internet Mail Service (5.5.2232.9) id ; Wed, 23 Jun 1999 09:50:45 -0700 Message-ID: <13881A0EBCBBD211954C00A0C9E5FF576A3314@polaris-xch.ssi.samsung.com> From: Richard Humpleman - SISA To: Richard Draves , "'Peter Tattam'" Cc: ipng@sunroof.eng.sun.com, mikezin@microsoft.com Subject: RE: Reality check (was Re: Other mechanisms for DNS server discov ery.) Date: Wed, 23 Jun 1999 09:50:39 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="EUC-KR" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A general point: I think for many uses DNS is subsumed by a universally accessible SSDP Service). User control via a Browser and a hierarchy of Web pages actually requires no DNS as the Names are an addressing convenience that can be replaced by the regeneration of the higher level Web pages using IP addresses in the hypertext links to get to the lower levels. Automatic control using Web technology (under development) using XML interface descriptions (for example like SSDP) and XML messages require standardised look-ups of more than Name. You can look up a DNS service in the SSDP data or names can be included in the SSDP description itself and dispense with DNS. Regards, Richard Humpleman, Manager Home Network Projects, SISA, Samsung Electronics, San Jose, CA 95134. -----Original Message----- From: Richard Draves [mailto:richdr@microsoft.com] Sent: Wednesday, June 23, 1999 8:04 AM To: 'Peter Tattam' Cc: ipng@sunroof.eng.sun.com Subject: RE: Reality check (was Re: Other mechanisms for DNS server discov ery.) I think a service discovery protocol like SSDP or SLP is the right approach for discovering DNS servers. > -----Original Message----- > From: Peter Tattam [mailto:peter@jazz-1.trumpet.com.au] > Sent: Wednesday, June 23, 1999 3:18 AM > To: ipng@sunroof.eng.sun.com > Subject: Reality check (was Re: Other mechanisms for DNS server > discovery.) > > > On Wed, 23 Jun 1999, Peter Tattam wrote: > > > As a developer of client TCP/IP stack software, we > experience a very common > > issue relating to automatic configuration of the client, > and that is defining > > the DNS server. > > > > While BOOTP/DHCP is the defined protocol for conveying such > information, in our > > experience it is not the most reliable of solutions as it > interacts with other > > items such as the IP address and the leasing concept of > DHCP sometimes breaks > > things. > > > > In light of the fact that DNS is absolutely essential for a > working stack these > > days and that there are mechanisms built in to IPv6 for > automatic address and > > network configuration, is there any merit in providing some > sure fire way of > > seeding a DNS server list for a host with a mechanism that > is different from > > DHCP? Perhaps including it in Router advertisements. > > > > Peter > > > > -- > > Peter R. Tattam peter@trumpet.com > > Managing Director, Trumpet Software International Pty Ltd > > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > > > As an addendum to this, could I make a gentle hint that some > consideration > be given in relation to setting up first time users of the Internet. > > Many of us have had years of experience with computers and > find many setup > tasks trivial, but the number of people experiencing a > computer for the first > time by connecting to the Internet is becoming a more common > occurence daily. > You just have to ask my tech support team and they could > rattle out story after > story. > > I would say that the lion's share of these users would be > using the Windows > platform but the representation of developers on this list > for that platform is > relatively low. If you sideline some of the key developers > in the process the > only result will be the establishment of proprietary > protocols and nobody wants > that to happen. > > Please try to keep this in mind in the design process. > Remember Murphy's Law > works *really* well in the actual ISP world :) > > Peter > > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 10:14:10 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA05755 for ipng-dist; Wed, 23 Jun 1999 10:10:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05748 for ; Wed, 23 Jun 1999 10:10:26 -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 KAA09434 for ; Wed, 23 Jun 1999 10:10:25 -0700 (PDT) Received: from inner.net (avarice.inner.net [199.33.248.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08218 for ; Wed, 23 Jun 1999 10:10:23 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id RAA12233; Wed, 23 Jun 1999 17:04:23 GMT Message-Id: <199906231704.RAA12233@inner.net> To: Richard Humpleman - SISA cc: "'Peter Tattam'" , ipng@sunroof.eng.sun.com Subject: Re: Reality check (was Re: Other mechanisms for DNS server discov ery.) In-reply-to: Your message of "Wed, 23 Jun 1999 09:50:39 PDT." <13881A0EBCBBD211954C00A0C9E5FF576A3314@polaris-xch.ssi.samsung.com> X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Wed, 23 Jun 1999 13:09:50 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <13881A0EBCBBD211954C00A0C9E5FF576A3314@polaris-xch.ssi.samsung.com> , you write: >A general point: I think for many uses DNS is subsumed by a universally >accessible SSDP Service). > >User control via a Browser and a hierarchy of Web pages actually requires >no DNS as the Names are an addressing convenience that can be replaced by >the regeneration of the higher level Web pages using IP addresses in the >hypertext links to get to the lower levels. > >Automatic control using Web technology (under development) using XML >interface descriptions (for example like SSDP) and XML messages require >standardised look-ups of more than Name. You can look up a DNS service in >the SSDP data or names can be included in the SSDP description itself and >dispense with DNS. Perhaps in the alternate reality in which Web people live your statement is correct, but the operational Internet uses DNS and is in no danger of changing that. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 10:16:40 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA05764 for ipng-dist; Wed, 23 Jun 1999 10:13:57 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05757 for ; Wed, 23 Jun 1999 10:13:48 -0700 (PDT) From: trawick@us.ibm.com 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 KAA06743 for ; Wed, 23 Jun 1999 10:13:47 -0700 (PDT) Received: from ny.us.ibm.com. (e4.ny.us.ibm.com [32.97.182.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA01880 for ; Wed, 23 Jun 1999 11:13:46 -0600 (MDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by ny.us.ibm.com. (8.9.3/8.9.3) with ESMTP id NAA17798 for ; Wed, 23 Jun 1999 13:13:32 -0400 Received: from d54mta05.raleigh.ibm.com (d54mta05.raleigh.ibm.com [9.67.228.37]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.03) with SMTP id NAA37790 for ; Wed, 23 Jun 1999 13:13:38 -0400 Received: by d54mta05.raleigh.ibm.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 85256799.005E9DA2 ; Wed, 23 Jun 1999 13:13:27 -0400 X-Lotus-FromDomain: IBMUS To: ipng@sunroof.eng.sun.com Message-ID: <85256799.005E9C75.00@d54mta05.raleigh.ibm.com> Date: Wed, 23 Jun 1999 13:13:22 -0400 Subject: getipnodebyname() and numeric address string arguments with various non-zero flags Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >From RFC 2553, I gather that it makes no difference what is passed for the flags parameter on getipnodebyname() when the type of the numeric address string matches the address family parameter. Right? So getipnodebyname("FE80::1000:whatever",AF_INET6,AI_DEFAULT,&error_num) on a system that doesn't have a local IPv6 interface will succeed, but the application won't be able to use the resulting address. Right? If this is correct, perhaps future documentation should be more clear about getipnodebyname() ignoring flags for this scenario? Thanks for any comments, Jeff Trawick, trawick@us.ibm.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 23 10:27:37 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA05815 for ipng-dist; Wed, 23 Jun 1999 10:25:03 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05808 for ; Wed, 23 Jun 1999 10:24:53 -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 KAA12061 for ; Wed, 23 Jun 1999 10:24:52 -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 LAA07730 for ; Wed, 23 Jun 1999 11:24:52 -0600 (MDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id KAA19728; Wed, 23 Jun 1999 10:24:31 -0700 (PDT) From: Bill Manning Message-Id: <199906231724.KAA19728@boreas.isi.edu> Subject: Re: Other mechanisms for DNS server discovery. To: peter@jazz-1.trumpet.com.au (Peter Tattam) Date: Wed, 23 Jun 1999 10:24:31 -0700 (PDT) Cc: cmetz@inner.net (Craig Metz), ipng@sunroof.eng.sun.com In-Reply-To: from "Peter Tattam" at Jun 23, 1999 01:39:31 PM X-Mailer: ELM [version 2.5 PL0] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>Sending this sort of information in router advertisements is bad. What about >>locating printers, file servers, mail servers, web servers, authentication >>servers... eventually, the size of "router advertisements" explodes due to all >>the baggage. >> >>There is a service location protocol on the standards track. That sort of >>approach -- client goes and looks for services it needs and the network >>provides some mechanism for finding the service -- seems to be a better overall >>approach. >> >>There was some talk of using anycasting for this purpose, but I think that a >>multicast approach would be better. >> >> > > I'm open to ideas. I just felt that DNS was such a special case that it needs > individual treatment. > draft-manning-multicast-dns-01.txt It has a couple of problems and a revison is in the works. --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 Jun 23 10:27:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA05806 for ipng-dist; Wed, 23 Jun 1999 10:24:03 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05799 for ; Wed, 23 Jun 1999 10:23:53 -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 KAA00096 for ; Wed, 23 Jun 1999 10:23:53 -0700 (PDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA07275 for ; Wed, 23 Jun 1999 11:23:52 -0600 (MDT) Received: from smtpsrv1.mitre.org (smtpsrv1.mitre.org [129.83.20.101]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id NAA18545; Wed, 23 Jun 1999 13:23:36 -0400 (EDT) Received: from MAILHUB1 (mailhub1.mitre.org [129.83.20.31]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id NAA29408; Wed, 23 Jun 1999 13:22:11 -0400 (EDT) Received: from m22025-pc.mitre.org (128.29.105.55) by mailhub1.mitre.org with SMTP id 1079980; Wed, 23 Jun 1999 13:23:23 EST Message-ID: <3771186B.84E130C4@mitre.org> Date: Wed, 23 Jun 1999 13:24:59 -0400 From: Sham Chakravorty Organization: The MITRE Corporation X-Mailer: Mozilla 4.5 [en]C-19990120M (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: Jim Bound , Matt Crawford , ipng@sunroof.eng.sun.com, namedroppers@internic.net, bindv9@isc.org, bind-workers@isc.org Subject: IPv6 Implementation References: <199906231448.KAA07464@cichlid.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We are in the process of summarizing various Ipv6 implementation issues including the status of the protocol, extent of its use around the world, etc., for a large organization for use in mostly mobile, narrow bandwidth environment. We would most appreciate information on your experience with IPv6 implementation for large organizations. We would appreciate knowing about extent of IPv4 (or other) tunneling you needed, interoperability issues, bandwidth usage (especially in the low bandwidth links such as radio links), delays due to dual stacking at the hosts and/or routers if any, issues for the mobile environment, and any other related issues such as impact on security, training the network managers/ops staff, etc. Thanks much in anticipation of your inputs. S. Chakravorty ************************************* -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 11:42:50 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA05919 for ipng-dist; Wed, 23 Jun 1999 11:29:19 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05912 for ; Wed, 23 Jun 1999 11:29:07 -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 LAA13852 for ; Wed, 23 Jun 1999 11:29:07 -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 LAA15810 for ; Wed, 23 Jun 1999 11:29:06 -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 NAA08299; Wed, 23 Jun 1999 13:29:04 -0500 (CDT) Message-Id: <199906231829.NAA08299@gungnir.fnal.gov> To: Randy Bush Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: Re: I-D ACTION:draft-ietf-ipngwg-icmp-name-lookups-04.txt In-reply-to: Your message of Wed, 23 Jun 1999 07:52:52 PDT. Date: Wed, 23 Jun 1999 13:29:04 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > the nWord and nSkip stuff seems to add complexity to the protocol and hence > the code. it can not break-even until there are more than 96 qtypes, and > there are currently only four. so this all seems to be an escape for user- > defined etc. qtypes. is this *really* worth the complexity? It breaks even at the first non-standards-track Qtype. Is it worth it? OK, that question is now on the floor. > reachable, it may be useful to create a proxy responder for a group > in fact, it would seem to be specifically precluded by [...] OK, that's two. Change to: 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. > in 5.4. Node Addresses > there seems to be no way to indicate that the reply set of addresses is > incomplete for reasons other than space, e.g. security through obscurity. Do those who want to lie by omission want to draw attention to the fact? I could change " for space reasons" to ", for example, for space reasons" but I'd rather have the Querier able to decide cleanly whether to start probing interface-by-interface if it wants to build a complete list. > in 5.4.A, i am having trouble parsing the plurality of the last part of > > If 0, only those addresses are requested which belong to the interface > (or any one interface) which has the Subject Address. It's supposed to be saying that if the A flag is zero, the Querier wants only addresses belong to the interface that has the subject address, but if there's more than one such interface, answer about any one of them. Can there be more than one? Yes. Is this the most useful thing to do if there is more than one? Maybe. Another choice would be to answer about all such interfaces. 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 Jun 23 17:59:37 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA07204 for ipng-dist; Wed, 23 Jun 1999 17:56:13 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07197 for ; Wed, 23 Jun 1999 17:56:04 -0700 (PDT) From: Sonum_Mathur@3com.com 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 RAA17051 for ; Wed, 23 Jun 1999 17:56:05 -0700 (PDT) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA16512 for ; Wed, 23 Jun 1999 17:56:05 -0700 (PDT) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id RAA11119 for ; Wed, 23 Jun 1999 17:56:04 -0700 (PDT) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id RAA24954 for ; Wed, 23 Jun 1999 17:56:04 -0700 (PDT) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id 8825679A.00051E9F ; Wed, 23 Jun 1999 17:55:55 -0700 X-Lotus-FromDomain: 3COM To: ipng@sunroof.eng.sun.com Message-ID: <8825679A.00051C8F.00@hqoutbound.ops.3com.com> Date: Wed, 23 Jun 1999 17:55:50 -0700 Subject: Installing inet6-apps on Linux Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am trying to install my Linux machine (Red Hat 6.0 with Kernel 2.2.5) as an IPv6 host. For that, I have downlaoded inet6-apps ver. 0.35 from ftp.inner.net:/pub/ipv6/inet6-apps-0.35.tar.gz. But the source codes of various utilities like finger, ping etc. are not compiling and giving errors. Most of them are giving problems related to header files in /usr/include. If anyone has installed inet6-apps on Linux, please help me out with this - were you able to successfully compile the downloaded codes for utilities like finger, ping. ftp etc. -- Sonum -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 23 18:26:18 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA07279 for ipng-dist; Wed, 23 Jun 1999 18:22:59 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA07272 for ; Wed, 23 Jun 1999 18:22:50 -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 SAA01997 for ; Wed, 23 Jun 1999 18:22:51 -0700 (PDT) Received: from isrv3.pa.vix.com (isrv3.pa.vix.com [204.152.184.182]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA28297 for ; Wed, 23 Jun 1999 18:22:51 -0700 (PDT) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by isrv3.pa.vix.com (8.9.1/8.9.1) via ESMTP id SAA23453; Wed, 23 Jun 1999 18:22:50 -0700 (PDT) env-from (Bob_Halley@iengines.net) Received: from bb.rc.vix.com (localhost [127.0.0.1]) by bb.rc.vix.com (8.9.1/8.9.1) via ESMTP id SAA26902; Wed, 23 Jun 1999 18:22:49 -0700 (PDT) env-from (Bob_Halley@iengines.net) Message-Id: <199906240122.SAA26902@bb.rc.vix.com> To: "Matt Crawford" cc: ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-Reply-To: Message from "Matt Crawford" of "Tue, 22 Jun 1999 11:46:16 CDT." <199906221646.LAA00242@gungnir.fnal.gov> Date: Wed, 23 Jun 1999 18:22:49 -0700 From: Bob Halley Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The rules for A6 processing in the server specify that A and AAAA > are returned as additional data. So requesting A6 from an A6-aware > server which holds no A6 records won't waste a round-trip. This is only true if the A6-aware server is authoritative for the name being queried, or if the server is nonauthoritative and the data is cached. Because the A and AAAA records are additional data, a nonauthoritative server will not recurse to retrieve them. Some additional clarification in section 4.1.2 might be helpful, since doing additional section processing when there are no records of the desired type is new. > Applications or libraries implementing the function of looking up > IPv6 addresses by means of either A6 or AAAA records MUST be > configurable to operate in at least the following modes: > requesting A6 records before AAAA, AAAA before A6, and A6 only. > The default mode SHOULD be to request A6 before AAAA. This sounds reasonable to me, except that I propose that the default be "A6 only". I prefer this default because this is where we want to be after the transition is over. If we use some other default, then after the transition period there are two options: People have to specify "A6 only" in their config files to get the desired post-transition behavior. The application/library default must change. Having to explicitly specify "A6 only" in config files after the transition period would be annoying, since it is the desired default behavior. Changing the application/library default is something I'd like to avoid, since it changes the meaning of configuration files that people have in production, perhaps breaking things. /Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Jun 24 04:04:22 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA07636 for ipng-dist; Thu, 24 Jun 1999 04:01:55 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07622 for ; Thu, 24 Jun 1999 04:01:43 -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 EAA12909 for ; Thu, 24 Jun 1999 04:01:43 -0700 (PDT) Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA08032 for ; Thu, 24 Jun 1999 04:01:42 -0700 (PDT) Received: from newton.ebina.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id UAA26627; Thu, 24 Jun 1999 20:13:42 +0900 (JST) Received: from gordon.ebina.hitachi.co.jp ([172.16.110.9]) by newton.ebina.hitachi.co.jp (8.9.0/3.7W-EBINA) with SMTP id UAA04196; Thu, 24 Jun 1999 20:01:41 +0900 (JST) Message-Id: <199906241101.UAA04196@newton.ebina.hitachi.co.jp> X-Sender: tsuchi@gpc.ebina.hitachi.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32) Date: Thu, 24 Jun 1999 20:02:33 +0900 To: ipng@sunroof.eng.sun.com From: Kazuaki Tsuchiya Subject: "Toolnet6", the transition tool based on BIS. Cc: tsuchi@ebina.hitachi.co.jp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPv6 Folks, We are happy to announce that new version of our transition tool is available for free from the following web site: http://www.hitachi.co.jp/Prod/comp/ network/pexv6-e.htm It's a NIC driver, which works as an IPv4/IPv6 self-translator on your Windows(R) PC and enables IPv6 communication using existing IPv4 applications. That is, it provides connectivity of both IPv4 and IPv6 for your Windows(R) PC. The new version can work with EtherLinkIIIs, in addition to NE2000- compatible Ethernet adapters' version. Let's enjoy IPv6 now on your PC! Thanks. -- Kazuaki Tsuchiya, Hitachi. ------------------------------------------------------- Kazuaki Tsuchiya (mailto:tsuchi@ebina.hitachi.co.jp) Hitachi,Ltd. Enterprise Server Division Phone: +81-462-35-8268(Dial-in) Fax: +81-462-35-8324 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 04:50:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA07770 for ipng-dist; Thu, 24 Jun 1999 04:48:04 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07763 for ; Thu, 24 Jun 1999 04:47:54 -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 EAA23524 for ; Thu, 24 Jun 1999 04:47:54 -0700 (PDT) Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA24658 for ; Thu, 24 Jun 1999 04:47:53 -0700 (PDT) Received: from newton.ebina.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id UAA04241; Thu, 24 Jun 1999 20:59:54 +0900 (JST) Received: from gordon.ebina.hitachi.co.jp ([172.16.110.9]) by newton.ebina.hitachi.co.jp (8.9.0/3.7W-EBINA) with SMTP id UAA05939 for ; Thu, 24 Jun 1999 20:47:52 +0900 (JST) Message-Id: <199906241147.UAA05939@newton.ebina.hitachi.co.jp> X-Sender: tsuchi@gpc.ebina.hitachi.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32) Date: Thu, 24 Jun 1999 20:48:47 +0900 To: ipng@sunroof.eng.sun.com From: Kazuaki Tsuchiya Subject: Re: "Toolnet6", the transition tool based on BIS. In-Reply-To: <199906241101.UAA04196@newton.ebina.hitachi.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 20:02 99/06/24 +0900, Kazuaki Tsuchiya wrote: > IPv6 Folks, > > We are happy to announce that new version of our transition tool > is available for free from the following web site: > http://www.hitachi.co.jp/Prod/comp/ network/pexv6-e.htm > Sorry for my mistake. Correct URL is: http://www.hitachi.co.jp/Prod/comp/network/pexv6-e.htm -- Kazuaki Tsuchiya. ------------------------------------------------------- Kazuaki Tsuchiya (mailto:tsuchi@ebina.hitachi.co.jp) Hitachi,Ltd. Enterprise Server Division Phone: +81-462-35-8268(Dial-in) Fax: +81-462-35-8324 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 04:53:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA07801 for ipng-dist; Thu, 24 Jun 1999 04:52:12 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07794 for ; Thu, 24 Jun 1999 04:52:03 -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 EAA23671 for ; Thu, 24 Jun 1999 04:52:03 -0700 (PDT) Received: from turbot.pdc.kth.se (turbot.pdc.kth.se [130.237.221.42]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26192 for ; Thu, 24 Jun 1999 04:52:01 -0700 (PDT) Received: (from d95-mah@localhost) by turbot.pdc.kth.se (8.8.7/8.8.7) id NAA12719; Thu, 24 Jun 1999 13:51:43 +0200 (MET DST) To: Richard Humpleman - SISA Cc: Richard Draves , "'Peter Tattam'" , ipng@sunroof.eng.sun.com, mikezin@microsoft.com Subject: Re: Reality check (was Re: Other mechanisms for DNS server discov ery.) References: <13881A0EBCBBD211954C00A0C9E5FF576A3314@polaris-xch.ssi.samsung.com> From: Magnus Ahltorp Content-Type: text/plain; charset="iso-8859-1" Content-Language: en Date: 24 Jun 1999 13:51:43 +0200 In-Reply-To: Richard Humpleman - SISA's message of "Wed, 23 Jun 1999 09:50:39 -0700" Message-ID: Lines: 9 X-Mailer: Gnus v5.6.45/Emacs 19.34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > User control via a Browser and a hierarchy of Web pages actually requires > no DNS as the Names are an addressing convenience that can be replaced by > the regeneration of the higher level Web pages using IP addresses in the > hypertext links to get to the lower levels. DNS adds an indirection layer, which is not only useful for human interaction, but also for mobility and temporary address assignments. /Magnus -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 05:11:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA07832 for ipng-dist; Thu, 24 Jun 1999 05:08:32 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07825 for ; Thu, 24 Jun 1999 05:08:23 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA04444 for ; Thu, 24 Jun 1999 05:08:23 -0700 (PDT) Received: from dfw-ix16.ix.netcom.com (dfw-ix16.ix.netcom.com [206.214.98.16]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA22612 for ; Thu, 24 Jun 1999 06:08:18 -0600 (MDT) Received: (from smap@localhost) by dfw-ix16.ix.netcom.com (8.8.4/8.8.4) id HAA29716; Thu, 24 Jun 1999 07:07:44 -0500 (CDT) Received: from dal-tx10-26.ix.netcom.com(207.94.124.90) by dfw-ix16.ix.netcom.com via smap (V1.3) id rma029708; Thu Jun 24 07:07:20 1999 Message-ID: <3771B197.F9C87B43@ix.netcom.com> Date: Thu, 24 Jun 1999 05:18:32 +0100 From: Jeff Williams Organization: INEG. Inc. (Spokesman INEGroup) X-Mailer: Mozilla 4.08 [en] (Win16; I) MIME-Version: 1.0 To: Kazuaki Tsuchiya CC: ipng@sunroof.eng.sun.com Subject: Re: "Toolnet6", the transition tool based on BIS. References: <199906241147.UAA05939@newton.ebina.hitachi.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kaz and all, Does it come with source code? Sounds good! >;) Kazuaki Tsuchiya wrote: > At 20:02 99/06/24 +0900, Kazuaki Tsuchiya wrote: > > IPv6 Folks, > > > > We are happy to announce that new version of our transition tool > > is available for free from the following web site: > > http://www.hitachi.co.jp/Prod/comp/ network/pexv6-e.htm > > > > Sorry for my mistake. Correct URL is: > http://www.hitachi.co.jp/Prod/comp/network/pexv6-e.htm > > -- Kazuaki Tsuchiya. > > ------------------------------------------------------- > Kazuaki Tsuchiya (mailto:tsuchi@ebina.hitachi.co.jp) > Hitachi,Ltd. Enterprise Server Division > Phone: +81-462-35-8268(Dial-in) Fax: +81-462-35-8324 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Regards, -- Jeffrey A. Williams CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng. Information Network Eng. Group. INEG. INC. E-Mail jwkckid1@ix.netcom.com Contact Number: 972-447-1894 Address: 5 East Kirkwood Blvd. Grapevine Texas 75208 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 06:02:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA07887 for ipng-dist; Thu, 24 Jun 1999 05:59:10 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA07880 for ; Thu, 24 Jun 1999 05:59:01 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id FAA06800 for ; Thu, 24 Jun 1999 05:59:00 -0700 (PDT) Received: from hitpro.hitachi.co.jp (hitpro.hitachi.co.jp [133.145.224.7]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02109 for ; Thu, 24 Jun 1999 06:58:59 -0600 (MDT) Received: from newton.ebina.hitachi.co.jp by hitpro.hitachi.co.jp (8.9.3/3.7W-hitpro) id WAA14073; Thu, 24 Jun 1999 22:11:01 +0900 (JST) Received: from gordon.ebina.hitachi.co.jp ([172.16.110.9]) by newton.ebina.hitachi.co.jp (8.9.0/3.7W-EBINA) with SMTP id VAA08601; Thu, 24 Jun 1999 21:58:58 +0900 (JST) Message-Id: <199906241258.VAA08601@newton.ebina.hitachi.co.jp> X-Sender: tsuchi@gpc.ebina.hitachi.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3-J (32) Date: Thu, 24 Jun 1999 21:59:51 +0900 To: Jeff Williams From: Kazuaki Tsuchiya Subject: Re: "Toolnet6", the transition tool based on BIS. Cc: ipng@sunroof.eng.sun.com, tsuchi@ebina.hitachi.co.jp In-Reply-To: <3771B197.F9C87B43@ix.netcom.com> References: <199906241147.UAA05939@newton.ebina.hitachi.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Jeff, Sorry, but it's only binary kit now. Thanks. -- Kazuaki Tsuchiya. At 05:18 99/06/24 +0100, Jeff Williams wrote: > Kaz and all, > > Does it come with source code? Sounds good! >;) > > Kazuaki Tsuchiya wrote: > > > At 20:02 99/06/24 +0900, Kazuaki Tsuchiya wrote: > > > IPv6 Folks, > > > > > > We are happy to announce that new version of our transition tool > > > is available for free from the following web site: > > > http://www.hitachi.co.jp/Prod/comp/network/pexv6-e.htm > > > > > > > Sorry for my mistake. Correct URL is: > > http://www.hitachi.co.jp/Prod/comp/network/pexv6-e.htm > > ------------------------------------------------------- Kazuaki Tsuchiya (mailto:tsuchi@ebina.hitachi.co.jp) Hitachi,Ltd. Enterprise Server Division Phone: +81-462-35-8268(Dial-in) Fax: +81-462-35-8324 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 24 10:58:58 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA08452 for ipng-dist; Thu, 24 Jun 1999 10:53:25 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08445 for ; Thu, 24 Jun 1999 10:53:16 -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 KAA14820 for ; Thu, 24 Jun 1999 10:53:16 -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 KAA28976 for ; Thu, 24 Jun 1999 10:53:14 -0700 (PDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA38944 for ; Thu, 24 Jun 1999 19:53:12 +0200 Received: from rennes.enst-bretagne.fr (albemuth.rennes.enst-bretagne.fr [193.52.74.199]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA13092 for ; Thu, 24 Jun 1999 19:53:10 +0200 (MET DST) Message-ID: <37727086.BD118ABE@rennes.enst-bretagne.fr> Date: Thu, 24 Jun 1999 19:53:11 +0200 From: Hossam Afifi X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: IPv6 for mobile telephony Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A draft has been sent to the internet draft secretary on IPv6 in Mobile Telephony the document is also available from http://www.rennes.enst-bretagne.fr/~afifi/e164ipv6.asc your comments are welcomed. Hossam -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 25 12:19:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA09854 for ipng-dist; Fri, 25 Jun 1999 11:56:22 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09847 for ; Fri, 25 Jun 1999 11:56:11 -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 LAA21879 for ; Fri, 25 Jun 1999 11:56:10 -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 LAA04618 for ; Fri, 25 Jun 1999 11:56:09 -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 OAA00737; Fri, 25 Jun 1999 14:56:04 -0400 (EDT) Message-Id: <199906251856.OAA00737@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-hbh-ext-csi-01.txt Date: Fri, 25 Jun 1999 14:56:03 -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 : Connection/Link Status Investigation (CSI) for IPv6 IPv6 Hop-by-Hop option and ICMPv6 messages Extension Author(s) : H. Kitamura Filename : draft-ietf-ipngwg-hbh-ext-csi-01.txt Pages : 31 Date : 24-Jun-99 This document proposes a new mechanism whereby status information is collected for nodes along both the outgoing and incoming paths. This mechanism is called 'Connection/Link Status Investigation (CSI).' In order to realize the CSI mechanism, one new IPv6 Hop-by-Hop option and three new ICMPv6 messages are proposed as extensions. The CSI mechanism is as simple as the 'ping' mechanism and is also efficient, because ideally the status information of the nodes is collected with a pair of 'request/reply' ICMPv6 messages. By using the CSI mechanism, more efficient and reliable 'traceroute' type functions can be realized. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-hbh-ext-csi-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-hbh-ext-csi-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-hbh-ext-csi-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990624134308.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-hbh-ext-csi-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-hbh-ext-csi-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990624134308.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 Sat Jun 26 03:25:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA10512 for ipng-dist; Sat, 26 Jun 1999 02:29:33 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10505 for ; Sat, 26 Jun 1999 02:29:19 -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 CAA07812 for ; Sat, 26 Jun 1999 02:29:18 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA16316 for ; Sat, 26 Jun 1999 03:29:18 -0600 (MDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id TAA11874; Sat, 26 Jun 1999 19:29:07 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Sat, 26 Jun 1999 19:29:07 +1000 (EST) From: Peter Tattam To: IPv6 Deployment List , IPNG Mailing List Subject: FTP broken for API level protocol translators?? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Although FTP can get through IPv4 NAT's using passive mode, I believe there may be a stumbling block for IPv6 NATs as the FTP commands are different. IPv6 FTP server -> translator -> IPv4 FTP client. Anyone got any ideas on how this could be dealt with without rewriting the FTP command TCP session. Peter -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 07:11:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA10598 for ipng-dist; Sat, 26 Jun 1999 06:17:43 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10591 for ; Sat, 26 Jun 1999 06:17:23 -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 GAA25163 for ; Sat, 26 Jun 1999 06:17: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 GAA09878 for ; Sat, 26 Jun 1999 06:17:22 -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 WAA21054; Sat, 26 Jun 1999 22:17:05 +0900 (JST) To: Peter Tattam cc: IPv6 Deployment List , IPNG Mailing List In-reply-to: peter's message of Sat, 26 Jun 1999 19:29:07 +1000. 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: FTP broken for API level protocol translators?? From: itojun@iijlab.net Date: Sat, 26 Jun 1999 22:17:05 +0900 Message-ID: <21052.930403025@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Although FTP can get through IPv4 NAT's using passive mode, I believe there may >be a stumbling block for IPv6 NATs as the FTP commands are different. > IPv6 FTP server -> translator -> IPv4 FTP client. >Anyone got any ideas on how this could be dealt with without rewriting the FTP >command TCP session. Among the commands for requesting data connection, EPSV (RFC2428) is the only one which never transmit address in control TCP stream. So, only EPSV has a good chance to fit your requirement. However, most of IPv4 ftp client does not EPSV. For translator you may need to remap tcp port # anyway, so even if IPv4 client supports EPSV you may need a rewrite in control TCP stream. SUMMARY: you need to rewrite control TCP stream anyway. 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 Sat Jun 26 07:33:45 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA10608 for ipng-dist; Sat, 26 Jun 1999 06:40:55 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10601 for ; Sat, 26 Jun 1999 06:40:40 -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 GAA13926 for ; Sat, 26 Jun 1999 06:40:39 -0700 (PDT) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA06177 for ; Sat, 26 Jun 1999 07:40:39 -0600 (MDT) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id PAA03083; Sat, 26 Jun 1999 15:40:37 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [193.51.193.144]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id PAA19330; Sat, 26 Jun 1999 15:40:35 +0200 (MET DST) Message-Id: <199906261340.PAA19330@givry.inria.fr> From: Francis Dupont To: Peter Tattam cc: IPv6 Deployment List , IPNG Mailing List Subject: Re: FTP broken for API level protocol translators?? In-reply-to: Your message of Sat, 26 Jun 1999 19:29:07 +1000. Date: Sat, 26 Jun 1999 15:40:35 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Although FTP can get through IPv4 NAT's using passive mode, I believe there may be a stumbling block for IPv6 NATs as the FTP commands are different. IPv6 FTP server -> translator -> IPv4 FTP client. Anyone got any ideas on how this could be dealt with without rewriting the FTP command TCP session. => the best solution is to use the Simple PORT command in passive mode. I think Craig (author of I-Ds about this) will answer soon. Francis.Dupont@inria.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 Jun 26 13:23:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA10745 for ipng-dist; Sat, 26 Jun 1999 12:32:27 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA10738 for ; Sat, 26 Jun 1999 12:32:04 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA21565 for ; Sat, 26 Jun 1999 12:32:03 -0700 (PDT) Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11548 for ; Sat, 26 Jun 1999 13:32:03 -0600 (MDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA07211; Sat, 26 Jun 1999 12:25:10 -0700 (PDT) Received: from kc.livingston.com ([149.198.1.4]) by server.livingston.com (8.8.5/8.6.9) with ESMTP id MAA04117; Sat, 26 Jun 1999 12:31:22 -0700 (PDT) Received: (from suresh@localhost) by kc.livingston.com (8.8.8+Sun/8.8.8) id MAA24822; Sat, 26 Jun 1999 12:31:22 -0700 (PDT) From: Pyda Srisuresh Message-Id: <199906261931.MAA24822@kc.livingston.com> Subject: Re: FTP broken for API level protocol translators?? To: peter@jazz-1.trumpet.com.au (Peter Tattam) Date: Sat, 26 Jun 1999 12:31:21 -0700 (PDT) Cc: deployment@ipv6.org, ipng@sunroof.eng.sun.com In-Reply-To: from "Peter Tattam" at Jun 26, 99 07:29:07 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk , section 6 covers this. Note, It may be a day or two before this draft is announced. cheers, suresh > > Although FTP can get through IPv4 NAT's using passive mode, I believe there may > be a stumbling block for IPv6 NATs as the FTP commands are different. > > IPv6 FTP server -> translator -> IPv4 FTP client. > > Anyone got any ideas on how this could be dealt with without rewriting the FTP > command TCP session. > > Peter > > > -- > Peter R. Tattam peter@trumpet.com > Managing Director, Trumpet Software International Pty Ltd > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sat Jun 26 23:01:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA10854 for ipng-dist; Sat, 26 Jun 1999 22:11:35 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA10847 for ; Sat, 26 Jun 1999 22:11:20 -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 WAA20437 for ; Sat, 26 Jun 1999 22:11:10 -0700 (PDT) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA00010 for ; Sat, 26 Jun 1999 22:11:09 -0700 (PDT) Received: from localhost (peter@localhost) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id PAA28687; Sun, 27 Jun 1999 15:10:13 +1000 (EST) (envelope-from peter@jazz-1.trumpet.com.au) Date: Sun, 27 Jun 1999 15:10:13 +1000 (EST) From: Peter Tattam To: Pyda Srisuresh cc: deployment@ipv6.org, ipng@sunroof.eng.sun.com Subject: Re: FTP broken for API level protocol translators?? In-Reply-To: <199906261931.MAA24822@kc.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hmm. Looks like intercepting the command stream is the only way. Guess I'll have to monitor send() call for the "PASV" command and take action there, presumably converting it to an EPSV. Then I would need to translate the response code back into the translated IPv4 address. I think this could be done if one assumed that the command/response calls were atomic. There are complications on the recv() call as it could potentially be called with MSG_PEEK and the call may only return a partial result. The send() call would typically be atomic so not too much of a problem. Is this a reasonable assessment? Also, is there any way that existing FTP servers could be modified to cope with translation without having to rewrite the command stream. At this stage, this could be beneficial as the number of deployed IPv6 FTP servers would be relatively small making the process easy. The process would have been trivial had the designers of FTP stuck with a symbolic method of passing the listened to address.... i.e. 227 Entering Passive Mode (203.5.119.51,4586) Instead of 227 Entering Passive Mode (203,5,119,51,17,234) as it would have allowed us to replace the symbolic IPv4 address with a IPv6 address. Then the client would use inet_ntoa to translate it into machine form which would have been easy for an API level translator to translate from an Ipv6 symbolic address to an IPv4 symbolic address. But alas, the deployment of IPv4 FTP clients is far too widespread to change things there. I have an idea.... One possibility that I can think of is that somehow the IPv6 FTP can determine that there is an API translator behind the the FTP session. This information could be conveyed via some out of band mechanism - perhaps a TCP option that gets passed with the command connection that says what the internally translated IPv4 address is. Another possibility is that an ICMPv6 probe or IPv6 option could be sent to the peer which would return whether this particular connection was being used by a non IPv6 aware client. In fact, this technique may have wider application than FTP, and could indeed be used for any protocol that passes IP address information as part of the session. It could also untangle the mess that translators make in this process. My money is on the TCP option. The information could be passed at connection startup and then obtained via the getsockopt() or ioctl() calls. Peter On Sat, 26 Jun 1999, Pyda Srisuresh wrote: > > , section 6 covers this. > Note, It may be a day or two before this draft is announced. > > cheers, > suresh > > > > > Although FTP can get through IPv4 NAT's using passive mode, I believe there may > > be a stumbling block for IPv6 NATs as the FTP commands are different. > > > > IPv6 FTP server -> translator -> IPv4 FTP client. > > > > Anyone got any ideas on how this could be dealt with without rewriting the FTP > > command TCP session. > > > > Peter > > > > > > -- > > Peter R. Tattam peter@trumpet.com > > Managing Director, Trumpet Software International Pty Ltd > > Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 > -------------------------------------------------------------------- > -- Peter R. Tattam peter@trumpet.com Managing Director, Trumpet Software International Pty Ltd Hobart, Australia, Ph. +61-3-6245-0220, Fax +61-3-62450210 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 26 23:13:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA10866 for ipng-dist; Sat, 26 Jun 1999 22:23:01 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA10859 for ; Sat, 26 Jun 1999 22:22:48 -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 WAA05514 for ; Sat, 26 Jun 1999 22:22:48 -0700 (PDT) Received: from inner.net (avarice.inner.net [199.33.248.2]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA01083 for ; Sat, 26 Jun 1999 22:22:47 -0700 (PDT) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id FAA18043; Sun, 27 Jun 1999 05:14:43 GMT Message-Id: <199906270514.FAA18043@inner.net> To: Peter Tattam cc: ipng@sunroof.eng.sun.com Subject: Re: FTP broken for API level protocol translators?? In-reply-to: Your message of "Sun, 27 Jun 1999 15:10:13 +1000." X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Sun, 27 Jun 1999 01:22:13 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , yo u write: >One possibility that I can think of is that somehow the IPv6 FTP can determine >that there is an API translator behind the the FTP session. In the general case, this is not possible. Consider a path with multiple protocol translations back and forth, and maybe some NATs in the IPv4 path. Sick, twisted, yet something that very weill might happen. So there's no way for the ends to know completely what protocol(s) might be running in the middle, and not a whole lot of way generally for them to tell what protocol(s) are available at the other end. One possibly more practical solution is to try to get some of the major FTP daemons supporting EPSV. A large portion of the anonymous FTP servers in the world run a small number of different daemons (wu, proftpd, etc.), so you could reach a fairly reasonable deployment critical mass fast. This wouldn't mean you wouldn't have to make your protocol translator do the old search and replace, but, together with the EPSV ALL, you can at least be able to quickly determine for most connections that you don't actually have to do any replaces (and then your implementation can fast-path the connection(s) for the rest of their lifetime). -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 05:31:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA11609 for ipng-dist; Mon, 28 Jun 1999 02:44:17 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11602 for ; Mon, 28 Jun 1999 02:42:50 -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 CAA06499 for ; Mon, 28 Jun 1999 02:42:10 -0700 (PDT) Received: from monza.broadswitch.se ([195.178.164.73]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA08882 for ; Mon, 28 Jun 1999 02:42:08 -0700 (PDT) Received: by MONZA with Internet Mail Service (5.5.2448.0) id ; Mon, 28 Jun 1999 11:42:02 +0200 Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD08DB12@MONZA> From: Thomas Eklund To: "'Hossam Afifi'" , ipng@sunroof.eng.sun.com Cc: "'bound@zk3.dec.com'" Subject: RE: IPv6 for mobile telephony Date: Mon, 28 Jun 1999 11:42:00 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is a lot of confusion in this draft. To me it seams that you try to specify whats already in place in GPRS.... What is the benefit of yor proposal? I dont see it! First of all in sec 2.2. you say that an IPv6 address is current MSC prefix + e.164 number that means that a MSC prefic could only be 8 bits long (128-120) and that would take up a big space of the TLA domain... I would suggest that you set one of the prefix bits in IPv6 to be assigned for the e.164 addressing...: 011 + 5 bits unassigned + 120 bits e.164 addressing. And I think that the AD should consider this! Because that means that the hole telecom world would not need to renumber. Another thing in 3: In GPRS today there is already specified how you connect a DHCP server for address management in GGSN Chapter4: You will NEVER use IPsec over GSM or GPRS due to the overhead! You already have ciphering today over the air and that does not introduce any overhead... This is handeled at layer 2 in GSM/GPRS.... Chapter 5: Does that mean that you suggest to always use dynamic DNS in mobile IP network? Best Regards Thomas Eklund, SwitchCore > -----Original Message----- > From: Hossam Afifi [mailto:Hossam.Afifi@enst-bretagne.fr] > Sent: Thursday, June 24, 1999 7:53 PM > To: ipng@sunroof.eng.sun.com > Subject: IPv6 for mobile telephony > > > > A draft has been sent to the internet draft secretary on > IPv6 in Mobile > Telephony > the document is also available from > http://www.rennes.enst-bretagne.fr/~afifi/e164ipv6.asc > > your comments are welcomed. > > Hossam > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 28 05:32:01 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA11619 for ipng-dist; Mon, 28 Jun 1999 02:52:34 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11612 for ; Mon, 28 Jun 1999 02:52:13 -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 CAA28286 for ; Mon, 28 Jun 1999 02:52:12 -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 DAA02166 for ; Mon, 28 Jun 1999 03:52:06 -0600 (MDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA49224; Mon, 28 Jun 1999 11:51:57 +0200 Received: from rennes.enst-bretagne.fr (ordimini.rennes.enst-bretagne.fr [193.52.74.15]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA07850; Mon, 28 Jun 1999 11:51:56 +0200 (MET DST) Message-ID: <377745BD.A6844354@rennes.enst-bretagne.fr> Date: Mon, 28 Jun 1999 11:51:57 +0200 From: Hossam Afifi X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Eklund , bound@zk3.dec.com, Laurent.Toutain@enst-bretagne.fr, ipng@sunroof.eng.sun.com Subject: Re: IPv6 for mobile telephony References: <45AFD48D077ED211BB4700A0C9DCE8FD08DB12@MONZA> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you for your comments The drafts was written in a hurry to meet with the ietf submission deadline. What we propose for addressing is the use of a 32 bit long prefix identifying the MSC and the rest holding the user MS-ISDN number to keep track of his mobility through different MSCs. In what concerns the security, we would like to be able de disable any packets from outside the GSM network if the user wishes so. So we suggest a label that would be put in every packet to filter the packets that are not welcomed and to protect your air resources. For the differences with GPRS we say that you should not have a separate entity called GGSN because it will add complexity to the system and it will need updates between MSC and GGSN. We would like to modify the CC and MM messages to include all that without the need of encapsulation protocols as described in GPRS. Hossam -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 06:09:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA11663 for ipng-dist; Mon, 28 Jun 1999 04:27:06 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11656 for ; Mon, 28 Jun 1999 04:26:47 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id EAA24864 for ; Mon, 28 Jun 1999 04:26:47 -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 FAA14168 for ; Mon, 28 Jun 1999 05:26:46 -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 HAA25400; Mon, 28 Jun 1999 07:26:42 -0400 (EDT) Message-Id: <199906281126.HAA25400@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-url-literal-01.txt Date: Mon, 28 Jun 1999 07:26:42 -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 : Preferred Format for Literal IPv6 Addresses in URL's Author(s) : B. Carpenter, B. Hinden Filename : draft-ietf-ipngwg-url-literal-01.txt Pages : 3 Date : 24-Jun-99 This document defines the preferred format for literal IPv6 Addresses in URL's for implementation in World Wide Web browsers. This format has been implemented in the IPv6 versions of several widely deployed browsers including Microsoft Internet Explorer, Mozilla, and Lynx. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-url-literal-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-url-literal-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-url-literal-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990624134323.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-url-literal-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-url-literal-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990624134323.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 28 08:06:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA11789 for ipng-dist; Mon, 28 Jun 1999 06:14:44 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11778 for ; Mon, 28 Jun 1999 06:14: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 GAA05747 for ; Mon, 28 Jun 1999 06:14:16 -0700 (PDT) Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id GAA18425 for ; Mon, 28 Jun 1999 06:14:15 -0700 (PDT) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Mon, 28 Jun 1999 14:13:36 +0100 Date: Mon, 28 Jun 1999 14:13:54 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Thomas Eklund cc: "'Hossam Afifi'" , ipng@sunroof.eng.sun.com, "'bound@zk3.dec.com'" Subject: RE: IPv6 for mobile telephony In-Reply-To: <45AFD48D077ED211BB4700A0C9DCE8FD08DB12@MONZA> Message-ID: Organization: speaking for none X-URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 28 Jun 1999, Thomas Eklund wrote: > Chapter4: > You will NEVER use IPsec over GSM or GPRS due to the overhead! You already > have ciphering today over the air and that does not introduce any > overhead... This is handeled at layer 2 in GSM/GPRS.... Er, what overhead? The only real security is end-to-end security. Air-interface-only encryption provided by someone else isn't security. How can you claim that ciphering over the air not introduce any overhead, when you claim that IPsec does? IPSec _will_ be increasingly used over GSM and GPRS. Any drafts in this area should address this. L. If you want secure voice communications over GSM, you might buy two of these mobile handsets: http://www.crypto.ch/product/hc2000_e.html#end > > -----Original Message----- > > From: Hossam Afifi [mailto:Hossam.Afifi@enst-bretagne.fr] > > Sent: Thursday, June 24, 1999 7:53 PM > > To: ipng@sunroof.eng.sun.com > > Subject: IPv6 for mobile telephony > > > > > > > > A draft has been sent to the internet draft secretary on > > IPv6 in Mobile > > Telephony > > the document is also available from > > http://www.rennes.enst-bretagne.fr/~afifi/e164ipv6.asc > > > > your comments are welcomed. > > > > Hossam PGP -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 08:33:14 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA11821 for ipng-dist; Mon, 28 Jun 1999 06:56:02 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA11814 for ; Mon, 28 Jun 1999 06:54:39 -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 GAA16425 for ; Mon, 28 Jun 1999 06:53:58 -0700 (PDT) Received: from monza.broadswitch.se (monza.broadswitch.se [195.178.164.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12361 for ; Mon, 28 Jun 1999 07:53:56 -0600 (MDT) Received: by MONZA with Internet Mail Service (5.5.2448.0) id ; Mon, 28 Jun 1999 15:53:49 +0200 Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD08DB16@MONZA> From: Thomas Eklund To: "'Lloyd Wood'" , Thomas Eklund Cc: "'Hossam Afifi'" , ipng@sunroof.eng.sun.com, "'bound@zk3.dec.com'" Subject: RE: IPv6 for mobile telephony Date: Mon, 28 Jun 1999 15:53:48 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Lloyd Wood [mailto:L.Wood@surrey.ac.uk] > Sent: Monday, June 28, 1999 3:14 PM > To: Thomas Eklund > Cc: 'Hossam Afifi'; ipng@sunroof.eng.sun.com; 'bound@zk3.dec.com' > Subject: RE: IPv6 for mobile telephony > > > On Mon, 28 Jun 1999, Thomas Eklund wrote: > > > Chapter4: > > You will NEVER use IPsec over GSM or GPRS due to the > overhead! You already > > have ciphering today over the air and that does not introduce any > > overhead... This is handeled at layer 2 in GSM/GPRS.... > > Er, what overhead? > > The only real security is end-to-end security. Air-interface-only And I dont argue you on that e-2-e security is the only way but in GSM and GPRS it dont work that way...:-( > encryption provided by someone else isn't security. How can you claim > that ciphering over the air not introduce any overhead, when you claim > that IPsec does? You will never use IPsec for securing the air... Because that is already done at Layer 2 in GSM and the ciphering mechanism used to NOT add any bits compared to IPsec that at least add a ESP or AH header... In other words if you use IP as switching mechanism you will never have it over the air... If you want e-2-e security for your app that is a totally different question... And not part of the GSM system... > > IPSec _will_ be increasingly used over GSM and GPRS. Any drafts in > this area should address this. What do you actually mean here... In GPRS and GSM there is NO way a user can have e-2-e security! The security offered is for securing the network access over radio and securing the handovers in a MSC area... And if you use IP and IP sec over GPRS/GSM I dont care,but the thing is you dont use it in GPRSand GSM over the radio,you CAN use it in GPRS between SGSN:s (i.e between different Radio access networks) in the GPRS Tunnel Protocol (GTP) which is similar to mobileIP but on L2. But GPRS still uses GSM ciphering over the air and NOT IPsec... Regards Thomas Eklund, SwitchCore Perhaps a clarifying picture: GMSC GGSN | | MSC SGSN | | (Voice)|____ _______|(packet) | | BSC ______ |___________ | | BS BS | | GSM terminal GPRS terminal This is how it looks like in GSM and in GPRS, The thing is that they use the same radio access network (i.e. GSM) and GPRS allocates timeslots from GSM for datatraffic... But they still use the same radio access networks and they do not use ipsec between the terminals and MSC, SGSN... > > L. > > > If you want secure voice communications over GSM, you might buy two of > these mobile handsets: http://www.crypto.ch/product/hc2000_e.html#end If you have security in the handset its a different thing and its up to the user what kind of security he/she wants... > > > > -----Original Message----- > > > From: Hossam Afifi [mailto:Hossam.Afifi@enst-bretagne.fr] > > > Sent: Thursday, June 24, 1999 7:53 PM > > > To: ipng@sunroof.eng.sun.com > > > Subject: IPv6 for mobile telephony > > > > > > > > > > > > A draft has been sent to the internet draft secretary on > > > IPv6 in Mobile > > > Telephony > > > the document is also available from > > > http://www.rennes.enst-bretagne.fr/~afifi/e164ipv6.asc > > > > > > your comments are welcomed. > > > > > > Hossam > > PGP > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 08:37:35 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA11834 for ipng-dist; Mon, 28 Jun 1999 07:05:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11825 for ; Mon, 28 Jun 1999 07:03:49 -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 HAA17082 for ; Mon, 28 Jun 1999 07:03:04 -0700 (PDT) Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id IAA14967 for ; Mon, 28 Jun 1999 08:03:02 -0600 (MDT) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Mon, 28 Jun 1999 15:02:20 +0100 Date: Mon, 28 Jun 1999 15:02:49 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: Thomas Eklund cc: "'Hossam Afifi'" , ipng@sunroof.eng.sun.com, "'bound@zk3.dec.com'" Subject: RE: IPv6 for mobile telephony In-Reply-To: <45AFD48D077ED211BB4700A0C9DCE8FD08DB16@MONZA> Message-ID: Organization: speaking for none X-URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 28 Jun 1999, Thomas Eklund wrote: > Lloyd Wood wrote: > > > > On Mon, 28 Jun 1999, Thomas Eklund wrote: > > > > > Chapter4: > > > You will NEVER use IPsec over GSM or GPRS due to the > > overhead! You already > > > have ciphering today over the air and that does not introduce any > > > overhead... This is handeled at layer 2 in GSM/GPRS.... > > > > Er, what overhead? > > > > The only real security is end-to-end security. Air-interface-only > And I dont argue you on that e-2-e security is the only way but in GSM and > GPRS it dont work that way...:-( > > > encryption provided by someone else isn't security. How can you claim > > that ciphering over the air not introduce any overhead, when you claim > > that IPsec does? > You will never use IPsec for securing the air... Because that is already > done at Layer 2 in GSM and the ciphering mechanism used to NOT add any bits > compared to IPsec that at least add a ESP or AH header... In other words if > you use IP as switching mechanism you will never have it over the air... You will. It will simply be tunnelled within the GSM air security. You can tunnel crypto just as you can tunnel anything else. L. 'over the air' means different things to different people. PGP -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 09:06:58 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA11859 for ipng-dist; Mon, 28 Jun 1999 07:25:35 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11852 for ; Mon, 28 Jun 1999 07:25: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 HAA13041 for ; Mon, 28 Jun 1999 07:25:13 -0700 (PDT) Received: from monza.broadswitch.se (monza.broadswitch.se [195.178.164.73]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA09146 for ; Mon, 28 Jun 1999 07:25:12 -0700 (PDT) Received: by MONZA with Internet Mail Service (5.5.2448.0) id ; Mon, 28 Jun 1999 16:25:10 +0200 Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD08DB18@MONZA> From: Thomas Eklund To: "'Hossam Afifi'" , Thomas Eklund , bound@zk3.dec.com, Laurent.Toutain@enst-bretagne.fr, ipng@sunroof.eng.sun.com Subject: RE: IPv6 for mobile telephony Date: Mon, 28 Jun 1999 16:25:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Hossam Afifi [mailto:Hossam.Afifi@enst-bretagne.fr] > Sent: Monday, June 28, 1999 11:52 AM > To: Thomas Eklund; bound@zk3.dec.com; > Laurent.Toutain@enst-bretagne.fr; > ipng@sunroof.eng.sun.com > Subject: Re: IPv6 for mobile telephony > > > Thank you for your comments > > The drafts was written in a hurry to meet with the ietf > submission deadline. Thats ok. > > What we propose for addressing is the use of a 32 bit long > prefix identifying > the MSC and > the rest holding the user MS-ISDN number to keep track of > his mobility through > different MSCs. So what you are saying is that the MSC will allocate its MCC and MNC from the TLA domain or what? (MCC - Mobile Country Code consists of three digits.cc identifies uniquely the country of the mobile subcriber, MNC - Mobile Network Code consists of two digits for GSM applications. The MNC identifies the home GSM PLMN operator of the mobile subsciber., MSIN - Mobile Subsciber Identification Number identifies the mobile subsciber within a GSM PLMN., NMSI - National Mobile Subscriber Identity consits the Mobile Network Code and the Mobile Subsciber Identification Number.) And the MCC + MNC is 32 bits... And what do you mean with the rest? a MS-ISDN is 120 bits???? That means 32+120 bits.... (You probably mean MSIN that is 80 bits long) I would recommend to allocate a prefix bit from the 3 bits in the address instead... > > In what concerns the security, we would like to be able de > disable any packets > from outside the GSM > network if the user wishes so. So we suggest a label that > would be put in > every packet to filter the > packets that are not welcomed and to protect your air resources. What do you really mean here? Because if you want to protect from evil packets you will set up a firewall filter in the GGSN node entering the packet based GPRS network and not entering circuit switched GSM.. > > > For the differences with GPRS we say that you should not > have a separate > entity called GGSN because What do you mean with say??? Its already there at the GSM operators... You cant just say something and expect the telecom world to follow. They standardize within ETSI, ITU TIA and others and its a long standadization proccess to define a system. And GPRS solve most (practically everything) you suggest... GPRS is also specified to use IPv6 addresses... But what is not there is a nice migration of e.164 addressing into IPv6 address domain in a nice way and I my sugesstion is to allocate a bit in the prefix for this... > it will add complexity to the system and it will need > updates between MSC and > GGSN. We would like > to modify the CC and MM messages to include all that without > the need of > encapsulation protocols as > described in GPRS. What do you really what to solve here that is NOT part of GPRS yet? Best Regards Thomas Eklund, SwitchCore > > > Hossam > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 28 09:06:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA11850 for ipng-dist; Mon, 28 Jun 1999 07:21:44 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11843 for ; Mon, 28 Jun 1999 07:21:17 -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 HAA10687 for ; Mon, 28 Jun 1999 07:21:16 -0700 (PDT) Received: from orchard.arlington.ma.us (orchard.epilogue.com [128.224.138.4]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07786 for ; Mon, 28 Jun 1999 07:21:15 -0700 (PDT) Received: from orchard.arlington.ma.us (localhost [[UNIX: localhost]]) by orchard.arlington.ma.us (8.8.8/1.34) with ESMTP id OAA27177; Mon, 28 Jun 1999 14:21:01 GMT Message-Id: <199906281421.OAA27177@orchard.arlington.ma.us> To: Thomas Eklund cc: "'Hossam Afifi'" , ipng@sunroof.eng.sun.com, "'bound@zk3.dec.com'" Subject: Re: IPv6 for mobile telephony In-Reply-To: Message from Thomas Eklund of "Mon, 28 Jun 1999 11:42:00 +0200." <45AFD48D077ED211BB4700A0C9DCE8FD08DB12@MONZA> Date: Mon, 28 Jun 1999 10:21:00 -0400 From: Bill Sommerfeld Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Chapter4: > You will NEVER use IPsec over GSM or GPRS due to the overhead! You already > have ciphering today over the air and that does not introduce any > overhead... This is handeled at layer 2 in GSM/GPRS.... link-layer encryption is not end-to-end encryption; most importantly, the trust properties are completely different. Also NEVER is a very strong word. Certainly, I can see that some applications would be willing to pay the additional overhead when they need end-to-end encryption (rather than sending in the clear over the internet to the GSM base station and then trusting the GSM base station to encrypt for them). - 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 Jun 28 09:07:01 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA11869 for ipng-dist; Mon, 28 Jun 1999 07:31:56 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA11862 for ; Mon, 28 Jun 1999 07:31:29 -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 HAA11430 for ; Mon, 28 Jun 1999 07:31:28 -0700 (PDT) Received: from monza.broadswitch.se (monza.broadswitch.se [195.178.164.73]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11262 for ; Mon, 28 Jun 1999 07:31:27 -0700 (PDT) Received: by MONZA with Internet Mail Service (5.5.2448.0) id ; Mon, 28 Jun 1999 16:31:26 +0200 Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD08DB19@MONZA> From: Thomas Eklund To: "'Bill Sommerfeld'" , Thomas Eklund Cc: "'Hossam Afifi'" , ipng@sunroof.eng.sun.com, "'bound@zk3.dec.com'" Subject: RE: IPv6 for mobile telephony Date: Mon, 28 Jun 1999 16:31:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@orchard.arlington.ma.us] > Sent: Monday, June 28, 1999 4:21 PM > To: Thomas Eklund > Cc: 'Hossam Afifi'; ipng@sunroof.eng.sun.com; 'bound@zk3.dec.com' > Subject: Re: IPv6 for mobile telephony > > > > Chapter4: > > You will NEVER use IPsec over GSM or GPRS due to the > overhead! You already > > have ciphering today over the air and that does not introduce any > > overhead... This is handeled at layer 2 in GSM/GPRS.... > > link-layer encryption is not end-to-end encryption; most importantly, > the trust properties are completely different. But what do we mean here, I also agre that e-2-e security have a totally different trust delegation arhitecture than only ciphering over the air... But read my answers and see what I mean. I have never talked about not being able to use IPsec as e-2-e security mechanism probably over PPP... I said that we will never use IPsec internally in GSM (between MS and BSC, MSC!!)....! > > Also NEVER is a very strong word. Certainly, I can see that some > applications would be willing to pay the additional overhead when they > need end-to-end encryption (rather than sending in the clear over the > internet to the GSM base station and then trusting the GSM base > station to encrypt for them). Then you will have to change the entire GSM spec... And that is a huge task and a lot of Politic!!! :-( /Thomas Eklund, SwitchCore > > - 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 Jun 28 09:33:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA12052 for ipng-dist; Mon, 28 Jun 1999 08:50:18 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA12045 for ; Mon, 28 Jun 1999 08:49:57 -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 IAA19960 for ; Mon, 28 Jun 1999 08:49:56 -0700 (PDT) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09061 for ; Mon, 28 Jun 1999 08:49:55 -0700 (PDT) Received: by jekyll.piermont.com (Postfix, from userid 1000) id 8AF9F1A6; Mon, 28 Jun 1999 11:49:53 -0400 (EDT) To: Thomas Eklund Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 for mobile telephony References: <45AFD48D077ED211BB4700A0C9DCE8FD08DB12@MONZA> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 28 Jun 1999 11:49:53 -0400 In-Reply-To: Thomas Eklund's message of "Mon, 28 Jun 1999 11:42:00 +0200" Message-ID: <87so7cuxy6.fsf@jekyll.piermont.com> Lines: 16 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Eklund writes: > Chapter4: > You will NEVER use IPsec over GSM or GPRS due to the overhead! You already > have ciphering today over the air and that does not introduce any > overhead... This is handeled at layer 2 in GSM/GPRS.... I must respectfully disagree with this statement. 0) GSM's link encryption is, to put it bluntly, garbage. 1) Link layer encryption is not a substitute for end to end encryption. Just protecting a single hop is not going to cut it. 2) The overhead of IPSec is very modest in practice. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 28 11:28:38 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA12497 for ipng-dist; Mon, 28 Jun 1999 11:24:51 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12490 for ; Mon, 28 Jun 1999 11:24:43 -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 LAA25631 for ; Mon, 28 Jun 1999 11:24:37 -0700 (PDT) Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA29121 for ; Mon, 28 Jun 1999 12:24:36 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail11.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id OAA01938; Mon, 28 Jun 1999 14:28:43 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000018884; Mon, 28 Jun 1999 14:24:36 -0400 (EDT) From: Jim Bound Message-Id: <199906281824.OAA0000018884@quarry.zk3.dec.com> To: trawick@us.ibm.com cc: ipng@sunroof.eng.sun.com Subject: Re: getipnodebyname() and numeric address string arguments with various non-zero flags In-reply-to: Your message of "Wed, 23 Jun 1999 13:13:22 EDT." <85256799.005E9C75.00@d54mta05.raleigh.ibm.com> Date: Mon, 28 Jun 1999 14:24:36 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>From RFC 2553, I gather that it makes no difference what is passed for the flags >parameter on getipnodebyname() when the type of the numeric address string >matches the address family parameter. Right? No. AI_V4MAPPED, AI_ADDRCONFIG, and AI_ALL still can be used. >So getipnodebyname("FE80::1000:whatever",AF_INET6,AI_DEFAULT,&error_num) on a >system that doesn't have a local IPv6 interface will succeed, but the >application won't be able to use the resulting address. Right? No. An error should be returned because AF_INET6 is specified and no IPv6 interface exists. AI_DEFAULT == (AI_V4MAPPED | AI_ADDRCONFIG) So one could get back a mapped address. But link-local addresses are not kept in the DNS at this time. >If this is correct, perhaps future documentation should be more clear about >getipnodebyname() ignoring flags for this scenario? I think your asking for the counter to what we did describe too? /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Jun 28 11:45:02 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA12557 for ipng-dist; Mon, 28 Jun 1999 11:41:24 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12550 for ; Mon, 28 Jun 1999 11:41:13 -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 LAA22777 for ; Mon, 28 Jun 1999 11:41:11 -0700 (PDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA05965 for ; Mon, 28 Jun 1999 12:41:11 -0600 (MDT) Received: from quarry.zk3.dec.com (quarry.zk3.dec.com [16.140.16.3]) by mail13.digital.com (8.9.2/8.9.2/WV2.0g) with ESMTP id OAA18224; Mon, 28 Jun 1999 14:41:07 -0400 (EDT) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id OAA0000024638; Mon, 28 Jun 1999 14:41:07 -0400 (EDT) From: Jim Bound Message-Id: <199906281841.OAA0000024638@quarry.zk3.dec.com> To: Thomas Narten cc: Jim Bound , "Matt Crawford" , ipng@sunroof.eng.sun.com, namedroppers@internic.net, bindv9@isc.org, bind-workers@isc.org Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of "Wed, 23 Jun 1999 10:48:29 EDT." <199906231448.KAA07464@cichlid.raleigh.ibm.com> Date: Mon, 28 Jun 1999 14:41:07 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tom, >> Why for the record and so its in the archives for future reference OK? >Once A6 records are specified, there would be two ways of doing the >same thing (i.e., query the DNS for v6 addresses). Implementers need >some guidance as to which of these two approaches to implement. >Moreover, AAAA records are deployed today, while A6 records are >not. Thus, a transition strategy for migrating from AAAA to A6 is >necessary. > >If this stuff isn't specified in an RFC, vendors will likely not know >what to do and make choices that aren't well thought out (e.g, ship >resolvers that do AAAA only or A6 only). Thus, some guidance is needed >to insure that once folks actually start deploying A6, it can be made >to work in a sensible fashion. > >This is akin to an applicability statement stating in what context >some new feature should be used and how it relates to an existing >feature that it conflicts/overlaps with. 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 Mon Jun 28 16:32:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id QAA12862 for ipng-dist; Mon, 28 Jun 1999 16:29:21 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12855 for ; Mon, 28 Jun 1999 16:29: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 QAA16900 for ; Mon, 28 Jun 1999 16:29:13 -0700 (PDT) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA01265 for ; Mon, 28 Jun 1999 16:29:12 -0700 (PDT) Received: from [171.69.199.124] (deering-office-mac.cisco.com [171.69.199.124]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id QAA26812 for ; Mon, 28 Jun 1999 16:29:10 -0700 (PDT) Mime-Version: 1.0 X-Sender: deering@postoffice Message-Id: Date: Mon, 28 Jun 1999 16:29:08 -0700 To: ipng@sunroof.eng.sun.com From: Steve Deering Subject: Oslo meetings Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPng WG Folks, I regret to say that I have had to cancel my trip to Oslo, due to a family medical emergency, so Bob Hinden will be bearing the chairing burdens by himself this time. 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 Jun 28 17:59:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA12936 for ipng-dist; Mon, 28 Jun 1999 17:56:38 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA12929 for ; Mon, 28 Jun 1999 17:56:29 -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 RAA00253 for ; Mon, 28 Jun 1999 17:56:28 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA13637 for ; Mon, 28 Jun 1999 18:56:17 -0600 (MDT) Received: from new (satsuma.iprg.nokia.com [205.226.1.120]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id RAA12770; Mon, 28 Jun 1999 17:56:14 -0700 (PDT) Message-Id: <3.0.5.32.19990628175538.00b626d0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 28 Jun 1999 17:55:38 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Proposed IPng w.g. Agenda for the Oslo IETF Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPng WG Folks, Attached is the proposed agenda for the IPng w.g. sessions at the Oslo IETF meeting. Please send me changes, additions, and corrections. Also, I am looking for a volunteer to help w/ the meeting minutes. Bob ______________________________________ WEDNESDAY, July 14, 1999 0900-1130 (Olympia) Introduction / R. Hinden (5 min) Review Agenda / R. Hinden (5 min) Document Status / R. Hinden (15 min) DNS Lookups (A6 / AAAA) / M. Crawford (10 min) Connection/Link Status Investigation (CSI) / H. Kitamura (15 min) UDP Lite / L. Larzon (10 min) Verification technology for IPv6 / N. Okabe (10 min) (http://www.tahi.org/) IPv6 in the GSM like infrastructure / H. Afifi (15 min) Preferred Format for Literal IPv6 Addresses in URL's / R. Hinden (10 min) Privacy Issues w/ Addrconf / T. Narten (10 min) THURSDAY, July 15, 1999 1530-1730 (Olympia) Session will be focused on IPv6 Multihoming Review of Multihoming Problem and Solutions/ S. Deering, R. Draves (45 min) RFC2260 Approach to IPv6 Multihoming / I. Jun-ichiro (15 min) Proposal for IPv6 Multihoming / R. Draves (30 min) Next Steps / R. Hinden (15 min) Interim Meeting? / R. Hinden (10 min) (Late September 1999?) --------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 01:07:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id BAA13108 for ipng-dist; Tue, 29 Jun 1999 01:04:05 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA13101 for ; Tue, 29 Jun 1999 01:03:54 -0700 (PDT) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id BAA972112; Tue, 29 Jun 1999 01:03:54 -0700 (PDT) Date: Tue, 29 Jun 1999 01:01:49 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt To: Jim Bound Cc: Matt Crawford , ipng@sunroof.eng.sun.com, namedroppers@internic.net, bindv9@isc.org, bind-workers@isc.org In-Reply-To: "Your message with ID" <199906231433.KAA0000028114@quarry.zk3.dec.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk To add to Thomas' concern about specifying transition: There is some interaction between the transition strategy in the resolver since section 7 says: A server providing recursive service MAY be configurable to synthesize AAAA records from A6 records in response to clients' AAAA queries. If a server does this and the resolvers ask for AAAA before A6 then how can the server tell that the resolver is capable of asking for A6 records so it can skip the synthesis? This issue points out that we need the resolver and server transition written down so that the WGs and the IESG can check that things work well together. Just having the transition strategy for the DNS server isn't enough. 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 Jun 29 03:54:03 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id DAA13228 for ipng-dist; Tue, 29 Jun 1999 03:51:08 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13221 for ; Tue, 29 Jun 1999 03:50:59 -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 DAA09856 for ; Tue, 29 Jun 1999 03:50:52 -0700 (PDT) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA22072 for ; Tue, 29 Jun 1999 03:50:42 -0700 (PDT) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id MAA28925; Tue, 29 Jun 1999 12:49:40 +0200 (MET DST) Message-ID: <19990629124939.B28873@theory.cs.uni-bonn.de> Date: Tue, 29 Jun 1999 12:49:39 +0200 From: Ignatios Souvatzis To: perry@piermont.com, Thomas Eklund Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6 for mobile telephony Reply-To: ipng@sunroof.eng.sun.com References: <45AFD48D077ED211BB4700A0C9DCE8FD08DB12@MONZA> <87so7cuxy6.fsf@jekyll.piermont.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <87so7cuxy6.fsf@jekyll.piermont.com>; from Perry E. Metzger on Mon, Jun 28, 1999 at 11:49:53AM -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Jun 28, 1999 at 11:49:53AM -0400, Perry E. Metzger wrote: > > Thomas Eklund writes: > > Chapter4: > > You will NEVER use IPsec over GSM or GPRS due to the overhead! You already > > have ciphering today over the air and that does not introduce any > > overhead... This is handeled at layer 2 in GSM/GPRS.... > > I must respectfully disagree with this statement. > > 0) GSM's link encryption is, to put it bluntly, garbage. ... and only used (in practice) from your phone to the base station, but not in between base stations. This is a feature demanded by the ... uhm... security agencies. At least in Europe. That is: if you are near the line of sight between two base stations, you can copy the traffic in clear{voice,text}. -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 29 04:09:24 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA13278 for ipng-dist; Tue, 29 Jun 1999 04:06:39 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13271 for ; Tue, 29 Jun 1999 04:06:30 -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 EAA03830 for ; Tue, 29 Jun 1999 04:06:29 -0700 (PDT) Received: from maile.surrey.ac.uk (maile.surrey.ac.uk [131.227.102.10]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id EAA25134 for ; Tue, 29 Jun 1999 04:06:29 -0700 (PDT) Received: from petra.ee.surrey.ac.uk by maile.surrey.ac.uk with SMTP (PP); Tue, 29 Jun 1999 12:05:52 +0100 Date: Tue, 29 Jun 1999 12:06:04 +0100 (BST) From: Lloyd Wood X-Sender: eep1lw@petra.ee.surrey.ac.uk Reply-To: Lloyd Wood To: ipng@sunroof.eng.sun.com cc: perry@piermont.com, Thomas Eklund Subject: Re: IPv6 for mobile telephony In-Reply-To: <19990629124939.B28873@theory.cs.uni-bonn.de> Message-ID: Organization: speaking for none X-URL: http://www.ee.surrey.ac.uk/Personal/L.Wood/ X-no-archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 29 Jun 1999, Ignatios Souvatzis wrote: > On Mon, Jun 28, 1999 at 11:49:53AM -0400, Perry E. Metzger wrote: > > > > Thomas Eklund writes: > > > Chapter4: > > > You will NEVER use IPsec over GSM or GPRS due to the overhead! You already > > > have ciphering today over the air and that does not introduce any > > > overhead... This is handeled at layer 2 in GSM/GPRS.... > > > > I must respectfully disagree with this statement. > > > > 0) GSM's link encryption is, to put it bluntly, garbage. > > ... and only used (in practice) from your phone to the base station, but not > in between base stations. This is a feature demanded by the ... uhm... > security agencies. At least in Europe. > > That is: if you are near the line of sight between two base stations, you > can copy the traffic in clear{voice,text}. http://catless.ncl.ac.uk/Risks/19.48.html#subj5.1 discusses this in some detail. I don't have a reference for the paper promised at end. L. mobile air interface != other dumb things in the mobile provider network. PGP -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 04:29:49 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id EAA13304 for ipng-dist; Tue, 29 Jun 1999 04:27:11 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13297 for ; Tue, 29 Jun 1999 04:27:00 -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 EAA18063 for ; Tue, 29 Jun 1999 04:27:00 -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 EAA28450 for ; Tue, 29 Jun 1999 04:26:59 -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 HAA08458; Tue, 29 Jun 1999 07:26:56 -0400 (EDT) Message-Id: <199906291126.HAA08458@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-2292bis-00.txt Date: Tue, 29 Jun 1999 07:26: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 : Advanced Sockets API for IPv6 Author(s) : R. Stevens, M. Thomas, E. Nordmark Filename : draft-ietf-ipngwg-2292bis-00.txt Pages : 63 Date : 28-Jun-99 A separate specification [RFC-2553] contain changes to the sockets API to support IP version 6. Those changes are for TCP and UDP-based applications and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-2292bis-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-2292bis-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-2292bis-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: <19990628150811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-2292bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-2292bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990628150811.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Jun 29 05:23:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA13425 for ipng-dist; Tue, 29 Jun 1999 05:20:40 -0700 (PDT) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13418 for ; Tue, 29 Jun 1999 05:20:31 -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 FAA11044 for ; Tue, 29 Jun 1999 05:20:31 -0700 (PDT) Received: from monza.broadswitch.se ([195.178.164.73]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA00179 for ; Tue, 29 Jun 1999 06:20:28 -0600 (MDT) Received: by MONZA with Internet Mail Service (5.5.2448.0) id ; Tue, 29 Jun 1999 14:20:26 +0200 Message-ID: <45AFD48D077ED211BB4700A0C9DCE8FD08DB21@MONZA> From: Thomas Eklund To: "'ipng@sunroof.eng.sun.com'" , perry@piermont.com, Thomas Eklund Cc: "'L.Wood@surrey.ac.uk'" , "'sommerfeld@orchard.arlington.ma.us'" Subject: RE: IPv6 for mobile telephony Date: Tue, 29 Jun 1999 14:20:26 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Ignatios Souvatzis [mailto:ignatios@cs.uni-bonn.de] > Sent: Tuesday, June 29, 1999 12:50 PM > To: perry@piermont.com; Thomas Eklund > Cc: ipng@sunroof.eng.sun.com > Subject: Re: IPv6 for mobile telephony > > > On Mon, Jun 28, 1999 at 11:49:53AM -0400, Perry E. Metzger wrote: > > > > Thomas Eklund writes: > > > Chapter4: > > > You will NEVER use IPsec over GSM or GPRS due to the > overhead! You already > > > have ciphering today over the air and that does not introduce any > > > overhead... This is handeled at layer 2 in GSM/GPRS.... > > > > I must respectfully disagree with this statement. > > > > 0) GSM's link encryption is, to put it bluntly, garbage. > > ... and only used (in practice) from your phone to the base > station, but not > in between base stations. This is a feature demanded by the > ... uhm... > security agencies. At least in Europe. > > That is: if you are near the line of sight between two base > stations, you > can copy the traffic in clear{voice,text}. Yes, and why do you want to use IPsec from BS and uplink in the MSC area? Whats the purpose of having a mechanism of encryption from the MSC using IPsec to only protect the air interface if its already there? The reason why the ciphering mechanism is there is to encrypt it over the air (from BS to MS). You have several hundreds of millions of terminals that uses this and they use their terminals only for voice and for circuit switched data (and only a circuit switched data connection that runs PPP over it and then that PPP connection protects the wireless hop in GSM from BS to MS using the ciphering mechanism already there). The intent is to stop eavesdropping on phone-conversations and data transmissions in the air. Nothing else. When you have a more always connected mode like GPRS then it makes more sense, but then its already there... In products and specifications... --------- The authentication procedure works very much like the Radius/Diameter auth procedure but it runs on level 2!! So its for subscriber auth. and for establish ciphering procedures ... It uses the AuC for generating the ciphering key and store it in HLR/VLR (MSC). And the Ciphering procedure relies on a predefined shared key and IMSI between the MS and the AuC. The MS store this info in the SIM card. And when the MS enters a MSC/VLR,HLR area it generates these ciphering keys and store them in the MS, BS and MSC/VLR. And that is very much the same thing as when you generates session keys in IP sec (SA:s)!!! So yes its the same mechanisms. And you can use different ciphering algorithm and different lenghts of the predefined keys but I still dont understand what benefit IP sec would give in circuit switched GSM for protecting the air, beside a re-write of all standardization documents!!!? For packet based systems, ok, but for circuit switched GSM?? Note: There is also a draft written by a former collegue of mine when I worked for Ericsson, Fergal Ladley, that specifies how Diameter can do link authentication using IPsec (http://www.ietf.org/internet-drafts/draft-ladley-diameter-pr-00.txt), the interested could have a look. (You can also check on the IMEI number also if you want, but thats another thing) Regards Thomas Eklund SwitchCore -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 07:57:18 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA13593 for ipng-dist; Tue, 29 Jun 1999 07:54:20 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13586 for ; Tue, 29 Jun 1999 07:54:09 -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 HAA20249; Tue, 29 Jun 1999 07:54:08 -0700 (PDT) Received: from isrv3.pa.vix.com (isrv3.pa.vix.com [204.152.184.182]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA13987; Tue, 29 Jun 1999 08:54:07 -0600 (MDT) Received: from bb.rc.vix.com (bb.rc.vix.com [204.152.187.11]) by isrv3.pa.vix.com (8.9.1/8.9.1) via ESMTP id HAA03526; Tue, 29 Jun 1999 07:54:02 -0700 (PDT) env-from (paul@vix.com) Received: from bb.rc.vix.com (localhost [127.0.0.1]) by bb.rc.vix.com (8.9.1/8.9.1) via ESMTP id HAA14959; Tue, 29 Jun 1999 07:54:02 -0700 (PDT) env-from (paul@vix.com) Message-Id: <199906291454.HAA14959@bb.rc.vix.com> To: Erik Nordmark cc: Jim Bound , Matt Crawford , ipng@sunroof.eng.sun.com, namedroppers@internic.net Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of "Tue, 29 Jun 1999 01:01:49 PDT." Date: Tue, 29 Jun 1999 07:54:01 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk note: i have removed , bindv9@isc.org, bind-workers@isc.org from the CC list, since these are internal ISC lists and should not have been CC'd (or mentioned in public, for that matter) by a thread which also hit namedroppers and ipng. bad jim, no bone. they might have been BCC'd; those of you who are on them will know :-). > To add to Thomas' concern about specifying transition: > > There is some interaction between the transition strategy in the resolver > since section 7 says: > A server providing recursive service MAY be configurable to > synthesize AAAA records from A6 records in response to clients' AAAA > queries. > > If a server does this and the resolvers ask for AAAA before A6 > then how can the server tell that the resolver is capable of > asking for A6 records so it can skip the synthesis? that's one possible bad thing. but record synthesis has to be very carefully considered -- and in this case after carefully considering it i hereby object to doing it for AAAA. if we want to specify a metaquery that can be satisfied by either AAAA or A6 records (or A records for that matter) then by all means let's make one. MAILA and MAILB are metaqueries. they have no corresponding RRTYPES; they are examples of QTYPE being a subtype of RRTYPE in the DNS specs. but answering with types not in evidence, or making things up on the fly, or putting unrelated things in as additional data, will all screw DNSSEC in different ways. repeat after me: dns is a coherent, reliable, distributed, autonomous database. it is not a directory service. it encodes policy as facts, and returns those facts reliably to questioners. it does not directly deal in policy. > This issue points out that we need the resolver and server > transition written down so that the WGs and the IESG can check > that things work well together. > Just having the transition strategy for the DNS server isn't enough. this is certainly also true. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Jun 29 08:17:02 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA13655 for ipng-dist; Tue, 29 Jun 1999 08:13:46 -0700 (PDT) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13648 for ; Tue, 29 Jun 1999 08:13:36 -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 IAA12451; Tue, 29 Jun 1999 08:13:34 -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 JAA22238; Tue, 29 Jun 1999 09:13:33 -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 KAA13509; Tue, 29 Jun 1999 10:13:31 -0500 (CDT) Message-Id: <199906291513.KAA13509@gungnir.fnal.gov> To: Paul A Vixie Cc: Erik Nordmark , Jim Bound , ipng@sunroof.eng.sun.com, namedroppers@internic.net From: "Matt Crawford" Subject: Re: draft-ietf-ipngwg-dns-lookups-04.txt In-reply-to: Your message of Tue, 29 Jun 1999 07:54:01 PDT. <199906291454.HAA14959@bb.rc.vix.com> Date: Tue, 29 Jun 1999 10:13:31 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > if we want to specify a metaquery that can be satisfied by either AAAA > or A6 records (or A records for that matter) then by all means let's make > one. MAILA and MAILB are metaqueries. they have no corresponding RRTYPES; > they are examples of QTYPE being a subtype of RRTYPE in the DNS specs. I made that suggestion to the AD's. I'll let them present their own arguments against it, rather than distort them from memory. 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 Tue Jun 29 11:12:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA13917 for ipng-dist; Tue, 29 Jun 1999 11:09:07 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA13910 for ; Tue, 29 Jun 1999 11:08:58 -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 LAA28006 for ; Tue, 29 Jun 1999 11:08:57 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id LAA11602 for ; Tue, 29 Jun 1999 11:08:57 -0700 (PDT) Received: from 157.54.9.103 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 29 Jun 1999 11:07:52 -0700 (Pacific Daylight Time) Received: by INET-IMC-04 with Internet Mail Service (5.5.2524.0) id ; Tue, 29 Jun 1999 11:07:53 -0700 Message-ID: <4D0A23B3F74DD111ACCD00805F31D81014515438@RED-MSG-50> From: Richard Draves To: "'IPng List'" Cc: "'6bone'" <6bone@isi.edu>, "'MSR IPv6 Users'" Subject: MSR IPv6 Release 1.3 Date: Tue, 29 Jun 1999 11:07:42 -0700 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Microsoft Research and ISI East are pleased to announce Release 1.3 of our MSR IPv6 stack for Windows NT. See http://www.research.microsoft.com/msripv6 for more details and download information. The main highlights: - IPsec support for all combinations of AH & ESP headers, both transport-mode and tunnel-mode. Note that we only support static keying and we only support authentication algorithms, not encryption algorithms. - 6to4 support. See http://www.research.microsoft.com/msripv6/docs/6to4.htm. In the future we'll automate 6to4 configuration, with a little configuration applet. - The usual miscellaneous enhancements and fixes, especially for routing. To support developers, we're also doing daily source drops. Send email to msripv6-bugs@list.research.microsoft.com to request more information about the daily source drops. See http://list.research.microsoft.com/archives/msripv6-users.html to join our discussion list or search the archives. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 30 12:21:08 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA00257 for ipng-dist; Wed, 30 Jun 1999 12:16:56 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00245 for ; Wed, 30 Jun 1999 12:16:42 -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 EAA06802 for ; Wed, 30 Jun 1999 04:51:17 -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 FAA09786 for ; Wed, 30 Jun 1999 05:51:17 -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 HAA13672; Wed, 30 Jun 1999 07:51:13 -0400 (EDT) Message-Id: <199906301151.HAA13672@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-addrconf-privacy-00.txt Date: Wed, 30 Jun 1999 07:51:13 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Author(s) : T. Narten Filename : draft-ietf-ipngwg-addrconf-privacy-00.txt Pages : 9 Date : 29-Jun-99 Nodes use IPv6 stateless address autoconfiguration to generate addresses without the necessity of a DHCP server. Addresses are formed by combining network prefixes with a constant interface identifier derived from the interface's IEEE Indentifier. This document describes an optional extension to IPv6 stateless address autoconfiguration that results in a node generating addresses from an interface identifier that changes over time. Changing the interface identifier over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addrconf-privacy-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-addrconf-privacy-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-addrconf-privacy-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: <19990629142834.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addrconf-privacy-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addrconf-privacy-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990629142834.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 30 12:21:22 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA00258 for ipng-dist; Wed, 30 Jun 1999 12:17:02 -0700 (PDT) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00243 for ; Wed, 30 Jun 1999 12:16: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 EAA06769 for ; Wed, 30 Jun 1999 04:50:32 -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 FAA09701 for ; Wed, 30 Jun 1999 05:50:32 -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 HAA13655; Wed, 30 Jun 1999 07:50:28 -0400 (EDT) Message-Id: <199906301150.HAA13655@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-icmp-v3-00.txt Date: Wed, 30 Jun 1999 07:50:27 -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 : Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-v3-00.txt Pages : 20 Date : 29-Jun-99 This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-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-icmp-v3-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-icmp-v3-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: <19990629142823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-v3-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-v3-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990629142823.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Jun 30 14:34:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA00929 for ipng-dist; Wed, 30 Jun 1999 14:30:58 -0700 (PDT) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00919 for ; Wed, 30 Jun 1999 14:30:49 -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 OAA04510 for ; Wed, 30 Jun 1999 14:30:52 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA18725 for ; Wed, 30 Jun 1999 14:30:51 -0700 (PDT) Received: from new (satsuma.iprg.nokia.com [205.226.1.120]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id OAA19957; Wed, 30 Jun 1999 14:30:51 -0700 (PDT) Message-Id: <3.0.5.32.19990630143012.0350b220@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 30 Jun 1999 14:30:12 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: IPng w.g. Agenda for the Oslo IETF Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPng WG Folks, Attached is the agenda for the IPng w.g. sessions at the Oslo IETF meeting. Please send me changes, additions, and corrections. Also, I am still looking for a volunteer to help w/ the meeting minutes. Bob ______________________________________ WEDNESDAY, July 14, 1999 0900-1130 (Olympia) Introduction / R. Hinden (5 min) Review Agenda / R. Hinden (5 min) Document Status / R. Hinden (15 min) DNS Lookups (A6 / AAAA) / M. Crawford (10 min) Connection/Link Status Investigation (CSI) / H. Kitamura (15 min) UDP Lite / L. Larzon (10 min) Verification technology for IPv6 / N. Okabe (10 min) (http://www.tahi.org/) IPv6 in the GSM like infrastructure / H. Afifi (15 min) Preferred Format for Literal IPv6 Addresses in URL's / R. Hinden (10 min) Privacy Issues w/ Addrconf / T. Narten (10 min) Update to IPv6 advanced API / E. Nordmark (10 min) Update to site prefixes draft / E. Nordmark (10 min)