From owner-ipng Fri Aug 2 07:42:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27676; Fri, 2 Aug 96 07:42:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27670; Fri, 2 Aug 96 07:37:32 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA06738; Fri, 2 Aug 1996 07:32:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA25037; Fri, 2 Aug 1996 07:32:47 -0700 Received: from munin.fnal.gov ("port 3967"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I7SNHI1S8Y001ISP@FNAL.FNAL.GOV>; Fri, 02 Aug 1996 09:32:46 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id JAA08253; Fri, 02 Aug 1996 09:31:11 -0500 (CDT) Date: Fri, 02 Aug 1996 09:31:10 -0500 From: Matt Crawford Subject: (IPng 1990) Re: Token Ring draft To: ipng@sunroof.eng.sun.com Cc: Stephen Thomas Message-Id: <199608021431.JAA08253@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27742; Fri, 2 Aug 96 08:32:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27736; Fri, 2 Aug 96 08:26:58 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA12312; Fri, 2 Aug 1996 08:22:13 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA08807; Fri, 2 Aug 1996 08:22:11 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id RAA22853 for ; Fri, 2 Aug 1996 17:22:01 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA31164; Fri, 2 Aug 1996 17:21:52 +0200 Message-Id: <9608021521.AA31164@dxcoms.cern.ch> Subject: (IPng 1991) Re: Token Ring draft To: ipng@sunroof.eng.sun.com Date: Fri, 2 Aug 1996 17:21:52 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Reply-To: ipng@sunroof.eng.sun.com In-Reply-To: <199608021431.JAA08253@munin.fnal.gov> from "Matt Crawford" at Aug 2, 96 09:31:10 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, > I claim that using a link-layer priority field to mark Neighbor > Discovery packets is not an abuse or pre-emption of that field. I > have no trouble considering those packets as actually having a higher > priority than some others. And if an implementation then uses that > user priority to determine the access priority, so much the better. > It also wouldn't bother me if some implementation assigned non-zero > priority to *all* ICMP packets. What if ISSLL needs to use the priority field in a way that interferes? Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Aug 2 09:01:23 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27775; Fri, 2 Aug 96 09:01:23 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27761; Fri, 2 Aug 96 08:56:34 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA16005; Fri, 2 Aug 1996 08:51:49 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA18883; Fri, 2 Aug 1996 08:51:16 -0700 Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA03760; Fri, 2 Aug 96 10:56:33 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA12574; Fri, 2 Aug 96 10:53:30 CDT Date: Fri, 2 Aug 96 10:53:30 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9608021553.AA12574@anubis.network.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 1992) Re: Token Ring draft Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I confess to some puzzlement over this worry about the default MTU for Token Ring. I freely admit to not really understanding the issues, and I may be missing something fundamental, but surely this is a solved problem? Token Ring<->Ethernet bridges have been doing IPv4 fragmentation forever. This is standard stuff in mixed media environments. IPv6 does fragmentation, right? Was it broken such that you really need a complete IPv6 device to successfully fragment? I urge the worthy folks driving IPv6 to please not go backwards. Andrew ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Aug 2 09:24:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27824; Fri, 2 Aug 96 09:24:55 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27810; Fri, 2 Aug 96 09:19:02 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA20384; Fri, 2 Aug 1996 09:14:17 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA27651; Fri, 2 Aug 1996 09:14:15 -0700 Received: from munin.fnal.gov ("port 4011"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I7SR19RDME001K87@FNAL.FNAL.GOV> for ipng@sunroof.eng.sun.com; Fri, 02 Aug 1996 11:14:12 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id LAA08681; Fri, 02 Aug 1996 11:12:38 -0500 (CDT) Date: Fri, 02 Aug 1996 11:12:37 -0500 From: Matt Crawford Subject: (IPng 1993) Re: Token Ring draft In-Reply-To: "02 Aug 1996 17:21:52 +0200." <"9608021521.AA31164"@dxcoms.cern.ch> To: ipng@sunroof.eng.sun.com Message-Id: <199608021612.LAA08681@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ > I claim that using a link-layer priority field to mark Neighbor > > Discovery packets is not an abuse or pre-emption of that field. ... > > What if ISSLL needs to use the priority field in a way that > interferes? Then ISSLL would break existing IPv4 implementations which even now send various sorts of packets with different priorities. I've seen these on my analyzers for years. I really don't think intserv will preclude use of link-layer priorities by non-intserv IP traffic. Matt ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Aug 2 14:32:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA28138; Fri, 2 Aug 96 14:32:21 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA28129; Fri, 2 Aug 96 14:26:58 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA14381; Fri, 2 Aug 1996 14:22:07 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA16649; Fri, 2 Aug 1996 14:22:07 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id RAA11434; Fri, 2 Aug 1996 17:12:21 -0400 (EDT) Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA08432; Fri, 2 Aug 1996 17:12:18 -0400 Received: by netrix.lkg.dec.com; (5.65v3.2/1.1.8.2/28May95-0415PM) id AA09831; Fri, 2 Aug 1996 17:12:17 -0400 Date: Fri, 2 Aug 1996 17:12:17 -0400 From: Dan Harrington Message-Id: <9608022112.AA09831@netrix.lkg.dec.com> To: addrconf@cisco.com, ipng@sunroof.eng.sun.com Subject: (IPng 1994) Request tightening of Neighbor Solicitation validation Cc: dan@lkg.dec.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, I made a note during the UNH interoperability testing in June, and would like to bring it up here for discussion and clarification. It involves the processing and validation of a Neighbor Solicitation packet used for the putative purpose of Duplicate Address Detection. The packet (and my analysis of it) is appended at the end of this mail. I would like to suggest a tightening of the Neighbor Solicitation validation rules, to add: - If the Source Address is the unspecified address, then the Destination Address must be a solicited-node multicast address. As with the existing validation checks, failure to meet this requirement would result in a silent discard of the packet. I have discussed this change briefly with an author of the draft in question (Neighbor Discovery), who feels that no particular change in wording is required. I disagree, as I feel that allowing the use of the unspecified address as the Source Address in Neighbor Solicitations for purposes other than DAD is inappropriate, and should not be permitted. This packet is not a DAD packet (it doesn't conform to the sending rules), so unless there is some specific need for this type of packet, it should be ignored. If there is such a need, it should be documented somewhere. Dan ============================================================================== [from mail dated Thu, 20 Jun 1996 12:04:12 -0400] Here is a Neighbor Solicitation message which we ignored (dropped semi-silently...we did spit out a kernel log message, appended below). This is from UNH test 2.7.2.3.1b. This was marked as a fail, in that we did not respond to it as the UNH test expected. However, the packet itself does not conform to the DAD behaviour specified in the Addrconf spec, as it is being sent unicast (link-layer) to the actual Link-local address being checked, where is should be sent to the Solicited nodes multicast group. However, while it does not pass the DAD sending rules, it does seem to pass all the receiving validation rules called out in both Neighbor Discovery, as well as Addrconf. It seems we should request some clarification (and tightening of the spec) at Montreal. Dan ============================================================================== Time = 08:57:28.530999 ms 0000000: 00 00 f8 21 2d 96 08 00 20 73 96 45 86 dd 6f 00 ...!-... s.E..o. 0000010: 00 00 00 20 3a ff 00 00 00 00 00 00 00 00 00 00 ... :........... 0000020: 00 00 00 00 00 00 fe 80 00 00 00 00 00 00 00 00 ................ 0000030: 00 00 f8 21 2d 96 87 00 94 6f 00 00 00 00 fe 80 ...!-....o...... 0000040: 00 00 00 00 00 00 00 00 00 00 f8 21 2d 96 01 01 ...........!-... 0000050: 08 00 20 11 72 b1 .. .r. DLL: ======Ethernet Header====== DLL: DLL: Frame Length = 86 DLL: Source Address = 8:0:20:73:96:45 (UNH Monitor) DLL: Destination Address = 0:0:f8:21:2d:96 (DEC UNIX) DLL: Protocol Type = 86dd (ipv6) DLL: IPv6: IPv6: Version = 6 IPv6: Priority = 15 IPv6: Flow Label = 0x000 IPv6: Payload Length = 32 IPv6: Next Header = 58 IPv6: Hop Limit = 255 IPv6: Source Address = 0:0:0:0:0:0:0:0 (Unspecified) IPv6: Destination Address = fe80:0:0:0:0:0:f821:2d96 (DEC UNIX *UNICAST*) IPV6: ICMPv6: ICMPv6: =======NEIGHBOR SOLICITATION======= ICMPv6: Type = 135 ICMPv6: Code = 0 ICMPv6: Checksum = 946f (Correct) ICMPv6: Reserved (32 bits) = 0 ICMPv6: Target Address = fe80:0:0:0:0:0:f821:2d96 (DEC UNIX) ICMPv6: ICMPv6: =======Source Link Layer Address Option======= ICMPv6: Type = 1 ICMPv6: Length = 1 (8 octet units) ICMPv6: Link Layer Address = 8:0:20:11:72:b1 (UNH Monitor) ICMPv6: Kernel log message: Jun 20 09:59:08 pollux vmunix: nd6_input: mcast redirect(0) or invalid src(::) ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 5 10:00:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29239; Mon, 5 Aug 96 10:00:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA29233; Mon, 5 Aug 96 09:59:56 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA17678; Mon, 5 Aug 1996 09:55:07 -0700 Received: by venus.Sun.COM (Sun.COM) id JAA17838; Mon, 5 Aug 1996 09:55:08 -0700 Received: by kdemailn2.kde.state.ky.us with Microsoft Exchange (IMC 4.0.838.14) id <01BB82C5.0A6E4E70@kdemailn2.kde.state.ky.us>; Mon, 5 Aug 1996 11:55:47 -0500 Message-Id: From: "Howell, Mike - KETS Engineer" To: "'IPng Mailing List'" Subject: (IPng 1995) How to subnet IPng Date: Mon, 5 Aug 1996 11:55:46 -0500 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14 Encoding: 2 TEXT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can anyone show me how IPng is going to be subnetted??? Is it going to use traditional subnetting standards.??? ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 5 10:21:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29303; Mon, 5 Aug 96 10:21:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27806; Fri, 2 Aug 96 09:17:50 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA20196; Fri, 2 Aug 1996 09:13:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA27171; Fri, 2 Aug 1996 09:13:01 -0700 Received: from eurohub (eurohub.spider.co.uk [134.191.64.200]) by lynx.spider.co.uk (8.6.12/8.6.12) with ESMTP id RAA24552 for ; Fri, 2 Aug 1996 17:12:19 +0100 Received: from Lotus Notes (PU Serial #1281) by eurohub (PostalUnion/SMTP(tm) v2.1.7 for Windows NT(tm)) id AA-1996Aug02.140833.1281.239941; Fri, 02 Aug 1996 16:09:58 GMT From: postmaster@spider.co.uk (Postmaster) To: ipng@sunroof.eng.sun.com Message-Id: <1996Aug02.140833.1281.239941@eurohub> X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 02 Aug 1996 16:09:58 GMT Subject: (IPng 1996) NDN: Re: Token Ring draft Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk PostalUnion for Lotus Notes(r) 'Non-Delivery Notice'! Your mail through the Notes 'SMTP' Gateway could not be delivered! ***Lotus Notes: No Valid Recipients ***Unknown Lotus Notes Error = 525 Please re-send with correct addressing. ------ Partial Text of Message Follows ------ Received: from lynx.spider.co.uk by eurohub (PostalUnion/SMTP(tm) v2.1.7 for Windows NT(tm)) id AA-1996Aug02.160306.1281.142953; Fri, 02 Aug 1996 16:03:06 GMT Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by lynx.spider.co.uk (8.6.12/8.6.12) with ESMTP id RAA24026 for ; Fri, 2 Aug 1996 17:05:13 +0100 Received: by mercury.Sun.COM (Sun.COM) id IAA17039; Fri, 2 Aug 1996 08:46:00 -0700 Received: from sunroof.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA16905; Fri, 2 Aug 1996 08:45:01 -0700 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA27742; Fri, 2 Aug 96 08:32:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA27736; Fri, 2 Aug 96 08:26:58 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA12312; Fri, 2 Aug 1996 08:22:13 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA08807; Fri, 2 Aug 1996 08:22:11 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id RAA22853 for ; Fri, 2 Aug 1996 17:22:01 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA31164; Fri, 2 Aug 1996 17:21:52 +0200 Message-Id: <9608021521.AA31164@dxcoms.cern.ch> Subject: (IPng 1991) Re: Token Ring draft To: ipng@sunroof.Eng.Sun.COM Date: Fri, 2 Aug 1996 17:21:52 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Reply-To: ipng@sunroof.Eng.Sun.COM In-Reply-To: <199608021431.JAA08253@munin.fnal.gov> from "Matt Crawford" at Aug 2, 96 09:31:10 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Matt, > I claim that using a link-layer priority field to mark Neighbor > Discovery packets is not an abuse or pre-emption of that field. I > have no trouble considering those packets as actually having a higher > priority than some others. And if an implementation then uses that > user priority to determine the access priority, so much the better. > It also wouldn't bother me if some implementation assigned non-zero > priority to *all* ICMP packets. What if ISSLL needs to use the priority field in a w ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 5 18:23:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA29966; Mon, 5 Aug 96 18:23:49 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA29960; Mon, 5 Aug 96 18:23:25 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA17428; Mon, 5 Aug 1996 18:18:37 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA25019; Mon, 5 Aug 1996 18:18:33 -0700 Received: from yogya.wasantara.net.id (yogya.wasantara.net.id [202.159.85.163]) by ns2.wasantara.net.id (8.6.11/8.6.9) with ESMTP id JAA00218 for ; Tue, 6 Aug 1996 09:22:30 +0700 Received: from YOGYA/SpoolDir by yogya.wasantara.net.id (Mercury 1.21); 6 Aug 96 08:24:20 GMT+0700 Received: from SpoolDir by YOGYA (Mercury 1.21); 6 Aug 96 08:24:03 GMT+0700 Received: from phuntos.kurdi.net.id by yogya.wasantara.net.id (Mercury 1.21); 6 Aug 96 08:23:50 GMT+0700 Message-Id: <32069E86.57C@yogya.wasantara.net.id> Date: Tue, 06 Aug 1996 08:23:18 +0700 From: Kurdi-Net Member Organization: STT-Telkom - WNet X-Mailer: Mozilla 2.01 (Win95; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 1997) Header Translating router Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is there anybody know where I can find draft about "Header Translating Router". Thanks...! ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Aug 7 09:41:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01230; Wed, 7 Aug 96 09:41:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01206; Wed, 7 Aug 96 09:12:28 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA18193; Wed, 7 Aug 1996 09:07:38 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA18089; Wed, 7 Aug 1996 09:02:02 -0700 Received: (from dab@localhost) by restless.BSDI.COM (8.7.3/8.7.3) id KAA11500; Wed, 7 Aug 1996 10:59:57 -0500 (CDT) Date: Wed, 7 Aug 1996 10:59:57 -0500 (CDT) From: David Borman Message-Id: <199608071559.KAA11500@restless.BSDI.COM> To: internet-drafts@cnri.reston.va.us Subject: (IPng 1998) TCP & UDP over IPv6 Jumbograms Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi. Attached is a short Internet-Draft that I wrote up after the March IETF meeting, but then forgot to do anything with it. This document proposes a method for allowing TCP and UDP to make use of IPv6 jumbograms. The only limiting factors that I am aware of are the TCP MSS option, and the UDP length field. I would like to see this document considered for the standards track. -David Borman, dab@bsdi.com ------ Cut Here ------ Network Working Group Internet Engineering Task Force Internet-Draft IPNG Working Group Updates: 1883 David Borman Berkeley Software Design, Inc. August 1996 TCP and UDP over IPv6 Jumbograms Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Overview IPv6 supports datagrams larger than 65535 bytes long, called jumbograms. The UDP protocol has a 16 length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, it does have an MSS option that has a 65535 byte length limitation. This document describes some simple changes that can be made to TCP and UDP over IPv6 to allow them to take advantage of jumbograms. 2. UDP Jumbograms Because the UDP length field includes the UDP header, the minimum valid value for this field is 8. To send a UDP packet with a UDP length > 65535, set the UDP length field to zero, and the IPv6 length field to correctly reflect the length of the UDP packet. If a UDP packet arrives with a length field of zero, the UDP IPNG Working Group Expires February 1997 [Page 1] Internet-Draft TCP and UDP over IPv6 Jumbograms August 1996 length should be ignored, and the length field from the pseudo header should be used. 3. TCP jumbograms Because there is no length field in the TCP header, there is nothing limiting the length of an individual TCP packet. However, the MSS value that is negotiated at the beginning of the connection limits the largest TCP packet that can be sent. When determining what MSS value to send, if the MTU of the directly attached interface is greater than 65535, then set the MSS value to 65535. When an MSS value of 65535 is received, it is to be treated as infinity. MTU discovery code, starting with the MTU of the outgoing interface, should be used to determine the actual MSS. 4. Security Considerations There are no known security issues involved in these changes. Author's Address David A. Borman Berkeley Software Design, Inc. 4719 Weston Hills Drive Eagan, MN 55123 Phone: (612) 405-8194 Mailing List: ipng@sunroof.Eng.Sun.COM Email: dab@bsdi.com IPNG Working Group Expires February 1997 [Page 2] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Aug 7 10:02:18 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01271; Wed, 7 Aug 96 10:02:18 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01265; Wed, 7 Aug 96 10:02:05 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA26694; Wed, 7 Aug 1996 09:57:14 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA08368; Wed, 7 Aug 1996 09:57:14 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id JAA02476; Wed, 7 Aug 1996 09:50:34 -0700 (PDT) Message-Id: <199608071650.JAA02476@aland.bbn.com> To: David Borman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 1999) Re: TCP & UDP over IPv6 Jumbograms In-Reply-To: Your message of Wed, 07 Aug 96 10:59:57 -0500. <199608071559.KAA11500@restless.BSDI.COM> Date: Wed, 07 Aug 96 09:50:33 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi. Attached is a short Internet-Draft that I wrote up after the March IETF meeting, but then forgot to do anything with it. This document proposes a method for allowing TCP and UDP to make use of IPv6 jumbograms. The only limiting factors that I am aware of are the TCP MSS option, and the UDP length field. I would like to see this document considered for the standards track. Dave: My quick sense was there are nasty problems if one end of a connection is IPv4 and one is IPv6. Imagine the IPv6 side sending a UDP jumbogram -- the IPv4 side will get a UDP jumbogram with a length=0. Ooops... Now the broader point is that use of jumbograms apparently precludes conversation with the IPv4 side. It seems to me the document ought to discuss this problem (and if any obvious ways to catch the problem exist, to mention them). Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Aug 7 13:30:37 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01450; Wed, 7 Aug 96 13:30:37 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01442; Wed, 7 Aug 96 13:30:23 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA06884; Wed, 7 Aug 1996 13:25:32 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA25101; Wed, 7 Aug 1996 13:25:19 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id NAA03100; Wed, 7 Aug 1996 13:23:56 -0700 (PDT) Message-Id: <199608072023.NAA03100@aland.bbn.com> To: David Borman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2000) Re: TCP & UDP over IPv6 Jumbograms In-Reply-To: Your message of Wed, 07 Aug 96 14:20:24 -0600. <199608072020.OAA12029@forge.BSDI.COM> Date: Wed, 07 Aug 96 13:23:55 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One of us is confused, and I'm not sure who... Dunno either -- there has certainly been a strain (perhaps now stomped out) in the community that in the transition to IPv6, IPv6 hosts would continue to be able to communicate (via TCP and UDP) with IPv4 hosts. Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Aug 7 13:52:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01481; Wed, 7 Aug 96 13:52:42 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01475; Wed, 7 Aug 96 13:52:28 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA10568; Wed, 7 Aug 1996 13:47:37 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA01852; Wed, 7 Aug 1996 13:47:24 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA09621; Wed, 7 Aug 96 13:44:23 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id NAA03299; Wed, 7 Aug 1996 13:44:06 -0700 Date: Wed, 7 Aug 1996 13:44:06 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199608072044.NAA03299@feller.mentat.com> To: dab@BSDI.com Subject: (IPng 2001) Re: TCP & UDP over IPv6 Jumbograms Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave, > > 2. UDP Jumbograms > > Because the UDP length field includes the UDP header, the minimum > valid value for this field is 8. > > To send a UDP packet with a UDP length > 65535, set the UDP length > field to zero, and the IPv6 length field to correctly reflect the > length of the UDP packet. > > If a UDP packet arrives with a length field of zero, the UDP > The section of text above seems to imply that the IPv6 header length field can contain a value larger than 65536. Last I checked it was only 16 bits. I assume you mean that the length in the jumbo payload option would reflect the true length of the UDP packet. The IPv6 header length field would need to be zero. I think that is what the base IPv6 specification says one should do when using the jumbo payload option. Does this synchronize with your understanding? Tim Hartrick ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Aug 7 14:06:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01501; Wed, 7 Aug 96 14:06:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01428; Wed, 7 Aug 96 13:25:44 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA06133; Wed, 7 Aug 1996 13:20:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA23623; Wed, 7 Aug 1996 13:20:37 -0700 Received: from forge.BSDI.COM (forge.BSDI.COM [205.230.224.24]) by external.BSDI.COM (8.7.4/8.7.3) with ESMTP id OAA06419; Wed, 7 Aug 1996 14:20:24 -0600 (MDT) Received: (from dab@localhost) by forge.BSDI.COM (8.7.5/8.7.3) id OAA12029; Wed, 7 Aug 1996 14:20:24 -0600 (MDT) Date: Wed, 7 Aug 1996 14:20:24 -0600 (MDT) From: David Borman Message-Id: <199608072020.OAA12029@forge.BSDI.COM> To: craig@aland.bbn.com Subject: (IPng 2002) Re: TCP & UDP over IPv6 Jumbograms Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, One of us is confused, and I'm not sure who... > My quick sense was there are nasty problems if one end of a connection > is IPv4 and one is IPv6. > > Imagine the IPv6 side sending a UDP jumbogram -- the IPv4 side will get > a UDP jumbogram with a length=0. Ooops... > > Now the broader point is that use of jumbograms apparently precludes > conversation with the IPv4 side. It seems to me the document ought to discuss > this problem (and if any obvious ways to catch the problem exist, to mention > them). I was under the impression that you talk IPv6 <-> IPv6, and IPv4 <-> IPv4, but not IPv6 <-> IPv4. The latter involves translation between IPv6 and IPv4 headers. If you do IPv6 <-> IPv4 packet translation, then yes, there are issues with TCP and UDP over jumbograms. Can someone clarify this? I looked over RFC 1933, "Transition Mechanisms for IPv6 Hosts and Routers", and it doesn't say anything about doing packet translation (at least I didn't find anything). So my assumption at this point is that I don't need to add anything about this issue. -David Borman, dab@bsdi.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Aug 7 14:25:17 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01536; Wed, 7 Aug 96 14:25:17 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01530; Wed, 7 Aug 96 14:25:05 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA16727; Wed, 7 Aug 1996 14:20:14 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA12499; Wed, 7 Aug 1996 14:19:34 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id VA07928; Thu, 8 Aug 1996 07:18:30 +1000 (from kre@munnari.OZ.AU) To: David Borman Cc: craig@aland.bbn.com, ipng@sunroof.eng.sun.com Subject: (IPng 2003) Re: TCP & UDP over IPv6 Jumbograms In-Reply-To: Your message of "Wed, 07 Aug 1996 14:20:24 CST." <199608072020.OAA12029@forge.BSDI.COM> Date: Thu, 08 Aug 1996 07:18:22 +1000 Message-Id: <10143.839452702@munnari.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 7 Aug 1996 14:20:24 -0600 (MDT) From: David Borman Message-ID: <199608072020.OAA12029@forge.BSDI.COM> One of us is confused, and I'm not sure who... I think Craig is... > Imagine the IPv6 side sending a UDP jumbogram -- the IPv4 side will get > a UDP jumbogram with a length=0. Ooops... Even assuming that it were possible for an IPv6 node to send directly to an IPv4 node, how on earth is an IPv6 jumbogram going to be transmitted to the IPv4 node? IPv4 only allows packets to 64Kb (-1), hence no jumbograms can ever be sent to IPv4, however any other translation might be done. It hardly seems to matter what thing that is inside the jumbogram (TCP, UDP, ICMP, or other) looks like. As long as the assumption is made, and stated, that your variation is only used inside jumbograms, I think you can forget about compatability with IPv4 (doesn't even need mentioning). Further, last I rememember (which may be incorrect), there was no way to fragment a jumbogram (they're sent as one packet or not sent at all, which is a perfectly rational, even brilliant, decision). Not that this is probably immediately relevant. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Aug 7 14:29:46 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01558; Wed, 7 Aug 96 14:29:46 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01549; Wed, 7 Aug 96 14:29:27 PDT Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA17465; Wed, 7 Aug 1996 14:24:36 -0700 Received: by venus.Sun.COM (Sun.COM) id OAA25220; Wed, 7 Aug 1996 14:24:35 -0700 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id RAA23042; Wed, 7 Aug 1996 17:27:33 -0400 Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA23503; Wed, 7 Aug 96 17:24:33 EDT Date: Wed, 7 Aug 96 17:24:33 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9608072124.AA23503@pobox.BayNetworks.com> To: craig@aland.bbn.com, dab@BSDI.COM Subject: (IPng 2004) Re: TCP & UDP over IPv6 Jumbograms Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Can someone clarify this? I looked over RFC 1933, "Transition Mechanisms > for IPv6 Hosts and Routers", and it doesn't say anything about doing packet > translation (at least I didn't find anything). So my assumption at this > point is that I don't need to add anything about this issue. > > -David Borman, dab@bsdi.com > IPv6<->IPv4 is not a part of the current IPv6 *transition* strategy. Nevertheless it does not mean that the possibility of eventually defining and implementing packet translation has beed ruled out. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Aug 7 14:30:35 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01574; Wed, 7 Aug 96 14:30:35 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01563; Wed, 7 Aug 96 14:30:13 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA17644; Wed, 7 Aug 1996 14:25:19 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA13859; Wed, 7 Aug 1996 14:23:46 -0700 Received: (dino@localhost) by stilton.cisco.com (8.6.12/8.6.5) id OAA07442; Wed, 7 Aug 1996 14:22:05 -0700 Date: Wed, 7 Aug 1996 14:22:05 -0700 From: Dino Farinacci Message-Id: <199608072122.OAA07442@stilton.cisco.com> To: dab@BSDI.COM Cc: craig@aland.bbn.com, ipng@sunroof.eng.sun.com In-Reply-To: <199608072020.OAA12029@forge.BSDI.COM> (message from David Borman on Wed, 7 Aug 1996 14:20:24 -0600 (MDT)) Subject: (IPng 2005) Re: TCP & UDP over IPv6 Jumbograms Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> I was under the impression that you talk IPv6 <-> IPv6, and IPv4 <-> IPv4, >> but not IPv6 <-> IPv4. The latter involves translation between IPv6 and >> IPv4 headers. If you do IPv6 <-> IPv4 packet translation, then yes, there >> are issues with TCP and UDP over jumbograms. Yes, and if you translate headers your more than likely to use IPv4 compatible IPv6 addresses. So when the IPv6 jumbogram builder sees the destination address as IPv4 compatible, it uses traditional datagram sizes. Dave, maybe your draft should say "if the destination is jumbogram capable, then you may do.....". Then later define what is and is not jumbogram capable. Dino ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Aug 8 00:33:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA01902; Thu, 8 Aug 96 00:33:07 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA01896; Thu, 8 Aug 96 00:32:52 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA25059; Thu, 8 Aug 1996 00:28:00 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA10227; Thu, 8 Aug 1996 00:27:59 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id JAA10656; Thu, 8 Aug 1996 09:27:56 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA11836; Thu, 8 Aug 1996 09:27:55 +0200 Message-Id: <9608080727.AA11836@dxcoms.cern.ch> Subject: (IPng 2006) Re: TCP & UDP over IPv6 Jumbograms To: dhaskin@baynetworks.com (Dimitry Haskin) Date: Thu, 8 Aug 1996 09:27:54 +0200 (MET DST) From: "Brian Carpenter CERN-CN" Cc: craig@aland.bbn.com, dab@BSDI.COM, ipng@sunroof.eng.sun.com In-Reply-To: <9608072124.AA23503@pobox.BayNetworks.com> from "Dimitry Haskin" at Aug 7, 96 05:24:33 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dimitry, > > > > Can someone clarify this? I looked over RFC 1933, "Transition Mechanisms > > for IPv6 Hosts and Routers", and it doesn't say anything about doing packet > > translation (at least I didn't find anything). So my assumption at this > > point is that I don't need to add anything about this issue. > > > > -David Borman, dab@bsdi.com > > > IPv6<->IPv4 is not a part of the current IPv6 *transition* strategy. > Nevertheless it does not mean that the possibility of eventually > defining and implementing packet translation has beed ruled out. > That is strictly speaking correct, but the whole point of adopting a dual-stack transition plan is to avoid ever having to open this Pandora's box. As far as jumbograms are concerned it is perfectly clear that they don't mix with IPv4 hosts. A hypothetical IPv6 to IPv4 translator would discard them. Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Aug 8 12:26:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02319; Thu, 8 Aug 96 12:26:44 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA02313; Thu, 8 Aug 96 12:26:31 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA13761; Thu, 8 Aug 1996 12:21:40 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA13880; Thu, 8 Aug 1996 12:21:39 -0700 Received: from pferguso-pc.cisco.com (c1robo14.cisco.com [171.68.13.14]) by lint.cisco.com (8.6.12/CISCO.SERVER.1.1) with SMTP id MAA14092; Thu, 8 Aug 1996 12:22:44 -0700 Message-Id: <199608081922.MAA14092@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 08 Aug 1996 15:21:34 -0400 To: dhaskin@BayNetworks.com (Dimitry Haskin) From: Paul Ferguson Subject: (IPng 2007) Re: TCP & UDP over IPv6 Jumbograms Cc: ipng@sunroof.eng.sun.com, brian@dxcoms.cern.ch, hcb@clark.net Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 05:24 PM 8/7/96 EDT, Dimitry Haskin wrote: >IPv6<->IPv4 is not a part of the current IPv6 *transition* strategy. >Nevertheless it does not mean that the possibility of eventually >defining and implementing packet translation has beed ruled out. > Thank you for stating this. It happens to be a premise in a draft that I'm working on for the PIER WG. :-) - paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Aug 8 13:48:01 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02403; Thu, 8 Aug 96 13:48:01 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA02397; Thu, 8 Aug 96 13:47:47 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA27445; Thu, 8 Aug 1996 13:42:55 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA09214; Thu, 8 Aug 1996 13:42:55 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <14572(7)>; Thu, 8 Aug 1996 13:42:41 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Thu, 8 Aug 1996 13:42:28 PDT To: David Borman Cc: ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2008) Re: TCP & UDP over IPv6 Jumbograms In-Reply-To: dab's message of Wed, 07 Aug 96 08:59:57 -0800. <199608071559.KAA11500@restless.BSDI.COM> Date: Thu, 8 Aug 1996 13:42:27 PDT From: Steve Deering Message-Id: <96Aug8.134228pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave, Thanks for submitting your jumbogram draft. First, regarding the IP6->IPv4 translation issue: as Dimitry said, the "official" transition plan does not include header translation, but we have tried not to do anything in the IPv6 design that would unnecessarily hinder or defeat the use of translators. According to recent reports on either the ipv6-implementors list or the 6bone list, IPv6<->IPv4 translation was demo'ed at the Tokyo Interop a few weeks ago, so clearly some folks are working on that approach. *Nonetheless*, I don't think your proposal in any way hinders translation, or requires any additional language to cover translation issues. In the case of UDP, if an IPv6 source sends a UDP jumbogram towards an IPv4 destination, the source will get back a packet-too-big ICMP message from the translator, if not from a router earlier in the path. Normal IPv6 MTU Discovery mechanisms will cause the source to then reduce its maximum packet size for that destination, to something less than jumbo size. In the case of TCP, if an IPv6 node sends an MSS option of 65535 to an IPv4 node, the IPv4 node won't interpret that as "infinity", but it will still interpret it as a very big value -- larger than any packet it could actually send -- which ought to result in acceptable behavior. Contrary to Dino's suggestion, I don't think that the IPv6 node has any reason to condition its behavior on the address type of the destination, in either the UDP or the TCP case. On to some coments on your draft: > 1. Overview > > IPv6 supports datagrams larger than 65535 bytes long, called > jumbograms. The UDP protocol has a 16 length field ... Change "16 length" to 16-bit length". > 2. UDP Jumbograms > > To send a UDP packet with a UDP length > 65535, set the UDP length > field to zero, and the IPv6 length field to correctly reflect the > length of the UDP packet. > > If a UDP packet arrives with a length field of zero, the UDP > length should be ignored, and the length field from the pseudo > header should be used. I suggest the following rewording, which is more verbose but I think less likely to leave any misunderstandings: When sending a UDP packet, if and only if the length of the UDP header plus data is greater than 65,535, set the length field in the UDP header to zero. Note 1: The length used in the "pseudo-header" for computing the UDP checksum is always the true length of the UDP header plus data, NOT zero [RFC-1883, Section 8.1]. Note 2: An IPv6 packet that carries a UDP packet of length greater than 65,535 will necessarily carry a Jumbo Payload option in a Hop-by-Hop Options header [RFC1883, Section 4.3]). The length field in the Jumbo Payload option contains the length of the IP packet excluding the IPv6 header, that is, it contains the length of all extension headers present plus the UDP header plus the UDP data. The length field in the IPv6 header contains zero to indicate the presence of the Jumbo Payload option. If a UDP packet is received with a length field of zero, the length of the UDP packet is computed from the the length field in the Jumbo Payload option minus the length of all extension headers present between the IPv6 header and the UDP header. Regarding the "if and only if" clause in the sending rules, in theory we *could* allow the use of zero in the UDP length field for *all* UDP packets, regardless of size, since the receivers can always compute the UDP length from the IP length. However, that *would* cause trouble (or at least extra work) for v6->v4 translators. Therefore, my suggested language restricts the use of the zero UDP length to *only* those UDP packets longer than 65,535. Note, by the way, that the presence of a Jumbo Payload option in an IPv6/UDP packet does not necessarily imply that the UDP packet itself is greater than 65,535 -- there may be extension headers present that force the IP length over 65,535, regardless of the UDP length. The TCP section looks fine to me, as is. Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Aug 8 14:39:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02474; Thu, 8 Aug 96 14:39:25 PDT Received: from pacific.eng.sun.com by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA02468; Thu, 8 Aug 96 14:39:09 PDT Received: from picadilly.eng.sun.com by pacific.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA04858; Thu, 8 Aug 1996 14:34:17 -0700 Received: from picadilly by picadilly.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA04833; Thu, 8 Aug 1996 14:31:56 -0700 Message-Id: <199608082131.OAA04833@picadilly.eng.sun.com> To: David Borman Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2009) Re: TCP & UDP over IPv6 Jumbograms Date: Thu, 08 Aug 1996 14:31:56 -0700 From: Steve Parker Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk - This document proposes a method for allowing TCP and UDP to - make use of IPv6 jumbograms. The only limiting factors that - I am aware of are the TCP MSS option, and the UDP length - field. Both the TCP window size and urgent pointers are 16-bit values. Although relief for the window size exists, you should explicitly reference RFC 1323. (If you haven't got window scaling, I can't see what good jumbogram support would be.) Personally, I shudder to think what happens in practice to TCPs when confronted with MSS > window size. Since I can't put an offset of > 64K in the urgent pointer, if there is an urgent mark must I make sure to send a partial MSS segment if it would fall, say, at 96K into a segment? I think this at least deserves some discussion and comment. Effectively, when your MSS is > 64K, the urgent indication doesn't get sent very "urgently" since you can't send it until you're within 64K of the mark in the stream. Cheers, ~sparker ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Aug 8 15:19:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02538; Thu, 8 Aug 96 15:19:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA02522; Thu, 8 Aug 96 15:15:54 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA12976; Thu, 8 Aug 1996 15:10:59 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA09185; Thu, 8 Aug 1996 15:10:50 -0700 Received: from forge.BSDI.COM (forge.BSDI.COM [205.230.224.24]) by external.BSDI.COM (8.7.4/8.7.3) with ESMTP id QAA03409; Thu, 8 Aug 1996 16:10:47 -0600 (MDT) Received: (from dab@localhost) by forge.BSDI.COM (8.7.5/8.7.3) id QAA12611; Thu, 8 Aug 1996 16:10:47 -0600 (MDT) Date: Thu, 8 Aug 1996 16:10:47 -0600 (MDT) From: David Borman Message-Id: <199608082210.QAA12611@forge.BSDI.COM> To: sparker@caribe-86.eng.sun.com Subject: (IPng 2010) Re: TCP & UDP over IPv6 Jumbograms Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Steve. Thanks for the response. > From sparker@caribe-86.Eng.Sun.COM Thu Aug 8 15:34:58 1996 > To: David Borman > cc: ipng@sunroof.Eng.Sun.COM > Subject: Re: (IPng 1998) TCP & UDP over IPv6 Jumbograms > Date: Thu, 08 Aug 1996 14:31:56 -0700 > From: Steve Parker > > > - This document proposes a method for allowing TCP and UDP to > - make use of IPv6 jumbograms. The only limiting factors that > - I am aware of are the TCP MSS option, and the UDP length > - field. > > Both the TCP window size and urgent pointers are 16-bit values. > Although relief for the window size exists, you should explicitly > reference RFC 1323. (If you haven't got window scaling, I can't see > what good jumbogram support would be.) Personally, I shudder to think > what happens in practice to TCPs when confronted with MSS > window > size. I didn't mention the TCP window, because that problem is addressed via the window shift option. But it would probably be good to at least put in a reference to this. > Since I can't put an offset of > 64K in the urgent pointer, if there > is an urgent mark must I make sure to send a partial MSS segment > if it would fall, say, at 96K into a segment? I think this at least > deserves some discussion and comment. > > Effectively, when your MSS is > 64K, the urgent indication doesn't > get sent very "urgently" since you can't send it until you're within > 64K of the mark in the stream. *Sigh* The urgent pointer isn't an issue in IPv4 with expanded windows, because you can keep using 65535 to push the pointer into the next packet. That's why the TCP extensions don't include a 32-bit Urgent Pointer option. But as you correctly point out, that trick won't work for Jumbograms. I can think of three different ways to address this: 1) Outlaw the use of the urgent pointer with jumbograms. 2) Add a 32-bit TCP Urgent Pointer option. (When sending the Urgent Pointer option, the URG bit is *not* set, since that implies the Urgent field is valid.) 3) A multi-step approach (which you alluded to): o State that an urgent pointer of 65535 means that the urgent pointer is beyond the end of this packet. o When sending a jumbogram, if the urgent pointer falls within the packet, but beyond 65534, then it must be sent as two packet. The first packet contains data up to, but not including the urgent pointer, and then the rest is sent in the second packet, and the urgent pointer is now within range. #1 is the easiest, but is looses functionality. #2 is the cleanest, but requires the implementation of a new TCP option. #3 retains functionality, avoids a new TCP option and adds a minimal amount of processing for the input side, but at the cost of a bit of complexity on the output side. I should also point out that if a new TCP option is added, there doesn't have to be any negotiation of it up front. This is because TCP implementations are supposed to ignore unknow options. Any TCP/IPv6 that doesn't understand the Urgent Pointer option, and doesn't correctly ignore it, is broken. It doesn't apply to IPv4, so we don't have to worry about legacy systems. Which of these to people like best, or does some else have a better solution? -David Borman, dab@bsdi.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Aug 8 15:19:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA02549; Thu, 8 Aug 96 15:19:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA02543; Thu, 8 Aug 96 15:19:30 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA13583; Thu, 8 Aug 1996 15:14:36 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA10373; Thu, 8 Aug 1996 15:14:33 -0700 Received: from munin.fnal.gov ("port 1566"@munin.fnal.gov) by FNAL.FNAL.GOV (PMDF V5.0-5 #3998) id <01I81HD1N8WE001NZK@FNAL.FNAL.GOV>; Thu, 08 Aug 1996 17:14:30 -0600 (CST) Received: from localhost.fnal.gov by munin.fnal.gov (8.7.3/SMI-4.1-m) id RAA07525; Thu, 08 Aug 1996 17:12:50 -0500 (CDT) Date: Thu, 08 Aug 1996 17:12:43 -0500 From: Matt Crawford Subject: (IPng 2011) Re: TCP & UDP over IPv6 Jumbograms In-Reply-To: "08 Aug 1996 14:31:56 PDT." <"199608082131.OAA04833"@picadilly.eng.sun.com> To: Steve Parker Cc: David Borman , ipng@sunroof.eng.sun.com Message-Id: <199608082212.RAA07525@munin.fnal.gov> Content-Transfer-Encoding: 7BIT X-Face: /RKQi"kntyd}7l)d8n%'Dum<~(aMW3,5g&'NiH5I4Jj|wT:j;Qa$!@A<~/*C:{:MmAQ:o%S /KKi}G4_.||4I[9!{%3]Hd"a*E{ Since I can't put an offset of > 64K in the urgent pointer, if there > is an urgent mark must I make sure to send a partial MSS segment > if it would fall, say, at 96K into a segment? I think this at least > deserves some discussion and comment. I suppose if someone urgently needs an extended urgent pointer they can define a new TCP option for it. Then when we accumulate enough options which are widely-implemented, someone will propose they all be bundled into a TCPng. (And then others will protest that TCPng doesn't have any radically new features!) _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab PGP: D5 27 83 7A 25 25 7D FB 09 3C BA 33 71 C4 DA 6A ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Aug 9 08:48:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03031; Fri, 9 Aug 96 08:48:52 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA03025; Fri, 9 Aug 96 08:48:39 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA14520; Fri, 9 Aug 1996 08:43:45 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA20600; Fri, 9 Aug 1996 08:43:45 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id IAA06719; Fri, 9 Aug 1996 08:42:28 -0700 (PDT) Message-Id: <199608091542.IAA06719@aland.bbn.com> To: Steve Deering Cc: David Borman , ipng@sunroof.eng.sun.com Subject: (IPng 2012) Re: TCP & UDP over IPv6 Jumbograms In-Reply-To: Your message of Thu, 08 Aug 96 13:42:27 -0700. <96Aug8.134228pdt."75270"@digit.parc.xerox.com> Date: Fri, 09 Aug 96 08:42:28 -0700 From: Craig Partridge Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk *Nonetheless*, I don't think your proposal in any way hinders translation, or requires any additional language to cover translation issues. In the case of UDP, if an IPv6 source sends a UDP jumbogram towards an IPv4 destination, the source will get back a packet-too-big ICMP message from the translator, if not from a router earlier in the path. Normal IPv6 MTU Discovery mechanisms will cause the source to then reduce its maximum packet size for that destination, to something less than jumbo size. In the case of TCP, if an IPv6 node sends an MSS option of 65535 to an IPv4 node, the IPv4 node won't interpret that as "infinity", but it will still interpret it as a very big value -- larger than any packet it could actually send -- which ought to result in acceptable behavior. Steve, I know you like to leave things out of documents, but I think that's a disservice to later readers. If there's a known solution, why not write it down? My inclination would be to just put these two paragraphs in the document under transition issues. Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Aug 9 09:16:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03076; Fri, 9 Aug 96 09:16:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA02997; Fri, 9 Aug 96 06:21:44 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA29334; Fri, 9 Aug 1996 06:16:51 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA12863; Fri, 9 Aug 1996 06:16:51 -0700 Received: from [168.143.1.215] (hcb-ppp.clark.net [168.143.1.215]) by mail.Clark.Net (8.7.3/8.6.5) with SMTP id JAA00505; Fri, 9 Aug 1996 09:16:23 -0400 (EDT) Date: Fri, 9 Aug 1996 09:16:23 -0400 (EDT) X-Sender: hcb@mail.clark.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: ipng@sunroof.eng.sun.com, brian@dxcoms.cern.ch From: hcb@CLARK.net (Howard C. Berkowitz) Subject: (IPng 2013) Was TCP/UDP over IPv6....Misdirected reply to list Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OOPS! I inadvertently replied to the list as a whole when I was redirecting a note to Paul. Apologies. The interaction of EITHER v4 or v6 address translation with TCP or UDP, however, remains interesting! Howard ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Aug 9 09:17:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03088; Fri, 9 Aug 96 09:17:48 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA02929; Fri, 9 Aug 96 05:04:12 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA24785; Fri, 9 Aug 1996 04:59:18 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA00746; Fri, 9 Aug 1996 04:59:19 -0700 Received: from [168.143.1.215] (hcb-ppp.clark.net [168.143.1.215]) by mail.Clark.Net (8.7.3/8.6.5) with SMTP id HAA17655; Fri, 9 Aug 1996 07:59:07 -0400 (EDT) Date: Fri, 9 Aug 1996 07:59:07 -0400 (EDT) X-Sender: hcb@mail.clark.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Paul Ferguson From: hcb@CLARK.net (Howard C. Berkowitz) Subject: (IPng 2014) Was--TCP & UDP over IPv6 Jumbograms...now packet translation Cc: ipng@sunroof.eng.sun.com, brian@dxcoms.cern.ch Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Paul, I've been doing an OSPF seminar at Lucent this week, and I've gotten an urgent request from them for a design teleconference this afternoon. Their immediate concern is the implementation of what they are calling "proxyless gateways" in their backbones. These backbones are mostly Cisco; the Wellfleet is mostly in local areas. Can you give me a pointer -- machine-readable from outside Cisco, or to a person inside Cisco -- to specifics of how the 11.2 NAT implementation deals with the implications of IP address information above the IP layer (e.g., TCP/UDP checksums, IP addresses in SNMP/FTP, etc.)? The literature I've seen so far is really at a sales level, and doesn't make it clear if and how more than the pure IP header translation takes place. There are some vague references to port mapping, but I don't have a real sense of what it does. I would guess it has some way of dealing with at least the TCP/UDP checksums, but that's purely a guess. I then have to find out what Lucent means by a "proxyless gateway," and how it relates to classical and/or real NAT. I'm also getting conflicting statements that they are looking at the technology either for address space management or for firewalling. It is my theory that a true consultant, in understanding the client's terminology, must be conversant with the theory that the Odyssey was not written by Homer, but by another Greek of the same name. Is it that way in Cisco Consulting Engineering? :-) Howard At 3:21 PM 8/8/96, Paul Ferguson wrote: >At 05:24 PM 8/7/96 EDT, Dimitry Haskin wrote: > >>IPv6<->IPv4 is not a part of the current IPv6 *transition* strategy. >>Nevertheless it does not mean that the possibility of eventually >>defining and implementing packet translation has beed ruled out. >> > >Thank you for stating this. It happens to be a premise in a draft >that I'm working on for the PIER WG. :-) > >- paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Aug 9 15:36:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03373; Fri, 9 Aug 96 15:36:12 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA03367; Fri, 9 Aug 96 15:35:59 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA10335; Fri, 9 Aug 1996 15:31:04 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA06831; Fri, 9 Aug 1996 09:28:39 -0700 Received: from digit.parc.xerox.com ([13.2.117.114]) by alpha.xerox.com with SMTP id <15053(3)>; Fri, 9 Aug 1996 09:23:04 PDT Received: from localhost by digit.parc.xerox.com with SMTP id <75270>; Fri, 9 Aug 1996 09:20:49 PDT To: Craig Partridge Cc: David Borman , ipng@sunroof.eng.sun.com, deering@parc.xerox.com Subject: (IPng 2015) Re: TCP & UDP over IPv6 Jumbograms In-Reply-To: craig's message of Fri, 09 Aug 96 08:42:28 -0800. <199608091542.IAA06719@aland.bbn.com> Date: Fri, 9 Aug 1996 09:20:49 PDT From: Steve Deering Message-Id: <96Aug9.092049pdt."75270"@digit.parc.xerox.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Steve, I know you like to leave things out of documents, but I think that's > a disservice to later readers. If there's a known solution, why not write > it down? Craig, I didn't identify a solution; I pointed out the lack of a problem. If the document were to list all of the problems that it didn't cause, it would be a very long document indeed. :-) > My inclination would be to just put these two paragraphs in the document > under transition issues. That's up to Dave; if it were me, I would leave them out, because they'd just create more questions than they would answer (What? IPv6 <-> IPv4 translation works? Then why do I have to do all this dual-stack stuff? How does IPSEC work through translators? For that matter, how are 32-bit addresses translated into 128-bit addresses? What the heck is goin' on??) Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Aug 9 18:05:30 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA03718; Fri, 9 Aug 96 18:05:30 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA03712; Fri, 9 Aug 96 18:05:16 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA15585; Fri, 9 Aug 1996 18:00:24 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA11367; Fri, 9 Aug 1996 17:59:59 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) id BAA23661; Sat, 10 Aug 1996 01:58:25 +0100 Date: Sat, 10 Aug 1996 01:58:25 +0100 Message-Id: <199608100058.BAA23661@oberon.di.fc.ul.pt> From: Pedro Roque Marques To: ipng@sunroof.eng.sun.com Subject: (IPng 2016) Link-local addresses and NUD on tunnels Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There has been some discussion on the 6bone about if tunnels should have a link local address on each side and if NUD should be performed. As it seams to me that there is no consensus still in the group about this issues and i feel it is important to clarify that as soon as possible because two implementation using different approaches are likely not to be able to interoperate. I can give you my view about the issue although it might lack careful consideration of the matter... Currently i'm not using either link-local addresses or NUD. reasons: 1) I don't really see the usefulness of link-local addresses on tunnels. 2) NUD can be a waste of bandwidth. The tunnel i run presently gets about 1 second rtt and about 50% packet loss. In this conditions your first thought is to minimise the overhead. On 1) ipv4-compatible addresses are by themself quasi-linklocal addresses. I don't consider a good idea to route them, or that they are legal on packets with provider-based-addresses (pba). Consider a packet with source_addr=v6-pba and dest_addr=v4-compat. By the current transition plan the originating host should send them over it's auto-tunnelling device, but lets suppose it doesn't and sends to default router. The corresponding node will most likely not know where to send packets in response since he might not have native-v6 connectivity*. Also packet on the form source_addr=v4-compat to dest_addr=v6-pba will most likely create a ugly assimetric path when the correspondent answers. * If it does i cannot think of a good reason to use the v4-compat address instead of v6-pba address. I'm not considering lack off DNS updates to the zone a good technical reason. The only scenario that seams sane is to use reversible routing headers (We don't know yet if rt_header type 0 is mandatory reverse or not right ?) so that a path [ v6-pba - v6-pba - ... - v6-pba/v4-compat* - v4-compat ] could be formed. * those would have to be on the same host. Also, Bob Hiden mentioned the usefulness of link-local addresses for renumbering but it is not a issue in this case. On 2) NUD is quite tied with address resolution in the sense that the same state machine and the same packet formats do ARP and NUD. Address resolution is really not necessary on tunnels. Reading the neighbour discovery draft one sees that NUD is required also over NBMAs, so if we consider a tunnel a PVC on an NBMA, NUD is indeed required. But i belive that is more reasonable, in this case, to have link state detection on the routing protocol (like Steve Deering suggested in the 6bone list). What ND mandates on detection of path failure is to "redo next hop determination" which in my reading refers to neighbour cache entries (for which a pointer is usually cached in a socket) not in terms of updating the routing table itself. Well, i hope the above is not a set of completly uninformed mistakes. But even if it is i would like this issue to be made clear. regards, Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Aug 11 11:33:38 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04159; Sun, 11 Aug 96 11:33:38 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04153; Sun, 11 Aug 96 11:33:25 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA01988; Sun, 11 Aug 1996 11:28:27 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA28728; Sun, 11 Aug 1996 11:28:28 -0700 Received: by iol.unh.edu (4.1/SMI-4.1) id AA12491; Sun, 11 Aug 96 14:23:33 EDT Date: Sun, 11 Aug 96 14:23:33 EDT From: qv@iol.unh.edu (Quaizar Vohra) Message-Id: <9608111823.AA12491@iol.unh.edu> To: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Pedro Roque Marques wrote : > > >There has been some discussion on the 6bone about if tunnels should >have a link local address on each side and if NUD should be >performed. As it seams to me that there is no consensus still in the >group about this issues and i feel it is important to clarify that as >soon as possible because two implementation using different approaches >are likely not to be able to interoperate. > >I can give you my view about the issue although it might lack careful >consideration of the matter... > >Currently i'm not using either link-local addresses or NUD. >reasons: > 1) I don't really see the usefulness of link-local addresses on >tunnels. > 2) NUD can be a waste of bandwidth. The tunnel i run presently gets >about 1 second rtt and about 50% packet loss. In this conditions your >first thought is to minimise the overhead. Well, I have some similar views. I had written a mail to Steve, Dimitry and Alain about the two views people have about tunneling interface. I didnot bring it up on the list fearing that I might be totally stupid. My view of tunnelng is as follows ( many people have the same view and many don't ) I think tunnel interface is on-link to ::0.0.0.0/96 subnet. So it is on a single nbma cloud consisting of all v4-compatible address. So automatically I have a route to ::/96 via the interface. Configured tunnels are nothing but routes with next hop as some v4-compatible address, which are all on-link to this interface now. (I think is a nice elagant thing). Now as Pedro mentioned that v4-compatible addresses are quasi link-local. I agree and disagree. Sometimes back Brian had pointed out the usefulness of v4-compatible addresses as global addresses for isolated list, which I agreed after some sulking. Now I think tunnel interface should have link-local addresses which are fe80::v4-address. Though not much different from v4-compatible addresses, they atleast maintain consistency to the notion of link-localnees and having them for routing protocols where next-hops should be link-local. But now I propose that v4-compaible addresses also co-exist as global addresses for the sake of isolated nodes only. My proposal is that only isolated nodes have these as global addresses, while encapsulating routers on the edges of IPv6 clouds with global prefix do not assign v4-compatible address to their tunnel interface but only use link-local address. The purpose of link-local address now being used for designating next-hops in case of routes over tunnels which are configured tunnels for me. So all tunnneling interface know that ::/96 is on-link but only isolated nodes use this for autoconfiguration of their global address. Another imporatant point it solves is that, those dual nodes at edges of v6 domains won't use v4-compatible or link-local (fe80::v4-addr) address as source address of normal packets (i.e. other than NUD or RIPng), which has been proved to be a problem, when choosing source addresses on such edge nodes even though they have global v6-prefix based addresses. Definitely the disadvantage is as that now tunnel is a multi-access interface where mutlicasting is a problem and hence may not be good for protocols like RIPng. But I don't think a node should have too many interfaces, one per tunnel (treating it as pt-to-pt interface) so that multicasting can be done easily. Thanks, Quaizar > >On 1) > >ipv4-compatible addresses are by themself quasi-linklocal >addresses. I don't consider a good idea to route them, or that they >are legal on packets with provider-based-addresses (pba). >Consider a packet with source_addr=v6-pba and dest_addr=v4-compat. By the >current transition plan the originating host should send them over >it's auto-tunnelling device, but lets suppose it doesn't and sends to >default router. The corresponding node will most likely >not know where to send packets in response since he might not have >native-v6 connectivity*. Also packet on the form source_addr=v4-compat to >dest_addr=v6-pba will most likely create a ugly assimetric path when >the correspondent answers. > >* If it does i cannot think of a good reason to use the v4-compat >address instead of v6-pba address. I'm not considering lack off DNS >updates to the zone a good technical reason. > >The only scenario that seams sane is to use reversible routing >headers (We don't know yet if rt_header type 0 is mandatory reverse or >not right ?) so that a path [ v6-pba - v6-pba - ... - v6-pba/v4-compat* - >v4-compat ] could be formed. >* those would have to be on the same host. > >Also, Bob Hiden mentioned the usefulness of link-local addresses for >renumbering but it is not a issue in this case. > >On 2) >NUD is quite tied with address resolution in the sense that the same >state machine and the same packet formats do ARP and NUD. Address >resolution is really not necessary on tunnels. Reading the neighbour >discovery draft one sees that NUD is required also over NBMAs, so if >we consider a tunnel a PVC on an NBMA, NUD is indeed required. But i >belive that is more reasonable, in this case, to have link state >detection on the routing protocol (like Steve Deering suggested in the >6bone list). >What ND mandates on detection of path failure is to "redo next hop >determination" which in my reading refers to neighbour cache entries >(for which a pointer is usually cached in a socket) not in terms of >updating the routing table itself. > > >Well, i hope the above is not a set of completly uninformed >mistakes. But even if it is i would like this issue to be made clear. > >regards, > Pedro. > > >------------------------------------------------------------------------------ >IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng >IPng Home Page: http://playground.sun.com/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com > -- ------------------------------------------------------ Quaizar Vohra Inter-Operatibility Lab. (IOL), Univ. of New Hampshire E-mail : qv@sun4.iol.unh.edu Phone : (603)-862-0090 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 12 04:12:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04390; Mon, 12 Aug 96 04:12:03 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04384; Mon, 12 Aug 96 04:11:50 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA07157; Mon, 12 Aug 1996 04:06:53 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA28226; Mon, 12 Aug 1996 04:06:41 -0700 Received: from inner.net (beavis.ipv6.nrl.navy.mil [132.250.90.8]) by inner.net (8.7.3/42) with ESMTP id SAA19666 for ; Sun, 11 Aug 1996 18:58:17 -0400 Message-Id: <199608112258.SAA19666@inner.net> To: ipng@sunroof.eng.sun.com Subject: (IPng 2017) FTP over IPv6: maybe not FOOBAR? X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Mon, 12 Aug 1996 07:04:51 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Having recently built a FTP client and server using FOOBAR, I am left seriously questioning the need to specify network endpoint addresses. In order to prevent the "FTP bounce attack," servers MUST check that the network address in PORT/LPRT commands match that of the control connection. Similarly, in order to prevent attacks, clients MUST check that the network address in the PASV/LPSV commands match that of the control control connection. So I am really questioning whether we should be sending any network address information in these commands. IMO, we already know a reasonable address for getting to the other side from our control connection, and, for security's sake, we must make sure we're using that address anyway. So it seems like a reasonable thing to me not to specify any network address information at all and instead only specify transport port information. As an aside, people who have made boxen that do NAT or transparent firewalling/proxying know that having to process the TCP connection to search and replace the network address in an FTP session in order to make sure the addresses appear correctly to each end is a major headache. It would be reduced, though maybe not eliminated, by omitting address information. So, I'd propose that, instead of using FOOBAR's LPRT and LPSV commands for IPv6, we use "short" versions instead: SPORT and SPASV. SPORT would have as arguments the port length and bytes as specified in FOOBAR. For example: "SPORT 2,4,240" SPASV would return in its success response the port length and bytes as specified in FOOBAR. For example: 200 Entering Passive Mode (2,4,240) Comments? -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 12 05:26:56 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04463; Mon, 12 Aug 96 05:26:56 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04457; Mon, 12 Aug 96 05:26:43 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA10944; Mon, 12 Aug 1996 05:21:45 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA06876; Mon, 12 Aug 1996 05:21:33 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id OAA12262; Mon, 12 Aug 1996 14:21:11 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.1/8.6.6) with ESMTP id OAA05329; Mon, 12 Aug 1996 14:21:11 +0200 (MET DST) Message-Id: <199608121221.OAA05329@givry.inria.fr> From: Francis Dupont To: Craig Metz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2018) Re: FTP over IPv6: maybe not FOOBAR? In-Reply-To: Your message of Mon, 12 Aug 1996 07:04:51 EDT. <199608112258.SAA19666@inner.net> Date: Mon, 12 Aug 1996 14:21:10 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Having recently built a FTP client and server using FOOBAR, I am left seriously questioning the need to specify network endpoint addresses. In order to prevent the "FTP bounce attack," servers MUST check that the network address in PORT/LPRT commands match that of the control connection. Similarly, in order to prevent attacks, clients MUST check that the network address in the PASV/LPSV commands match that of the control control connection. => can you describe: - the "FTP bounce attack" - how do you manage "three way" FTP service (perhaps you don't want it ?) (it is the figure #2 of RFC 959) Thanks Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 12 05:46:54 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04488; Mon, 12 Aug 96 05:46:54 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04482; Mon, 12 Aug 96 05:46:41 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA12093; Mon, 12 Aug 1996 05:41:43 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA10402; Mon, 12 Aug 1996 05:41:32 -0700 Received: from inner.net (beavis.ipv6.nrl.navy.mil [132.250.90.8]) by inner.net (8.7.3/42) with ESMTP id UAA19716; Sun, 11 Aug 1996 20:32:06 -0400 Message-Id: <199608120032.UAA19716@inner.net> To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2019) Re: FTP over IPv6: maybe not FOOBAR? In-Reply-To: Your message of "Mon, 12 Aug 1996 14:21:10 +0200." <199608121221.OAA05329@givry.inria.fr> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Mon, 12 Aug 1996 08:38:43 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199608121221.OAA05329@givry.inria.fr>, you write: >=> can you describe: > - the "FTP bounce attack" "*Hobbit*" has a good description at ftp.avian.org:/random/ftp-attack > - how do you manage "three way" FTP service (perhaps you don't want it ?) > (it is the figure #2 of RFC 959) You don't. The FTP bounce attack basically uses "three way" FTP to do its dirtywork. I've never seen a legitimate use for "three way" FTP (although I'm sure people can come up with theoretical uses), and I don't think it's unreasonable to de-implement it. -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 12 06:32:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04551; Mon, 12 Aug 96 06:32:24 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04545; Mon, 12 Aug 96 06:32:11 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA15131; Mon, 12 Aug 1996 06:27:14 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA19359; Mon, 12 Aug 1996 06:27:01 -0700 Received: from inner.net (beavis.ipv6.nrl.navy.mil [132.250.90.8]) by inner.net (8.7.3/42) with ESMTP id VAA19740; Sun, 11 Aug 1996 21:18:24 -0400 Message-Id: <199608120118.VAA19740@inner.net> To: Margaret Forsythe Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2020) Re: FTP over IPv6: maybe not FOOBAR? In-Reply-To: Your message of "Mon, 12 Aug 1996 09:02:05 EDT." <9608120902.aa03734@quern.epilogue.com> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Mon, 12 Aug 1996 09:25:02 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <9608120902.aa03734@quern.epilogue.com>, you write: >The PASV command and the ability to specify a different IP address for >the PORT command are specifically to allow one ftp client to set up >an FTP transfer between two *other* hosts (both running ftp servers). >Your proposal (it seems) would eliminate that possibility. Yes. I have never seen the three-way FTP used. I know of several FTP daemons that employ "*Hobbit*"'s bounce attack fix, which prevents users from doing a three-way FTP. I've never heard a single complaint about it. This leads me to believe that this is a "feature" that is not used. Also note that the reason the bounce attack works is that there is not really any security in the three-way configuration. This leads me to believe that this is a "feature" that should be reconsidered. >I am not familiar with the "bounce attack", but is it possible that >people with firewalls or other security measures in place (such as >encryption) would be unconcerned about this attack and still be >interest in setting up a proxy FTP transfer, as described above? I've never seen a FTP proxy use the three-way FTP mode. -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 12 10:08:36 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04745; Mon, 12 Aug 96 10:08:36 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04207; Sun, 11 Aug 96 12:48:36 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA05401; Sun, 11 Aug 1996 12:43:39 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA03574; Sun, 11 Aug 1996 12:43:38 -0700 Received: by mail.noris.net id <34840-16819>; Sun, 11 Aug 1996 21:43:35 +0100 Path: noris.net!not-for-mail From: smurf@noris.de (Matthias Urlichs) Newsgroups: dist.ipng Subject: (IPng 2021) Re: TCP & UDP over IPv6 Jumbograms Date: 11 Aug 1996 21:43:09 +0200 Organization: noris network GmbH, Nuernberg, FRG Lines: 26 Message-Id: <4uld4d$9b8@work.smurf.noris.de> References: <199608082210.QAA12611@forge.BSDI.COM> <839543543.4502@noris.de> Nntp-Posting-Host: work.smurf.noris.de Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit To: unlisted-recipients:;@mercury (no To-header on input) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David Borman writes: > > 1) Outlaw the use of the urgent pointer with jumbograms. > 2) Add a 32-bit TCP Urgent Pointer option. > 3) A multi-step approach: > o State that an urgent pointer of 65535 means that > the urgent pointer is beyond the end of this packet. > o When sending a jumbogram, if the urgent pointer > falls within the packet, but beyond 65534, then > it must be sent as two packet. > > Which of these to people like best, or does some else have > a better solution? > I'd use (1). In fact, I'd argue that anything you can do with an urgent pointer, I can do equally well by simply opening a second TCP connection... -- A grapefruit is a lemon that had a chance and took advantage of it. -- Oscar Wilde -- Matthias Urlichs \ noris network GmbH / Xlink-POP Nürnberg Schleiermacherstraße 12 \ Linux+Internet / EMail: urlichs@noris.de 90491 Nürnberg (Germany) \ Consulting+Programming+Networking+etc'ing PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE Click here. 42 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 12 10:36:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04789; Mon, 12 Aug 96 10:36:11 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04519; Mon, 12 Aug 96 06:07:59 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA13437; Mon, 12 Aug 1996 06:03:00 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA14546; Mon, 12 Aug 1996 06:02:50 -0700 From: Margaret Forsythe To: cmetz@inner.net Cc: ipng@sunroof.eng.sun.com In-Reply-To: Craig Metz's message of Mon, 12 Aug 1996 07:04:51 -0400 <199608112258.SAA19666@inner.net> Subject: (IPng 2022) FTP over IPv6: maybe not FOOBAR? Date: Mon, 12 Aug 96 09:02:05 -0400 Message-Id: <9608120902.aa03734@quern.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So I am really questioning whether we should be sending any network >address information in these commands. IMO, we already know a reasonable >address for getting to the other side from our control connection, and, for >security's sake, we must make sure we're using that address anyway. So it >seems like a reasonable thing to me not to specify any network address >information at all and instead only specify transport port information. The PASV command and the ability to specify a different IP address for the PORT command are specifically to allow one ftp client to set up an FTP transfer between two *other* hosts (both running ftp servers). Your proposal (it seems) would eliminate that possibility. I am not familiar with the "bounce attack", but is it possible that people with firewalls or other security measures in place (such as encryption) would be unconcerned about this attack and still be interest in setting up a proxy FTP transfer, as described above? mrf Margaret Forsythe mrf@epilogue.com Epilogue Technology Corp. (617) 245-0804 268 Main Street, Suite 283 Fax: (617) 245-8122 North Reading, MA 01864 Sales: (505) 271-9933 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 12 10:39:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04812; Mon, 12 Aug 96 10:39:29 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04658; Mon, 12 Aug 96 08:32:30 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA28575; Mon, 12 Aug 1996 08:27:32 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA21909; Mon, 12 Aug 1996 08:26:27 -0700 From: Margaret Forsythe To: cmetz@inner.net Cc: ipng@sunroof.eng.sun.com In-Reply-To: Craig Metz's message of Mon, 12 Aug 1996 09:25:02 -0400 <199608120118.VAA19740@inner.net> Subject: (IPng 2023) FTP over IPv6: maybe not FOOBAR? Date: Mon, 12 Aug 96 11:24:46 -0400 Message-Id: <9608121124.aa06578@quern.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Also note that the reason the bounce attack works is that there is >not really any security in the three-way configuration. This leads me to >believe that this is a "feature" that should be reconsidered. In my experience, I have seem people use three-way FTP for "legitimate" reasons (at least in their opinion(s)). It has exactly the same security as a situation where you move a file from another machine to a local machine and then from a local machine to a different remote machine (the regular USER/PASS security on each remote machine). But, it does not require moving the data twice, or having sufficient local diskspace to hold the file. > I've never seen a FTP proxy use the three-way FTP mode. Sorry -- unfortunate choice of words on my part...I was referring to the remote-to-remote transfer allowed by 3-way FTP. mrf Margaret Forsythe mrf@epilogue.com Epilogue Technology Corp. (617) 245-0804 268 Main Street, Suite 283 Fax: (617) 245-8122 North Reading, MA 01864 Sales: (505) 271-9933 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 12 13:02:25 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA04994; Mon, 12 Aug 96 13:02:25 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA04988; Mon, 12 Aug 96 13:02:11 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA08894; Mon, 12 Aug 1996 12:57:13 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA03194; Mon, 12 Aug 1996 12:56:58 -0700 Received: from tsc.csc.cxo.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA29915; Mon, 12 Aug 1996 15:43:50 -0400 (EDT) Received: from clrvew.csc.cxo.dec.com by tsc.csc.cxo.dec.com; (5.65v3.2/1.1.8.2/20Jul96-0832PM) id AA28667; Mon, 12 Aug 1996 13:38:28 -0600 Received: by clearview with Microsoft Mail id <01BB8853.96E87360@clearview>; Mon, 12 Aug 1996 13:38:47 -0600 Message-Id: <01BB8853.96E87360@clearview> From: Mark Menkhus To: "'ipng'" Subject: (IPng 2024) Re: FTP over IPv6: maybe not FOOBAR? Date: Mon, 12 Aug 1996 13:38:46 -0600 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, FWIW, I do TCP/IP telephone support. the 3way ftp does not seem to get a lot of request. I have had less than 5 sites requested this in the last year. In every case it was needed because they were not fully using a firewall. If there is a chance to nix the 3way, I vote to not have it. Mark Menkhus, Digital TCP/IP (UCX) Support ---------- From: Craig Metz[SMTP:cmetz@inner.net] Sent: Monday, August 12, 1996 7:25 AM To: Margaret Forsythe Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2020) Re: FTP over IPv6: maybe not FOOBAR? In message <9608120902.aa03734@quern.epilogue.com>, you write: >The PASV command and the ability to specify a different IP address for >the PORT command are specifically to allow one ftp client to set up >an FTP transfer between two *other* hosts (both running ftp servers). >Your proposal (it seems) would eliminate that possibility. Yes. I have never seen the three-way FTP used. I know of several FTP daemons that employ "*Hobbit*"'s bounce attack fix, which prevents users from doing a three-way FTP. I've never heard a single complaint about it. This leads me to believe that this is a "feature" that is not used. Also note that the reason the bounce attack works is that there is not really any security in the three-way configuration. This leads me to believe that this is a "feature" that should be reconsidered. >I am not familiar with the "bounce attack", but is it possible that >people with firewalls or other security measures in place (such as >encryption) would be unconcerned about this attack and still be >interest in setting up a proxy FTP transfer, as described above? I've never seen a FTP proxy use the three-way FTP mode. -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 12 14:11:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05155; Mon, 12 Aug 96 14:11:44 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05149; Mon, 12 Aug 96 14:11:31 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA12119; Mon, 12 Aug 1996 14:06:04 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA24435; Mon, 12 Aug 1996 14:05:18 -0700 Received: by stb.info.com (Smail3.1.28.1 #4) id m0uq4AX-000ZBxC; Mon, 12 Aug 96 14:05 PDT Message-Id: Date: Mon, 12 Aug 96 14:05 PDT From: Michael Gersten To: ipng@sunroof.eng.sun.com Subject: (IPng 2025) Re: Three way FTP Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The only reason I've never used three way FTP was that I've never seen it documented. But I have, many times, done the move it once, move it again method. Usually over a 14.4 link. Twice. Painfully. PLEASE, keep it. Now that I know it's there, I want it!. Michael ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 12 14:14:29 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05167; Mon, 12 Aug 96 14:14:29 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05161; Mon, 12 Aug 96 14:14:16 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA12873; Mon, 12 Aug 1996 14:09:02 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA25350; Mon, 12 Aug 1996 14:08:28 -0700 Received: from inner.net (beavis.ipv6.nrl.navy.mil [132.250.90.8]) by inner.net (8.7.3/42) with ESMTP id EAA20044; Mon, 12 Aug 1996 04:59:24 -0400 Message-Id: <199608120859.EAA20044@inner.net> To: Mukesh.Kacker@Eng (Mukesh Kacker) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2026) Re: FTP over IPv6: maybe not FOOBAR? In-Reply-To: Your message of "Mon, 12 Aug 1996 13:56:49 PDT." <199608122056.NAA01812@lucknow.eng.sun.com> X-Copyright: Copyright 1996, Craig Metz, All Rights Reserved. X-Reposting-Policy: With explicit permission only Date: Mon, 12 Aug 1996 17:05:59 -0400 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199608122056.NAA01812@lucknow.eng.sun.com>, you write: >> The PASV command and the ability to specify a different IP address for >> the PORT command are specifically to allow one ftp client to set up >> an FTP transfer between two *other* hosts (both running ftp servers). >> Your proposal (it seems) would eliminate that possibility. >Three way transfer may have been the original intent of the PASV command, >however it is also the mechanism used in RFC1579 >( "Firewall Friendly FTP" - S.Bellovin) in simple two way transfers. > >The Netscape browser/navigator has implemented RFC1579 for a while >as part of its FTP client code. So I would suspect there are quite instances >of FTP clients using the PASV command all the time. Obsoleting it >as an obscure feature that is not used as is being suggested is not >the case. Nobody suggested eliminating PASV, which has legtimate uses. I suggested eliminating the address argument in PORT and PASV commands, which has plenty of illegitimate uses and an obscure and rarely used legitimate use. -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Aug 13 00:29:26 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05649; Tue, 13 Aug 96 00:29:26 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05643; Tue, 13 Aug 96 00:29:13 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA06284; Tue, 13 Aug 1996 00:24:15 -0700 Received: by mercury.Sun.COM (Sun.COM) id AAA25283; Tue, 13 Aug 1996 00:24:14 -0700 Received: (from shaver@localhost) by neon.ingenia.com (8.8.Alpha.2/8.6.9) id DAA12997; Tue, 13 Aug 1996 03:24:00 -0400 From: Mike Shaver Message-Id: <199608130724.DAA12997@neon.ingenia.com> Subject: (IPng 2027) Re: FTP over IPv6: maybe not FOOBAR? To: mrf@epilogue.com (Margaret Forsythe) Date: Tue, 13 Aug 1996 03:23:59 -0400 (EDT) Cc: cmetz@inner.net, ipng@sunroof.eng.sun.com In-Reply-To: <9608121124.aa06578@quern.epilogue.com> from "Margaret Forsythe" at Aug 12, 96 11:24:46 am Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake Margaret Forsythe: > In my experience, I have seem people use three-way FTP for "legitimate" > reasons (at least in their opinion(s)). It has exactly the same > security as a situation where you move a file from another machine > to a local machine and then from a local machine to a different remote > machine (the regular USER/PASS security on each remote machine). However, it lets me use your machine to send (possibly arbitrary, certainly voluminous) traffic to another host, presumably as an attack. User/pass often means ftp/email@address, so the authentication aspect is kinda shot. I think the 3-way FTP functionality is generally regarded as a mis-feature in security circles, interesting though it may be. Mike -- #> Mike Shaver (shaver@ingenia.com) Ingenia Communications Corporation <# #> UNIX medicine man -- dark magick, cheap! <# #> <# #> When the going gets tough, the tough give cryptic error messages. <# #> "We believe in rough consensus and running code." <# ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Aug 13 08:52:27 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA05817; Tue, 13 Aug 96 08:52:27 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA05811; Tue, 13 Aug 96 08:52:14 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA22815; Tue, 13 Aug 1996 08:47:15 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA02508; Tue, 13 Aug 1996 08:47:13 -0700 Received: from lnxemedwards.lehi.micron.com (localhost [127.0.0.1]) by lnxemedwards.lehi.micron.com (8.7.4/8.7.3) with SMTP id JAA08602 for ; Tue, 13 Aug 1996 09:48:18 -0600 Message-Id: <3210A3C1.4EAA7CB0@micron.com> Date: Tue, 13 Aug 1996 09:48:17 -0600 From: Erik M Edwards Organization: Micron, Inc. X-Mailer: Mozilla 3.0b4Gold (X11; I; Linux 2.0.5 i586) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 2028) Re: FTP over IPv6: maybe not FOOBAR? References: <199608120859.EAA20044@inner.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Novell uses something very similar in the ncopy from server to server. 600 mg of data can be transfered easily even when ncopy is used over NetConnect/LanRover/... and the pipe between servers is fddi etc. This is a functionality I'd like to keep in ftp. -erik Craig Metz wrote: ...deleted... > has plenty of illegitimate uses and an obscure and rarely used legitimate use. > > -Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Aug 14 09:42:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA06658; Wed, 14 Aug 96 09:42:51 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA06368; Tue, 13 Aug 96 22:40:07 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA00871; Tue, 13 Aug 1996 22:35:07 -0700 Received: by mercury.Sun.COM (Sun.COM) id WAA13299; Tue, 13 Aug 1996 22:35:07 -0700 Received: from droid.fit.qut.edu.au (n1534823@droid.fit.qut.edu.au [131.181.27.1]) by sky.fit.qut.edu.au (8.7.5/8.7.5/tony) with ESMTP id PAA15493 for ; Wed, 14 Aug 1996 15:09:21 +1000 (EST) Received: from localhost (n1534823@localhost) by droid.fit.qut.edu.au (8.7.4/8.7.3) with SMTP id PAA19955 for ; Wed, 14 Aug 1996 15:09:15 +1000 (EST) Date: Wed, 14 Aug 1996 15:09:15 +1000 (EST) From: KENNETH W DALGLEISH X-Sender: n1534823@droid.fit.qut.edu.au To: ipng@sunroof.eng.sun.com Subject: (IPng 2029) IPv4/IPv6 Conversion Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am a student of Information Technology at QUT in Australia and am in the process of studying the conversion from IPv4 to IPv6. Can somebody please help me? I would like a copy of a IPv4 DNS file and the same file converted to an IPv4/IPv6 dual stack system format. I have roamed the 'web for hours and have been unsuccessful in finding anything. A copy of an executable file that does the conversion would be appreciated too, but not required at this time as I will write one later. Thanks in advance for any assistance. Cheers Ken ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Aug 14 12:25:51 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA08538; Wed, 14 Aug 96 12:25:51 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA08522; Wed, 14 Aug 96 12:23:51 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA28712; Wed, 14 Aug 1996 12:18:41 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA22891; Wed, 14 Aug 1996 12:18:31 -0700 Received: from mailhub1.watson.ibm.com (mailhub1.watson.ibm.com [9.2.249.31]) by igw2.watson.ibm.com (8.7.4/8.7.1) with ESMTP id PAA07813 for ; Wed, 14 Aug 1996 15:19:00 -0400 Received: from hawpub1.watson.ibm.com (hawpub1.watson.ibm.com [9.2.90.32]) by mailhub1.watson.ibm.com (8.7.1/08-13-96) with SMTP id PAA59566 for ; Wed, 14 Aug 1996 15:18:27 -0400 Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/6/25/96) id AA16798; Wed, 14 Aug 1996 15:18:26 -0400 From: Charlie Perkins Message-Id: <9608141918.AA16798@hawpub1.watson.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2030) IPv6 encryption requirement In-Reply-To: Your message of Wed, 14 Aug 96 15:09:15 W. Date: Wed, 14 Aug 96 15:18:26 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I believe that an implementation of IPv6, to be considered compliant, MUST be able (at the IP level) to authenticate data using MD5 according to some formula, and to encrypt data using DES. Is this correct? Thanks, Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Aug 15 03:45:48 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10343; Thu, 15 Aug 96 03:45:48 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10337; Thu, 15 Aug 96 03:45:33 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA23997; Thu, 15 Aug 1996 03:40:31 -0700 Received: by mercury.Sun.COM (Sun.COM) id DAA14944; Thu, 15 Aug 1996 03:40:28 -0700 Received: from sparc.com.eg by ritsec.com.eg (SMI-8.6/SMI-SVR4) id NAA14894; Thu, 15 Aug 1996 13:41:21 +0300 Message-Id: <3212FE98.7902@ritsec.com.eg> Date: Thu, 15 Aug 1996 13:40:25 +0300 From: Wael Ashmawy Reply-To: washmawy@ritsec.com.eg Organization: RITSEC X-Mailer: Mozilla 3.0b5aGold (Win95; I) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 2031) IPv6 Simulation Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm doing my master in the area of IPV6 and what i want is to do some performance analysis and comparison between IPv6 and IPv4. But due to the lack of IPv6 implementation I’m think to do this based on simulation. So I'm looking for a simulator to use it for the IPv6 Performance. Any suggestion are appreciated ThanX in Advance. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Aug 15 10:03:00 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10575; Thu, 15 Aug 96 10:03:00 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10366; Thu, 15 Aug 96 04:22:15 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA25128; Thu, 15 Aug 1996 04:17:14 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA18182; Thu, 15 Aug 1996 04:15:42 -0700 Received: by aic.net (8.7.3/8.7.3) id PAA06966; Thu, 15 Aug 1996 15:11:39 +0400 (AMT) From: Edgar Der-Danieliantz X-Amnic-Url: http://www.nic.am (will soon change to www.amnic.net) X-Amnic-Telephone: +374 2 28 14 25 (will change) X-Amnic-Fax: +374 2 28 50 82 (will change) Message-Id: <199608151111.PAA06966@aic.net> Subject: (IPng 2032) Re: IPv6 Simulation To: washmawy@ritsec.com.eg Date: Thu, 15 Aug 1996 15:11:38 +0400 (AMT) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3212FE98.7902@ritsec.com.eg> from "Wael Ashmawy" at Aug 15, 96 01:40:25 pm Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Wael, performance of any network protocol heavily depends on the implementation of such protocol. So it is inappropriate to use simulation (whatever this means) to measure the performance of any protocol, including but not limited to IPng. If you ultimately need to measure IPng performance, use any implementation, and give platform, OS, and version of that implementation in accompanying docs. Just IMHO, -edd > I'm doing my master in the area of IPV6 and what i want is to do some > performance analysis and comparison between IPv6 and IPv4. But due to > the lack of IPv6 implementation I’m think to do this based on > simulation. > So I'm looking for a simulator to use it for the IPv6 Performance. > Any suggestion are appreciated Edgar Der-Danieliantz edd@nic.am ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Aug 15 10:04:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10587; Thu, 15 Aug 96 10:04:28 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10385; Thu, 15 Aug 96 05:15:32 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA27036; Thu, 15 Aug 1996 05:10:30 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA23167; Thu, 15 Aug 1996 05:10:30 -0700 Received: from sloth.ncsl.nist.gov (sloth.ncsl.nist.gov [129.6.55.36]) by snad.ncsl.nist.gov (8.7.5/8.7.3) with ESMTP id IAA28965; Thu, 15 Aug 1996 08:10:13 -0400 (EDT) From: Robert Glenn Received: (from glenn@localhost) by sloth.ncsl.nist.gov (8.7.5/8.7.3) id IAA03737; Thu, 15 Aug 1996 08:10:01 -0400 (EDT) Date: Thu, 15 Aug 1996 08:10:01 -0400 (EDT) Message-Id: <199608151210.IAA03737@sloth.ncsl.nist.gov> To: ipng@sunroof.eng.sun.com Subject: (IPng 2033) Re: IPv6 encryption requirement Cc: charliep@watson.ibm.com, rob.glenn@nist.gov Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, For IPv6 conformance, RFC 1883 points to RFC-1825 regarding Security Considerations. According to RFC1825, " All IPv6-capable hosts MUST implement the IP Authentication Header with at least the MD5 algorithm using a 128-bit key." ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Aug 15 10:06:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10602; Thu, 15 Aug 96 10:06:11 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10402; Thu, 15 Aug 96 06:27:40 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA01269; Thu, 15 Aug 1996 06:22:37 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA06165; Thu, 15 Aug 1996 06:22:37 -0700 Received: from localhost by ietf.org id aa01595; 15 Aug 96 9:16 EDT Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@mercury Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: (IPng 2034) I-D ACTION:draft-cisco-ipv6-router-alert-01.txt Date: Thu, 15 Aug 1996 09:16:01 -0400 Message-Id: <9608150916.aa01595@ietf.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Router Alert Option Author(s) : D. Katz, R. Atkinson Filename : draft-cisco-ipv6-router-alert-01.txt Pages : 4 Date : 08/14/1996 This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP packet. This is useful for protocols addressed to a destination but also require special processing in routers along the path. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-cisco-ipv6-router-alert-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-cisco-ipv6-router-alert-01.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.8) o Europe Address: nic.nordu.net (192.36.148.17) Address: ftp.nis.garr.it (193.205.245.10) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-cisco-ipv6-router-alert-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@ietf.org Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19960814105025.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-cisco-ipv6-router-alert-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-cisco-ipv6-router-alert-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19960814105025.I-D@ietf.org> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Aug 15 10:13:33 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10628; Thu, 15 Aug 96 10:13:33 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10608; Thu, 15 Aug 96 10:08:38 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA05451; Thu, 15 Aug 1996 10:03:23 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA19225; Thu, 15 Aug 1996 10:02:55 -0700 Received: from forge.BSDI.COM (forge.BSDI.COM [205.230.224.24]) by external.BSDI.COM (8.7.4/8.7.3) with ESMTP id LAA27945; Thu, 15 Aug 1996 11:02:51 -0600 (MDT) Received: (from dab@localhost) by forge.BSDI.COM (8.7.5/8.7.3) id LAA09949; Thu, 15 Aug 1996 11:02:49 -0600 (MDT) Date: Thu, 15 Aug 1996 11:02:49 -0600 (MDT) From: David Borman Message-Id: <199608151702.LAA09949@forge.BSDI.COM> To: internet-drafts@cnri.reston.va.us Subject: (IPng 2035) TCP & UDP over IPv6 Jumbograms, Draft #2 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi. Thanks for all the helpful input that I've received. Attached is my second draft of "TCP & UDP over IPv6 Jumbograms". I've include information about the TCP Urgent pointer. I chose not to pursue adding a TCP Urgent Pointer Option, as I feel that that is overkill for the problem. I decided not to include any discussion about IPv4 <-> IPv6 translation, because 1) as Steve put it, it's really a non-problem, and 2) if there is to be any discussion, it really belongs in the IPv4 <-> IPv6 translation document, if someone decides to pursue that issue. -David Borman, dab@bsdi.com ------ Cut Here ------ Network Working Group Internet Engineering Task Force Internet-Draft IPNG Working Group Updates: 1883 David Borman Category: Standards Track Berkeley Software Design, Inc. August 1996 TCP and UDP over IPv6 Jumbograms Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Overview IPv6 supports datagrams larger than 65535 bytes long, often referred to as jumbograms, through use of the Jumbo Payload hop-by-hop option [Deering95]. The UDP protocol has a 16-bit length field that keeps it from being able to make use of jumbograms, and though TCP does not have a length field, both the MSS option and the Urgent field are constrained by 16-bits. This document describes some simple changes that can be made to allow TCP and UDP to make use of IPv6 jumbograms. 2. UDP Jumbograms To allow UDP to make use of jumbograms, either the UDP length field needs to be extended, or it needs to be ignored. Since the size of the field can't be changed, a length of zero is used to indicate that it is to be ignored, and the length in the "pseudo-header" is to be used to determine the true length of the UDP header plus data. This works because UDP length field includes the UDP header, so the minimum valid value for this field is 8. IPNG Working Group Expires February 1997 [Page 1] Internet-Draft TCP and UDP over IPv6 Jumbograms August 1996 When sending a UDP packet, if and only if the length of the UDP header plus data is greater than 65,535, set the length field in the UDP header to zero. Note 1: The length used in the "pseudo-header" for computing the UDP checksum is always the true length of the UDP header plus data, NOT zero [RFC-1883, Section 8.1]. Note 2: An IPv6 packet that carries a UDP packet of length greater than 65,535 will necessarily carry a Jumbo Payload option in a Hop-by-Hop Options header [RFC1883, Section 4.3]). The length field in the Jumbo Payload option contains the length of the IP packet excluding the IPv6 header, that is, it contains the length of all extension headers present plus the UDP header plus the UDP data. The length field in the IPv6 header contains zero to indicate the presence of the Jumbo Payload option. If a UDP packet is received with a length field of zero, the length of the UDP packet is computed from the the length field in the Jumbo Payload option minus the length of all extension headers present between the IPv6 header and the UDP header. 3. TCP Jumbograms Because there is no length field in the TCP header, there is nothing limiting the length of an individual TCP packet. However, the MSS value that is negotiated at the beginning of the connection limits the largest TCP packet that can be sent, and the Urgent Pointer cannot reference data beyond 65535 bytes. 3.1 TCP MSS When determining what MSS value to send, if the MTU of the directly attached interface is greater than 65535, then set the MSS value to 65535. When an MSS value of 65535 is received, it is to be treated as infinity. MTU discovery code, starting with the MTU of the outgoing interface, will be used to determine the actual MSS. 3.2 TCP Urgent Pointer The Urgent Pointer problem could be fixed by adding a TCP Urgent Pointer Option. However, since it is unlikely that applications using jumbograms will also use Urgent Pointers, a less intrusive change similar to the MSS change will suffice. When a TCP packet is to be sent with an Urgent Pointer (i.e., the URG bit set), first calculate the offset from the Sequence Number to the Urgent Pointer. If the offset is less than 65535, fill in the Urgent IPNG Working Group Expires February 1997 [Page 2] Internet-Draft TCP and UDP over IPv6 Jumbograms August 1996 field and continue with the normal TCP processing. If the offset is greater than 65535, and the offset is greater than or equal to the length of the TCP data, fill in the Urgent Pointer with 65535 and continue with the normal TCP processing. Otherwise, the TCP packet must be split into two pieces. The first piece contains data up to, but not including the data pointed to by the Urgent Pointer, and the Urgent field is set to 65535 to indicate that the Urgent Pointer is beyond the end of this packet. The second piece can then be sent with the Urgent field set normally. Note: The first piece does not have to include all of the data up to the Urgent Pointer. It can be shorter, just as long as it ends within 65534 bytes of the Urgent Pointer, so that the offset to the Urgent Pointer in the second piece will be less than 65535 bytes. For TCP input processing, when a TCP packet is received with the URG bit set and an Urgent field of 65535, the Urgent Pointer is calculated using an offset equal to the length of the TCP data, rather than the offset in the Urgent field. It should also be noted that though the TCP window is only 16-bits, larger windows can be used through use of the TCP Window Scale option [Jacobson92]. 4. Security Considerations There are no known security issues involved in these changes. 5. References [Jacobson92] Jacobson, V., R. Braden and D. Borman, "TCP Extensions for High Performance", RFC 1323, LBL, ISI and Cray Research, May 1992. [Deering95] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, Xerox PARC and Ipsilon Networks, December 1995. Author's Address David A. Borman Berkeley Software Design, Inc. 4719 Weston Hills Drive Eagan, MN 55123 Phone: (612) 405-8194 Mailing List: ipng@sunroof.Eng.Sun.COM Email: dab@bsdi.com IPNG Working Group Expires February 1997 [Page 3] ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Aug 15 10:43:44 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10682; Thu, 15 Aug 96 10:43:44 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10676; Thu, 15 Aug 96 10:43:26 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA14486; Thu, 15 Aug 1996 10:38:20 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA06218; Thu, 15 Aug 1996 10:38:13 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id NAA01091; Thu, 15 Aug 1996 13:38:00 -0400 (EDT) Message-Id: <199608151738.NAA01091@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Robert Glenn Cc: ipng@sunroof.eng.sun.com, charliep@watson.ibm.com, rob.glenn@nist.gov Subject: (IPng 2036) Re: IPv6 encryption requirement In-Reply-To: Your message of "Thu, 15 Aug 1996 08:10:01 EDT." <199608151210.IAA03737@sloth.ncsl.nist.gov> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Thu, 15 Aug 1996 13:37:55 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Glenn writes: > Charlie, > > For IPv6 conformance, RFC 1883 points to RFC-1825 regarding Security > Considerations. > > According to RFC1825, > > " All IPv6-capable hosts MUST implement the IP Authentication Header > with at least the MD5 algorithm using a 128-bit key." Robert; You left out the DES requirement. It is indeed required to implement the DES ESP transform of IPSec. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Aug 15 14:53:03 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA10982; Thu, 15 Aug 96 14:53:03 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA10965; Thu, 15 Aug 96 14:39:24 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA12556; Thu, 15 Aug 1996 14:33:45 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA26960; Thu, 15 Aug 1996 14:33:32 -0700 Received: (from glenn@localhost) by snad.ncsl.nist.gov (8.7.5/8.7.3) id RAA12058; Thu, 15 Aug 1996 17:33:29 -0400 (EDT) Date: Thu, 15 Aug 1996 17:33:29 -0400 (EDT) From: Robert Glenn Message-Id: <199608152133.RAA12058@snad.ncsl.nist.gov> To: charliep@watson.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 2037) Re: IPv6 encryption requirement Cc: glenn@snad.ncsl.nist.gov Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well it seems my mail message got truncated. Yes, I had a period on a line by itself. I just loooove mailing list software ;( Anyway, here is the message without the period, reconstructed from memory. ------------------ For IPv6 conformance, RFC 1883 points to RFC-1825 regarding Security Considerations. According to RFC1825, "All IPv6-capable hosts MUST implement the IP Authentication Header with at least the MD5 algorithm using a 128-bit key. IPv4-systems claiming to implement the Authentication Header MUST implement the IP Authentication Header with at least the MD5 algorithm using a 128-bit key [MS95]." and "For interoperability throughout the worldwide Internet, all conforming implementations of the IP Encapsulating Security Payload MUST support the use of the Data Encryption Standard (DES) in Cipher-Block Chaining (CBC) Mode as detailed in the ESP specification. This would imply that IPv6 *host* implementations must include AH using MD5. I will assume that router implementations that choose to include AH must implement AH with MD5. ESP is not mandatory, but if implemented, must support DES-CBC. That said, things are changing. There are a new set of drafts designed to replace the current set of RFCs. The new architecture draft draft-ietf-ipsec-arch-sec-00.txt states: "All IPv6-capable nodes and all IPv4 systems claiming to implement the Authentication Header MUST implement the standards- track mandatory-to- implement AH transforms. As of this writing these are HMAC MD5 [OG96] and HMAC SHA [CG96], but implementers should consult the most recent edition of the "Internet Official Protocol Standards" [STD-1] for current guidance." and "For interoperability throughout the worldwide Internet, all conforming implementations of the IP Encapsulating Security Payload MUST also implement the standard mandatory ESP transform. As of this writing, that is the Combined ESP transform with DES-CBC, HMAC MD5, and Replay Protection. [Hugh96] Implementers should consult the most recent "IAB Official Protocols" RFC for current information on the mandatory to implement ESP transform(s). " The first sentence is confusing. Is AH mandatory for all IPv6 nodes? >From the text, I would guess not, but that may have been an ambiguity which resulted when combining the two relevant sentences from RFC1825. If AH is implemented that mandatory transforms are HMAC MD5 and HMAC SHA. ESP is still optional for implementation but the mandatory transform is now DES-CBC, HMAC MD5, and Replay Protection. Hope this clarifies things a bit. Rob G. rob.glenn@nist.gov ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Aug 16 08:45:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11386; Fri, 16 Aug 96 08:45:10 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11380; Fri, 16 Aug 96 08:44:51 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA19280; Fri, 16 Aug 1996 08:39:48 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA16347; Fri, 16 Aug 1996 08:39:46 -0700 Received: from localhost (perry@localhost) by jekyll.piermont.com (8.7.5/8.6.12) with SMTP id LAA03840; Fri, 16 Aug 1996 11:39:37 -0400 (EDT) Message-Id: <199608161539.LAA03840@jekyll.piermont.com> X-Authentication-Warning: jekyll.piermont.com: Host perry@localhost didn't use HELO protocol To: Robert Glenn Cc: charliep@watson.ibm.com, ipng@sunroof.eng.sun.com Subject: (IPng 2038) Re: IPv6 encryption requirement In-Reply-To: Your message of "Thu, 15 Aug 1996 17:33:29 EDT." <199608152133.RAA12058@snad.ncsl.nist.gov> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Fri, 16 Aug 1996 11:39:37 -0400 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Glenn writes: > This would imply that IPv6 *host* implementations must include AH using > MD5. I will assume that router implementations that choose to include AH > must implement AH with MD5. ESP is not mandatory, but if implemented, > must support DES-CBC. Sorry, but that isn't correct. ESP *is* mandatory, as is the DES transform. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Aug 16 09:51:55 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA11438; Fri, 16 Aug 96 09:51:55 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA11322; Fri, 16 Aug 96 06:38:20 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA04048; Fri, 16 Aug 1996 06:33:19 -0700 Received: by mercury.Sun.COM (Sun.COM) id GAA12500; Fri, 16 Aug 1996 06:33:18 -0700 From: Margaret Forsythe To: perry@piermont.com Cc: glenn@snad.ncsl.nist.gov, ipng@sunroof.eng.sun.com, charliep@watson.ibm.com, rob.glenn@nist.gov In-Reply-To: "Perry E. Metzger"'s message of Thu, 15 Aug 1996 13:37:55 -0400 <199608151738.NAA01091@jekyll.piermont.com> Subject: (IPng 2039) Re: IPv6 encryption requirement Date: Fri, 16 Aug 96 09:32:30 -0400 Message-Id: <9608160932.aa23772@quern.epilogue.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Robert Glenn writes: >> Charlie, >> >> For IPv6 conformance, RFC 1883 points to RFC-1825 regarding Security >> Considerations. >> >> According to RFC1825, >> >> " All IPv6-capable hosts MUST implement the IP Authentication Header >> with at least the MD5 algorithm using a 128-bit key." > >Robert; > >You left out the DES requirement. It is indeed required to implement >the DES ESP transform of IPSec. My interpretation of the current RFCs matches Robert's -- specifically, MD5/128-bit key authentication with manual key distribution is required for an IPv6 implementation. Also support for both the ESP and AH headers is required. BUT, no specific ESP transforms are required (i.e. DES is not required). If this is not the intention, clearly the documents need to be clarified. mrf Margaret Forsythe mrf@epilogue.com Epilogue Technology Corp. (617) 245-0804 268 Main Street, Suite 283 Fax: (617) 245-8122 North Reading, MA 01864 Sales: (505) 271-9933 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Aug 18 10:40:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12142; Sun, 18 Aug 96 10:40:12 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12136; Sun, 18 Aug 96 10:39:58 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA05790; Sun, 18 Aug 1996 10:34:52 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA27727; Sun, 18 Aug 1996 10:34:52 -0700 Received: (from craig@localhost) by aland.bbn.com (8.7.1/8.7.1) id KAA09047; Sun, 18 Aug 1996 10:33:49 -0700 (PDT) Message-Id: <199608181733.KAA09047@aland.bbn.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2040) IPv6 tutorial by Steve Deering Reply-To: Craig Partridge From: Craig Partridge Date: Sun, 18 Aug 96 10:33:49 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk While most of you on this list probably don't feel the need for an IPv6 tutorial -- you probably know someone who would benefit (and stop asking you questions... :-)). So, FYI, Steve Deering is giving a one-day tutorial on IPv6 as part of the ACM SIGCOMM Conference at Stanford University next week. Beyond being able to take the course on campus, people at companies that are part of the Stanford Instructional Television Network (nearly 200 companies around the US) can sign up to receive the tutorial via SITN. More info at http://www.acm.org/sigcomm/sigcomm96/ Craig ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 19 11:08:09 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12592; Mon, 19 Aug 96 11:08:09 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12586; Mon, 19 Aug 96 11:07:56 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA20099; Mon, 19 Aug 1996 11:02:46 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA08748; Mon, 19 Aug 1996 11:02:43 -0700 Received: from gemini.tuc.noao.edu (gemini.tuc.noao.edu [140.252.1.11]) by noao.edu (8.7.5/8.7.3/SAG-16Aug96) with ESMTP id LAA12493 for ; Mon, 19 Aug 1996 11:02:38 -0700 (MST) Received: (from rstevens@localhost) by gemini.tuc.noao.edu (8.7.5/8.7.3/SAG-11Jul96) id LAA09689 for ipng@sunroof.Eng.Sun.COM; Mon, 19 Aug 1996 11:02:30 -0700 (MST) Message-Id: <199608191802.LAA09689@gemini.tuc.noao.edu> From: rstevens@noao.edu (Richard Stevens) Date: Mon, 19 Aug 1996 11:02:30 -0700 Reply-To: Richard Stevens X-Phone: +1 520 297 9416 X-Homepage: http://www.noao.edu/~rstevens X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: ipng@sunroof.eng.sun.com Subject: (IPng 2041) a few questions Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have a couple of questions that I think I know the answer to, but for which I cannot find explicit answers in the IPv6 documentation. - IPv4-mapped addresses should only be created by DNS resolvers when a hostname is looked up and the hostname has no AAAA records but an A record, and the caller wants a AAAA record returned. IPv4-mapped addresses should never appear in a DNS data file--they are created as needed by the resolver. - An IPv4/6 host should have a AAAA record with an IPv4-compatible address only if that host does not have an IPv6 neighbor router. IPv4-compatible addresses must appear in DNS data files--they are never created automatically by resolvers. - If I have two LANS connected by IPv4 routers, with *no* configured tunnels, IPv4-compatible addresses must be used by IPv4/6 hosts on the two LANs to communicate with each other. - If I have two IPv4/6 hosts on a LAN, both with IPv4-compatible addresses (since there is no neighbor IPv6 router) they will use an automatic tunnel to communicate. Do people have a way around this needless tunneling? Could you assign each of the two hosts two AAAA records: one with a real (RFC 1897) IPv6 address and another with an IPv4-compatible address? - If I then configure a tunnel between the two LANS, I must get rid of the AAAA IPv4-compatible addresses and replace them with RFC 1897 addresses. - A host with a configured tunnel is really acting as an IPv6 router (for all the IPv6 hosts on its attached networks) and therefore must do things such as respond to neighbor solicitations, and everything else an IPv6 router must do. - It seems that most host implementations support (or will soon support) configured tunnels, so the use of IPv4-compatible addresses should really not be needed. - How are people handling DNS entries for IPv4/6 hosts today? I'd guess for a host foo.bar.com you're just adding a AAAA record for the same name with the RFC 1897 address (i.e., you're hand configuring the MAC address into the DNS record)? Do any implementations that support configured tunnels advertise the subnet prefix (i.e., for the RFC 1897 address today) using router advertisements? Are you putting link-local addresses into the DNS? Rich Stevens ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 19 12:41:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12706; Mon, 19 Aug 96 12:41:12 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12700; Mon, 19 Aug 96 12:40:59 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA09964; Mon, 19 Aug 1996 12:35:36 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id MAA13329; Mon, 19 Aug 1996 12:35:29 -0700 Received: from fwasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA00741; Mon, 19 Aug 1996 15:29:29 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA11200; Mon, 19 Aug 1996 15:29:26 -0400 Message-Id: <9608191929.AA11200@fwasted.zk3.dec.com> To: Craig Metz Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2042) Re: FTP over IPv6: maybe not FOOBAR? In-Reply-To: Your message of "Mon, 12 Aug 96 07:04:51 EDT." <199608112258.SAA19666@inner.net> Date: Mon, 19 Aug 96 15:29:26 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Craig, I implemented foobar and think the spec is overkill. In my spare time I am going to rewrite it before the San Jose meeting. I think all we need is 6prt and 6psv. The 6 tells you its IPv6 and 16bytes. I see no reason for a port length > 16 bits so why have that extra field. In otherwords the parameters passed are the same as today except for the name of the commands. As far as lpasv I would like to hear more uses than I have so far and more on the security issues as it seems to be a hole from my perspective, even with our present security models for IPv6. As far as supporting other address families who really cares for the next Internet Next Generation Protocol for FTP. I think its a waist of bytes to add that and length of the address to every ftp connection in the world. All that matters is IPv6. If we have IPv7 then we make it 7prt, then 8prt, etc.. etc... Sorry I was on vacation last week and just saw the mail. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 19 15:17:52 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12859; Mon, 19 Aug 96 15:17:52 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12853; Mon, 19 Aug 96 15:17:34 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA20518; Mon, 19 Aug 1996 15:12:14 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA06064; Mon, 19 Aug 1996 15:12:12 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id SAA18549; Mon, 19 Aug 1996 18:10:36 -0400 Date: Mon, 19 Aug 1996 18:10:36 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <9608191810.ZM18547@seawind.bellcore.com> In-Reply-To: rstevens@noao.edu (Richard Stevens) "(IPng 2041) a few questions" (Aug 19, 11:02am) References: <199608191802.LAA09689@gemini.tuc.noao.edu> X-Mailer: Z-Mail (3.2.0 06sep94) To: Richard Stevens , ipng@sunroof.eng.sun.com Subject: (IPng 2043) Re: a few questions Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk One of your assertions seems, IMHO, bizarre: If I have two LANS connected by IPv4 routers, with *no* configured tunnels, IPv4-compatible addresses must be used by IPv4/6 hosts on the two LANs to communicate with each other. The truth is that if there is no explicit IPv6 connectivity, one certainly cannot communicate using IPv6, except if one uses tunnelling. But then, if there is no connectivity, one should normally not have IPv6 addresses at all. How come that a router advertizes an IPv6 prefix if it is not somehow connected to an IPv6 mesh? One may perhaps have some "local scope" addresses, but this is equivalent to sitting behind a very restrictive firewall. -- Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 19 15:54:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12895; Mon, 19 Aug 96 15:54:11 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12889; Mon, 19 Aug 96 15:53:54 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA29926; Mon, 19 Aug 1996 15:48:44 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA16421; Mon, 19 Aug 1996 15:48:45 -0700 Received: by gw.home.vix.com id PAA08189; Mon, 19 Aug 1996 15:48:43 -0700 (PDT) Date: Mon, 19 Aug 1996 15:48:43 -0700 (PDT) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us To: ipng@sunroof.eng.sun.com From: paul@vix.com (Paul A Vixie) Subject: (IPng 2044) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... Organization: Vixie Enterprises Message-Id: References: <9605300725.AA20929@dmssyd.syd.dms.CSIRO.AU> Nntp-Posting-Host: wisdom.home.vix.com In-Reply-To: Mark.Andrews@dms.CSIRO.AU's message of 31 May 1996 10:06:43 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quite a while ago, Mark Andrews asked me.. > Paul, > by your logic all the le0:X interfaces would have to have > the same names. We are talking interface names here not addresses. > > I could well imagine someone wanting ::1.2.3.4 to be foo-ip6.bar > and 1.2.3.4 to be foo.bar. I can see no reason for forcing these > to be identical. I would prefer them to be identical however and > providing a mechanism that facilitates this would be useful. > > The alternative could be to look in ip6.int and if you get > NXDOMAIN retry in in-addr.arpa. Basically this section of the > ip6.int tree would be translucent. > > Mark Nobody followed up. I think this is a good idea, but my plate is full. If someone else wants to write the I-D, I will implement it in BIND. While we're at it, I'm thinking that an AAAA query should be treated as a metaquery, such that an AAAA RRset should be sent if one exists, else an A RRset. No need to send both, but don't we all hate querying for both? -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 19 15:55:42 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA12907; Mon, 19 Aug 96 15:55:42 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA12901; Mon, 19 Aug 96 15:55:24 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA00306; Mon, 19 Aug 1996 15:50:10 -0700 Received: by mercury.Sun.COM (Sun.COM) id PAA16856; Mon, 19 Aug 1996 15:50:06 -0700 Received: by gw.home.vix.com id PAA08272; Mon, 19 Aug 1996 15:50:05 -0700 (PDT) X-Btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by wisdom.home.vix.com id AA16036; Mon, 19 Aug 1996 15:50:00 -0700 Date: Mon, 19 Aug 1996 15:50:00 -0700 Message-Id: <9608192250.AA16036@wisdom.home.vix.com> From: Paul Vixie To: ipng@sunroof.eng.sun.com Subject: (IPng 2045) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quite a while ago, Mark Andrews asked me.. > Paul, > by your logic all the le0:X interfaces would have to have > the same names. We are talking interface names here not addresses. > > I could well imagine someone wanting ::1.2.3.4 to be foo-ip6.bar > and 1.2.3.4 to be foo.bar. I can see no reason for forcing these > to be identical. I would prefer them to be identical however and > providing a mechanism that facilitates this would be useful. > > The alternative could be to look in ip6.int and if you get > NXDOMAIN retry in in-addr.arpa. Basically this section of the > ip6.int tree would be translucent. > > Mark Nobody followed up. I think this is a good idea, but my plate is full. If someone else wants to write the I-D, I will implement it in BIND. While we're at it, I'm thinking that an AAAA query should be treated as a metaquery, such that an AAAA RRset should be sent if one exists, else an A RRset. No need to send both, but don't we all hate querying for both? -- Paul Vixie La Honda, CA "Illegitimibus non carborundum." pacbell!vixie!paul ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Aug 20 04:58:10 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13226; Tue, 20 Aug 96 04:58:10 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13220; Tue, 20 Aug 96 04:57:51 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA19348; Tue, 20 Aug 1996 04:52:42 -0700 Received: by mercury.Sun.COM (Sun.COM) id EAA01330; Tue, 20 Aug 1996 04:52:40 -0700 Received: from mundamutti.cs.mu.OZ.AU by munnari.OZ.AU with SMTP (5.83--+1.3.1+0.56) id LA15614; Tue, 20 Aug 1996 21:52:21 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: paul@vix.com (Paul A Vixie) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2046) Re: Nobody seems to know if ::I.P.V.4 and ::FFFF:I.P.V.4 will have... In-Reply-To: Your message of "Mon, 19 Aug 1996 15:48:43 MST." Date: Tue, 20 Aug 1996 21:52:06 +1000 Message-Id: <21577.840541926@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 19 Aug 1996 15:48:43 -0700 (PDT) From: paul@vix.com (Paul A Vixie) Message-ID: > The alternative could be to look in ip6.int and if you get > NXDOMAIN retry in in-addr.arpa. Basically this section of the > ip6.int tree would be translucent. Nobody followed up. I think this is a good idea, but my plate is full. If someone else wants to write the I-D, I will implement it in BIND. You can achieve the same effect, better, in almost all cases, and absolutely without requiring an I-D to be written (as it would just be a local implementation matter), if you were to add to named.boot's syntax an option like generate P.Q...X.Y.Z.IP6.INT b.c.d.IN-ADDR.ARPA (and allow the reverse as well). "generate" would be exactly "primary" except the zone would be synthesised from the data in the other zone (basically convert labels from decimal to hex). This does assume that the IP6.INT delegation is to the same servers as the IN-ADDR.ARPA delegation, but where the zones are expected to be the same, this doesn't sound unreasonable to me. If someone else is to manage one of those, and I the other, then I would be anticipating differences... It also assumes that IP6.INT delegations actually happen - that is, unlike Mark's suggestion, it won't work if people simply don't bother to have IP6.INT delegations made. This I consider to be a feature, not a bug. kre ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Aug 20 05:23:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13246; Tue, 20 Aug 96 05:23:28 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13240; Tue, 20 Aug 96 05:23:15 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA20649; Tue, 20 Aug 1996 05:18:05 -0700 Received: by mercury.Sun.COM (Sun.COM) id FAA05930; Tue, 20 Aug 1996 05:18:06 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id OAA13407; Tue, 20 Aug 1996 14:18:03 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.1/8.6.6) with ESMTP id OAA12307; Tue, 20 Aug 1996 14:18:03 +0200 (MET DST) Message-Id: <199608201218.OAA12307@givry.inria.fr> From: Francis Dupont To: Richard Stevens Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2047) Re: a few questions In-Reply-To: Your message of Mon, 19 Aug 1996 11:02:30 PDT. <199608191802.LAA09689@gemini.tuc.noao.edu> Date: Tue, 20 Aug 1996 14:17:58 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I have a couple of questions that I think I know the answer to, but for which I cannot find explicit answers in the IPv6 documentation. - An IPv4/6 host should have a AAAA record with an IPv4-compatible address only if that host does not have an IPv6 neighbor router. IPv4-compatible addresses must appear in DNS data files--they are never created automatically by resolvers. => the problem is not closed (ie there is no strong concensus) for PTR RRs associated to IPv4-compatible addresses... Personally I believe the usage of IPv4-compatible addresses should be as restricted as possible then they are "manualy" given, ie they are not in the DNS and I have not the problem... But I'd still like to get a solution (:-) ! - If I have two IPv4/6 hosts on a LAN, both with IPv4-compatible addresses (since there is no neighbor IPv6 router) they will use an automatic tunnel to communicate. Do people have a way around this needless tunneling? => it is possible to use ND and "native" IPv6 in this case on the shared LAN. We discovered this choice last year in July and Peter Sjodin convinced me the tunnel should be avoid. I am still convinced but both hosts must use or not use a tunnel (ie this should be specified in a RFC). Could you assign each of the two hosts two AAAA records: one with a real (RFC 1897) IPv6 address and another with an IPv4-compatible address? => it is possible but if you prefer *real* things and don't want to open the problem of address choice then you can put only the RFC 1897 address. I don't believe we need a standard way to know if IPv4-compatible / automatic tunnel is supported. - If I then configure a tunnel between the two LANS, I must get rid of the AAAA IPv4-compatible addresses and replace them with RFC 1897 addresses. => perhaps "must" is too strong but I agree! - It seems that most host implementations support (or will soon support) configured tunnels, so the use of IPv4-compatible addresses should really not be needed. => I agree, I believe IPv4-compatible addresses are a bad "good idea". They are useful only at the beginning and become a burden after (and I'd like to think we are no more at the beginning). - How are people handling DNS entries for IPv4/6 hosts today? I'd guess for a host foo.bar.com you're just adding a AAAA record for the same name with the RFC 1897 address (i.e., you're hand configuring the MAC address into the DNS record)? => we use special subzones (because AAAA RRs are not supported everywhere) and special names (because we'd like to select easily IPv4 or IPv6 addresses). For instance I use duvel.inria.fr for the A (IPv4) RR and duvel-v6.ipv6.inria.fr for the AAAA (IPv6) RR associated with "search inria.fr ipv6.inria.fr" in /etc/resolv.conf. Do any implementations that support configured tunnels advertise the subnet prefix (i.e., for the RFC 1897 address today) using router advertisements? => this should be done by any implementations! Are you putting link-local addresses into the DNS? => no, there is a special proposal for link-local address name service which works for the "dentist case" but must be refined for multi-homed boxes (where link-local things are very ambiguous). Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Aug 20 07:20:24 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13351; Tue, 20 Aug 96 07:20:24 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13345; Tue, 20 Aug 96 07:20:11 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA27880; Tue, 20 Aug 1996 07:15:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id HAA00210; Tue, 20 Aug 1996 07:15:00 -0700 Received: (from weiss@localhost) by bianca.ZDV.Uni-Mainz.DE (8.7.3/8.6.12) id QAA28679; Tue, 20 Aug 1996 16:14:55 +0200 (MET DST) Date: Tue, 20 Aug 1996 16:14:55 +0200 (MET DST) Message-Id: <199608201414.QAA28679@bianca.ZDV.Uni-Mainz.DE> From: Juergen Weiss To: ipng@sunroof.eng.sun.com Subject: (IPng 2048) Re: a few questions In-Reply-To: <199608201218.OAA12307@givry.inria.fr> References: <199608191802.LAA09689@gemini.tuc.noao.edu> <199608201218.OAA12307@givry.inria.fr> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Looking at the Sun and Netbsd Implementations I do not see any problem with IPv4 compatible IPv6 addresses. On my Sun the routing table looks as follows ::134.93.8.0/119 ::134.93.8.136 U 5 0 le0#v6:150 ::0.0.0.0/96 ::134.93.8.136 U 2 0 ip0 My understanding is, that in general packets to ipv4 compatible addresses are routed to the tunnel interface. But packets to ipv4 compatible addresses on the local lan are routed to the ethernet interface directly. Furthermore if I get specific routing information for ipv4 compatible nets by any routing protocol, the information has precedence over the `default route' into the tunnel. Juergen Weiss -- Juergen Weiss | Universitaet Mainz, Zentrum f"ur Datenverarbeitung, weiss@uni-mainz.de | 55099 Mainz, Tel: 06131/39-6361, FAX: 06131/39-6407 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Aug 20 08:25:12 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13403; Tue, 20 Aug 96 08:25:12 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13397; Tue, 20 Aug 96 08:24:55 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA06061; Tue, 20 Aug 1996 08:19:47 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA20034; Tue, 20 Aug 1996 08:19:47 -0700 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id LAA12566; Tue, 20 Aug 1996 11:22:51 -0400 Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA17864; Tue, 20 Aug 96 11:19:33 EDT Date: Tue, 20 Aug 96 11:19:33 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9608201519.AA17864@pobox.BayNetworks.com> To: rstevens@noao.edu, Francis.Dupont@inria.fr Subject: (IPng 2049) Re: a few questions Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > - It seems that most host implementations support (or will soon support) > configured tunnels, so the use of IPv4-compatible addresses should > really not be needed. > > => I agree, I believe IPv4-compatible addresses are a bad "good idea". > They are useful only at the beginning and become a burden after > (and I'd like to think we are no more at the beginning). > I think it is too soon to declare IPv4-compatible addresses useless. At this point there are enough routers on 6bone to support configured tunnels to a manageable number of isolated hosts. Indeed, with a small hosts-to-routers ratio, it is possible to do without automatic tunneling and forgo IPv4-compatible addresses completely. The situation may change if the number of IPv6 capable hosts outpace the number of IPv6 routers by a large margin. E.g. if there are hundreds isolated hosts per a router, it would be quite a chalange to set up and maintain hundres configured tunnels on a router. This is exactly the configuration burden that automatic tunneling was designed to alleviate. Basically configured tunnels meant to be used between routers not between a router and hundreds hosts. > > Do any implementations that support configured tunnels advertise the > subnet prefix (i.e., for the RFC 1897 address today) using router > advertisements? > > => this should be done by any implementations! > I agree. Basically configured tunnels should have the look and feel of a 'normal' p-to-p link. There is no need to perform the L2 address resolusion but all other ND functions are to be retained. Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Aug 20 08:25:57 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13415; Tue, 20 Aug 96 08:25:57 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13404; Tue, 20 Aug 96 08:25:40 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA06154; Tue, 20 Aug 1996 08:20:32 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA20234; Tue, 20 Aug 1996 08:20:31 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id LAA06774; Tue, 20 Aug 1996 11:12:38 -0400 (EDT) Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA04721; Tue, 20 Aug 1996 11:12:34 -0400 Received: by netrix.lkg.dec.com; (5.65v3.2/1.1.8.2/28May95-0415PM) id AA02110; Tue, 20 Aug 1996 11:12:32 -0400 Date: Tue, 20 Aug 1996 11:12:32 -0400 From: Dan Harrington Message-Id: <9608201512.AA02110@netrix.lkg.dec.com> To: weiss@uni-mainz.de Subject: (IPng 2050) Re: a few questions Cc: dan@lkg.dec.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Juergen, > My understanding is, that in general packets to ipv4 compatible > addresses are routed to the tunnel interface. But packets to > ipv4 compatible addresses on the local lan are routed to the > ethernet interface directly. Yes, the current ngtrans spec (RFC 1933) does provide for the common subnet special case. I feel this is an unnecessary optimization, as IPv4-compatible addresses indicate an IPv4 path from source to destination, and that the packets should therefore travel from source to destination using IPv4, whether the IPv4 cloud is the entire Internet, or one little piece of Ethernet. If we're using IPv4 as a link layer, we let it do the link layer's job of moving the packets around, and not do any network layer second-guessing. Otherwise we're just adding extra complexity and integration headaches. > Furthermore if I get specific routing information for ipv4 compatible > nets by any routing protocol, the information has precedence over the > `default route' into the tunnel. This is where it starts getting sticky...there are two issues that I'm aware of...Ran Atkinson brought up the point that duplicating IPv4 routing information as IPv6 routes (for IPv4-compatible addresses) is going to exacerbate the memory squeeze in routers. Also, it seems to me that if we start forcing routers to handle the task of encapsulating and decapsulating IPv6 into/from IPv4 packets, we've given them extra work to do, and extra work for routers seems to be something that everyone wants to avoid. If we've made the decision that routers must not fragment, and that it's a host's job to deal with the performance penalty, then it seems perfectly reasonable to let the hosts deal with IPv4 encapsulation/decapsulation when doing IPv4-compatible addressing. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Aug 20 09:18:39 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13505; Tue, 20 Aug 96 09:18:39 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13499; Tue, 20 Aug 96 09:18:26 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA15423; Tue, 20 Aug 1996 09:13:16 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA08170; Tue, 20 Aug 1996 09:13:16 -0700 Received: from muggsy.lkg.dec.com by mail13.digital.com (8.7.5/UNX 1.2/1.0/WV) id MAA19910; Tue, 20 Aug 1996 12:01:21 -0400 (EDT) Received: from netrix.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA05314; Tue, 20 Aug 1996 12:01:17 -0400 Received: by netrix.lkg.dec.com; (5.65v3.2/1.1.8.2/28May95-0415PM) id AA19200; Tue, 20 Aug 1996 12:01:16 -0400 Date: Tue, 20 Aug 1996 12:01:16 -0400 From: Dan Harrington Message-Id: <9608201601.AA19200@netrix.lkg.dec.com> To: rstevens@noao.edu Subject: (IPng 2051) Re: a few questions Cc: dan@lkg.dec.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Rich, Looks like you've mapped out the ngtrans agenda for the next IETF... :-) There seem to be some either/or options here... > - IPv4-mapped addresses should only be created by DNS resolvers when > a hostname is looked up and the hostname has no AAAA records but an > A record, and the caller wants a AAAA record returned. IPv4-mapped > addresses should never appear in a DNS data file--they are created as > needed by the resolver. Sounds like a bad idea...if you do this, there is no correlation between what address is in the DNS and what protocols are actually available on the remote system. If Dynamic Updates to DNS are available, then those hosts configured with IPv4-compatible addresses should be able to put the data in the DNS when it is appropriate. > - An IPv4/6 host should have a AAAA record with an IPv4-compatible address > only if that host does not have an IPv6 neighbor router. IPv4-compatible > addresses must appear in DNS data files--they are never created > automatically by resolvers. I'm not sure it should be tied to the existence of a router...certainly, IPv4-compatible addresses will be needed by hosts which are isolated...but they may well need to communicate with systems running IPv6 which are within a "real" IPv6 network. If that system does not have an IPv4-compatible address, the isolated system would not be able to connect to it (without manual configuration). > - If I have two LANS connected by IPv4 routers, with *no* configured > tunnels, IPv4-compatible addresses must be used by IPv4/6 hosts on the > two LANs to communicate with each other. > > - If I have two IPv4/6 hosts on a LAN, both with IPv4-compatible addresses > (since there is no neighbor IPv6 router) they will use an automatic > tunnel to communicate. Do people have a way around this needless > tunneling? I've responded to this issue separately...see IPng mail #2050. > Could you assign each of the two hosts two AAAA records: one with a real > (RFC 1897) IPv6 address and another with an IPv4-compatible address? Sure. > - If I then configure a tunnel between the two LANS, I must get rid of > the AAAA IPv4-compatible addresses and replace them with RFC 1897 > addresses. If you've already given them both AAAA records, and both paths (v4 and v6) are still valid, this would be up to you. > - A host with a configured tunnel is really acting as an IPv6 router > (for all the IPv6 hosts on its attached networks) and therefore must > do things such as respond to neighbor solicitations, and everything > else an IPv6 router must do. No, a host with a configured tunnel has a static route *for itself*. It's not acting as a router until you configure it to be a router, with all the behaviour that requires. > - It seems that most host implementations support (or will soon support) > configured tunnels, so the use of IPv4-compatible addresses should > really not be needed. They do have the benefit of not requiring manual intervention (aside from the DNS aspect). > - How are people handling DNS entries for IPv4/6 hosts today? I'd guess > for a host foo.bar.com you're just adding a AAAA record for the same > name with the RFC 1897 address (i.e., you're hand configuring the MAC > address into the DNS record)? As Francis has mentioned, separate names or subdomains is common practice. > Do any implementations that support configured tunnels advertise the > subnet prefix (i.e., for the RFC 1897 address today) using router > advertisements? The current Digital UNIX IPv6 kit supports this. > Are you putting link-local addresses into the DNS? I don't think this is appropriate...I've written a draft to discuss an alternate solution (draft-ietf-ipngwg-linkname-00.txt). I need to update this shortly, now that the IANA has provided the port/address information. Any and all feedback appreciated. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Aug 20 09:40:07 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13545; Tue, 20 Aug 96 09:40:07 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13539; Tue, 20 Aug 96 09:39:53 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA20477; Tue, 20 Aug 1996 09:34:37 -0700 Received: by mercury.Sun.COM (Sun.COM) id JAA16422; Tue, 20 Aug 1996 09:34:05 -0700 Received: (from roque@localhost) by oberon.di.fc.ul.pt (8.6.6.Beta9/8.6.6.Beta9) id RAA14653; Tue, 20 Aug 1996 17:31:51 +0100 Date: Tue, 20 Aug 1996 17:31:51 +0100 Message-Id: <199608201631.RAA14653@oberon.di.fc.ul.pt> From: Pedro Roque Marques To: dhaskin@BayNetworks.com (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2052) Re: a few questions In-Reply-To: <9608201519.AA17864@pobox.BayNetworks.com> References: <9608201519.AA17864@pobox.BayNetworks.com> Mime-Version: 1.0 (generated by tm-edit 7.69) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> "Dimitry" == Dimitry Haskin writes: >> Dimitry> I agree. Basically configured tunnels should have the Dimitry> look and feel of a 'normal' p-to-p link. There is no Dimitry> need to perform the L2 address resolusion but all other Dimitry> ND functions are to be retained. NUD ? Why ? >From my reading NUD was defined with two purposes: switching default router on failure and fix the problems you get with ARP when one node changes MAC address (usually when one host assumes the function of another). This problems are not present on point to point links. I believe that NUD assumes LAN speeds and bandwidth, using its default settings. Also NUD does not require any interaction with routing protocols when nexthop is deemed unreachable. regards, ./Pedro. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Aug 20 10:15:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13724; Tue, 20 Aug 96 10:15:21 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13718; Tue, 20 Aug 96 10:15:06 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA29356; Tue, 20 Aug 1996 10:09:34 -0700 Received: by mercury.Sun.COM (Sun.COM) id KAA00577; Tue, 20 Aug 1996 10:09:29 -0700 Received: from [9.67.9.217] by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA180538; Tue, 20 Aug 1996 09:56:04 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.37.18]) by rtpdce03.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id JAA176214; Tue, 20 Aug 1996 09:54:38 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03-RAL) id AA17812; Tue, 20 Aug 1996 09:56:12 -0400 Message-Id: <9608201356.AA17812@cichlid.raleigh.ibm.com> To: Richard Stevens Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2053) Re: a few questions In-Reply-To: Your message of "Mon, 19 Aug 1996 11:02:30 PDT." <199608191802.LAA09689@gemini.tuc.noao.edu> Date: Tue, 20 Aug 1996 09:56:09 -0300 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I have a couple of questions that I think I know the answer to, but >for which I cannot find explicit answers in the IPv6 documentation. Yikes! Is this a midterm exam or what? :-) >- IPv4-mapped addresses should only be created by DNS resolvers when > a hostname is looked up and the hostname has no AAAA records but an > A record, and the caller wants a AAAA record returned. IPv4-mapped > addresses should never appear in a DNS data file--they are created as > needed by the resolver. I think there are still disagreements on this, but a case can be made for the above. >- An IPv4/6 host should have a AAAA record with an IPv4-compatible address > only if that host does not have an IPv6 neighbor router. I'm not sure I agree with this, if this is related to the ambiguity about whether to tunnel or use native v6 when two nodes are connected to the same link. (But that's another discussion that hasn't been closed yet.) > IPv4-compatible > addresses must appear in DNS data files--they are never created > automatically by resolvers. This is almost a no-brainer. Since by default nodes don't speak v6 (at least short term), it doesn't make sense for the DNS to assume that all v4-speaking nodes also speak v6. I.e., there wouldn't need to be a distinction between IPv4-mapped and IPv4-compatible addresses, if DNS resolvers automatically created IPv4-compatible addresses by default. I think it would be useful, however, to allow DNS configurations in which it is easy for the sys admin to say "all v4 nodes also speak v6", or "all except the following", etc. IPv4-compatible addresses would still need to be explicitely configured, but it should be easy to do so. So I think it is useful to allow IPv4-compatible addresses to be generated automatically be the DNS, but only if configured to do so. >- If I have two LANS connected by IPv4 routers, with *no* configured > tunnels, IPv4-compatible addresses must be used by IPv4/6 hosts on the > two LANs to communicate with each other. Actually, I think you mean "... IPv4-mapped addresses must be used". That is, v6 isn't used at all. >- If I have two IPv4/6 hosts on a LAN, both with IPv4-compatible addresses > (since there is no neighbor IPv6 router) they will use an automatic > tunnel to communicate. Do people have a way around this needless > tunneling? Here is one possibility. In the common case, a v4-compatible address is generated/configured automatically by 1) turning on v6, and 2) looking at the v4 configuration. For each configured v4 address, automatically configure a v4-compatible address. Moreover, since the v4 subnet is "on-link", add an analagous v4-compatible prefix to the set of on-link v6 prefixes. The problem with the above, is that now a v4-compatible address is assigned to an Ethernet, which means it can't also be a tunnel end point (i.e., the purist line is that we can't assign the same unicast address to multiple interfaces). Another issue (I think) is that if you have a native v6 address and a v4-compatible one, which one should peer applications use? One proposal seems to be to not put the v4-compatible address in the DNS (your first point). The issue could also be resolved by having the DNS (or resolver, or the v6 application) have a rule that says you use the v4-compatible address last, i.e., only if communication using the other v6 addresses fails. I tend to prefer the latter because I think we will eventually need some policy/rules governing address selection, and the latter approach fits that model. > Could you assign each of the two hosts two AAAA records: one with a real > (RFC 1897) IPv6 address and another with an IPv4-compatible > address? One could. Then, Francis writes: >=> it is possible but if you prefer *real* things and don't want >to open the problem of address choice then you can put only the >RFC 1897 address. I don't believe we need a standard way to know >if IPv4-compatible / automatic tunnel is supported. Avoiding the question of address selection isn't going to make it go away. As folks come more dependent on the Internet for real business, I expect that sites will become increasingly multihomed (in the multiple ISP sense). >- If I then configure a tunnel between the two LANS, I must get rid of > the AAAA IPv4-compatible addresses and replace them with RFC 1897 > addresses. I'm not particularly comfortable with tightly coupling the use of IPv4-compatible addresses (and tunneling) with what is and is not in the DNS. In practice, it will lead to misconfigurations and interoperability problems. >- A host with a configured tunnel is really acting as an IPv6 router > (for all the IPv6 hosts on its attached networks) and therefore must > do things such as respond to neighbor solicitations, and everything > else an IPv6 router must do. Huh? I must be missing something. A host with a tunnel isn't forwarding packets that don't originate from itself, so it's not a router in the standard IPv6 sense. Why would it need to respond to Router Solicitations? >- It seems that most host implementations support (or will soon support) > configured tunnels, so the use of IPv4-compatible addresses should > really not be needed. I thought that the point of IPv4-compatible addresses was 1) to let a peer know that a destination host understands IPv6, and 2) to define a tunnel endpoint for tunneling v6 packets. This is to benefit sites that are just starting to deploy IPv6, which is completely independent of how long the destination site has been using v6. Just because site XXX has been using v6 for umpteen months, doesn't mean that other sites can do without IPv4-compatible addresses to site XXX. If folks really believe that IPv4-compatible addresses are a bad thing, we need to start with the assumption that they are not used at all, as opposed to pretending we can use them for a "little while". The transition to v6 is *not* going to happen quickly. >- How are people handling DNS entries for IPv4/6 hosts today? I'd guess > for a host foo.bar.com you're just adding a AAAA record for the same > name with the RFC 1897 address (i.e., you're hand configuring the MAC > address into the DNS record)? Francis writes: >=> we use special subzones (because AAAA RRs are not supported everywhere) >and special names (because we'd like to select easily IPv4 or IPv6 addresses). >For instance I use duvel.inria.fr for the A (IPv4) RR >and duvel-v6.ipv6.inria.fr for the AAAA (IPv6) RR associated >with "search inria.fr ipv6.inria.fr" in /etc/resolv.conf. And what does the PTR record look like? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Aug 20 11:12:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13814; Tue, 20 Aug 96 11:12:50 PDT Received: from Eng.Sun.COM (engmail1) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13808; Tue, 20 Aug 96 11:12:32 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA06647; Tue, 20 Aug 1996 11:07:18 -0700 Received: by mercury.Sun.COM (Sun.COM) id LAA26449; Tue, 20 Aug 1996 11:07:15 -0700 Received: from pobox.BayNetworks.com by lobster.wellfleet.com (SMI-8.6/SMI-4.1) id OAA20122; Tue, 20 Aug 1996 14:10:18 -0400 Received: from andover.engeast by pobox.BayNetworks.com (4.1/SMI-4.1) id AA26914; Tue, 20 Aug 96 14:06:41 EDT Date: Tue, 20 Aug 96 14:06:41 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9608201806.AA26914@pobox.BayNetworks.com> To: roque@di.fc.ul.pt Subject: (IPng 2054) Re: a few questions Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Pedro Roque Marques > > >>>>> "Dimitry" == Dimitry Haskin writes: > > >> > Dimitry> I agree. Basically configured tunnels should have the > Dimitry> look and feel of a 'normal' p-to-p link. There is no > Dimitry> need to perform the L2 address resolusion but all other > Dimitry> ND functions are to be retained. > > NUD ? Why ? > Yes, NUD too. Note that NUD has the concept of upper layer reachability advise. In the presence of such an advise no ND probes have to be actualy sent. > >From my reading NUD was defined with two purposes: switching default > router on failure and fix the problems you get with ARP when one node > changes MAC address (usually when one host assumes the function of > another). Well an alternative router could be on a different link (which can be a tunnel too). In such a case it would be quite handy to be able to learn that the remote end of a configured tunnel is not reachable. >This problems are not present on point to point links. > I believe that NUD assumes LAN speeds and bandwidth, using its > default settings. > The default settings may not be right for all types of links -- tunnel or not. It is why they are only defaults not the protocol constants. And again, the actual ND probe excange is not necessary if a upper level advise is present. > Also NUD does not require any interaction with routing protocols when > nexthop is deemed unreachable. > But it can influence the route selection. > regards, > ./Pedro. > Dimitry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Aug 20 12:25:11 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA13875; Tue, 20 Aug 96 12:25:11 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA13869; Tue, 20 Aug 96 12:24:56 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA02310; Tue, 20 Aug 1996 12:19:46 -0700 Received: by mercury.Sun.COM (Sun.COM) id MAA19990; Tue, 20 Aug 1996 12:19:45 -0700 Received: from muggsy.lkg.dec.com by mail12.digital.com (8.7.5/UNX 1.2/1.0/WV) id PAA28996; Tue, 20 Aug 1996 15:14:39 -0400 (EDT) Received: from whydos.lkg.dec.com by muggsy.lkg.dec.com (5.65/DEC-Ultrix/4.3) with SMTP id AA06863; Tue, 20 Aug 1996 15:14:30 -0400 Received: from localhost.lkg.dec.com (localhost.lkg.dec.com [127.0.0.1]) by whydos.lkg.dec.com (8.6.12/8.6.12) with SMTP id PAA11462; Tue, 20 Aug 1996 15:18:56 GMT Message-Id: <199608201518.PAA11462@whydos.lkg.dec.com> X-Authentication-Warning: whydos.lkg.dec.com: Host localhost.lkg.dec.com didn't use HELO protocol X-Mailer: exmh version 1.6.5 12/11/95 To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2055) Re: a few questions In-Reply-To: Your message of "Tue, 20 Aug 1996 11:19:33 EDT." <9608201519.AA17864@pobox.BayNetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Aug 1996 15:18:55 +0000 From: Matt Thomas Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I agree. Basically configured tunnels should have the look and feel of > a 'normal' p-to-p link. There is no need to perform the L2 address > resolusion but all other ND functions are to be retained. I strongly disagree. I view a tunnel as a neighboring node on a NBMA datalink where the underlying network is the NBMA datalink. As such, tunnels are more like neighbor cache entries than p-p endpoints. This also corresponds nicely with unidirectional characteristic of a tunnel (this is how I send packets to X. The return path is not my concern). -- Matt Thomas Internet: matt@lkg.dec.com IPv6 Kernel Grunt WWW URL: http://ftp.dec.com/%7Ethomas/ Digital Equipment Corporation Disclaimer: This message reflects my Littleton, MA own warped views, etc. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Aug 20 14:14:21 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14076; Tue, 20 Aug 96 14:14:21 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA14070; Tue, 20 Aug 96 14:14:07 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA29237; Tue, 20 Aug 1996 14:08:49 -0700 Received: by mercury.Sun.COM (Sun.COM) id OAA00546; Tue, 20 Aug 1996 14:08:34 -0700 Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.7.1/8.7.1) with ESMTP id XAA17901; Tue, 20 Aug 1996 23:08:26 +0200 (MET DST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.1/8.6.6) with ESMTP id XAA13425; Tue, 20 Aug 1996 23:08:25 +0200 (MET DST) Message-Id: <199608202108.XAA13425@givry.inria.fr> From: Francis Dupont To: Thomas Narten Cc: Richard Stevens , ipng@sunroof.eng.sun.com Subject: (IPng 2056) Re: a few questions In-Reply-To: Your message of Tue, 20 Aug 1996 09:56:09 -0300. <9608201356.AA17812@cichlid.raleigh.ibm.com> Date: Tue, 20 Aug 1996 23:08:09 +0200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >- IPv4-mapped addresses should only be created by DNS resolvers when > a hostname is looked up and the hostname has no AAAA records but an > A record, and the caller wants a AAAA record returned. IPv4-mapped > addresses should never appear in a DNS data file--they are created as > needed by the resolver. I think there are still disagreements on this, but a case can be made for the above. => I believe[d] disagreements what about IPv4-compatible addresses, not for IPv4-mapped addresses ? >- If I have two IPv4/6 hosts on a LAN, both with IPv4-compatible addresses > (since there is no neighbor IPv6 router) they will use an automatic > tunnel to communicate. Do people have a way around this needless > tunneling? => I don't think there is a definitive argument here, but we have to do the choice for interoperability. Another issue (I think) is that if you have a native v6 address and a v4-compatible one, which one should peer applications use? One proposal seems to be to not put the v4-compatible address in the DNS (your first point). The issue could also be resolved by having the DNS (or resolver, or the v6 application) have a rule that says you use the v4-compatible address last, i.e., only if communication using the other v6 addresses fails. I tend to prefer the latter because I think we will eventually need some policy/rules governing address selection, and the latter approach fits that model. => I use the first proposal but I agree address selection issue cannot be avoid (but what to do here, for instance between several native global IPv6 addresses ? There is no preference field...) Then, Francis writes: >=> it is possible but if you prefer *real* things and don't want >to open the problem of address choice then you can put only the >RFC 1897 address. I don't believe we need a standard way to know >if IPv4-compatible / automatic tunnel is supported. Avoiding the question of address selection isn't going to make it go away. As folks come more dependent on the Internet for real business, I expect that sites will become increasingly multihomed (in the multiple ISP sense). => I agree. There is the "sortlist" trick for IPv4 but I believe it is not enough... We can use the TTL too (and the API can return / returns it with each address) ? >- It seems that most host implementations support (or will soon support) > configured tunnels, so the use of IPv4-compatible addresses should > really not be needed. I thought that the point of IPv4-compatible addresses was 1) to let a peer know that a destination host understands IPv6, and 2) to define a tunnel endpoint for tunneling v6 packets. This is to benefit sites that are just starting to deploy IPv6, which is completely independent of how long the destination site has been using v6. Just because site XXX has been using v6 for umpteen months, doesn't mean that other sites can do without IPv4-compatible addresses to site XXX. If folks really believe that IPv4-compatible addresses are a bad thing, we need to start with the assumption that they are not used at all, as opposed to pretending we can use them for a "little while". The transition to v6 is *not* going to happen quickly. => in fact they are two main ways for deploying IPv6, from routers and from hosts: - from routers: the whole site gets a native global IPv6 prefix, routers are used for configured tunnel end-points and do the job. IPv4-compatible addresses are only used for the tunnels and are not known by the hosts and users. - from hosts: IPv6 hosts are isolated (at the beginning) and need IPv4-compatible addresses for aotomatic tunnelling. I prefer the first way but the reality will use both then we have to keep IPv4-compatible stuff. My point is we should not abuse because the future IPv6 world shall be router based... >- How are people handling DNS entries for IPv4/6 hosts today? I'd guess > for a host foo.bar.com you're just adding a AAAA record for the same > name with the RFC 1897 address (i.e., you're hand configuring the MAC > address into the DNS record)? Francis writes: >=> we use special subzones (because AAAA RRs are not supported everywhere) >and special names (because we'd like to select easily IPv4 or IPv6 addresses). >For instance I use duvel.inria.fr for the A (IPv4) RR >and duvel-v6.ipv6.inria.fr for the AAAA (IPv6) RR associated >with "search inria.fr ipv6.inria.fr" in /etc/resolv.conf. And what does the PTR record look like? => exactly what you expect: 50.9.93.128.in-addr.arpa. IN PTR duvel.inria.fr. 1.8.7.8.0.0.e.f.0.2.0.0.0.0.0.0.0.0.0.0.d.5.0.8.0.0.5.b.6.0.f.5.ip6.int. IN PTR duvel-v6.ipv6.inria.fr. (of course my nslookup/dig can reverse/mask/truncate the address for me :-) Regards Francis.Dupont@inria.fr ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Aug 20 21:47:28 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14392; Tue, 20 Aug 96 21:47:28 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA14386; Tue, 20 Aug 96 21:47:16 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA17894; Tue, 20 Aug 1996 21:42:06 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id VAA17186; Tue, 20 Aug 1996 21:42:06 -0700 Received: from fwasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id AAA09551; Wed, 21 Aug 1996 00:31:38 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA27997; Wed, 21 Aug 1996 00:30:21 -0400 Message-Id: <9608210430.AA27997@fwasted.zk3.dec.com> To: Richard Stevens Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2057) Re: a few questions In-Reply-To: Your message of "Mon, 19 Aug 96 11:02:30 PDT." <199608191802.LAA09689@gemini.tuc.noao.edu> Date: Wed, 21 Aug 96 00:30:21 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, IPv4 compatible addresses I think should only be used for tunnels. The reason is that if your on the LAN all IPv6 nodes have a LL-address. So use that. If your going off lan and there is no IPv6 router then you should use IPv4 tunnel configured our automatic. I don't think IPv4 compatible addresses should be propogatged to be used thru an IPv6 router or on the local link. I don't think that the DNS should return IPv4 compatible or IPv4 mapped addresses. AAAA records should only be RFC 1897 IPv6 addresses for now (which is not good enough for tomorrow real soon). Use RFC 1897 for now. Don't put anyother addresses as AAAA records in the DNS. This keeps it real simple and a very minor change to the transition spec and I really don't have a clue why anything else is an option after Montreal. We don't want to propogate IPv4-Compatible addresses in the Routing table and that had much consensus and I think the DNS has the same arguments. If you look at the implementations running now this works pretty well are you running one of them and on the 6bone? It seems to be working as I right this mail and I really don't want to enter a gigantic undefined, unscoped rathole that we have basically figured out some time ago except now we know propogating IPv4-compatible addresses seems to be a bad idea. As someone else pointed out this has nothing to do with IPv4-mapped addresses. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Aug 21 13:55:41 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14871; Wed, 21 Aug 96 13:55:41 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA14865; Wed, 21 Aug 96 13:55:27 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA19357; Wed, 21 Aug 1996 13:50:03 -0700 Received: by mercury.Sun.COM (Sun.COM) id NAA18001; Wed, 21 Aug 1996 13:49:56 -0700 Received: from rtpdce01.raleigh.ibm.com by socks2.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA70842; Wed, 21 Aug 1996 16:48:12 -0400 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.37.18]) by rtpdce01.raleigh.ibm.com (8.7.3/8.7.3/RTP-ral-1.0) with SMTP id QAA56640 for ; Wed, 21 Aug 1996 16:48:10 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 3.2/UCB 5.64/4.03-RAL) id AA21312; Wed, 21 Aug 1996 16:49:52 -0400 Message-Id: <9608212049.AA21312@cichlid.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 2058) Re: a few questions In-Reply-To: Your message of "Wed, 21 Aug 1996 00:30:21 EDT." <9608210430.AA27997@fwasted.zk3.dec.com> Date: Wed, 21 Aug 1996 16:49:52 -0300 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > >- IPv4-mapped addresses should only be created by DNS resolvers when > > a hostname is looked up and the hostname has no AAAA records but an > > A record, and the caller wants a AAAA record returned. IPv4-mapped > > addresses should never appear in a DNS data file--they are created as > > needed by the resolver. > > I think there are still disagreements on this, but a case can be made > for the above. > >=> I believe[d] disagreements what about IPv4-compatible addresses, >not for IPv4-mapped addresses ? If so, then don't we need to state (forcefully) that resolvers MUST map DNS PTR queries for v4-mapped addresses into corresponding v4 PTR lookups? bound@zk3.dec.com writes: >I don't think that the DNS should return IPv4 compatible or IPv4 mapped >addresses. AAAA records should only be RFC 1897 IPv6 addresses for now >(which is not good enough for tomorrow real soon). Do you really mean that first sentence? If IPv4-compatible addresses aren't in the DNS, how will anyone know they exist? That would break one of the basic transition mechanisms. Are you suggesting that a resolver query for an A record, and then manufacture a corresponding compatible address and then hope it actually works? Thomas ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Aug 21 19:25:04 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA15092; Wed, 21 Aug 96 19:25:04 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA15086; Wed, 21 Aug 96 19:24:51 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA03236; Wed, 21 Aug 1996 19:19:40 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id TAA24488; Wed, 21 Aug 1996 19:19:40 -0700 Received: from fwasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id WAA03615; Wed, 21 Aug 1996 22:13:31 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA05639; Wed, 21 Aug 1996 22:13:31 -0400 Message-Id: <9608220213.AA05639@fwasted.zk3.dec.com> To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2059) Re: a few questions In-Reply-To: Your message of "Wed, 21 Aug 96 16:49:52 -0300." <9608212049.AA21312@cichlid.raleigh.ibm.com> Date: Wed, 21 Aug 96 22:13:30 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >> >- IPv4-mapped addresses should only be created by DNS resolvers when >> > a hostname is looked up and the hostname has no AAAA records but an >> > A record, and the caller wants a AAAA record returned. IPv4-mapped >> > addresses should never appear in a DNS data file--they are created as >> > needed by the resolver. >> >> I think there are still disagreements on this, but a case can be made >> for the above. >> >>=> I believe[d] disagreements what about IPv4-compatible addresses, >>not for IPv4-mapped addresses ? > >If so, then don't we need to state (forcefully) that resolvers MUST >map DNS PTR queries for v4-mapped addresses into corresponding v4 PTR >lookups? See below....for my comments on IPv4 mapped addresses. >bound@zk3.dec.com writes: > >>I don't think that the DNS should return IPv4 compatible or IPv4 mapped >>addresses. AAAA records should only be RFC 1897 IPv6 addresses for now >>(which is not good enough for tomorrow real soon). >Do you really mean that first sentence? If IPv4-compatible addresses >aren't in the DNS, how will anyone know they exist? That would break >one of the basic transition mechanisms. Are you suggesting that a >resolver query for an A record, and then manufacture a corresponding >compatible address and then hope it actually works? Well I should state what I believe now and I am not saying we should change anything as I want to test it with users I know are now beginning to prepare to deploy IPv6 OK. But I am beginning to think that IPv4 compatible addresses are totally unecessary. The reason is that for the link the LL-address will work fine. If someone wants to advertise themseleves as an IPv6 node then they must use RFC 1897+ (meaning we get a new RFC out a.s.a.p. that uses real IPv6 addresses). This way the entire notion of an IPv4 compatible address is not even needed. IPv4 mapped addresses are only useful for one purpose to map IPv4 addresses up a stack that only supports a dual network layer and dual API layer. In other words its only used when you want the entire IPv6 stack between those to layers to deal with 16byte thingees. I don't think it breaks the transition spec just makes it more simple especially the sending rules state diagrams which I have reviewed with users and it takes a lot of doing to explain it to them. Plus we get rid of the long term problem of having those IPv4 compatible addresses hanging around later. What it does do is leave us without the ability to deploy IPv6 with automatic tunnels using the IPv4 address of the IPv4 compatible address. But that can be resolved with configured tunnels until IPv6 is on the backbone. This is the point that may break my new thought???? I have not talked to "1" user who will not go get real IPv6 addresses. I know of no implementation that cannot support real IPv6 addresses. It has no affect on the routing infrastructure. All it does is remove extra baggage. I also do not believe now that IPv4 compatible addresses will make IPv6 easier or more expedient to deploy. My other concern is that this use will only be useful as long as IPv4 addresses exist and I don't believe that will be long. I am certainly open to being convinced I am wrong as I used to believe they were important but once I saw the mess they will cause in the routing tables, DNS, and eventually after nodes are deployed widely with IPv6 I am changing my mind. In my defense of this change its from implementing transition mechanisms, talking to users that will deploy IPv6, and seeing the 6bone work. I really don't think we need them anymore. But automatic tunnels can be useful. At the end of the day it has to be determined how much they will hurt the deployment later and maybe its OK as an option and if we do that then what we might want is another type of record in the DNS like an ACMP record that clearly differentiates IPv4 compatible addresses from IPv6 addresses so they can be cleaned up later. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Aug 23 17:06:50 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA16098; Fri, 23 Aug 96 17:06:50 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA16092; Fri, 23 Aug 96 17:06:36 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA23500; Fri, 23 Aug 1996 17:01:19 -0700 Received: by mercury.Sun.COM (Sun.COM) id RAA10139; Fri, 23 Aug 1996 17:01:19 -0700 Received: (from root@localhost) by littlewing.mcom.com (8.7.3/8.7.3) id PAA28434; Fri, 23 Aug 1996 15:41:44 -0700 (PDT) Received: from maleman.mcom.com (maleman.mcom.com [198.93.92.3]) by tera.mcom.com (8.6.12/8.6.9) with ESMTP id TAA17248 for ; Thu, 22 Aug 1996 19:37:44 -0700 Received: from ns.netscape.com (ns.netscape.com.mcom.com [198.95.251.10]) by maleman.mcom.com (8.6.9/8.6.9) with ESMTP id VAA05800 for ; Tue, 20 Aug 1996 21:43:50 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.netscape.com (8.7.3/8.7.3) with SMTP id VAA01220 for ; Tue, 20 Aug 1996 21:42:50 -0700 (PDT) Received: by mercury.Sun.COM (Sun.COM) id VAA17610; Tue, 20 Aug 1996 21:44:25 -0700 Received: from sunroof.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA18061; Tue, 20 Aug 1996 21:44:15 -0700 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14392; Tue, 20 Aug 96 21:47:28 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA14386; Tue, 20 Aug 96 21:47:16 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA17894; Tue, 20 Aug 1996 21:42:06 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id VAA17186; Tue, 20 Aug 1996 21:42:06 -0700 Received: from fwasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id AAA09551; Wed, 21 Aug 1996 00:31:38 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA27997; Wed, 21 Aug 1996 00:30:21 -0400 Message-Id: <9608210430.AA27997@fwasted.zk3.dec.com> To: Richard Stevens Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2060) Re: a few questions In-Reply-To: Your message of "Mon, 19 Aug 96 11:02:30 PDT." <199608191802.LAA09689@gemini.tuc.noao.edu> Date: Wed, 21 Aug 96 00:30:21 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Message body suppressed ----- --TAA17255.840768101/tera.mcom.com-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Aug 23 18:58:06 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA17590; Fri, 23 Aug 96 18:58:06 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA17584; Fri, 23 Aug 96 18:57:52 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA11988; Fri, 23 Aug 1996 18:51:55 -0700 Received: by mercury.Sun.COM (Sun.COM) id SAA28087; Fri, 23 Aug 1996 18:51:50 -0700 Received: (from root@localhost) by littlewing.mcom.com (8.7.3/8.7.3) id SAA03272; Fri, 23 Aug 1996 18:54:15 -0700 (PDT) Received: from maleman.mcom.com (maleman.mcom.com [198.93.92.3]) by tera.mcom.com (8.6.12/8.6.9) with ESMTP id TAA17248 for ; Thu, 22 Aug 1996 19:37:44 -0700 Received: from ns.netscape.com (ns.netscape.com.mcom.com [198.95.251.10]) by maleman.mcom.com (8.6.9/8.6.9) with ESMTP id VAA05800 for ; Tue, 20 Aug 1996 21:43:50 -0700 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.netscape.com (8.7.3/8.7.3) with SMTP id VAA01220 for ; Tue, 20 Aug 1996 21:42:50 -0700 (PDT) Received: by mercury.Sun.COM (Sun.COM) id VAA17610; Tue, 20 Aug 1996 21:44:25 -0700 Received: from sunroof.eng.sun.com by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA18061; Tue, 20 Aug 1996 21:44:15 -0700 Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA14392; Tue, 20 Aug 96 21:47:28 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA14386; Tue, 20 Aug 96 21:47:16 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA17894; Tue, 20 Aug 1996 21:42:06 -0700 From: bound@zk3.dec.com Received: by mercury.Sun.COM (Sun.COM) id VAA17186; Tue, 20 Aug 1996 21:42:06 -0700 Received: from fwasted.zk3.dec.com by mail11.digital.com (8.7.5/UNX 1.2/1.0/WV) id AAA09551; Wed, 21 Aug 1996 00:31:38 -0400 (EDT) Received: from localhost by fwasted.zk3.dec.com; (5.65v3.2/1.1.8.2/18Feb95-1123AM) id AA27997; Wed, 21 Aug 1996 00:30:21 -0400 Message-Id: <9608210430.AA27997@fwasted.zk3.dec.com> To: Richard Stevens Cc: ipng@sunroof.eng.sun.com Subject: (IPng 2061) Re: a few questions In-Reply-To: Your message of "Mon, 19 Aug 96 11:02:30 PDT." <199608191802.LAA09689@gemini.tuc.noao.edu> Date: Wed, 21 Aug 96 00:30:21 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Message body suppressed ----- --TAA17255.840768101/tera.mcom.com-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Aug 25 16:28:40 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19552; Sun, 25 Aug 96 16:28:40 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA19546; Sun, 25 Aug 96 16:28:27 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA29578; Sun, 25 Aug 1996 16:23:11 -0700 From: ocrds@iitk.ernet.in Received: by mercury.Sun.COM (Sun.COM) id QAA17261; Sun, 25 Aug 1996 16:23:05 -0700 Received: by doe.ernet.in (4.1/SMI-4.1-MHS-7.0) id AA19769; Mon, 26 Aug 96 04:57:40+050 Received: by iitk.ernet.in (Smail3.1.29.1 #1) id m0uul5K-0009rrC; Mon, 26 Aug 96 01:13 GMT+5:30 Received: from csesun1 by yamuna.iitk.ernet.in with smtp (Smail3.1.29.1 #3) id m0uul08-000JbIC; Mon, 26 Aug 96 01:07 IST(+5:30) Received: from csealpha1.cse.iitk.ernet.in by csesun1 (4.0/SMI-4.0) id AA12781; Sun, 25 Aug 96 10:05:43 IST Received: by csealpha1.cse.iitk.ernet.in; (5.65/1.1.8.2/26Jul95-0331PM) id AA21458; Mon, 26 Aug 1996 01:14:53 +0530 Message-Id: <9608251944.AA21458@csealpha1.cse.iitk.ernet.in> Subject: (IPng 2062) Converting IPv4 appls. to use the extended API To: ipng@sunroof.eng.sun.com Date: Mon, 26 Aug 96 1:14:53 IST X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Transition from IPv4 to IPv6 will require conversion of IPv4 applications to use the extended API. The extended API provides both source & binary compatibility for programs written using the original API. But these appls should also be able to use IPv6 only addresses. I guess a tool to automatically convert IPv4 sources using the original API, to now use the extended API, would be very helpful. Though new features, like using the newer setsockopt ( ) options, cannot be provided directly. But the basic functionality can be. Is such a tool already available ? Any suggestions are welcome. ------------------------------------------------------------------------------ Sameer Shah Ph. : +91-512-257653 (Lab.) Indian Institute of Technology E-mail : ocrds@iitk.ernet.in Kanpur 208 016, India ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Aug 26 08:21:49 1996 Return-Path: Received: by sunroof.eng.sun.com (4.1/SMI-4.1) id AA19764; Mon, 26 Aug 96 08:21:49 PDT Received: from Eng.Sun.COM (engmail2) by sunroof.eng.sun.com.eng.sun.com (4.1/SMI-4.1) id AA19758; Mon, 26 Aug 96 08:21:36 PDT Received: from mercury.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA15201; Mon, 26 Aug 1996 08:16:19 -0700 Received: by mercury.Sun.COM (Sun.COM) id IAA21646; Mon, 26 Aug 1996 08:16:18 -0700 Received: from dxcoms.cern.ch (dxcoms.cern.ch [137.138.28.176]) by dxmint.cern.ch with SMTP id RAA04037 for ; Mon, 26 Aug 1996 17:16:17 +0200 (MET DST) Received: by dxcoms.cern.ch; (5.65v3.0/1.1.8.2/28Jul95-0949AM) id AA16304; Mon, 26 Aug 1996 17:16:16 +0200 Message-Id: <9608261516.AA16304@dxcoms.cern.ch> Subject: (IPng 2063) Re: FTP over IPv6: maybe not FOOBAR? To: ipng@sunroof.eng.sun.com Date: Mon, 26 Aug 1996 17:16:16 +0200 (MET DST) From: "Brian Carpenter CERN-CN" In-Reply-To: <199608120032.UAA19716@inner.net> from "Craig Metz" at Aug 12, 96 08:38:43 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ... I've never seen a legitimate use for "three way" FTP > (although I'm sure people can come up with theoretical uses), and I don't > think it's unreasonable to de-implement it. > RFC 1068 A. DeSchon, R. Braden, "Background File Transfer Program BFTP" This *is* useful functionality although when we tried to deploy BFTP a few years ago the code seemed to be fairly broken. However I can see no computer science reason why 3-way FTP requires numeric addresses to be passed around; it could be achieved using FQDNs just as well. I'd support referring this to the imminent FTP working group. Brian Carpenter ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng IPng Home Page: http://playground.sun.com/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com