From owner-ipng Sun Jan 1 05:11:27 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02026; Sun, 1 Jan 95 05:11:27 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02020; Sun, 1 Jan 95 05:11:15 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA13301; Sun, 1 Jan 95 05:05:19 PST Received: from mail04.mail.aol.com by Sun.COM (sun-barr.Sun.COM) id AA03276; Sun, 1 Jan 95 05:05:26 PST Received: by mail04.mail.aol.com (1.38.193.5/16.2) id AA07547; Sun, 1 Jan 1995 08:02:18 -0500 Date: Sun, 1 Jan 1995 08:02:18 -0500 From: Telford001@aol.com Message-Id: <950101080212_3720301@aol.com> To: ipng@sunroof.Eng.Sun.COM Cc: Telford001@aol.com, rcallon@pobox.wellfleet.com(rosscallon) Subject: Re: (IPng) MTU size issues Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >> > It is not at all clear to me that adding a shim layer between IPv6 and >> > small-MTU link layers to provide intra-link fragmentation and reassembly >> > is "penalizing" those layers. In fact, it makes more efficient use of >> > the bandwidth of those links (*assuming low packet loss*) than does IP-layer >> > or transport-layer fragmentation, since each fragment does not have to >> > incur the significant overhead of IP-layer or IP+transport layer headers. >> It only penalizes users if someone doesn't specify the exact method of >> doing the fragmentation and reassembly. If suppliers are left to spec >> this themselves, then it could become a problem for users and this >> would be punative. >If we agree on an MTU which is too large for any common data >link, then clearly this is correct and we will need to also >define a protocol for local F&R over each "small MTU" data >link. People keep making assertions of the innocuousness or benefits of link layer fragmentation and reassembly. Relative to network layer fragmentation with reassembly at the destination host, link layer F&R can increase latency through the network tremendously. Succeeding links may be underutilized while the packets are rassembled at the previous link. In the case of a succession of networks with little loss and small MTUs where traffic is shared among multiple equal cost routes (as happens in OSPF based networks) or near equal cost routes (as happens in IGRP and EIGRP based networks), fragmentation with reassembly at the end host improves bandwidth utilization throughout the network while link layer F&R on a per link basis can result in poor bandwidth utilization while increasing total latency through the network tremendously. >Given that we are talking about "datagrams" here, and a >very low but greater than zero probability of packet loss >is acceptable, the F&R shim protocol should be very simple. Until network designers decide to multiplex channels to crank up the bandwidth for a link and some sort of multiplexed link layer procedures are required. >I think that it would help the discussion if someone with >appropriate experience could take a look at how hard it >would be to implement a local F&R protocol to run over >Localtalk networks (and PPP links), and what sort of >impact this will have on the efficiency of link utilization. >I agree with Steve's observation that this is likely to >actually improve link utilization. There is no reason to believe that local F&R protocols will lead to improved link utilization in the general case. A significant proportion of possible network designs will probably suffer degradation due to the use of local F&R protocols. >Ross Joachim Carlo Santos Martillo Ajami ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jan 2 05:54:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02264; Mon, 2 Jan 95 05:54:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02258; Mon, 2 Jan 95 05:54:36 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA03234; Mon, 2 Jan 95 05:48:39 PST Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA12145; Mon, 2 Jan 95 05:48:45 PST Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA12056; Mon, 2 Jan 1995 14:48:38 +0100 Message-Id: <199501021348.AA12056@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) the MTU bullet Date: Mon, 02 Jan 1995 14:48:37 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, There are two rationales for using larger MTU, transmission efficiency and the support of UDP based applications (and other datagrams too). In fact, only the second can be a rationale for *mandating* a large MTU: given path MTU discovery, the efficiency gains would fall out anyhow if a large MTU was recommended, even if it is not mandated. Did we really investigate what would be needed to support sufficient path MTU discovery for UDP? Suppose that your UDP stack maintains some state variable describing the MTU associated to one particular destination. Then, UDP could automatically implement end-to-end fragmentaion if the message is larger than the MTU. If by mistake it sends a too large datagram, that datagram will indeed be lost, but upon reception of the ICMP message the UDP stack could update the destination's MTU. Just like TCP, with one caveat though - there is no ACK/repeat in UDP, so the applications should be capable of dicreasing the MTU in case of timer expiration. Indeed, the very large UDP servers will not want to keep state for all of their clients. But there are many tricks that they can play. They may wish to keep exactly one state variable, common to all destinations, effectively converging towards the lowest of all their partner's MTU. They may also use caches of the most recently used clients, separate the clients into classes, etc. We could also consider Yakov's idea of a forward path indication. As the lowest MTUs are more likely to be found in the last hops (Appletalk, radio, noisy phone lines), one may assume that this particularity is known by the "client". Why not pass this information in an end-to-end parameter, then keep it in a LRU cache at the server's side? I would rather see us investing in end-to-end protocols than imposing strong requirements to connecting networks. IP should run over everything, be it IPv4 or IPv6. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jan 2 12:19:04 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02436; Mon, 2 Jan 95 12:19:04 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02430; Mon, 2 Jan 95 12:18:57 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA10822; Mon, 2 Jan 95 12:12:59 PST Received: from black-ice.cc.vt.edu by Sun.COM (sun-barr.Sun.COM) id AA28164; Mon, 2 Jan 95 12:13:06 PST Received: from localhost (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.6.9/8.6.9) with ESMTP id PAA15090 for ; Mon, 2 Jan 1995 15:13:05 -0500 Message-Id: <199501022013.PAA15090@black-ice.cc.vt.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) the MTU bullet In-Reply-To: Your message of "Mon, 02 Jan 1995 14:48:37 +0100." <199501021348.AA12056@mitsou.inria.fr> From: Valdis.Kletnieks@vt.edu Date: Mon, 02 Jan 1995 15:13:01 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On Mon, 02 Jan 1995 14:48:37 +0100, Christian Huitema said: > Indeed, the very large UDP servers will not want to keep state for all of > their clients. But there are many tricks that they can play. They may wish to > keep exactly one state variable, common to all destinations, effectively > converging towards the lowest of all their partner's MTU. They may also use > caches of the most recently used clients, separate the clients into classes, > etc. All 'one state variable' means is that one query from some old outdated part of the network will cause a root nameserver to strangle all it's replies to the entire world until such time as it decides to unthrottle... Also, I suspect that for DNS, the 'most recently used clients' cache will be a non-starter. For a root nameserver, most of the replies will be for a SOA/NS entry for an entire *.wombat.com domain referring the petitioner off to another server. Said reply will probably get cached and not re-asked for up to a week or so. I'm sure similar logic applies to most of the second-level nameservers as well - I know that I have a machine here that does some 100K lookups a day, but since it has a local caching nameserver, only 2K/day actually make it onto the wire (basically, the ones refreshing timed-out cache entries). I suspect that we'll just have to mandate a "try this size and recover in if you get an ICMP error" behavior. I have to admit wondering if, since the DNS will require at least *some* changes for IPv6 *anyhow*, we can win anything by creating a not-quite-UDP format for DNS - seems that some of the problems that DNS will have are similar to generic UDP applications, but some are rather specific to DNS. Valdis Kletnieks Computer Systems Engineer Virginia Tech ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jan 2 17:09:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02581; Mon, 2 Jan 95 17:09:59 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02575; Mon, 2 Jan 95 17:09:46 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA17206; Mon, 2 Jan 95 17:03:48 PST Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA09494; Mon, 2 Jan 95 16:56:43 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm036-13.dialip.mich.net [141.211.7.55]) by merit.edu (8.6.9/merit-2.0) with SMTP id TAA14934 for ; Mon, 2 Jan 1995 19:34:26 -0500 Date: Mon, 2 Jan 95 16:11:36 GMT From: "William Allen Simpson" Message-Id: <3618.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) the MTU bullet Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > From: Christian Huitema > We could also consider Yakov's idea of a forward path indication. As the > lowest MTUs are more likely to be found in the last hops (Appletalk, radio, > noisy phone lines), one may assume that this particularity is known by the > "client". Why not pass this information in an end-to-end parameter, then keep > it in a LRU cache at the server's side? > This is a good idea (Maximum Receive Unit). All DNS requests could include the indication, and all DNS replies should send the minimum of their link MTU and the requesting MRU. But, the DNS SHOULD also include a fragmentation header, in case intervening links have a lower MTU. That should handle all cases in the most expeditious fashion. But why bother caching it? Certainly not for DNS. Better to cache at the application (for NFS). > I would rather see us investing in end-to-end protocols than imposing > strong requirements to connecting networks. IP should run over everything, be > it IPv4 or IPv6. > Hear, Hear! Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jan 2 18:35:44 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02598; Mon, 2 Jan 95 18:35:44 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02592; Mon, 2 Jan 95 18:35:37 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA18930; Mon, 2 Jan 95 18:29:39 PST Received: from bridge2.NSD.3Com.COM by Sun.COM (sun-barr.Sun.COM) id AA12691; Mon, 2 Jan 95 18:29:46 PST Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA29833 (5.65c/IDA-1.4.4nsd for ); Mon, 2 Jan 1995 18:29:45 -0800 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA07327 (5.65c/IDA-1.4.4-910725 for ); Mon, 2 Jan 1995 18:29:43 -0800 Message-Id: <199501030229.AA07327@remmel.NSD.3Com.COM> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) minimum MTU In-Reply-To: Your message of "Thu, 22 Dec 1994 18:58:30 +1100." <3557.788083110@munnari.OZ.AU> Date: Mon, 02 Jan 1995 18:29:42 -0800 From: Tracy Mallory Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [My most important message is near the end: suggestion for use of PPP Multilink for serial lines if large MTU is supported.] > I don't recall consensus anywhere on 1500 octet reassembly though? Not > that I disagree, but when and where did this get agreed to by the > working group? > > /jim > > You'd do better to ask SteveD. As I recall it was about 20 > seconds of hand waving, followed by 5 seconds of silence in the > "any objections" period. It was probably in Toronto. > > kre > > My recollection is that we "recommended" it at the October > implementor's meeting, then we sort of let it stand at the first > session of the San Jose WG meeting. > > -mad At San Jose there was a fair amount of debate(~10 minutes), with several people strongly opposed, and the vast majority willing to go along with "...since we're changing the stack anyway, and DNS/UDP will certainly want more than 576". All the way to 1500-ish was simply that, once you went much above 576 (I don't consider 587 for Appletalk enough different to matter) it didn't matter much how far you went since, of the somewhat interesting problem cases ("slow" serial, packet radio(serial?), Appletalk, and Ran's satellite net with 1024 byte frames), only the satellite net would be helped by an intermediate value. I argued (not very convincingly) against going above 576. ----- If the MTU is to be large, however, it seems to me that, at least for serial links, the F/R issue is readily solved using the PPP Multilink protocol(rfc1717.txt). With the short sequence number option it requires 4 extra bytes per frame (not quite optimial, I grant), but it allows the use of all standard PPP compression options. Plus, it is possible to send MP(multi-link protocol) and non-MP frames on the same link, so interleaving of small frames with fragments of large ones is possible. With a single link, the multilink protocol is pretty lightweight. I haven't thought about Appletalk. Regards, Tracy ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 3 01:09:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02642; Tue, 3 Jan 95 01:09:41 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02636; Tue, 3 Jan 95 01:09:33 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA27352; Tue, 3 Jan 95 01:03:35 PST Received: from mitsou.inria.fr by Sun.COM (sun-barr.Sun.COM) id AA02173; Tue, 3 Jan 95 01:03:34 PST Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA15123; Tue, 3 Jan 1995 10:03:30 +0100 Message-Id: <199501030903.AA15123@mitsou.inria.fr> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) the MTU bullet Date: Tue, 03 Jan 1995 10:03:29 +0100 From: Christian Huitema Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In my recent message, I attributed the "forward path indication" to Yakov. This is an error in fact; it was first mentioned in this list by Steve Bellovin. I apologize to Steve. In fact, I do not personnally endorse the idea of a "forward path MTU indication". Using the word "path" in the indication suggest that this would be an hop-by-hop attribute, checked and possibly updated by each router. This would have terrible performance implications. I merely suggested an indication in an end-to-end attribute, mentioning that "I am sending this datagram from a weird location, the MTU cannot possibly be larger than XXX". LRU caching of this indication would work for large servers if the cache is large enough to still include the indication present in the question when the response is ready. Christian Huitema ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 3 10:09:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02885; Tue, 3 Jan 95 10:09:58 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA02844; Tue, 3 Jan 95 09:26:09 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id JAA10395; Tue, 3 Jan 1995 09:20:15 -0800 Date: Tue, 3 Jan 1995 09:20:15 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199501031720.JAA10395@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) > 576 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM To help set the tone for MTU size discussions, I thought you should all know that as of December 22 the IPng mailing list has exceeded 576 entries. :-) Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 3 21:22:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03351; Tue, 3 Jan 95 21:22:02 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA03345; Tue, 3 Jan 95 21:21:55 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA05909; Tue, 3 Jan 95 21:15:54 PST Received: from inet-gw-1.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA20187; Tue, 3 Jan 95 21:15:51 PST Received: from xirtlu.zk3.dec.com by inet-gw-1.pa.dec.com (5.65/10Aug94) id AA11571; Tue, 3 Jan 95 21:13:09 -0800 Received: by xirtlu.zk3.dec.com; id AA20938; Wed, 4 Jan 1995 00:13:07 -0500 Message-Id: <9501040513.AA20938@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Hotels : IETF Meeting XEROX PARC Feb 9 & 10. Date: Wed, 04 Jan 95 00:13:01 -0500 From: bound@zk3.dec.com X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Any suggestions on Hotels for this yet??? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 5 17:01:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04462; Thu, 5 Jan 95 17:01:23 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04456; Thu, 5 Jan 95 17:01:16 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA18402; Thu, 5 Jan 1995 11:29:42 -0800 Received: from interramp.com (pop3.interramp.com) by Sun.COM (sun-barr.Sun.COM) id AA22281; Thu, 5 Jan 95 11:29:38 PST Received: from ip157.los-angeles.ca.interramp.com by interramp.com (4.1/SMI-4.1.3-PSI-pop-local) id AA17754; Thu, 5 Jan 95 14:29:47 EST Message-Id: <9501051929.AA17754@interramp.com> To: ipng@sunroof.Eng.Sun.COM Cc: dqua@interramp.com Subject: Re: (IPng) the MTU bullet In-Reply-To: Your message of "Mon, 02 Jan 1995 14:48:37 +0100." <199501021348.AA12056@mitsou.inria.fr> Date: Thu, 05 Jan 1995 11:34:42 -0800 From: Derick Gonzalez Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In <199501021348.AA12056@mitsou.inria.fr>, Christian Huitema said: > > Suppose that your UDP stack maintains some state variable > describing the MTU associated to one particular destination. Then, > UDP could automatically implement end-to-end fragmentaion if the > message is larger than the MTU. > Assuming, of course, that the route taken between them are the same each time, which cannot be guaranteed. I can see how one might design a protocol that could return the MTU along a path upon the initial handshake. For ``short'' UDP conversations, this would be fine, but not for extended exchanges because routes will change over time. What about a protocol that sends/propagates MTU changes? Then we can keep everyone (eventually) informed...imagine extending a link-state protocol (e.g. OSPF) so that the information passed along is more than just ``up'' or ``down,'' but also the MTU and maybe the line speed/cost/restrictions. Then the routers/gateways will have a network topology that will allow them to make more intelligent routing decisions, modifying (say) Dijkstra's algorithm to account for the MTU and other line costs. > Indeed, the very large UDP servers will not want to keep state for > all of their clients. But there are many tricks that they can play. > They may wish to keep exactly one state variable, common to all > destinations, effectively converging towards the lowest of all > their partner's MTU. ... If the server keeps the single state variable, then a few destina- tions that are running over (say) 9.6k lines or Appletalk would impose their (small) MTU over even those running at FT1/T1 speeds and higher. This would cause unnecessary fragmentation, and lower bandwidth utili- zation. The biggest problem I see in IPv4 with respect to MTU, is the fact that once a packet is disassembled, it is not reassembled until the endpoint. If this happens early in the path along a slow route, it wastes the bandwidth of more reliable, higher-speed lines along the way. However, since there is no notion of connection or reliability, fragments can and are lost, so are we then to burden routers and gateways with the task now relegated to endpoints? Think of the volume of traffic on the net... +----------------------------------------------------------------------------+ | Derick R. Gonzalez | ________ | | Department of High Engery Physics | \ / | | California State University | \ / | | dqua@interramp.com | \ / | | |29c \/ | +----------------------------------------------------------------------------+ ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 5 20:37:53 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04491; Thu, 5 Jan 95 20:37:53 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04485; Thu, 5 Jan 95 20:37:41 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA21076; Thu, 5 Jan 95 20:31:38 PST Received: from odin.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA20987; Thu, 5 Jan 95 20:31:36 PST Received: by odin.UU.NET (maildrop) id QQxxlq06762; Thu, 5 Jan 1995 23:31:37 -0500 Date: Thu, 5 Jan 1995 23:31:37 -0500 Message-Id: From: Joseph Malcolm To: Derick Gonzalez Cc: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) the MTU bullet In-Reply-To: <9501051929.AA17754@interramp.com> References: <199501021348.AA12056@mitsou.inria.fr> <9501051929.AA17754@interramp.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Derick Gonzalez writes: >In <199501021348.AA12056@mitsou.inria.fr>, Christian Huitema > said: >> >> Suppose that your UDP stack maintains some state variable >> describing the MTU associated to one particular destination. Then, >> UDP could automatically implement end-to-end fragmentaion if the >> message is larger than the MTU. > > Then we can keep everyone (eventually) informed...imagine extending >a link-state protocol (e.g. OSPF) so that the information passed along >is more than just ``up'' or ``down,'' but also the MTU and maybe the >line speed/cost/restrictions. Then the routers/gateways will have a >network topology that will allow them to make more intelligent routing >decisions, modifying (say) Dijkstra's algorithm to account for the MTU >and other line costs. Link-state protocols require a complete state-view in each router. You do not want the complete topology of the Internet in your router. >In <199501021348.AA12056@mitsou.inria.fr>, Christian Huitema > said: >> Indeed, the very large UDP servers will not want to keep state for >> all of their clients. But there are many tricks that they can play. >> They may wish to keep exactly one state variable, common to all >> destinations, effectively converging towards the lowest of all >> their partner's MTU. ... Then increasing the maximum DNS UDP packet size would only help for small, rarely queried servers. We might as well not bother. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jan 6 03:50:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04621; Fri, 6 Jan 95 03:50:35 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA04615; Fri, 6 Jan 95 03:50:21 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA08789; Fri, 6 Jan 95 03:44:18 PST Received: from mail02.mail.aol.com by Sun.COM (sun-barr.Sun.COM) id AA22310; Fri, 6 Jan 95 03:44:25 PST Received: by mail02.mail.aol.com (1.38.193.5/16.2) id AA14109; Fri, 6 Jan 1995 06:45:13 -0500 Date: Fri, 6 Jan 1995 06:45:13 -0500 From: Telford001@aol.com Message-Id: <950106064511_358208@aol.com> To: ipng@sunroof.Eng.Sun.COM Cc: dqua@interramp.com, Telford001@aol.com Subject: Re: (IPng) the MTU bullet Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > The biggest problem I see in IPv4 with respect to MTU, is the fact >that once a packet is disassembled, it is not reassembled until the >endpoint. If this happens early in the path along a slow route, it >wastes the bandwidth of more reliable, higher-speed lines along the >way. However, since there is no notion of connection or reliability, >fragments can and are lost, so are we then to burden routers and >gateways with the task now relegated to endpoints? Think of the >volume of traffic on the net... Given that individual fragments of the same packet may take different routes to the same end-host, it is possible that there would be no intermediate router which could collect all the fragments to perform reassembly anyway. Joachim Carlo Santos Martillo Ajami ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jan 9 08:10:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05671; Mon, 9 Jan 95 08:10:52 PST Received: from Eng.Sun.COM (engmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA05665; Mon, 9 Jan 95 08:10:45 PST Received: from Sun.COM (sun-barr) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA16588; Mon, 9 Jan 95 08:04:37 PST Received: from watson.ibm.com by Sun.COM (sun-barr.Sun.COM) id AA11088; Mon, 9 Jan 95 08:04:45 PST Received: from WATSON by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 5577; Mon, 09 Jan 95 11:04:42 EST Received: from YKTVMV by watson.vnet.ibm.com with "VAGENT.V1.0" id 1361; Mon, 9 Jan 1995 11:04:41 EST Received: from hawpub1.watson.ibm.com by yktvmv.watson.ibm.com (IBM VM SMTP V2R3) with TCP; Mon, 09 Jan 95 11:04:38 EST Received: by hawpub1.watson.ibm.com (AIX 3.2/UCB 5.64/930311) id AA26804; Mon, 9 Jan 1995 11:04:36 -0500 From: perk@watson.ibm.com (Charlie Perkins) Message-Id: <9501091604.AA26804@hawpub1.watson.ibm.com> To: ipng@sunroof.Eng.Sun.COM Cc: Steve Deering Subject: (IPng) Re: interim IPng WG meeting In-Reply-To: (Your message of Fri, 23 Dec 94 07:08:18 PST.) <94Dec23.070826pst.12174@skylark.parc.xerox.com> Date: Mon, 09 Jan 95 11:04:36 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Is mobility going to be discussed? If it is going to be specifically excluded from discussion (probably to maximize the forward progress on the other subjects) then I will plan not to attend. Thanks for any clarification. Charlie P. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 11 11:09:16 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07243; Wed, 11 Jan 95 11:09:16 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07237; Wed, 11 Jan 95 11:09:08 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA24147; Wed, 11 Jan 1995 11:03:03 -0800 Received: from caraway.lcs.mit.edu by Sun.COM (sun-barr.Sun.COM) id AA16946; Wed, 11 Jan 95 11:01:40 PST Received: by caraway.lcs.mit.edu id AA28426; Wed, 11 Jan 95 14:01:09 -0500 Message-Id: <9501111901.AA28426@caraway.lcs.mit.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) A thought on addressing From: David Clark Date: Wed, 11 Jan 95 14:01:09 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, This is a comment on how addresses might be used in IPv6. Perhaps there is a more addressing-specific mailing list that might be a better place to start an addressing debate, but... The problem I want to deal with is the continuing concern with provider based addresses, which seem to lock subscribers into a particular provider, unless we implement highly dynamic address reassignment. The ways out of this box (dynamic reassignment or geographical addressing) each seem to have their own perils. I feel we need a different approach. I want to offer one for consideration. Doing so takes us down a path with certain different forms of difficulty and tastelessness, but with advantages as well, so hold on. (BTW, I believe that I am not the first person to propose this idea, but I cannot sort out who else has proposed it. So if its your idea, I know I heard it somewhere; I just cannot remember where.) While the IPv6 address field has an unconstrained format, I note that in fact, for many uses of that field, it is moving towards a fixed two part structure, with a provider and subscriber part. Lets take advantage of that, and architect it (for certain address prefixes, perhaps.) Let's divide the address into the "UID" part, like the 48 bit thing, and the "prefix". The prefix would identify the provider, and the provider's name for the subscriber, and so on. The rule I want to propose is that the prefix can be rewritten in a packet during its transit in the net; both the source and destination prefix. A subscriber would be issued a prefix for internal use, probably unique but not generally routable. At the edge of the subscriber region (at a "subscriber boundary point"), an outgoing packet is rewritten to have its source prefix replaced by the prefix routable by the provider attached to that point. How would the destination prefix be filled in? If this packet is being sent in reply to an arriving packet, the destination address is just the source in the incoming packet, which the foreign subscriber modified at its boundary point to indicate the preferred provider prefix for that subscriber. If this outgoing packet originates the communication, the destination comes from a DNS lookup. The destination subscriber would provide a DNS server that returns addresses with the preferred (routable) prefix. What does this approach buy us? o Provider independence -- when a subscriber moves from one provider to another, the only change is to adjust the prefix inserted by the DNS and the subscriber boundary point. This approach provides an easy form of dynamic address reassignment, with no requirements for topological limitations. o Multi-homed subscribers -- a subscriber can now be multi-homed with no support in individual host software, and no inefficient use of provider address space. The boundary point just inserts the correct prefix for the provider being used for these packets. o Control of incoming provider -- a multi-homed subscriber can, as described above, control what provider is used for outgoing connections. But by returning different prefixes in response to different DNS lookups, it can also control which provider is used for a connection originated at the other end. o Mobile hosts -- while I have not thought about it much, this ability to rewrite the prefix should make it possible to route packets to a mobile host. All these are powerful advantages. Here are some additional thoughts. First, any host should be able to be a subscriber boundary point. While a host deep inside a subscriber network will not need this ability, it should be part of the base IPv6 implementation. The feature would be used in a number of situations. Running PPP, dynamic address assignment would imply setting the prefix to the correct current value. When mobile, a similar event would occur. In general, setting the prefix would arise as a interchange between the IPv6 code, a user interface, and the network device driver. Second, this approach gives the subscriber a means to enter into complex pricing deal with providers, and select among them. Different prefixes can be bound to different charging agreements, such as "collect connections". There would arise a market in sophisticated DNS servers that would return different prefixes in different circumtances, to control how distant hosts would send to a subscriber. Sophisticated subscribers will demand such capabilites, and the packet headers have to able to express them, without the ugly option of opening connections underneath to select the desired service. Third, not all addresses need look like this. There could be address forms (selected by their first byte) that do not have the prefix/UID boundary, and are not rewritable. TCP (and other protocols) would have to compute a pseudo-header based only on the unique part of the address. If this part were not really unique, a failure could occur in unusual circumstances. I believe that this problem is not a real one. A distasteful issue is that if not all addresses have this form, then TCP might need to compute pseudo-headers across different parts of the address in different cases. People with long memories will recognize that we have been here before... The major drawback to this schem is that the boundary between the prefix and the UID gets frozen which restricts the use of the address field. While this is a valid point, the address field is so big, perhaps it does not really matter. So here is the marketing slogan for IPv6: "Use IPv6 -- it makes NAT boxes work." (The last line was the joke, the rest of the message was the serious point. Think about the problems this approach solves, and think how else we can solve them.) Dave ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 11 15:09:30 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07433; Wed, 11 Jan 95 15:09:30 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07427; Wed, 11 Jan 95 15:09:18 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id PAA17841; Wed, 11 Jan 1995 15:03:12 -0800 Received: from sgigate.sgi.com by Sun.COM (sun-barr.Sun.COM) id AA25699; Wed, 11 Jan 95 14:59:00 PST Received: from sgihub.corp.sgi.com by sgigate.sgi.com via ESMTP (940627.SGI.8.6.9/911001.SGI) for <@sgigate.sgi.com:ipng@sunroof.eng.sun.com> id OAA01463; Wed, 11 Jan 1995 14:58:16 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for <@sgihub.corp.sgi.com:ipng@sunroof.eng.sun.com> id OAA11301; Wed, 11 Jan 1995 14:58:15 -0800 Received: from gauss.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:ipng@sunroof.eng.sun.com id AA00494; Wed, 11 Jan 95 14:58:10 -0800 Received: from localhost by gauss.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA20859; Wed, 11 Jan 1995 14:58:02 -0800 Message-Id: <199501112258.OAA20859@gauss.asd.sgi.com> From: leedom@gauss.asd.sgi.com (Casey Leedom) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) A thought on addressing Date: Wed, 11 Jan 1995 14:57:54 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM David, Basically it sounds like you're talking about introducing a new addressing layer on top of IP6 addresses. Yes, there's only one IP6 address in use at any one point, but the boundary substitution really seems like an attempt to spoof two names into the same slot. Basically introducing a new layer of addressing via an implementation hack. (If I've misunderstood your point please feel free to flame me.) Note that I'm not arguing against a separate layer. This works very well for Ethernet vs. IP4 addresses on an Ethernet! When we want to send a packet to host IP4 A.B.C.D we do a dynamic arp translation, get an Ethernet address to use for the link layer encapsulation and we're happy. However, I thought we already have a separate addressing layer. It's called the host name. Again, applications want to send a message to host foo.bar, request a DNS hostname to IP4 address translation and know what IP4 address to send the message to (which can be a specific interface on a host of course). This also works extremely well. Now your message addressed two fundamental problems: 1. The desire to enable switching providers easily. 2. The desire to support mobile computing. For 1.: is it really all that difficult to get a DNS record changed? We presume that someone is using an address that is not part of the provider's domain name space and the provider provides DNS service for your domain name as well as internet connectivity. All that's required is that you pick a new provider and get the root name servers to point your domain name at the new provider. If you manage your TTLs reasonably carefully this can be pretty hassle free. For 2.: It strikes me that a good way to handle this would be to enhance DNS to enable a mobile host to update its host to IP translation with its DNS server(s). It could acquire a dynamically allocated IP address in the IP routed domain it happened to find itself in and register that as its new hostname/IP translation (this registration would of course have to be done in an authenticated manner)[1]. The problem with this is that we don't address packets with hostnames. That translation is handled by the application. So hostnames, while providing an abstract translation to and from a lower layer addressing scheme, are not truly part of the protocol and packet encapsulation. Thus we couldn't handle keeping a TCP session alive across a mobile IP address change ... Maybe we do need a fully functional separate addressing layer (one that is part of the packet encapsulation similar to the way that Ethernet MAC addresses are part of the IP packet encapsulation on Ethernet). One could easily imagine having unique client addresses (UIDs in your proposal?) along with a local IP connectivity address. As you moved through IP connectivity domains, your unique client address would stay fixed but the local IP connection address would vary. In this scheme your unique hostname(s) would map on-to-one and onto your unique client address(es). In other words, the unique client addresses would just be machine friendly versions of hostnames. Probably rambling in a completely incoherent manner, Casey [1] Here we would definitely need to have separate DNS and connectivity providers. A client would have to have a DNS provider to translate its hostname into its new IP address. It would also have to get an IP to hostname translation set up in the DNS server of the local IP connectivity service provider. Postulating authenticated transactions for this isn't really a problem since the IP connectivity provider is going to want to charge for the connection service and we'll need to send it authenticated credit information. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 11 15:33:10 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07458; Wed, 11 Jan 95 15:33:10 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07452; Wed, 11 Jan 95 15:32:58 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id PAA21581; Wed, 11 Jan 1995 15:26:52 -0800 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA13918; Wed, 11 Jan 95 13:59:22 PST Subject: Re: (IPng) A thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Wed, 11 Jan 1995 16:57:43 -0500 (EST) From: Dan McDonald Cc: ddc@lcs.mit.edu, atkinson@sundance.itd.nrl.navy.mil In-Reply-To: <9501111901.AA28426@caraway.lcs.mit.edu> from "David Clark" at Jan 11, 95 02:01:09 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9501112157.aa07542@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dave, I just discussed the proposal with Ran. We have a few questions: > TCP (and other protocols) would have to compute a pseudo-header based > only on the unique part of the address. If this part were not really > unique, a failure could occur in unusual circumstances. What about authentication? I want to authenticate the entire address. Ran seems to think that even with a unique UID portion, authentication will break. I can imagine a bad guy at a site forging packets with a, and they pass authentication because the WHOLE address is not authenticated. What about security systems that use address-based access control? Even if the UID portion is unique across the Internet, it may not reflect enough topology to allow address-based filtering. (Either that, or my firewall will need more entries because of my multiple provider/subscriber prefixes.) The bad guy problem applies here, too. > problem is not a real one. A distasteful issue is that if not all addresses > have this form, then TCP might need to compute pseudo-headers across > different parts of the address in different cases. People with long > memories will recognize that we have been here before... I don't have a long memory, could you elaborate? (That TCP checksum argument also applies to authentication.) > (The last line was the joke, the rest of the message was the serious point. > Think about the problems this approach solves, and think how else we can > solve them.) I wish I had some hard answers for you. Thanks for posting this note on the list. I will re-read it a few more times. Dan McDonald - NRL ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 11 18:07:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07555; Wed, 11 Jan 95 18:07:55 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07549; Wed, 11 Jan 95 18:07:43 PST Received: by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id SAA28873; Wed, 11 Jan 1995 18:00:15 -0800 Date: Wed, 11 Jan 1995 18:00:15 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <199501120200.SAA28873@jurassic.Eng.Sun.COM> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) IPng W.G. Meeting Minutes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The IPng working group meeting minutes for the December IETF are available for anonymous ftp on playground.sun.com in pub/ipng/Meeting_Minutes.Dec94.txt Please send me comments. I plan to send them to CNRI tomorrow afternoon. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 11 22:30:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07656; Wed, 11 Jan 95 22:30:37 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07650; Wed, 11 Jan 95 22:30:30 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id WAA20186; Wed, 11 Jan 1995 22:24:23 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA25559; Wed, 11 Jan 95 22:24:23 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 12 Jan 95 15:23:29 +0900 From: Masataka Ohta Message-Id: <9501120623.AA14567@necom830.cc.titech.ac.jp> Subject: Re: (IPng) A thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Thu, 12 Jan 95 15:23:27 JST In-Reply-To: <9501111901.AA28426@caraway.lcs.mit.edu>; from "David Clark" at Jan 11, 95 2:01 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Folks, > This is a comment on how addresses might be used in IPv6. Perhaps there > is a more addressing-specific mailing list that might be a better place to > start an addressing debate, but... Are there any? > The problem I want to deal with is the continuing concern with provider > based addresses, which seem to lock subscribers into a particular provider, > unless we implement highly dynamic address reassignment. > (BTW, I > believe that I am not the first person to propose this idea, but I cannot sort > out who else has proposed it. So if its your idea, I know I heard it somewhere; > I just cannot remember where.) I'm one of a person who suggested so. The problem, IMHO, is that people tend to think that such a proposal can solve all the problem and tend to overload the concept. The other problem is that the word "EID" is so infamous now. > Let's divide the address into the "UID" part, like the 48 bit thing, So, we should live with the new name. "UID" is fine. And, not trying to solve all the problems, we should have a specific narrow purpose. > The problem I want to deal with is the continuing concern with provider > based addresses, which seem to lock subscribers into a particular provider, > unless we implement highly dynamic address reassignment. is a good and absolutely-necessary-to-be-addressed purpose, I think. Other less important problems (such as rerouting related to mobility) may be solved as by-product. But, we shouldn't try to overload the proposal, should we? > and the "prefix". The prefix would identify the provider, and the > provider's name for the subscriber, and so on. The rule I want to propose > is that the prefix can be rewritten in a packet during its transit in the > net; both the source and destination prefix. That might be a way. Or, it might be better for the source choose prefixes. > The destination subscriber would provide a DNS server that returns addresses > with the preferred (routable) prefix. Which means that "UID" must follow DNS deligation hierarchy (but free from the routing hierarchy). So, 48bits are not enough for large number of hosts. > What does this approach buy us? > > o Provider independence -- Sure. > o Multi-homed subscribers -- Absolutely. > o Control of incoming provider -- Wait. Do we really need that? > a multi-homed subscriber can, as > described above, control what provider is used for outgoing connections. > But by returning different prefixes in response to different DNS lookups, You are proposing something very incompatible with the nature of DNS, I'm afraid. Is the goal worth to be pursued? > o Mobile hosts -- As mobility can be handled completely well by other mechanisms, it should be an explicite non-goal. > All these are powerful advantages. The problem, IMHO, is that there are too many powerful advantages. > Third, not all addresses need look like this. There could be address > forms (selected by their first byte) that do not have the prefix/UID > boundary, and are not rewritable. True. As we, anyway, must support variable length bit masks for forwarding, limiting the maximum mask length to, say, 64 bits adds no extra complexity. > The major drawback to this schem is that the boundary between the prefix > and the UID gets frozen which restricts the use of the address field. While > this is a valid point, the address field is so big, perhaps it does not > really matter. In my proposal, I already gave proof that 64+64 bit separation is more than enough to support 10^12 networks and 10^15 hosts with some safety factors. So, 4+60+64 scheme (first 4 bits for the coresidence with other schemes) also is proved to work. The problem is that I have lost the original text in disk crash. Where is the archive of IPNG ML? It's not where documented in 1wg-charters.txt. Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 11 23:14:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07677; Wed, 11 Jan 95 23:14:19 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07671; Wed, 11 Jan 95 23:14:12 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id XAA21492; Wed, 11 Jan 1995 23:08:06 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA28512; Wed, 11 Jan 95 23:08:07 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 12 Jan 95 16:07:10 +0900 From: Masataka Ohta Message-Id: <9501120707.AA14789@necom830.cc.titech.ac.jp> Subject: Re: (IPng) A thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Thu, 12 Jan 95 16:07:08 JST In-Reply-To: <9501112157.aa07542@sundance.itd.nrl.navy.mil>; from "Dan McDonald" at Jan 11, 95 4:57 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > TCP (and other protocols) would have to compute a pseudo-header based > > only on the unique part of the address. If this part were not really > > unique, a failure could occur in unusual circumstances. > > What about authentication? I hope you are not calling weak security authentication. > I want to authenticate the entire address. Ran > seems to think that even with a unique UID portion, authentication will > break. I can imagine a bad guy at a site forging packets with a, and they > pass authentication because the WHOLE address is not authenticated. As for end-end authentication, Host identification (such as DNS lookup) is done only with the UID part. So, a forged routing prefix can't be harmful. > What about security systems that use address-based access control? Do UID-based access control. > Even if > the UID portion is unique across the Internet, it may not reflect enough > topology UID SHOULD NOT reflect any topology. > to allow address-based filtering. For such authentication, an entity (in this case, a border router) which assigns prefix should know the secret information to compute MD5 hash. The situation is no different from the IP security model to protect a subnet with security unaware hosts by a security aware border router. > (Either that, or my firewall > will need more entries because of my multiple provider/subscriber prefixes.) As long as you want to communicate with someone who is connected to multiple providers using address-based access control, you need multiple entries. > The bad guy problem applies here, too. Who are the bad buys? Could you elaborate? Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 12 00:00:32 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07705; Thu, 12 Jan 95 00:00:32 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA07699; Thu, 12 Jan 95 00:00:24 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id XAA22790; Wed, 11 Jan 1995 23:54:18 -0800 Received: from dxmint.cern.ch by Sun.COM (sun-barr.Sun.COM) id AA01853; Wed, 11 Jan 95 23:54:19 PST Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA13760; Thu, 12 Jan 1995 08:54:17 +0100 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA21626; Thu, 12 Jan 1995 08:54:15 +0100 Message-Id: <9501120754.AA21626@dxcoms.cern.ch> Subject: Re: (IPng) A thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Thu, 12 Jan 1995 08:54:14 +0100 (MET) From: "Brian Carpenter CERN-CN" In-Reply-To: <9501111901.AA28426@caraway.lcs.mit.edu> from "David Clark" at Jan 11, 95 02:01:09 pm X-Mailer: ELM [version 2.4 PL23 DXCOMS1] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dave, The thing to do with this is to get a fraction of the reserved space set aside for "rewritable addresses" or whatever you want to call them (as Ohta-san said, 124 bits is still a lot). Then the people working on the current proposals can get on with them undisturbed, and somebody else can get on with rewritables. The trouble with rewritable addresses is that you have to rewrite them. The trouble with ordinary ones is that you have to update DNS dynamically. I wouldn't like to say which is the lesser evil. Regards, Brian Carpenter (CERN) (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 12 10:13:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08079; Thu, 12 Jan 95 10:13:00 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08073; Thu, 12 Jan 95 10:12:49 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id KAA20404; Thu, 12 Jan 1995 10:06:44 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA00107; Thu, 12 Jan 95 09:59:58 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-17.dialip.mich.net [141.211.7.153]) by merit.edu (8.6.9/merit-2.0) with SMTP id KAA27012 for ; Thu, 12 Jan 1995 10:04:43 -0500 Date: Thu, 12 Jan 95 14:42:14 GMT From: "William Allen Simpson" Message-Id: <3696.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) A thought on addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > o Mobile hosts -- while I have not thought about it much, this ability > to rewrite the prefix should make it possible to route packets to a mobile > host. > Only when the Mobile Node initiates a connection to the Correspondent. Correspondent initiated traffic still requires a Well-Known Home Address for tunnelling, and/or very fast dynamically updated DNS. Since there are simpler methods in IPng for a MN initiated connection (Routing Header), let's leave mobility out of this thought experiement. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 12 16:57:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08470; Thu, 12 Jan 95 16:57:37 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08464; Thu, 12 Jan 95 16:57:29 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA00690; Thu, 12 Jan 1995 16:51:22 -0800 Received: from necom830.cc.titech.ac.jp by Sun.COM (sun-barr.Sun.COM) id AA23878; Thu, 12 Jan 95 16:51:19 PST Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 13 Jan 95 09:50:13 +0900 From: Masataka Ohta Message-Id: <9501130050.AA18544@necom830.cc.titech.ac.jp> Subject: Re: (IPng) A thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Fri, 13 Jan 95 9:50:11 JST In-Reply-To: <9501120754.AA21626@dxcoms.cern.ch>; from "Brian Carpenter CERN-CN" at Jan 12, 95 8:54 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Dave, > > The thing to do with this is to get a fraction of the reserved space > set aside for "rewritable addresses" or whatever you want to call > them I'm afraid you misunderstand the issue. If the goal is: > The problem I want to deal with is the continuing concern with provider > based addresses, which seem to lock subscribers into a particular provider, > unless we implement highly dynamic address reassignment. and NOT to "support mobility", which can be supported by routing header, tunneling or any other existing techniques, prefix can be attached anywhere between the border router and gethostbyname(). So, rewriting is not essential for the above goal. So, call it prefix UID separation. BTW, we need strong provider independence so that user programs do not have to care about provider change during operation, that is, do not have to reset existing TCP/UDP connection or re-read UDP "addresses" from DNS and just continue normal operation, prefix must be added below bind() within the operating system and above the border router. [Note: Though some people thought quite connection oriented that they tied the separation and TCP here, they are unrelated.] > (as Ohta-san said, 124 bits is still a lot). Then the people > working on the current proposals can get on with them undisturbed, > and somebody else can get on with rewritables. > The trouble with rewritable addresses is that you have to rewrite them. No. Dave said that ALL the hosts should have rewriting capability. If you configure hosts to always add prefixes, no rewriting is necessary. And, anyway, rewriting is inessential for the provider independence. > The trouble with ordinary ones is that you have to update DNS > dynamically. I wouldn't like to say which is the lesser evil. Really? But, it is trivial to prove that it does not work. That is, though name servers, as hosts, MUST be able to change providers freely, DNS stops operation if glue A records are invalid. So, I'm afraid we must throw away "ordinary ones". Masataka Ohta ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jan 13 10:00:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08921; Fri, 13 Jan 95 10:00:02 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA08584; Thu, 12 Jan 95 20:07:50 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id UAA18677; Thu, 12 Jan 1995 20:01:44 -0800 Received: from classic.iinet.com.au by Sun.COM (sun-barr.Sun.COM) id AA06508; Thu, 12 Jan 95 20:01:39 PST Received: (from michael@localhost) by classic.iinet.com.au (8.6.9/8.6.9) id MAA22030 for ipng@sunroof.eng.sun.com; Fri, 13 Jan 1995 12:01:34 +0800 Date: Fri, 13 Jan 1995 12:01:34 +0800 From: "Michael O'Reilly" Message-Id: <199501130401.MAA22030@classic.iinet.com.au> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) A thought on addressing Newsgroups: local.ietf.ipng Organization: iiNet Technologies X-Newsreader: TIN [UNIX 1.3 941213BETA PL0] Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM In article <9501111901.AA28426@caraway.lcs.mit.edu> you wrote: : Let's divide the address into the "UID" part, like the 48 bit thing, : and the "prefix". The prefix would identify the provider, and the : provider's name for the subscriber, and so on. The rule I want to propose : is that the prefix can be rewritten in a packet during its transit in the : net; both the source and destination prefix. : A subscriber would be issued a prefix for internal use, probably : unique but not generally routable. At the edge of the subscriber region (at : a "subscriber boundary point"), an outgoing packet is rewritten to have its : source prefix replaced by the prefix routable by the provider attached to : that point. This much I like. What I don't think too much of is that you seem to be implying only one re-write. Excuse me if I'm just lost but... My point of view, is that it seems to be fairly common to see multi-level providers. So supporting a re-write trail that runs.... user --> provider1 --> provider2 --> net at large Would be pretty nice. Each re-write point sets X bits from point Y in an address that is open for re-writing. It looks reasonable clean to me. The minor little point that I see as a problem is a machine asking for it's actually IP# to hand out in data. No idea how you'd cleanly handle that. Michael. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jan 15 09:52:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09603; Sun, 15 Jan 95 09:52:45 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09597; Sun, 15 Jan 95 09:52:32 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA06226; Sun, 15 Jan 1995 09:46:23 -0800 From: Telford001@aol.com Received: from mail02.mail.aol.com by Sun.COM (sun-barr.Sun.COM) id AA04520; Sun, 15 Jan 95 09:46:23 PST Received: by mail02.mail.aol.com (1.38.193.5/16.2) id AA12984; Sun, 15 Jan 1995 12:47:23 -0500 Date: Sun, 15 Jan 1995 12:47:23 -0500 Message-Id: <950115124720_1874015@aol.com> To: ipng@sunroof.Eng.Sun.COM Cc: ddc@lcs.mit.edu (davidclark) Subject: Re: (IPng) A thought on addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > This is a comment on how addresses might be used in IPv6. Perhaps there >is a more addressing-specific mailing list that might be a better place to >start an addressing debate, but... > The problem I want to deal with is the continuing concern with provider >based addresses, which seem to lock subscribers into a particular provider, >unless we implement highly dynamic address reassignment. The ways out of this >box (dynamic reassignment or geographical addressing) each seem to have their >own perils. I feel we need a different approach. I want to offer one for >consideration. Doing so takes us down a path with certain different forms of >difficulty and tastelessness, but with advantages as well, so hold on. (BTW, I >believe that I am not the first person to propose this idea, but I cannot sort >out who else has proposed it. So if its your idea, I know I heard it somewhere; >I just cannot remember where.) > While the IPv6 address field has an unconstrained format, I note that in >fact, for many uses of that field, it is moving towards a fixed two part >structure, with a provider and subscriber part. Lets take advantage of that, >and architect it (for certain address prefixes, perhaps.) > Let's divide the address into the "UID" part, like the 48 bit thing, >and the "prefix". The prefix would identify the provider, and the >provider's name for the subscriber, and so on. The rule I want to propose >is that the prefix can be rewritten in a packet during its transit in the >net; both the source and destination prefix. > A subscriber would be issued a prefix for internal use, probably >unique but not generally routable. At the edge of the subscriber region (at >a "subscriber boundary point"), an outgoing packet is rewritten to have its >source prefix replaced by the prefix routable by the provider attached to >that point. (1) At this point the destination has a prefix which is routable by the provider??? (2) How is a packet handled which is merely transiting a subscriber network (to get from one provider to another)??? (3) Or is transitting a private network disallowed??? Answer (1): > How would the destination prefix be filled in? If this packet is being sent >in reply to an arriving packet, the destination address is just the source in >the incoming packet, which the foreign subscriber modified at its boundary point >to indicate the preferred provider prefix for that subscriber. If this outgoing This procedure seems to limit asymetric routing of packets between two peers. (4) Is this destination address the destination address which the local node would obtain on a domain look-up??? (5) How is collision (i.e. both sides start communicating with the other simultaneously potentially with different choices of prefixes) to be handled??? Answer (4): >packet originates the communication, the destination comes from a DNS lookup. >The destination subscriber would provide a DNS server that returns addresses >with the preferred (routable) prefix. (6) Is this procedure really the correct procedure??? (7) Is a new order of security problems being created here??? (8) In the case of TCP communication origination has a fairly obvious meaning. Is the meaning obvious in all other cases??? (9) Are prefixes to be changeable dynamically??? (10) If so, at what granularity??? > What does this approach buy us? > o Provider independence -- when a subscriber moves from one provider to >another, the only change is to adjust the prefix inserted by the DNS and >the subscriber boundary point. This approach provides an easy form of >dynamic address reassignment, with no requirements for topological >limitations. (11) Are problems with subscribers who subscribe to multiple providers solved??? Answer (11): > o Multi-homed subscribers -- a subscriber can now be multi-homed with no >support in individual host software, and no inefficient use of provider >address space. The boundary point just inserts the correct prefix for the >provider being used for these packets. > o Control of incoming provider -- a multi-homed subscriber can, as >described above, control what provider is used for outgoing connections. >But by returning different prefixes in response to different DNS lookups, >it can also control which provider is used for a connection originated at >the other end. (12) What logic would govern the return of different prefixes by the DNS??? > o Mobile hosts -- while I have not thought about it much, this ability >to rewrite the prefix should make it possible to route packets to a mobile >host. > All these are powerful advantages. > Here are some additional thoughts. > First, any host should be able to be a subscriber boundary point. >While a host deep inside a subscriber network will not need this ability, >it should be part of the base IPv6 implementation. The feature would be >used in a number of situations. Running PPP, dynamic address assignment >would imply setting the prefix to the correct current value. When mobile, a >similar event would occur. In general, setting the prefix would arise as a >interchange between the IPv6 code, a user interface, and the network device >driver. (13) If a PPP based subscriber dials in successively to different providers, how are domain name server databases throughout the internet to be updated??? (14) Suppose that the dial-up PPP subscriber device is the access router, so that dynamically through the day the correct provider prefix for a given subscriber network is changing, in fact suppose lots of subscribers connect to providers in this way, will there be continous topological instability within the internet??? > Second, this approach gives the subscriber a means to enter into >complex pricing deal with providers, and select among them. Different >prefixes can be bound to different charging agreements, such as "collect >connections". There would arise a market in sophisticated DNS servers that >would return different prefixes in different circumtances, to control how >distant hosts would send to a subscriber. Sophisticated subscribers will >demand such capabilites, and the packet headers have to able to express >them, without the ugly option of opening connections underneath to select >the desired service. (15) Is there a move to point-to-point billing in addition to the service billing under which, I believe, most people and organizations obtain internet service??? While there might be some value in providing a rewrite capability for addresses, there is some possibility that creating the universal virtual network, creating an infrastructure for surface providers and creating the means for billing are really separate problems. The telco providers have worked out a system for dealing with these issues in the voice network. While their system may not be fully applicable to data internetworks, there might be some useful information which telco service providers can provide toward the solution. I have experimented with building very large very intelligent multiprotocol virtual communications subnets which interwork very different technologies and which can perform sophisticated path selection within the virtual communications subnet. It should be possible to modify some of the frame formants to contain the information necessary to carry out provider billing. Providers might be better off if they built their physical infrastructures as units within a special provider virtual communications subnet. There are many benefits to such an approach: 1) The proliferation of providers does not mean a proliferation of IP networks. 2) Changing a provider just means changing the address on some interface with respect to the provider virtual communications subnet. The subscribers own IP addresses need not change. 3) The cruft associated with billing is put into the provider virtual communications subnet frames and not into the IP packet. 4) Billing multiple hops through successive private and provider networks becomes a tractable problem generating multiple billing records rather than a complex problem of charging pieces of the network layer route. 5) The provider virtual communications subnet could be multiprotocl and could facilitate the provision of IPX, SNA, DECNET, Appletalk, Banyan Vines and similar carriage to subscribers who are willing to pay for them. 6) It might be possible to move a lot of the complexity of dial-up IP network access into the virtual communications subnet -- although I grant that this problem is somewhat more general and is related to many of the key assumptions may in the original design of IP and similar networking systems. 7) IP is not amenable to certain types of digital data services which providers might wish to offer. It might be possible to design the provider virtual communications subnet to be compatible with the provision of such services. Joachim Carlo Santos Martillo Ajami ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jan 15 11:55:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09621; Sun, 15 Jan 95 11:55:00 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09615; Sun, 15 Jan 95 11:54:47 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA08521; Sun, 15 Jan 1995 11:48:37 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA08186; Sun, 15 Jan 95 11:48:38 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm002-24.dialip.mich.net [141.211.7.160]) by merit.edu (8.6.9/merit-2.0) with SMTP id OAA00719 for ; Sun, 15 Jan 1995 14:48:26 -0500 Date: Sun, 15 Jan 95 19:04:51 GMT From: "William Allen Simpson" Message-Id: <3742.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) variant of DES-CBC Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM A couple of us in the IP Security WG have proposed a modification of Ran's current ESP draft (with Ran's permission), following Phil Karn's suggestion: 1) that the Next Header and padding be moved to the end, 2) that the size of the synchronization be variable, so that headers can be aligned. The following (short) draft attempts to do this in a way that is generic and useful to both IPv4 and IPv6. I am hoping that the IPv6 WG will find this to their liking, and build support for moving this through the IP-SEC WG. Network Working Group P Metzger Internet Draft W A Simpson expires in six months January 1995 The ESP DES-CBC Transform draft-ietf-ipsec-esp-des-cbc-00.txt Status of this Memo This document is a submission to the IP Security Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipsec@ans.net mailing list. Distribution of this memo is unlimited. 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 not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``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) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This document describes the DES-CBC security transform for the Encapsulating Security Payload (ESP). Troublemakers expires in six months [Page 1] DRAFT ESP DES-CBC January 1995 1. Introduction The Encapsulating Security Payload (ESP) [1] provides confidentiality and integrity by encrypting the data to be protected. This specification describes the ESP use of the Cipher Block Chaining (CBC) mode of the US Data Encryption Standard (DES) algorithm. DES is described is several US Government publications [2, 3, 4, 5]. A recent book also provides information on DES [6]. At least one hardware implementation of DES-CBC can encrypt or decrypt at about 1 Gbps [6, p. 231]. Conformance with ESP requires that this Security Transform MUST be implemented. 1.1. Keys The secret DES key shared between the communicating parties is 64 bits long. This key consists of a 56-bit quantity used by the DES algorithm, and 8 parity bits arranged such that one parity bit is the least significant bit of each octet. 1.2. Initialization Vector This mode of DES requires an Initialization Vector (IV) that is 8 octets in length. Each datagram contains its own DES IV. Including the IV in each datagram ensures that decryption of each received datagram can be performed, even when other datagrams are dropped, or datagrams are re-ordered in transit. The method for selection of the IV values is implementation dependent. Note: A common technique is simply a counter, beginning with a randomly chosen value. Other implementations also exhibit unpredictability, usually through a pseudo-random number generator. Care should be taken that the periodicity of the number generator is long enough to prevent repetition during the lifetime of the session key. Troublemakers expires in six months [Page 1] DRAFT ESP DES-CBC January 1995 1.3. Data Size The DES algorithm operates on blocks of 8 octets. This often requires padding after the end of the unencrypted payload data. Both input and output result in the same number of octets, which facilitates in-place encryption and decryption. On receipt, if the length of the data to be decrypted is not an integral multiple of 8 octets, then an error is indicated. The datagram is discarded, and an appropriate ICMP message is returned. The failure SHOULD be recorded in the system or audit log, including the cleartext values for the SAID, date/time, Source, Destination, and other identifying information. 2. Payload Format +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Association Identifier (SAID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Initialization Vector (IV) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Payload Data ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... Padding | Pad Length | Data Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Security Association Identifier (SAID) A 32-bit value identifying the Security Association for this datagram. If no Security Association has been established, the value of this field is zero. Initialization Vector The size of this field is variable, though for any given Security Association it has a particular known size. Its position and size is constant for all DES-CBC datagrams of the same SAID and IP Destination. Troublemakers expires in six months [Page 2] DRAFT ESP DES-CBC January 1995 This field is considered to be transparent, though most users will not be able to make sense of its contents. The field may be longer or shorter than the 64-bits used by DES, in multiples of 32-bits. This allows alignment of the Encrypted Data for in-place decryption. All conformant implementations MUST correctly process a 64-bit field size. When the size is negotiated to 32-bits, the inverse of the 32-bits is appended to form a 64-bit value. When the size is negotiated to 96-bits or greater, the alignment of the 64-bit value within this field is negotiated by a variable parameter. Unused octets are filled with unspecified implementation dependent values. Payload Data The size of this field is variable. This field is opaque. Prior to encryption and after decryption, the contents of this field begins with an entire IP datagram (IP-Mode), or an IP Payload header (Transport-Mode). Padding The size of this field is variable. This field is opaque. Prior to encryption, it is filled with unspecified implementation dependent values. After decryption, it MUST be ignored. Pad Length This field indicates the size of the Padding field. It does not include the Pad Length and Data Type fields. The value typically ranges from 0 to 7, but may be up to 255 to permit hiding of that actual data length. This field is opaque. That is, the value is set prior to encryption, and is examined only after decryption. Data Type This field indicates the contents of the Payload Data field, using Troublemakers expires in six months [Page 3] DRAFT ESP DES-CBC January 1995 the IP Protocol/Payload value. Up-to-date values of the IP Protocol/Payload are specified in the most recent "Assigned Numbers" RFC [7]. This field is opaque. That is, the value is set prior to encryption, and is examined only after decryption. For example, when encrypting an entire IP datagram (IP-Mode), this field will contain the value 4, which indicates IP-in-IP encapsulation. Security Considerations Users need to understand that the quality of the security provided by this specification depends completely on the strength of whichever encryption algorithm that has been implemented, the correctness of that algorithm's implementation, the security of the key management mechanism and its implementation, the strength of the key [8], and upon the correctness of the ESP and IP implementations in all of the participating systems. It is known that DES is an algorithm approaching the end of its useful lifetime. As of the writing of this document, Biham and Shamir [9] have demonstrated a differential cryptanalysis based chosen-plaintext attack requiring 2^47 plaintext-ciphertext pairs, and Mitsuru Matsui [10] has demonstrated a linear cryptanalysis based known-plaintext attack requiring only 2^43 plaintext-ciphertext pairs. Although these attacks are not considered practical, they must be taken into account. More disturbingly, Wiener [11] has shown the design of a DES cracking machine costing $1 Million that can crack one key every 3.5 hours. This is an extremely practical attack, and it is suggested that DES is not a good encryption algorithm for the protection of even moderate value in the face of such equipment. Triple DES is probably a better choice for such purposes. Acknowledgements The original text of this specification was derived from work by Ran Atkinson for the SIP, SIPP, and IPv6 Working Groups. The use of DES for confidentiality is closely modeled on the work done for SNMPv2 [12]. Troublemakers expires in six months [Page 4] DRAFT ESP DES-CBC January 1995 References [1] Randall Atkinson, Perry Metzger, William Simpson, "Encapsulating Security Protocol (ESP)", work in progress. [2] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46, January 1977. [3] US National Bureau of Standards, "Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 46- 1, January 1988. [4] US National Bureau of Standards, "DES Modes of Operation" Federal Information Processing Standard (FIPS) Publication 81, December 1980. [5] US National Bureau of Standards, "Guidelines for Implementing and Using the Data Encryption Standard", Federal Information Processing Standard (FIPS) Publication 74, April 1981. [6] Schneier, B., "Applied Cryptography", John Wiley & Sons, New York, NY, 1994. ISBN 0-471-59756-2 [7] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC 1700, USC/Information Sciences Institute, October 1994. [8] Carroll, J.M., and Nudiati, S., "On Weak Keys and Weak Data: Foiling the Two Nemeses", Cryptologia, Vol. 18 No. 23 pp. 253- 280, July 1994. [9] Biham, E., and Shamir, A., "Differential Cryptanalysis of the Data Encryption Standard", Berlin: Springer-Verlag, 1993. [10] Matsui, M., "Linear Cryptanalysis method dor DES Cipher," Advances in cryptology -- Eurocrypt '93 Proceedings, Berlin: Springer-Verlag, 1994. [11] Wiener, M.J., "Efficient DES Key Search", School of Computer Science, Carleton University, Ottawa, Canada, TR-244, May 1994. Presented at the Rump Session of Crypto '93. [12] Galvin, J., and McCloghrie, K., "Security Protocols for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC- 1446, DDN Network Information Center, April 1993. Troublemakers expires in six months [Page 5] DRAFT ESP DES-CBC January 1995 Author's Address Questions about this memo can also be directed to: Randall Atkinson Information Technology Division Naval Research Laboratory Washington, DC 20375-5320 USA Telephone: (DSN) 354-8590 Fax: (DSN) 354-7942 Perry Metzger Piermont Information Systems Inc. 160 Cabrini Blvd., Suite #2 New York, NY 10033 perry@piermont.com William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com Troublemakers expires in six months [Page 6] DRAFT ESP DES-CBC January 1995 Table of Contents 1. Introduction .......................................... 1 1.1 Keys ............................................ 1 1.2 Initialization Vector ........................... 1 1.3 Data Size ....................................... 2 2. Payload Format ........................................ 2 SECURITY CONSIDERATIONS ...................................... 4 ACKNOWLEDGEMENTS ............................................. 4 REFERENCES ................................................... 5 AUTHOR'S ADDRESS ............................................. 5 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jan 15 14:25:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09692; Sun, 15 Jan 95 14:25:58 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09686; Sun, 15 Jan 95 14:25:47 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA11717; Sun, 15 Jan 1995 14:19:36 -0800 Received: from sgigate.sgi.com by Sun.COM (sun-barr.Sun.COM) id AA13241; Sun, 15 Jan 95 14:19:00 PST Received: from sgihub.corp.sgi.com by sgigate.sgi.com via ESMTP (940627.SGI.8.6.9/911001.SGI) for <@sgigate.sgi.com:ipng@sunroof.eng.sun.com> id OAA02339; Sun, 15 Jan 1995 14:18:58 -0800 Received: from giraffe.asd.sgi.com by sgihub.corp.sgi.com via SMTP (940519.SGI.8.6.9/911001.SGI) for <@sgihub.corp.sgi.com:ipng@sunroof.eng.sun.com> id OAA29751; Sun, 15 Jan 1995 14:18:57 -0800 Received: from gauss.asd.sgi.com by giraffe.asd.sgi.com via SMTP (920330.SGI/920502.SGI) for @sgihub.corp.sgi.com:ipng@sunroof.eng.sun.com id AA17425; Sun, 15 Jan 95 14:18:56 -0800 Received: from localhost by gauss.asd.sgi.com via SMTP (940816.SGI.8.6.9/940406.SGI.AUTO) for id OAA05758; Sun, 15 Jan 1995 14:18:56 -0800 Message-Id: <199501152218.OAA05758@gauss.asd.sgi.com> From: leedom@gauss.asd.sgi.com (Casey Leedom) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) A thought on addressing Date: Sun, 15 Jan 1995 14:18:48 -0800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM | Date: Sun, 15 Jan 1995 12:47:23 -0500 | From: Telford001@aol.com (Joachim Carlo Santos Martillo Ajami) | | (13) If a PPP based subscriber dials in successively to different | providers, how are domain name server databases throughout the | internet to be updated??? | | (14) Suppose that the dial-up PPP subscriber device is the access router, | so that dynamically through the day the correct provider prefix for a | given subscriber network is changing, in fact suppose lots of | subscribers connect to providers in this way, will there be continous | topological instability within the internet??? I didn't get the impression that we were talking about something that would be changing the topology of the network infrastructure at all. Only the connection points for hosts. I still don't understand the rewriting scheme David outlined (probably my lack of background in the topic at hand). And it still seems to me that what David is talking about is very similar to dynamic IP address to Ethernet address lookup[1]. Please feel free to flame me if I'm babbling nonsense! Casey [1] In this case we have ``unique client interface addresses'' (which correspond one-to-one with hostnames) and the ``current network network topological address for that interface. For Ethernet, this translation is handled via broadcast ARP. For translating client IDs to client addresses something like DNS seems to be the right answer. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jan 15 15:13:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09705; Sun, 15 Jan 95 15:13:18 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09699; Sun, 15 Jan 95 15:13:10 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id PAA12635; Sun, 15 Jan 1995 15:06:59 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA14819; Sun, 15 Jan 95 15:06:55 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA29326; Sun, 15 Jan 95 15:00:55 -0800 Received: by xirtlu.zk3.dec.com; id AA18147; Sun, 15 Jan 1995 18:00:43 -0500 Message-Id: <9501152300.AA18147@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) A thought on addressing In-Reply-To: Your message of "Wed, 11 Jan 95 14:01:09 EST." <9501111901.AA28426@caraway.lcs.mit.edu> Date: Sun, 15 Jan 95 18:00:37 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dave, > This is a comment on how addresses might be used in IPv6. Perhaps there >is a more addressing-specific mailing list that might be a better place to >start an addressing debate, but... I think this is a good place to discuss it. > The problem I want to deal with is the continuing concern with provider >based addresses, which seem to lock subscribers into a particular provider, >unless we implement highly dynamic address reassignment. The ways out of this >box (dynamic reassignment or geographical addressing) each seem to have their >own perils. I feel we need a different approach. I want to offer one for >consideration. Doing so takes us down a path with certain different forms of >difficulty and tastelessness, but with advantages as well, so hold on. (BTW, I >believe that I am not the first person to propose this idea, but I cannot sort >out who else has proposed it. So if its your idea, I know I heard it somewhere; >I just cannot remember where.) Responding to the problem. I don't think that subscribers are "locked" into a providers to the point they cannot change to another provider for whatever business reason that may exist. So I do not think that is whats urgent. Isn't the problem that its technically and admistratively messy? The question is there a less messy way to accomplish making switching providers for subscribers easier technically and administratively. If XXX really does a bad job or costs are not competitve as a provider they will get dumped in the market by the subscribers. > While the IPv6 address field has an unconstrained format, I note that in >fact, for many uses of that field, it is moving towards a fixed two part >structure, with a provider and subscriber part. Lets take advantage of that, >and architect it (for certain address prefixes, perhaps.) I don't see this from my viewing of the address specifications from Hinden and Rekhter. Can you be more specific? The reason is that we really gave up on EIDs and Locators sometime ago as far as a work item in IPv6 for now. So I may be misinterpreting your statement that the field is moving towards a fixed two part address? > Let's divide the address into the "UID" part, like the 48 bit thing, >and the "prefix". The prefix would identify the provider, and the >provider's name for the subscriber, and so on. The rule I want to propose >is that the prefix can be rewritten in a packet during its transit in the >net; both the source and destination prefix. Again if you look at Rekhter draft for IPv6 addresses the parts are more than just a prefix. Now if you don't believe that draft is complete or could be structured differently then thats input to Yakov and the IPng WG. I believe we have a rough consensus on Yakov's draft at this time. Your rule proposed which essentially states you want to write into a live packet on its way to the Internet makes me very nervous. One reason is "security" which we just spent a lot of time working on and folks tell me its high priority for the Internet per the IETF and IESG. In addition what kind of nodes are going to do this? How do you get them back on a reply, which I know is further discussed below. > A subscriber would be issued a prefix for internal use, probably >unique but not generally routable. At the edge of the subscriber region (at >a "subscriber boundary point"), an outgoing packet is rewritten to have its >source prefix replaced by the prefix routable by the provider attached to >that point. I really don't want that at all. I want globally unique addresses for the Internet for users. This may be the critical point of difference and consume much of the discussion. But I will continue to respond but stating that this is not acceptable in my understanding of what we are trying to provide in IPv6 or the Internet. > How would the destination prefix be filled in? If this packet is being sent >in reply to an arriving packet, the destination address is just the source in >the incoming packet, which the foreign subscriber modified at its boundary point >to indicate the preferred provider prefix for that subscriber. If this outgoing >packet originates the communication, the destination comes from a DNS lookup. >The destination subscriber would provide a DNS server that returns addresses >with the preferred (routable) prefix. This is a lot of state to maintain. Even to get back to the source address will require the prefix to be altered again. The DNS records and space would increase and we are again dumping our database problems on to DNS. Network performance will be reduced by such a strategy. > What does this approach buy us? > o Provider independence -- when a subscriber moves from one provider to >another, the only change is to adjust the prefix inserted by the DNS and >the subscriber boundary point. This approach provides an easy form of >dynamic address reassignment, with no requirements for topological >limitations. This can be accomplished too by creating a specification as to changing the provider part in IPv6 address for Statefull Autoconfig Server-to-Server protocol that would also update DNS Root Servers. Then none of the state or performance loss takes place with this thought experiment. > o Multi-homed subscribers -- a subscriber can now be multi-homed with no >support in individual host software, and no inefficient use of provider >address space. The boundary point just inserts the correct prefix for the >provider being used for these packets. This entire problem needs more thought I agree. Yes this scheme could alleviate the problem but at the cost of having to write in users packets by the provider. > o Control of incoming provider -- a multi-homed subscriber can, as >described above, control what provider is used for outgoing connections. >But by returning different prefixes in response to different DNS lookups, >it can also control which provider is used for a connection originated at >the other end. DNS Assumption here. What does this DNS record look like? What access mechanism exists to update, create, or change it? Whats its relation to AAAA Records? Does transition affect this? Many questions would need to be answered. > o Mobile hosts -- while I have not thought about it much, this ability >to rewrite the prefix should make it possible to route packets to a mobile >host. Not required in IPv6. This can be done through system discovery using the high order parts of the Rekhter IPv6 addressing plan. > All these are powerful advantages. Here are some disadvantages: 1. Providers now have "authority" to go into a users packet and change the address, which opens a security hole and creates a major liability for the integrity of the packet on the Providers. I think it also intereferes with the privacy of a subscriber. Providers role is to router packets not interpret them. 2. There will be a network performance loss at the subscriber / provider boundaries. 3. Additional complications for DNS WG to resolve and will take up more space in the DNS. > Here are some additional thoughts. > First, any host should be able to be a subscriber boundary point. >While a host deep inside a subscriber network will not need this ability, >it should be part of the base IPv6 implementation. The feature would be >used in a number of situations. Running PPP, dynamic address assignment >would imply setting the prefix to the correct current value. When mobile, a >similar event would occur. In general, setting the prefix would arise as a >interchange between the IPv6 code, a user interface, and the network device >driver. We don't have any specs for dynamic address re-assignment in IPv6. As I said above if we could solve this problem then this idea would not be needed. There is work on doing stateless/statefull autoconfiguration and DNS autoregistration for DNS in IPv6. Dynamic Address Re-Assignment could use the outcome of that work to solve this problem. Most of the technical tools are in the IPv6 specs I mentioned to design at least an outline of how this would work. This way providers stay out of the loop and subscribers have a specification and technical tool to "execute" if they change providers. > Second, this approach gives the subscriber a means to enter into >complex pricing deal with providers, and select among them. Different >prefixes can be bound to different charging agreements, such as "collect >connections". There would arise a market in sophisticated DNS servers that >would return different prefixes in different circumtances, to control how >distant hosts would send to a subscriber. Sophisticated subscribers will >demand such capabilites, and the packet headers have to able to express >them, without the ugly option of opening connections underneath to select >the desired service. Yes but with a real Dyn-Reassign-Spec for subscribers the same business benefit can be attained by subscribers and providers are not changing subscriber packets at the network layer, and all the disadvantages I listed with this approach above are avoided. As far as ugly changing packet source and destination addresses I find very ugly. Dyn-Reassign-Spec can be made to be very clean, robust, and technically architected to be efficient. > Third, not all addresses need look like this. There could be address >forms (selected by their first byte) that do not have the prefix/UID >boundary, and are not rewritable. Another disadvantage of this idea because it now wants to use up a byte in the IPv6 address space. This can be avoided to with a proper Dyn-Reassign-Spec. > TCP (and other protocols) would have to compute a pseudo-header based >only on the unique part of the address. If this part were not really >unique, a failure could occur in unusual circumstances. I believe that this >problem is not a real one. A distasteful issue is that if not all addresses >have this form, then TCP might need to compute pseudo-headers across >different parts of the address in different cases. People with long >memories will recognize that we have been here before... Another performance cost. The reason is now I can't just load the address of the IPv6 addr into my checksum routine I must pick a part of it and parse it out on every packet. Checksum routines exists that provide real performance gains to Hosts. This will reduce the performance of those routines on every packets. Also in IPv6 checksum is required for UDP not optional. So it is every packet. Going across different parts of the address is really not a good idea. >The major drawback to this schem is that the boundary between the prefix >and the UID gets frozen which restricts the use of the address field. While >this is a valid point, the address field is so big, perhaps it does not >really matter. Well I think there are several major drawbacks to this scheme as I have presented as input. I think we should still remain frugal with our large address space, and rather than eating it up figure out if we can solve the problem without stepping on the address space a subscriber/provideer boundaries which I really think is not a good idea. /jim So here is the marketing slogan for IPv6: "Use IPv6 -- it makes NAT boxes work." (The last line was the joke, the rest of the message was the serious point. Think about the problems this approach solves, and think how else we can solve them.) Dave ------- End of Forwarded Message ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jan 15 17:44:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09731; Sun, 15 Jan 95 17:44:07 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09725; Sun, 15 Jan 95 17:43:59 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id RAA15576; Sun, 15 Jan 1995 17:37:49 -0800 Received: from pluto.dss.com by Sun.COM (sun-barr.Sun.COM) id AA19813; Sun, 15 Jan 95 17:37:49 PST Received: by pluto.dss.com (4.1/SMI-4.0) id AA06175; Sun, 15 Jan 95 20:37:32 EST From: martillo@pluto.dss.com (Joachim Martillo) Message-Id: <9501160137.AA06175@pluto.dss.com> Subject: Re: (IPng) A thought on addressing To: ipng@sunroof.Eng.Sun.COM Date: Sun, 15 Jan 1995 20:37:30 -0500 (EST) Cc: bound@zk3.dec.com, wizard@pluto.dss.com (Tony Bono), mario@pluto.dss.com (Mario Savvides) In-Reply-To: <9501152300.AA18147@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jan 15, 95 06:00:37 pm X-Mailer: ELM [version 2.4 PL21] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Dave, > Here are some disadvantages: > 1. Providers now have "authority" to go into a users packet and change > the address, which opens a security hole and creates a major liability > for the integrity of the packet on the Providers. I think it also > intereferes with the privacy of a subscriber. Providers role is to > router packets not interpret them. > /jim Hi, Just a short note on this disadvantage. In some legal environments, the rules of common carriage may preclude the provider from modifying the IP datagram at all. This possibility is another reason to move anything related to commercial providers one step lower in the protocol stack to a provider virtual communications subnet. While I grant this issue is merely a possible legal technicality with no legitimate basis in the actual engineering of data networks, there may be a serious problem with any sort of requirement which might force a provider to modify user data. Joachim Martillo Manager of Internetworking Research Penril Datability Networks Penril Datability Advanced Communications Research Center 190 N. Main St. Natick, MA 01760 VOICE 508-653-5313 FAX 508-653-6415 EMAIL martillo@dss.com martillo@penril.com This note does not reflect an official Penril Datability Networks, Inc. position with respect to internetworking or related issues. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jan 15 19:17:23 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09767; Sun, 15 Jan 95 19:17:23 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09761; Sun, 15 Jan 95 19:17:11 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id TAA17433; Sun, 15 Jan 1995 19:11:01 -0800 Received: from rodan.UU.NET by Sun.COM (sun-barr.Sun.COM) id AA23498; Sun, 15 Jan 95 19:07:09 PST Received: by rodan.UU.NET id QQxywi09667; Sun, 15 Jan 1995 22:07:08 -0500 Message-Id: To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com, wizard@pluto.dss.com (Tony Bono), mario@pluto.dss.com (Mario Savvides) From: "Louis A. Mamakos" Subject: Re: (IPng) A thought on addressing In-Reply-To: Your message of "Sun, 15 Jan 1995 20:37:30 EST." <9501160137.AA06175@pluto.dss.com> Date: Sun, 15 Jan 1995 22:07:07 -0500 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > Dave, > > > Here are some disadvantages: > > > 1. Providers now have "authority" to go into a users packet and change > > the address, which opens a security hole and creates a major liability > > for the integrity of the packet on the Providers. I think it also > > intereferes with the privacy of a subscriber. Providers role is to > > router packets not interpret them. > > > /jim > > Hi, > > Just a short note on this disadvantage. In some legal environments, > the rules of common carriage may preclude the provider from modifying > the IP datagram at all. This possibility is another reason to move > anything related to commercial providers one step lower in the > protocol stack to a provider virtual communications subnet. This is a bogus argument. There may be good reasons to use a level-2 communications subnet in an IP(ng) network, but I don't think this is one of them. Consider a typical virtual communications subnet like frame relay. The DLCI in the frame gets modified along the way. The DE, FECN and BECN bits may get set along they way. How is this significantly different, in a regulatory way, than what happens in an IP header? Louis A. Mamakos louie@alter.net Backbone Architecture & Engineering Guy uunet!louie AlterNet / UUNET Technologies, Inc. 3060 Williams Drive Voice: +1 703 206 5823 Falls Church, Virginia 22031 Fax: +1 703 206 5601 ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jan 15 20:56:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09803; Sun, 15 Jan 95 20:56:08 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09796; Sun, 15 Jan 95 20:56:00 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id UAA19551; Sun, 15 Jan 1995 20:49:49 -0800 Received: from titan.sprintlink.net by Sun.COM (sun-barr.Sun.COM) id AA27323; Sun, 15 Jan 95 20:49:51 PST Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id XAA15898 for ipng@sunroof.Eng.Sun.COM; Sun, 15 Jan 1995 23:49:50 -0500 Date: Sun, 15 Jan 1995 23:49:50 -0500 From: Vadim Antonov Message-Id: <199501160449.XAA15898@titan.sprintlink.net> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) A thought on addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Just a short note on this disadvantage. In some legal environments, > the rules of common carriage may preclude the provider from modifying > the IP datagram at all. This possibility is another reason to move > anything related to commercial providers one step lower in the > protocol stack to a provider virtual communications subnet. >This is a bogus argument. Well, the argument is bogus but the problem is real. Address translation is a recipe for disaster. I can see zillions of real funny failure modes (and don't forget that you have to do *identical* translation on all exits... and, moreover, the practice codifies the distinction between "providers" and "non providers", which makes life very interesting when "customers" have backdoors). Also, there is much simplier solution (dynamic addressing), which is necessary to solve a lot of other problems anyway. Unless you're thinking about ours (netadmins') job security :-) --vadim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jan 16 06:18:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09993; Mon, 16 Jan 95 06:18:41 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09987; Mon, 16 Jan 95 06:18:33 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA02354; Mon, 16 Jan 1995 06:12:21 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA05423; Mon, 16 Jan 95 06:12:15 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA23305; Mon, 16 Jan 95 06:04:40 -0800 Received: by xirtlu.zk3.dec.com; id AA03062; Mon, 16 Jan 1995 09:04:26 -0500 Message-Id: <9501161404.AA03062@xirtlu.zk3.dec.com> To: "Louis A. Mamakos" Cc: ipng@sunroof.Eng.Sun.COM, bound@zk3.dec.com, wizard@pluto.dss.com (Tony Bono), mario@pluto.dss.com (Mario Savvides) Subject: Re: (IPng) A thought on addressing In-Reply-To: Your message of "Sun, 15 Jan 95 22:07:07 EST." Date: Mon, 16 Jan 95 09:04:20 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >From: "Louis A. Mamakos" >Date: Sun, 15 Jan 1995 22:07:07 -0500 >> > Dave, >> >> > Here are some disadvantages: >> >> > 1. Providers now have "authority" to go into a users packet and change >> > the address, which opens a security hole and creates a major liability >> > for the integrity of the packet on the Providers. I think it also >> > intereferes with the privacy of a subscriber. Providers role is to >> > router packets not interpret them. >> >> > /jim >> >> Hi, >> >> Just a short note on this disadvantage. In some legal environments, >> the rules of common carriage may preclude the provider from modifying >> the IP datagram at all. This possibility is another reason to move >> anything related to commercial providers one step lower in the >> protocol stack to a provider virtual communications subnet. >This is a bogus argument. There may be good reasons to use a level-2 >communications subnet in an IP(ng) network, but I don't think this is >one of them. No its not see next reply. >Consider a typical virtual communications subnet like frame relay. >The DLCI in the frame gets modified along the way. The DE, FECN and >BECN bits may get set along they way. How is this significantly >different, in a regulatory way, than what happens in an IP header? Response is based on U.S. Legal Philosophy and I won't go into the legal issues in depth. The legal issues are twofold. Intent and Right to Privacy. When a provider on a backbone network "sets" bits along the way in Louies comment the intent is: first to "set" or add bits to make the frame actually function. This Intent is not to snoop to change the packet. In addition any modifications to the actual user packet are not intentional and from my reading above in Louies case the bits only modify the frame on the medium. In Dave's scenario there is an intentional snooping of the packet for a bonified user packet. The Intent is to change the users packet which was transmitted from their "computer". At a minimum there would have to be contractual and privacy discussions between the provider and the subscriber, to avoid liability on anyones part. The Internet will experience more and more of these kinds of legal and privacy issues at least in the U.S. and they will have to be worked out. The reason is that industry will not use the Internet unless these kinds of issues are very well understood. So my argument was not bogus, becasue it is a pointer to what will have to happen between provider and subscriber legally to implement such an arrangement. I realize it would require real legal analysis but I am sure there is an issue here regarding "intent" and "privacy" at least in the U.S. and more work for someone. Also this was just one disadvantage of Daves scheme in my mail. There are others. thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jan 16 06:25:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10005; Mon, 16 Jan 95 06:25:07 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA09999; Mon, 16 Jan 95 06:25:00 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA02557; Mon, 16 Jan 1995 06:18:49 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA05977; Mon, 16 Jan 95 06:18:45 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA23651; Mon, 16 Jan 95 06:14:57 -0800 Received: by xirtlu.zk3.dec.com; id AA03667; Mon, 16 Jan 1995 09:14:43 -0500 Message-Id: <9501161414.AA03667@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) A thought on addressing In-Reply-To: Your message of "Sun, 15 Jan 95 23:49:50 EST." <199501160449.XAA15898@titan.sprintlink.net> Date: Mon, 16 Jan 95 09:14:37 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Well, the argument is bogus but the problem is real. Address >translation is a recipe for disaster. I can see zillions of >real funny failure modes (and don't forget that you have to do >*identical* translation on all exits... and, moreover, the practice >codifies the distinction between "providers" and "non providers", >which makes life very interesting when "customers" have backdoors). The mention of backdoors bring about the picture of the "prohibition phenomenna of don't do this" to me. Its an argument used in some circles to avoid making more rules and laws and implies self-reliance is best. In this discussion per Dave's scenario the rules (a word dave used several times in his memo to us) and laws are the instance of making packets from a subscriber altered at the network layer for the greater good of all on the network to solve a problem that is real but not necessarily a problem that only can be solved that way. The U.S. Govt tried prohibition in the 20's to get people to not drink alcohol. But they did and in some analysis drank more. In Dave's scenario if the performance hit is great enough backdoors between annoyed subscribers and smart thinking Providers will be created. Are we to outlaw them? What problems will that cause? >Also, there is much simplier solution (dynamic addressing), which >is necessary to solve a lot of other problems anyway. Unless >you're thinking about ours (netadmins') job security :-) I agree and it supports Self-Reliance from above not Social mandates for the Internet community that do not support Self-Reliance. See Emerson or Thoreau for futher philosophical discussion and especially Civil Disobedience. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jan 16 06:56:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10038; Mon, 16 Jan 95 06:56:59 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10032; Mon, 16 Jan 95 06:56:52 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id GAA03715; Mon, 16 Jan 1995 06:50:40 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA08936; Mon, 16 Jan 95 06:50:36 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA24658; Mon, 16 Jan 95 06:40:42 -0800 Received: by xirtlu.zk3.dec.com; id AA05447; Mon, 16 Jan 1995 09:40:22 -0500 Message-Id: <9501161440.AA05447@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: (IPng) Dynamic Readdressing Template and Work Items. Date: Mon, 16 Jan 95 09:40:16 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dynamic Readressing Assignment (DRA) Template and Work Items: Problem: If subscribers wish to change providers they will receive a new provider prefix part and other components affecting their aggregate address in: draft-hinden-ipng-addr-00.txt draft-hinden-ipng-ipv6-spec-01.txt draft-rekhter-IPv6-address-format-00.txt draft-rekhter-ipng-arch-IPv6-addr-00.txt Each of these documents need to be analyzed to support DRA. If the provider is clearly demarcated from provider part in relation to other component parts of the address then a simple DRA solution can be developed to readdress all nodes below the provider demarcation point in the subscribers address space. If the entire aggregate space is altered at the high-order bits, assuming the local address part is in tact the problem is more difficult but still can be solved. The multihomed subscriber issue should have some analysis but simply cannot be solved and thats the way it goes. But we should try! So the above specs need to be in synch to solve this problem. Template: The IPv6 effort in the IETF has work items that are moving progressively to provide solutions to: Stateless Autoconfiguration of Host Addresses Statefull Autoconfiguration of Host Addresses Dynamic Updates to BIND DNS Autoregistration of Host Addresses to the DNS. BIND DNS Secondary Notification and Incremental Zone Transfer The above are the core parts to design a DRA solution. In addition we would need Server-Server protocols, packet definitions, and processing algrithms for Statfull Address Servers and BIND DNS Master/Primary Servers. We would also need DRA Servers within a subscriber site to begin the update process to the DNS Servers and Autoconfig Statefull Servers (or if defined well the Stateless Algorithms being developed could go into process with the DRA). When a subscriber receives a new address from a provider (depending on how the specs define the address space above) the DRA server would be executed to update DNS and provide a mirror only with new addresses for other Servers. This is a mouth full and hand waving but the idea is we have to start some where. All addresses can now be reclaimed in IPv6 or expired by address servers and clients need to now get new addresses. So there is a way to tell all stop using your address and come get a new one. What to do with the NAME in DNS is another issue. Or tell all nodes to fall back to local addresses and keep all other state like name and config parameters and begin inter-org communications only during the DRA conversion. We have a multicast inter-org and inter-site defined in IPv6 but thats about it maybe we need to define this further in IPv6 specs. I will stop here and hope that other ideas can move this forward. Already doing to many IPv6 tasks. But willing to discuss it as I am working on some of the core parts suggested above. /jim - ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jan 16 10:13:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10141; Mon, 16 Jan 95 10:13:19 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10135; Mon, 16 Jan 95 10:13:12 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id KAA13570; Mon, 16 Jan 1995 10:07:01 -0800 Received: from clark.net by Sun.COM (sun-barr.Sun.COM) id AA02571; Mon, 16 Jan 95 10:06:57 PST Received: (hcb@localhost) by clark.net (8.6.9/8.6.5) id NAA07845; Mon, 16 Jan 1995 13:06:55 -0500 From: Howard Berkowitz Message-Id: <199501161806.NAA07845@clark.net> Subject: Re: (IPng) Dynamic Readdressing Template and Work Items. To: ipng@sunroof.Eng.Sun.COM, autoconf@cisco.com Date: Mon, 16 Jan 1995 13:06:53 -0500 (EST) Cc: hcb@clark.net (Howard Berkowitz) In-Reply-To: <9501161440.AA05447@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jan 16, 95 09:40:16 am X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On a related topic, has any group taken on the work item of getting the MIB model to deal with transient IP addresses? Clearly, I can't use the existing model to reset an entity at a given IP address, if the IP address might have been reassigned. There seems occasionally to be an assumption that SNMP/MIB will begin to be accessed by domain names, but I haven't seen that discussed anywhere in detail. EID's also come up as a solution. Howard ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 17 15:53:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10776; Tue, 17 Jan 95 15:53:45 PST Received: from jurassic.Eng.Sun.COM (camilla) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10770; Tue, 17 Jan 95 15:53:34 PST Received: from chestnut.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id PAA14363; Tue, 17 Jan 1995 15:47:19 -0800 Received: by chestnut.Eng.Sun.COM (5.x/SMI-SVR4) id AA09582; Tue, 17 Jan 1995 15:46:18 -0800 Date: Tue, 17 Jan 1995 15:46:18 -0800 From: hinden@jurassic (Bob Hinden) Message-Id: <9501172346.AA09582@chestnut.Eng.Sun.COM> To: ipng@sunroof, iesg@cnri.reston.va.us, iab@isi.edu Cc: hinden@mdv.com, hinden@jurassic Subject: (IPng) New Position Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I wanted you to know that I am leaving Sun Microsystems and moving to a startup called Ipsilon Networks, Inc. located in Menlo Park, CA. I can be reached at hinden@mdv.com and at (415) 854-9734. I will continue my IETF involvement in IPng. Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 17 16:26:28 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10827; Tue, 17 Jan 95 16:26:28 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA10821; Tue, 17 Jan 95 16:26:20 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA09854; Tue, 17 Jan 1995 16:20:05 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA19155; Tue, 17 Jan 95 16:19:59 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA15585; Wed, 18 Jan 1995 11:19:32 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA02389; Wed, 18 Jan 95 11:15:41 +1100 Received: by dcthq2.datacraft.com.au; Wed, 18 Jan 95 11:21:00 +1100 Date: Wed, 18 Jan 95 11:06:53 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re: (IPng) A thought on addressing X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM hello all, just landed after hols so forgive the fact of speed reading the mail and may have missed things. I have a philosophical point to raise and it is probably obvious to all so bear with me. With all this discussion on addressing and subcribers and providers, etc we seem to be designing the topology of the network (or allowing flexible addressing mechanisms such as auto assignment) without having the control of the networks design (that will use IP6) or the address space administration. Should we break the work down into (eg.) four main areas. Proposed Address Formats where the top bytes/prefix IDs are mandated Dynamic Address Mechanisms Discovery, Auto Assignment, Multicast Registration and Assignments Who gets what and how it is dished out. Migration / Transistion Mechanisms and Assignments If we can do this we can then see clearly what the address admin issues are and perhaps get IANA or ISEG involved with these. Certainly one will have difficulty resolving address format issues if one is trying to accommodate all the vagaries of its (global) administration and network operation of any system that uses IP6. thoughts please Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 17 19:41:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11086; Tue, 17 Jan 95 19:41:59 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11080; Tue, 17 Jan 95 19:41:51 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id TAA25696; Tue, 17 Jan 1995 19:35:38 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA16079; Tue, 17 Jan 95 19:35:38 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA03531; Tue, 17 Jan 95 19:31:27 -0800 Received: by xirtlu.zk3.dec.com; id AA05916; Tue, 17 Jan 1995 22:31:15 -0500 Message-Id: <9501180331.AA05916@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) A thought on addressing In-Reply-To: Your message of "Wed, 18 Jan 95 11:06:53 +1100." Date: Tue, 17 Jan 95 22:31:09 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I think we should proceed with Alan's suggestion. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 18 01:58:39 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11165; Wed, 18 Jan 95 01:58:39 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11159; Wed, 18 Jan 95 01:58:31 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id BAA13660; Wed, 18 Jan 1995 01:52:19 -0800 Received: from nsco.network.com by Sun.COM (sun-barr.Sun.COM) id AA13574; Wed, 18 Jan 95 01:52:18 PST Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA29261; Wed, 18 Jan 95 04:07:49 CST Received: from eros.network.com by anubis.network.com (4.1/SMI-4.1) id AA04412; Wed, 18 Jan 95 03:51:52 CST Date: Wed, 18 Jan 95 03:51:52 CST From: fredr@anubis.network.com (Fred Rabouw (Gouda office)) Message-Id: <9501180951.AA04412@anubis.network.com> To: ipng@sunroof.Eng.Sun.COM Subject: re: re: (IPng) A though on addressing Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM You're right Alan, too often multiple subjects are mixed in a single discussion. Splitting in in the four areas you propose will create a change to agree on some of them. Regards Fred Rabouw ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 18 14:53:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11500; Wed, 18 Jan 95 14:53:07 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA11494; Wed, 18 Jan 95 14:52:56 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA14038; Wed, 18 Jan 1995 14:46:41 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA15804; Wed, 18 Jan 95 14:46:29 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa10561; 18 Jan 95 16:02 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM From: Internet-Drafts@CNRI.Reston.VA.US Subject: (IPng) I-D ACTION:draft-ietf-ipngwg-icmp-00.txt Date: Wed, 18 Jan 95 16:01:55 -0500 Message-Id: <9501181602.aa10561@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : ICMP for the Internet Protocol Version 6 (IPv6) Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-00.txt Pages : 18 Date : 01/17/1995 This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). The Internet Group Management Protocol (IGMP) messages specified in RFC-1112 have been merged into ICMP, for IPv6, and are included in this document. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-icmp-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-ipngwg-icmp-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-icmp-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950117173853.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950117173853.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 19 14:58:37 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12194; Thu, 19 Jan 95 14:58:37 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12188; Thu, 19 Jan 95 14:58:23 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA20445; Thu, 19 Jan 1995 14:52:06 -0800 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA08898; Thu, 19 Jan 95 14:52:06 PST Subject: (IPng) Outbound multicast interface To: IPng Mailing list Date: Thu, 19 Jan 1995 17:52:32 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9501192252.aa07021@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Say I'm the IPv6 engine, and I just got a multicast packet from above. Let's also say the multicast option for outbound interface has not been set. Let's furthermore say that I haven't heard any router advertisements, and I have multiple interfaces. Do I: 1. Send this multicast packet out multiple interfaces? 2. Send it out a random interface? 3. Don't send out the datagram? (4.4BSD IPv4 does this currently. If it can't first find a route, it never even makes it to the multicast part.) 4. Send an IGMP join, and wait for some sort of advertisement? (Sort of like a unicast address.) Thanks, Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 19 15:22:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12240; Thu, 19 Jan 95 15:22:46 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12234; Thu, 19 Jan 95 15:22:34 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id PAA23240; Thu, 19 Jan 1995 15:16:17 -0800 Received: from wintermute.imsi.com by Sun.COM (sun-barr.Sun.COM) id AA13756; Thu, 19 Jan 95 15:15:51 PST Received: from relay.imsi.com by wintermute.imsi.com id SAA01309; Thu, 19 Jan 1995 18:15:35 -0500 Received: from snark.imsi.com by relay.imsi.com id SAA06451; Thu, 19 Jan 1995 18:15:34 -0500 Received: by snark.imsi.com (4.1/SMI-4.1) id AA05050; Thu, 19 Jan 95 18:15:34 EST Message-Id: <9501192315.AA05050@snark.imsi.com> To: ipng@sunroof.Eng.Sun.COM Cc: Dan McDonald Subject: Re: (IPng) Outbound multicast interface In-Reply-To: Your message of "Thu, 19 Jan 1995 17:52:32 EST." <9501192252.aa07021@sundance.itd.nrl.navy.mil> X-Reposting-Policy: redistribute only with permission Date: Thu, 19 Jan 1995 18:15:33 -0500 From: "Perry E. Metzger" Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Dan McDonald says: > Say I'm the IPv6 engine, and I just got a multicast packet from above. > Let's also say the multicast option for outbound interface has not been set. > Let's furthermore say that I haven't heard any router advertisements, and I > have multiple interfaces. Do I: > 3. Don't send out the datagram? > (4.4BSD IPv4 does this currently. If it can't first find a > route, it never even makes it to the multicast part.) If the option has not been set, NEVER send out a packet either multicast or broadcast. Sun created a significant security threat because they removed the check for SO_BROADCAST in their networking code (at least for 4.1.X, I haven't checked Solaris 2.X), and as a result this one can melt down almost any normal network of Suns attached to the Internet, remotely, and with nearly no risk of being caught. Applications should only be allowed to broadcast or multicast if they have said that they want to, in order to prevent nasty accidents from occuring, or more to the point, being induced. Perry ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 19 18:43:00 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12425; Thu, 19 Jan 95 18:43:00 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12419; Thu, 19 Jan 95 18:42:53 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id SAA12743; Thu, 19 Jan 1995 18:36:37 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA17414; Thu, 19 Jan 95 18:36:29 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA04894; Fri, 20 Jan 1995 13:25:34 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from dcthq2.datacraft.com.au by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA07954; Fri, 20 Jan 95 13:21:22 +1100 Received: by dcthq2.datacraft.com.au; Fri, 20 Jan 95 13:27:36 +1100 Date: Fri, 20 Jan 95 13:18:58 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re: (IPng) Dynamic Readdressing Template and W ork Items. X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM howard, fancy you mentioning SNMP and Domain Names. This smells of named managed objects (eg. CMIP and ISOs Management Information Model). Isnt it funny that when it comes down to it, large scale systems that change their addresses (eg the human race) still rely on names - global names. However, are you seeing the issues I perceive that auto address assignment on a global basis will require administered directories and these directories will require management and all the objects and managed objects within these systems will require global naming (and protocols that carry the name attributes).. Just a thought Regards Alan@Oz ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 19 22:33:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12487; Thu, 19 Jan 95 22:33:11 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA12481; Thu, 19 Jan 95 22:33:04 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id WAA23172; Thu, 19 Jan 1995 22:26:46 -0800 Received: from clark.net by Sun.COM (sun-barr.Sun.COM) id AA15661; Thu, 19 Jan 95 22:26:47 PST Received: (hcb@localhost) by clark.net (8.6.9/8.6.5) id BAA19850; Fri, 20 Jan 1995 01:26:46 -0500 From: Howard Berkowitz Message-Id: <199501200626.BAA19850@clark.net> Subject: Re: Re: (IPng) Dynamic Readdressing Template and W To: ipng@sunroof.Eng.Sun.COM Date: Fri, 20 Jan 1995 01:26:45 -0500 (EST) Cc: hcb@clark.net (Howard Berkowitz) In-Reply-To: from "Alan.Lloyd@datacraft.com.au" at Jan 20, 95 01:18:58 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > > howard, fancy you mentioning SNMP and Domain Names. This smells of named > managed objects (eg. CMIP and ISOs Management Information Model). > Isnt it funny that when it comes down to it, large scale systems that change > their addresses (eg the human race) still rely on names - global names. Domain names are mentioned here only because they are the only things that we have that are agreed to (relatively speaking) as persistent identifiers for objects, in a dynamically assigned network address environment. If we ever agree what an EID is and how create one, that would serve as well. Actually, I would disagree that human-oriented names are essential to a network management system. In a complex environment, the names become too complex to be all that mnemonic. The key is having unique identifiers, probably keyed to a graphic metaphor for operational use. In the longer term, the size and complexity of networks, coupled with the declining skill level of operations staff, will IMHO push us farther toward expert systems. > > However, are you seeing the issues I perceive that auto address assignment on > a global basis will require administered directories and these directories > will require management and all the objects and managed objects within these > systems will require global naming (and protocols that carry the name > attributes).. > I wasn't assuming that names, or the equivalent, truly be global. Certainly, that is appropriate for some environments, but I was thinking more of a single installation trying to get long-term statistics on devices that no longer could be identified by IP address. Before dealing with the global addressing problem, I'd like to see a solution that even works locally (or at least in a single enterprise). I am concerned that while we might field IPv6 autoconfiguration relatively soon, there will be a significant lag for network management. A similar lag in the GDMO managed object specification, I suspect, is one of many reasons OSI has not become as prominent as might have been desired. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Jan 21 09:17:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13278; Sat, 21 Jan 95 09:17:42 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13272; Sat, 21 Jan 95 09:17:33 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA22598; Sat, 21 Jan 1995 09:11:15 -0800 Received: from cheops.anu.edu.au by Sun.COM (sun-barr.Sun.COM) id AA08091; Sat, 21 Jan 95 09:11:14 PST Message-Id: <9501211711.AA08091@Sun.COM> Received: by cheops.anu.edu.au (1.38.193.3/16.2) id AA25504; Sat, 21 Jan 95 19:02:28 +1100 From: Darren Reed Subject: Re: (IPng) IPv6 Security API To: ipng@sunroof.Eng.Sun.COM Date: Sat, 21 Jan 1995 19:02:27 +1100 (EDT) In-Reply-To: <9412050701.aa04992@sundance.itd.nrl.navy.mil> from "Dan McDonald" at Dec 5, 94 02:01:51 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM [...] > Instant Security Violation Notification > > [NB. This is a controversial section. These could be done in > error codes instead, but would be less "up-to-date". Also the > IP_SECEXCEP and IP_SECMSG options could be moved to the socket > options section.] > > In earlier sections, several error conditions, and mechanisms to > enable error reporting, were defined. This section discusses the > method for implementing error reporting. > > A UNIX signal, SIGURG, will be sent to the owning process of a socket > that has a security error occur. To determine which of the three > possible error sources, failure packets, naked packets, or paranoid > packets, generated the signal, another (read-only) socket option must > be implemented. This socket option is IP_SECEXCEPT. [...] How is the management of errors through SIGURG intended to work when an application has multiple AF_INET6 sockets open, with different security levels and options set ? Is using the 3rd fd_set in select(2) up for consideration ? In most cases, return from select() is "instantaneous". (I see this used _very_ rarely by applications using it - does it serve any real/useful purpose currently ?). Darren ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sun Jan 22 13:50:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13442; Sun, 22 Jan 95 13:50:35 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA13436; Sun, 22 Jan 95 13:50:27 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id NAA23570; Sun, 22 Jan 1995 13:44:08 -0800 Received: from munnari.oz.au by Sun.COM (sun-barr.Sun.COM) id AA01203; Sun, 22 Jan 95 13:44:07 PST Received: from Marketing.DCTHQ.vines.datacraft.com.au by munnari.oz.au with MHSnet (5.83--+1.3.1+0.50) id AA08661; Mon, 23 Jan 1995 08:44:02 +1100 (from Alan.Lloyd@Marketing.DCTHQ.vines.datacraft.com.au) Received: from [148.182.10.2] by cms.datacraft.com.au with SMTP (5.65/1.2-eef) id AA12925; Mon, 23 Jan 95 08:38:08 +1100 Received: by dcthq2.datacraft.com.au; Mon, 23 Jan 95 8:43:58 +1100 Date: Mon, 23 Jan 95 8:37:20 +1100 Message-Id: From: Alan.Lloyd@datacraft.com.au To: ipng@sunroof.Eng.Sun.COM Subject: re: Re: Re: (IPng) Dynamic Readdressing Template a nd W X-Incognito-Sn: 578 X-Incognito-Format: VERSION=1.74 ENCRYPTED=NO Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM howard, oh well my comment was meant to be a bit light hearted. Dont have too much time to discuss this cos' I am buried in my X.400, X.500 and X.700 work at the moment with Defence and Govt and putting presentations together for these systems. "the first action of a network design is to determine its naming and addressing scheme". The second is to design its management system. regards and good luck. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jan 23 17:20:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14119; Mon, 23 Jan 95 17:20:12 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14113; Mon, 23 Jan 95 17:20:04 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id RAA22049; Mon, 23 Jan 1995 17:13:41 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA14419; Mon, 23 Jan 95 17:13:37 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14452(5)>; Mon, 23 Jan 1995 17:13:21 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Mon, 23 Jan 1995 17:13:18 -0800 To: ipng@sunroof.Eng.Sun.COM Cc: deering@parc.xerox.com Subject: (IPng) interim IPng WG meeting -- attendees and logistics Date: Mon, 23 Jan 1995 17:13:14 PST From: Steve Deering Message-Id: <95Jan23.171318pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Here is the current list of attendees for the IPng + addrconf + ngtrans meetings at Xerox PARC on February 9 and 10, culled from my email inbox. PLEASE LET ME KNOW of any names to be added or removed from this list, so I can get a reasonably accurate headcount for room set-up and catering, and so I can speed sign-in by having visitor badges pre-made. Jim Bound Scott Bradner Ross Callon Alex Conta Mike Davis Steve Deering Barbara Denny Ralph Droms Bob Fink Dimitry Haskins Marc Hasson Bob Hinden Wan-yen Hsu Allison Mankin Greg Minshall Julie Myers Erik Nordmark Bill Nowicki Yakov Rekhter Steve Russell Frank Solensky Sue Thomson Justin Walker The meetings will start at 9:00 am and will continue to at least 5:00 pm on *both* days, so please don't schedule an early get-away on Friday if you can avoid it. We plan to transmit the meetings over the MBone -- watch for an announcement on the rem-conf list and in 'sd'. If you are flying in, and haven't yet made your flight arrangements, note that Palo Alto is roughly equidistant from San Franscisco and San Jose airports (about a 30 minute drive on highway 101, assuming no congestion), so either one will work. San Jose is a little closer and usually less crowded/hectic, but you can often get better flights into San Francisco. Bob Hinden recommends the following hotels (no special rates, sorry!): Holiday Inn Palo Alto/Stanford 625 El Camino Real Palo Alto, CA 415 328-2800 Hyatt Rickeys 4219 El Camino Real Palo Alto, CA 415 493-8000 Garden Court Hotel (for those with generous travel allowances) 520 Cowper Street Palo Alto, CA 800 824-9028 The meetings will take place at Xerox PARC, 3333 Coyote Hill Road, Palo Alto. The phone number of the meeting room is 415 812-4414. Following is a map, showing the location of PARC, the Holiday Inn, and Hyatt Rickeys. (The Garden Court Hotel is half a block south of University Avenue on Cowper Street, not far from the Holiday Inn.) The map is approximately to scale. Top of the map is "logical north", i.e., towards San Francisco. (It's really West-North-West.) All the roads illustrated, except Coyote Hill Road, are major roads, separated by about 1.5 to 2 miles, i.e., there are many blocks and traffic lights between them. Coyote Hill Road is a minor road, one block logical west of Foothill Expressway. As you drive up Coyote Hill Road, Xerox PARC is on your left, just after you crest the hill. Park in the visitors lot (or, if that's full, lower down in the employees lot), and go in the main entrance at the top level to sign in. 280 101 from San Junipero El Camino from San Francisco Sera Blvd Real (82) Francisco || | | airport || | | || || | | || || | | || || | Palm Drive | University Ave /||\ || | ========|====================||== || | |Holiday \||/ || | Stanford |Inn || || | University | || || | | || || | | || || | | || || | | || || | | || || | | || || open | | || || grassy | | || || hills | | || /||\ | Page Mill Road | Oregon Expwy /||\ ==||=========================================|====================||= \||/ | | | \||/ || | | | || || |PARC | | || || | | | || || Coyote | | || || Hill | | || || Rd | | || || | | || || | | || || | | || || | | || || | Arastredero Rd | W. Charleston Rd || || ------------|--------------------|----------- || || | |Hyatt || || | |Rickeys || || | | || || | | || || | | || 280 from Foothill El Camino 101 from San Jose Expressway Real (82) San Jose airport ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 24 10:02:17 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14466; Tue, 24 Jan 95 10:02:17 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14388; Tue, 24 Jan 95 07:24:31 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA22422; Tue, 24 Jan 1995 07:18:09 -0800 Received: from bnl.gov by Sun.COM (sun-barr.Sun.COM) id AA12893; Tue, 24 Jan 95 07:17:59 PST Received: by bnl.gov (5.57/Ultrix3.0-C) id AA19818; Tue, 24 Jan 95 10:17:51 -0500 Received: by sirius.ccd.bnl.gov (940715.SGI.52/930416.SGI.AUTO) for @bnl.gov:ipng@sunroof.eng.sun.com id AA02963; Tue, 24 Jan 95 10:17:43 -0500 From: "Graham Campbell" Message-Id: <9501241017.ZM2961@sirius.ccd.bnl.gov> Date: Tue, 24 Jan 1995 10:17:42 -0500 In-Reply-To: Steve Deering "(IPng) interim IPng WG meeting -- attendees and logistics" (Jan 23, 5:13pm) References: <95Jan23.171318pst.12174@skylark.parc.xerox.com> X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) interim IPng WG meeting -- attendees and logistics Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I would like to attend the IPng WG meeting. I am on the ESnet IPng transition committee and am trying to get up to speed. Graham Campbell Brookhaven National Lab. -- Graham gc@bnl.gov ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 24 10:15:58 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14533; Tue, 24 Jan 95 10:15:58 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA14527; Tue, 24 Jan 95 10:15:50 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id KAA05772; Tue, 24 Jan 1995 10:09:29 -0800 Received: from eagle.es.net by Sun.COM (sun-barr.Sun.COM) id AA16268; Tue, 24 Jan 95 10:09:24 PST Received: from localhost by eagle.es.net; (5.65/1.1.8.2/18May94-0333PM) id AA11896; Tue, 24 Jan 1995 10:09:17 -0800 Message-Id: <9501241809.AA11896@eagle.es.net> To: ipng@sunroof.Eng.Sun.COM Cc: alh@es.net Subject: Re: (IPng) interim IPng WG meeting -- attendees and logistics In-Reply-To: Your message of "Mon, 23 Jan 95 17:13:14 PST." <95Jan23.171318pst.12174@skylark.parc.xerox.com> X-Mailer: exmh version 1.4.1 7/21/94 Date: Tue, 24 Jan 95 10:09:16 -0800 From: "Tony Hain" X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I will attend. Tony ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 25 11:45:46 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15064; Wed, 25 Jan 95 11:45:46 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15005; Wed, 25 Jan 95 10:25:30 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id KAA05780; Wed, 25 Jan 1995 10:19:07 -0800 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA01264; Wed, 25 Jan 95 10:18:06 PST Subject: (IPng) Yet another case for 1024-byte MTU To: IPng Mailing list Date: Wed, 25 Jan 1995 13:17:53 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9501251818.aa14295@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I'm re-writing/porting my ICMP code to 4.4 as I write this. I'm looking at the ICMP document, which states that 576 is the maximum size ICMP message that can be sent. I assume the ICMP maximum message will be minimum IPv6 MTU, whatever that turns out to be. Given that assumption, I have yet ANOTHER (admittedly selfish) reason for setting the IPv6 minimum MTU to 1024, and no higher. MBUFs come in two varieties. The normal kind, which holds about 104 bytes per MBUF, and the cluster MBUF, which holds 1024 bytes. With a minimum MTU/maximum ICMP size of 1024, I can fit any ICMP message into a single cluster MBUF, which makes my processing somewhat easier, because I don't have to fiddle with MBUF chains. Of course, a better buffering scheme than MBUFs could also solve this problem, but I've enough to do already, thank you. Dan McD. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 25 12:03:41 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15168; Wed, 25 Jan 95 12:03:41 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15162; Wed, 25 Jan 95 12:03:33 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA14251; Wed, 25 Jan 1995 11:57:09 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA19872; Wed, 25 Jan 95 11:56:03 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA22477; Wed, 25 Jan 95 11:50:58 -0800 Received: by xirtlu.zk3.dec.com; id AA03995; Wed, 25 Jan 1995 14:50:31 -0500 Message-Id: <9501251950.AA03995@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: (IPng) What's the Implementation Status for IPng Core Specs Date: Wed, 25 Jan 95 14:50:25 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM It appears we will move the Core specs per Bob Hinden's minutes to Proposed Standard Status soon. Though its not required to have implementations to move to Proposed Standard, I think its prudent as a WG member that we have some implementation experience with the Core specs before making them a Proposed Standard. Nothing verifies a protocol design or protocol architecture like implementation experience. IPv6 and the Core specs are pretty major changes to the Internet Model. If we don't have implementation experience I am not clear we are doing the right thing to make these Core specs Proposed Standards. Am I the only one in the WG with this concern? If I am not I think other views on this are prudent input to the WG Chairs and ADs on this mail list. I will send same message to addrconf and ngtrans for those WG's input too. Or do we need to make these Proposed Standards to get people to build implementations? This is a counter view. But is it valid and do we have all the Core Specifications defined? I don't think so. Also do not confuse the SIPP prototypes with IPv6 prototypes they are not the same test. [this should not be confused what needs to be done to move WGs out of the IPng Area into the "normal" WG areas.] Comments ??? thanks /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 25 14:45:42 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15549; Wed, 25 Jan 95 14:45:42 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15543; Wed, 25 Jan 95 14:45:34 PST Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id OAA14108; Wed, 25 Jan 1995 14:39:19 -0800 Received: by kandinsky.Eng.Sun.COM (5.x/SMI-SVR4) id AA15833; Wed, 25 Jan 1995 14:39:51 -0800 Date: Wed, 25 Jan 1995 14:39:51 -0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9501252239.AA15833@kandinsky.Eng.Sun.COM> To: ipng@sunroof Subject: (IPng) IPv6 testing at The Connectathon Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM On a note related to Jim Bound's recent mail about the status of IPv6 implementations, I'd like to find out whether any IPv6 implementors would be interested in doing interoperability testing at the Connectathon in March. The Connectathon is yearly get-together, sponsored by Sun, where network implementors perform interoperability testing. Originally organized to test NFS, this year the Connectathon will be testing lots of other protocols, and the organizers have said that IPv6 testing is welcome. The extent of the IPv6 testing, if it occurs, would be entirely up to the participants. The Connectathon will take place March 9 through 17 at the San Jose Convention Center. If you think you might be interested in participating in IPv6 testing, please let me know. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 25 21:22:08 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15784; Wed, 25 Jan 95 21:22:08 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15778; Wed, 25 Jan 95 21:22:00 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id VAA28463; Wed, 25 Jan 1995 21:15:36 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA29322; Wed, 25 Jan 95 21:15:31 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA08269; Wed, 25 Jan 95 21:11:42 -0800 Received: by xirtlu.zk3.dec.com; id AA13843; Thu, 26 Jan 1995 00:11:20 -0500 Message-Id: <9501260511.AA13843@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) Yet another case for 1024-byte MTU In-Reply-To: Your message of "Wed, 25 Jan 95 13:17:53 EST." <9501251818.aa14295@sundance.itd.nrl.navy.mil> Date: Thu, 26 Jan 95 00:11:14 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM >Given that assumption, I have yet ANOTHER (admittedly selfish) reason for >setting the IPv6 minimum MTU to 1024, and no higher. MBUFs come in two >varieties. The normal kind, which holds about 104 bytes per MBUF, and the >cluster MBUF, which holds 1024 bytes. With a minimum MTU/maximum ICMP size >of 1024, I can fit any ICMP message into a single cluster MBUF, which makes >my processing somewhat easier, because I don't have to fiddle with MBUF >chains. See your point but want to make other observation. I don't think we can justify min MTU by an OS implementation. Or we will open a real can of worms IMHO. >Of course, a better buffering scheme than MBUFs could also solve this >problem, but I've enough to do already, thank you. Yep. Lots of people have fixed this and changed it and don't have the problem anymore. But this is very privy stuff and not STANDARDABLE (best word I could come up with). But I suggest looking at MACH 3.2 VM model and that can be done IMHO in BSD derivative if someone wanted to do it. But that would be a lot of work and take one out of the network subsystem and into VM subsystem and it gets much different regarding disciplines quickly. Or just port to Streams? But please lets not justify min MTUs on Mbufs. Nice try though. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Wed Jan 25 21:46:56 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15796; Wed, 25 Jan 95 21:46:56 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15790; Wed, 25 Jan 95 21:46:49 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id VAA29173; Wed, 25 Jan 1995 21:40:24 -0800 From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA03121; Wed, 25 Jan 95 21:40:24 PST Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/10Aug94) id AA10014; Wed, 25 Jan 95 21:35:39 -0800 Received: by xirtlu.zk3.dec.com; id AA13986; Thu, 26 Jan 1995 00:35:17 -0500 Message-Id: <9501260535.AA13986@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) IPv6 testing at The Connectathon In-Reply-To: Your message of "Wed, 25 Jan 95 14:39:51 PST." <9501252239.AA15833@kandinsky.Eng.Sun.COM> Date: Thu, 26 Jan 95 00:35:11 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Also I have request into one of the Hosts of the Danvers MA IETF meeting for an Ethernet subnet so we can do some IPv6 testing at the IETF too. Too early to tell or get answer. I hope by mid-February. Response back to me was: would folks be willing pay nominal fee? I asked what the fee would be but thats unknown too but I would think it would be very cheap. My idea was to have all day Sunday for implementors to do IPv6 interoperability testing. Then during the week we can leave the net up for testing too and in the evenings (maybe we can even use it to test a debate on a spec - just kidding). Friday we could maybe get all day to do some testing after the code gets changed/altered from the tests and recap what we learned. This would be a real implementors event. Here is what I am thinking? Ethernet segment (not connected to terminal room or filtered by bridge) Assume dual stacks so we can test System Discovery and Autoconfig (stateless) to test IPv6 to IPv6. Could also test tunnels between Hosts too. Could test out DNS AAAA Records and Local File support as back up. This would test some of the sockets APIs. If energetic some of us could write a client/server test program. APPS: FTP, TELNET, TTCP, PING, and any utilities folks have ported. If someone can provide a router and connect to the Internet we could also test back to our firewall via encapsulation too. With the router we could also all set up two IPv6 address for each interface with different subnets and let the router forward packets to the other subnet on the same link via encapsulation using IPv4. Lets test those transition mechanisms. If we got real energetic maybe we could set up the Dan McDonald Dentist Office scenario and see if we can solve that problem. Also if you think you could provide a bridge or router and help us out that would be cool too. Or anything. Other ideas for testing ???? Comments?? /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 26 02:25:55 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15913; Thu, 26 Jan 95 02:25:55 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA15907; Thu, 26 Jan 95 02:25:42 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id CAA06108; Thu, 26 Jan 1995 02:19:18 -0800 Received: from iiit.swan.ac.uk (iifeak.swan.ac.uk) by Sun.COM (sun-barr.Sun.COM) id AA05827; Thu, 26 Jan 95 02:14:10 PST Message-Id: From: iialan@iiit.swan.ac.uk (Alan Cox) Subject: Re: (IPng) Yet another case for 1024-byte MTU To: ipng@sunroof.Eng.Sun.COM Date: Thu, 26 Jan 1995 10:13:53 +0000 (GMT) In-Reply-To: <9501260511.AA13843@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jan 26, 95 00:11:14 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > See your point but want to make other observation. I don't think we can > justify min MTU by an OS implementation. Or we will open a real can of > worms IMHO. Definitely. I'm going to have to rewrite the Linux buffer management somewhat for multiple payloads..... Alan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 26 07:42:45 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16052; Thu, 26 Jan 95 07:42:45 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16046; Thu, 26 Jan 95 07:42:38 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA15954; Thu, 26 Jan 1995 07:36:12 -0800 Received: from uu9.psi.com by Sun.COM (sun-barr.Sun.COM) id AA11728; Thu, 26 Jan 95 07:36:08 PST Received: from musak.UUCP by uu9.psi.com (5.65b/4.0.071791-PSI/PSINet) via UUCP; id AA02232 for ; Thu, 26 Jan 95 10:29:18 -0500 Received: from zydeco.csystems by dasw.com (4.1/SMI-4.1) id AA09790; Thu, 26 Jan 95 10:47:07 EST Received: from raga.csystems by zydeco.csystems (4.1/SMI-4.1) id AA20298; Thu, 26 Jan 95 10:22:48 EST Date: Thu, 26 Jan 95 10:22:48 EST From: jwelfeld@dasw.com (Joe Welfeld) Message-Id: <9501261522.AA20298@zydeco.csystems> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) ipv4 - ipv6 how do they talk ? Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Hello, Can someone on this list point me to some documents that might explain how ipV4 hosts can address ipv6 hosts ? I can understand how v6 hosts can talk to v4 hosts, but I am having problems understanding the v4 to v6 addressing ? Thanks in advance, ===================================================== Joe Welfeld Data Switch Corporation Email:jwelfeld@dasw.com 1 Enterprise Dr. Systems Engineer Shelton, CT. 06484 203.925.7548 Fax:203.929.8494 ==================================================== ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 26 07:58:36 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16065; Thu, 26 Jan 95 07:58:36 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16059; Thu, 26 Jan 95 07:58:26 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id HAA16871; Thu, 26 Jan 1995 07:52:01 -0800 From: smb@research.att.com Received: from research.att.com by Sun.COM (sun-barr.Sun.COM) id AA14260; Thu, 26 Jan 95 07:51:58 PST Message-Id: <9501261551.AA14260@Sun.COM> Received: by gryphon; Thu Jan 26 10:18:51 EST 1995 To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng) New Position Date: Thu, 26 Jan 95 10:18:50 EST Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM I wanted you to know that I am leaving Sun Microsystems and moving to a startup called Ipsilon Networks, Inc. located in Menlo Park, CA. I ca n be reached at hinden@mdv.com and at (415) 854-9734. I will continue m y IETF involvement in IPng. Bob Good luck! ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 26 08:45:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16120; Thu, 26 Jan 95 08:45:57 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16114; Thu, 26 Jan 95 08:45:49 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA20395; Thu, 26 Jan 1995 08:39:24 -0800 Received: from nic1.barrnet.net by Sun.COM (sun-barr.Sun.COM) id AA23141; Thu, 26 Jan 95 08:39:26 PST Received: from mdv.com by nic1.barrnet.net (8.6.8/BARRNET-RELAY.1) id IAA03726; Thu, 26 Jan 1995 08:39:25 -0800 Received: from [192.216.126.207] (acacia) by mdv.com (4.1/SMI-4.1MDV1.0) id AA26345; Thu, 26 Jan 95 08:40:56 PST X-Sender: hinden@orion.mdv.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Jan 1995 08:39:15 -0800 To: ipng@sunroof.Eng.Sun.COM From: hinden@mdv.com (Bob Hinden) Subject: Re: (IPng) New Position Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Thanks, Bob ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 26 09:03:24 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16139; Thu, 26 Jan 95 09:03:24 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16133; Thu, 26 Jan 95 09:03:17 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA22034; Thu, 26 Jan 1995 08:56:51 -0800 From: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA26433; Thu, 26 Jan 95 08:56:52 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA29612; Thu, 26 Jan 95 08:55:00 -0800 Received: by xirtlu.zk3.dec.com; id AA01885; Thu, 26 Jan 1995 11:54:55 -0500 Message-Id: <9501261654.AA01885@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: (IPng) Danvers MA - IPv6 Interoperability Test Date: Thu, 26 Jan 95 11:54:49 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Looks like we "might?" have 2 days Thurs/Fri March 30/31 prior to IETF meeting for room to do IPv6 interopabiltiy tests and nominal fee for attendees. Will know more in two weeks. We have to be out by Saturday 8 a.m. April 1st (really no fool stuff), as they need to set up terminal room then for IETF. What do you think? I will bring hostess twinkies for the old people and carrots for the health conscious. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 26 09:18:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16155; Thu, 26 Jan 95 09:18:50 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16149; Thu, 26 Jan 95 09:18:42 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id JAA23327; Thu, 26 Jan 1995 09:12:18 -0800 From: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA29282; Thu, 26 Jan 95 09:12:18 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA00706; Thu, 26 Jan 95 09:05:21 -0800 Received: by xirtlu.zk3.dec.com; id AA02136; Thu, 26 Jan 1995 12:05:11 -0500 Message-Id: <9501261705.AA02136@xirtlu.zk3.dec.com> To: ipng@sunroof.Eng.Sun.COM Cc: bound@zk3.dec.com Subject: Re: (IPng) IPv6 testing at The Connectathon In-Reply-To: Your message of "Wed, 25 Jan 95 14:39:51 PST." <9501252239.AA15833@kandinsky.Eng.Sun.COM> Date: Thu, 26 Jan 95 12:05:05 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob, I am interested but concerned too. As Digital goes to Connectathon I am somewhat familiar with the test strategy. My last contact states there is nothing formal for IPng such as test suites etc, though we could just put our IPv6 code base on our machines and try to connect (no pun intended) with other implementations and do some testing. I think you should tell the list the logistics of cost and what dates during Connectathon you feel this could be done (its two weeks March 13-24). I am sure none of us can be there or send developers for IPv6 for two weeks anywhere so picking a few days might be a better choice. The other issue is that I am pretty sure we have two days (memo just sent) for an IPv6 Interoperability test prior to the IETF meeting in Danvers MA. I think this will be cheaper and most implementors are coming to the IETF meeting anyway. This lets those implementors justify the travel and expense costs I would think better. If we are going to Danvers MA then why do Connectathon is one of my concerns. None of us make any revenue on IPv6 and piggybacking where we can costs to the IETF meetings is a much better sell to the management teams. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 26 13:47:18 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16338; Thu, 26 Jan 95 13:47:18 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16332; Thu, 26 Jan 95 13:47:10 PST Received: from kandinsky.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id NAA27812; Thu, 26 Jan 1995 13:40:45 -0800 Received: by kandinsky.Eng.Sun.COM (5.x/SMI-SVR4) id AA16727; Thu, 26 Jan 1995 13:41:19 -0800 Date: Thu, 26 Jan 1995 13:41:19 -0800 From: gilligan@jurassic.Eng.Sun.COM (Bob Gilligan) Message-Id: <9501262141.AA16727@kandinsky.Eng.Sun.COM> To: bound@zk3.dec.com, ipng@sunroof Subject: (IPng) re: IPv6 testing at The Connectathon Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > I am interested but concerned too. . . . Jim - Actually, I don't think that its an either/or question. If people want to test IPv6 at Connectathon, they can do that. If people want to test IPv6 at Danvers, they can do that too. I don't think any harm would result if IPv6 testing took place at both locations. As far as what parts of IPv6 would be tested and what test suites would be used: that would be up to the participants. They can test whatever they like. The actual tests performed would probably depend strongly on what parts of IPv6 people have implemented by then. And they can perform the tests whenever they wish during the two-week period. They could spend the entire two weeks testing, or just test for one day. My guess is that one or two days would suffice. The Connectathon is just a big room with power, network connections, and a security guard. I have talked to the people running the Connectathon and they would be happy to have IPv6 implementors attend and test whatever they wish to. As far as the costs of Connectathon are concerned, they charge participants a fee per table occupied. Most corporations that attend have one or more table. If your company already has a table, and your IPv6 machine can be accommodated at that table, then you could attend for no additional charge. If there are any implementors who would like to attend, but can not afford to, please get in touch with me and we'll look into alternatives. One possibility would be for some benefactor to lease an "IPv6 table" at which all of the IPv6 testors could sit. Bob. ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 26 14:34:57 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16405; Thu, 26 Jan 95 14:34:57 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16399; Thu, 26 Jan 95 14:34:49 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id OAA21758; Thu, 26 Jan 1995 14:28:24 -0800 Received: from alpha.xerox.com by Sun.COM (sun-barr.Sun.COM) id AA29593; Thu, 26 Jan 95 14:26:03 PST Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14426(1)>; Thu, 26 Jan 1995 14:24:39 PST Received: from localhost by skylark.parc.xerox.com with SMTP id <12174>; Thu, 26 Jan 1995 14:24:19 -0800 To: ipng@sunroof.Eng.Sun.COM, ngtrans@sunnroof.Eng.Sun.COM, addrconf@cisco.com Subject: (IPng) Re: interim IPng WG meeting -- attendees and logistics In-Reply-To: deering's message of Mon, 23 Jan 95 17:13:14 -0800. <95Jan23.171318pst.12174@skylark.parc.xerox.com> Date: Thu, 26 Jan 1995 14:24:12 PST From: Steve Deering Message-Id: <95Jan26.142419pst.12174@skylark.parc.xerox.com> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Here's the current list of attendees for the IPng + addrconf + ngtrans meeting on Feb 9 & 10 at PARC, updated according to messages I've received since my last posting. Please send me any additional corrections. Jim Bound Scott Bradner Ross Callon Graham Campbell Ping Chen Alex Conta Mike Davis Steve Deering Phil DeMar Barbara Denny Ralph Droms Bob Fink Rich Fox Bob Gilligan Heather Gray Tony Hain Dimitry Haskins Wayne Hathaway Marc Hasson Bob Hinden Wan-yen Hsu Allison Mankin Joachim Martillo Greg Minshall Erik Nordmark Bill Nowicki Steve Russell Frank Solensky Sue Thomson Justin Walker Steve ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 26 16:20:50 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16471; Thu, 26 Jan 95 16:20:50 PST Received: from jurassic.Eng.Sun.COM (jurassic-50) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16465; Thu, 26 Jan 95 16:20:42 PST Received: from elrond.ss-eng.eng.sun.com by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id QAA06924; Thu, 26 Jan 1995 16:14:25 -0800 Received: by elrond.ss-eng.eng.sun.com (SMI-8.6.9/SMI-SVR4) id QAA02148; Thu, 26 Jan 1995 16:14:07 -0800 Date: Thu, 26 Jan 1995 16:14:07 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199501270014.QAA02148@elrond.ss-eng.eng.sun.com> To: ipng@sunroof.Eng.Sun.COM, ngtrans@sunnroof.Eng.Sun.COM, addrconf@cisco.com Subject: Re: (IPng) Re: interim IPng WG meeting -- attendees and logistics X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Steve, I plan on attending the meeting. My specific interest is in IPng security. Is there an agenda yet? I will not be able to make it on the morning of the 10th and am hoping that security is not a topic then. Also, are there others who are interested in the security issues surrounding IPng? If so, I would like to find out what are their ideas so I don't waste everyone's time asking boring questions during the meeting. I have read the three internet drafts on IPng security (ipng-sec, ipng-auth and ipng-esp), so I am somewhat up to speed. However, I don't know what may have been discussed beyond what is in these documents. Regards, Dan Nessett ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Thu Jan 26 20:57:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16638; Thu, 26 Jan 95 20:57:52 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16632; Thu, 26 Jan 95 20:57:44 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id UAA20162; Thu, 26 Jan 1995 20:51:19 -0800 From: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com by Sun.COM (sun-barr.Sun.COM) id AA07861; Thu, 26 Jan 95 20:51:19 PST Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA20853; Thu, 26 Jan 95 20:47:57 -0800 Received: by xirtlu.zk3.dec.com; id AA21860; Thu, 26 Jan 1995 23:47:55 -0500 Message-Id: <9501270447.AA21860@xirtlu.zk3.dec.com> To: Bob.Gilligan@Eng (Bob Gilligan) Cc: bound@zk3.dec.com, ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: IPv6 testing at The Connectathon In-Reply-To: Your message of "Thu, 26 Jan 95 13:41:19 PST." <9501262141.AA16727@kandinsky.Eng.Sun.COM> Date: Thu, 26 Jan 95 23:47:49 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Bob, I agree more is better and two bake-offs are better than one. We will have someone there for testing IPv6 Mar 21-24. Lets talk off line about the benefactor thing not sure what I do but maybe I can help. /jim ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jan 27 08:07:43 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16957; Fri, 27 Jan 95 08:07:43 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA16951; Fri, 27 Jan 95 08:07:31 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id IAA24931; Fri, 27 Jan 1995 08:01:04 -0800 Received: from itd.nrl.navy.mil (itd-fddi.nrl.navy.mil) by Sun.COM (sun-barr.Sun.COM) id AA09393; Fri, 27 Jan 95 08:00:43 PST Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA01118; Fri, 27 Jan 95 11:00:41 EST Date: Fri, 27 Jan 95 11:00:41 EST From: atkinson@itd.nrl.navy.mil (Ran Atkinson) Message-Id: <9501271600.AA01118@itd.nrl.navy.mil> To: ipng@sunroof2.Eng.Sun.COM Subject: (IPng) IPv6 security, etc. Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, No one from NRL will be able to attend the Palo Alto meeting due to red tape problems that are unlikely to be resolved by then. We plan to MBONE to that meeting, but recent experience with our PIM routing within the building has been mixed. I did not fully understand Jim Bound's comment about the security specs and security policy and would appreciate help from everyone in fixing the documents. I was trying to define mechanisms rather than policy -- except in the area where we talked about the need to (by default, but tunable by the sys admin) authenticate "security critical" packets. I need help finding places where that isn't a good approach or where I didn't quite follow that approach. (ASIDE: a very drafty attempt to define those security critical packet types will appear in the next revision of I-Ds with corrections being sought). Specific comments telling me what sections to change and how to change them and why the change is better would be very helpful to me and might help focus list discussions. I very firmly agree with Jim Bound that the performance impact of security needs careful attention. The real world bottom line is that if the performance hit is too high, then security simply won't be widely used. We need "good enough" security but probably can't afford the performance hit of "perfect security". Work done by the good folks at Arizona has indicated that MD5 goes order(70Mbps) _tops_ on a 175 MHz Alpha (and this is with everything neatly aligned and during a good phase of the moon). Software encryption is also not cheap. The work by Joe Touch raises questions about whether a faster but still "strong enough" algorithm can be found that the Internet community is agreeable towards. I'm completely open to suggestions on new algorithms. I'm trying to follow the IETF precedents in my current drafts. I am not at all religious about the current algorithms. I'd like any new proposals to be run past the Security AD and Security Directorate before adoption as a sanity check. In particular, I am not a mathematician or an algorithm person and have never claimed to be such. :-) On key management, my desire is to try to reuse the work on hybrid Diffie-Hellman using the Eastlake-Kaufman DNS Public Keys to provide authentication for the key setup. Karn has a draft out on his version of this, which is called "Photuris". Network Systems has implemented and deployed something similar. I've urged those folks to try to get together and merge their proposals into a unified proposal for hybrid D-H using DNS Public Keys. Most of the discussions about those proposals have been in the IPv4 Security Protocol WG (IPsec) because the key mgmt is being proposed for use there. I really really want to reuse that key mgmt work rather than re-inventing the wheel over here. Ran atkinson@itd.nrl.navy.mil ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Fri Jan 27 17:28:12 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17596; Fri, 27 Jan 95 17:28:12 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17590; Fri, 27 Jan 95 17:28:00 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id RAA10701; Fri, 27 Jan 1995 17:21:34 -0800 Received: from sundance.itd.nrl.navy.mil by Sun.COM (sun-barr.Sun.COM) id AA20134; Fri, 27 Jan 95 14:56:15 PST Subject: (IPng) ICMP Destination unreachable and options To: IPng Mailing list Date: Fri, 27 Jan 1995 17:56:07 -0500 (EST) From: Dan McDonald X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <9501272256.aa16877@sundance.itd.nrl.navy.mil> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM The following is a note I sent to the list in August. I looked through notes and didn't see a solid answer to this question, so I'm reposting, since I'm moving my ICMP code from Net/2 to 4.4. =====================(Cut up to and including here.)====================== Under IP, or at least IP inside BSD Net/2 (Reno), when a Destination Unreachable is generated by UDP, the IP options are stripped. My subsequent question is two-fold: 1. Should a higher level protocol (like UDP) strip IPng options from a packet before sending Dest. Unreachable so that the source of the offending packet can send the incoming Dest. Unreachable to its appropriate higher-level protocol? 2. If not, what if the options (like a monstrously large source route) take all of the 576 bytes allowed for ICMP messages? How does my IPng module deal with this? Let me illustrate with an example. Let's say I send a UDP message with a source route to a machine. The header chain will look like: 0 40 n +------------+----------------+------------------------ | IPv6 hdr | Routing header | UDP header + data | | | | Next Hdr = | Next Header = | | Routing | UDP | +------------+----------------+------------------------ Now let's say the UDP header specifies a port that has no listeners. The receiving UDP module will send an ICMP Dest. Unreachable with code Port Unreachable. What will the ICMP message look like? Will it look like this? <----- Offending packet, up to 576 bytes ---> (Potentially might not include UDP header. Think of n > 526. ) 0 40 48 88 n+48 +------------+-----++-----------+----------------+------------------ | IPv6 hdr |I D U||(Bad) IPv6 | Routing header | UDP header + data | |C e n||Header | | | Next Hdr = |M s r||Next Hdr = | Next Header = | | ICMP |P t c|| Routing | UDP | +------------+-----++-----------+----------------+------------------ Or will it look like.... 0 40 48 88 +------------+-----++-----------+------------------ | IPv6 hdr |I D U||(Bad) IPv6 | UDP header + data | |C e n||Header | | Next Hdr = |M s r||Next Hdr = | | ICMP |P t c|| UDP | +------------+-----++-----------+------------------ If it is the former, my IPv6 ICMP module will have to potentially parse through the headers of the included offending packet to know to deliver the ICMP message to UDP. If the latter, my UDP module will have to strip options, much like UDP modules do in current IP on BSD Net/2. Also, if this is true, my IPng module may have to strip options in the case of destination unreachable codes and packet too big code. IWBNI anybody who's done SIPP-8s and ICMPs already would speak up on this. Thanks a ton! Dan McD. =====================(Cut up to and including here.)====================== My position on this is to probably strip away headers in UDP, and have UDP send the IPv6 + UDP header in the "offensive datagram" portion of an ICMP port unreachable message. Dan ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Sat Jan 28 11:37:11 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17742; Sat, 28 Jan 95 11:37:11 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA17736; Sat, 28 Jan 95 11:36:58 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id LAA13693; Sat, 28 Jan 1995 11:30:30 -0800 Received: from merit.edu by Sun.COM (sun-barr.Sun.COM) id AA00380; Sat, 28 Jan 95 11:29:13 PST Received: from Bill.Simpson.DialUp.Mich.Net (pm035-01.dialip.mich.net [141.211.7.12]) by merit.edu (8.6.9/merit-2.0) with SMTP id LAA18715 for ; Sat, 28 Jan 1995 11:47:44 -0500 Date: Sat, 28 Jan 95 16:11:52 GMT From: "William Allen Simpson" Message-Id: <3828.bill.simpson@um.cc.umich.edu> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Re: W.G. Meeting Minutes Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM > Please send me comments. I plan to send them to CNRI tomorrow afternoon. > It was irresponsible to expect us to review this in one day. Having a small amount of time to do a cursory reading of the minutes, I have found a number of significant errors. ! Bill Simpson would like link-specific F&R over all or most links. I spoke AGAINST link-specific F&R, saying it was a severe burden to REQUIRE all links, most of which are defined outside the IETF, to create link specific F&R just for us. It won't happen. We have to operate over current links. ! The consensus therefore is to use the Pack approach No, only for higher levels. It was agreed that the trailing zero approach be required for the "final" layer, to facilitate Auto-Configuration and Neighbor Discovery. ! It is proposed to change the lifetime field to hundreds of seconds. That's hundredths! A big difference. ! Range of time values: Request had been made for 100 msec. granularity. ! No room currently for larger values, hence upper limit of 650 seconds. Here, you have 100 msec. That's wrong, too. 10 msec is 0.01 seconds. ! Group decision to increase field size to 32 bits. No way in hell! Group seemed happy with 0.01 seconds to 650+ seconds. And I pointed out that an increase in field size would double the size of the header, since it would displace all the other fields. 10 minutes is a very long time! I can't imagine any user willing to wait that long to get a response.... ! Random (dithering) Solicitation Delay: Group agreed to not delay initial ! transmission of router solicitation. We most certainly did not! We agreed not to delay initial transmission of GENERAL solicitation. We also agreed that the Dead Node detection would be expanded, which affects the General Solicitation algorithm considerably. ! Cluster bit: Group agreed that each advertised prefix shall have two ! associated bits, indicating (a) whether or not the prefix may be used to ! form a self-configured host address, and (b) whether or not the hosts ! may assume that all destinations with that prefix are directly reachable ! on the immediate link. If no address-configuration-allowed prefixes are ! advertised, hosts are expected to use DHCPng to obtain their addresses. This was a proposal by one person. Nobody explained how it is supposed to actually work! The group certainly did not agree! My notes say separate messages, not bits. People already didn't understand the Cluster bit. Finally, this simply won't work with Sue's text. Bill.Simpson@um.cc.umich.edu ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Mon Jan 30 16:52:59 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18456; Mon, 30 Jan 95 16:52:59 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18450; Mon, 30 Jan 95 16:52:51 PST Received: from elrond.ss-eng.eng.sun.com by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id QAA29693; Mon, 30 Jan 1995 16:46:31 -0800 Received: by elrond.ss-eng.eng.sun.com (SMI-8.6.9/SMI-SVR4) id QAA04437; Mon, 30 Jan 1995 16:46:16 -0800 Date: Mon, 30 Jan 1995 16:46:16 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199501310046.QAA04437@elrond.ss-eng.eng.sun.com> To: ipng@sunroof.Eng.Sun.COM Subject: (IPng) Security Issues for IPng X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, Last week I asked if there was anyone on this list interested in IPng security issues. The only response I received was from Steve Bellovin (who said he wouldn't be able to make the Xerox Parc meeting). I was hoping that others would step up and point me to some past email or document that summarized the current state of affairs. Since that didn't happen, I decided to investigate this myself and come up with a set of current issues. I don't mean to barge into a discussion and would be happy if someone would point me to the "official" list of issues. I read the three security IDs and trundled through the IPng mail archives. Here are the current issues as I understand them (in no particular order) : o There has been some significant discussion about the security of ICMP. It wasn't clear just exactly what the options are for this issue, so I will summarize these in a follow-up message. o There has been discussion whether the ARP protocol requires new security functionality or ICMP should be enhanced to perform ARP-like semantics. The current consensus seems to be that ICMP should be enhanced. o Some email suggested that security labeling should not occur in IPng packets. Rather, only implicit labels should be allowed. These implicit labels would be derived from encryption parameters associated with the SAID carried by the packet. [question : what if the packet contains both an authentication header and and ESP header. Which SAID should be used to derive the implicit label?] o There were at least two issues related to mobile system. One concerns how ICMP security is handled. As mobile system move around, the first gateway in their outbound routes potentially will change. This will affect authentication of ICMP redirect and other messages. o The second mobile system issue concerns access control to the resources of the networks to which they are directly connected. This will involve some sort of authentication of the mobile system to these networks. Such authentication is also necessary for accounting purposes. Authorization of resource use will mean either access control lists maintained by the networks or some sort of capability based scheme. o One email message mentioned a possible denial of service threat if intermediate systems can invalidate flow ids. o One issue I didn't see discussed is how SAIDs are generated and exchanged. The documents attempt to separate this issue from IPng by assuming it is going to be solved by the Key Management WG. However, I couldn't even find a charter for the KMWG, although I perhaps didn't look in the right place. o Another issue related to Key Management is support of Key Management schemes that use in-band signalling of Key Management information (e.g., SKIP). Currently, IPng has no defined header options for this (neither the authentication nor the ESP header supports in-band signalling). The issue here is whether such headers will exist and who will define them. If such headers exist, how will the authentication and ESP headers use the information they carry to authenticate/protect the message? o Some higher level services, such as protocols providing message stream integrity and confidentiality, require a service interface to IPng that supports event driven changes of SAIDs (e.g., when a TCP connection is opened, it may require a new SAID to protect against replay attacks). As far as I can tell, there has been no discussion of the service interfaces between IPng and higher level protocols. o The draft socket API document assumes an SAID will be available when a request for a specific property set is made. What should the API do if such an SAID isn't immediately available, but could be in the future due to activity initiated because of the API call. For example, if a security setsockopt() call is made asking for a security level [by the way, this is a bad choice of terms, since it is commonly used to mean the level of the data within a packet, e.g., SECRET, CONFIDENTIAL] that no current SAID provides, the key management software may be called to set up such an SAID. Should the API call hang until the key management software completes its task? Should it return an error and assume the application will keep trying (in which case there should be an error code that says something like, "can't do this now, but try again later")? o There are several implementation issues that probably are not something this group will address. I only mention them because they occured to me during my reading and others may be interested in them. - SAIDs are identifiers that will be attached to information on both end systems. In the parlance of GSSAPI, they will name security contexts that are managed by those systems. Generating, evolving and deleting SAIDs and their associated security contexts requires care to ensure both systems remain synchronized and conditions such as half-open security "connections" do not occur. [This is probably also a key management protoco issue]. - Since the establishment of security contexts may require the exercise of significant software, there may be a necessity of moving security contexts between user-level and the OS kernel. This will require synchronization/locking of contexts to ensure that concurrent access to them by threads/processes maintains the correct state. Please feel free to criticize/comment on this set of issues or to add to it, if I have missed something. Regards, Dan Nessett ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 31 14:00:35 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18938; Tue, 31 Jan 95 14:00:35 PST Received: from jurassic.Eng.Sun.COM by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA18932; Tue, 31 Jan 95 14:00:28 PST Received: from elrond.ss-eng.eng.sun.com by jurassic.Eng.Sun.COM (SMI-8.6.9/SMI-SVR4) id NAA01602; Tue, 31 Jan 1995 13:54:07 -0800 Received: by elrond.ss-eng.eng.sun.com (SMI-8.6.9/SMI-SVR4) id NAA05341; Tue, 31 Jan 1995 13:53:52 -0800 Date: Tue, 31 Jan 1995 13:53:52 -0800 From: nessett@jurassic (Dan Nessett) Message-Id: <199501312153.NAA05341@elrond.ss-eng.eng.sun.com> To: ipng@sunroof Subject: (IPng) ICMP security issues X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM Folks, Here are some security issues that either were brought up in recent email discussions on this list or occured to me while reading those discussions. My purpose in listing these is to get them down in one place so we can address them in some organized way. The most fundamental issue is whether ICMP messages need to be authenticated or not. I think most would agree that at least some types should be authenticated. Whether or not there are situations in which some may also need to be confidentiality protected (i.e., by placing them in an ESP protected message) has not been discussed. I thought it would be useful to describe the vulnerabilities of particular ICMP messages if they are not authenticated. This will help in determining which ones (perhaps all of them) require such protection. To keep this message as short as possible, I decided to list the vulnerabilities first and beneath these list the messages that are susceptible to them. I made this list using ICMPv4 definitions; it should be easy to map it into the corresponding ICMPv6 equivalents. Also, the neighbor discover I-D doesn't have the reference to the document describing how those ICMP messages are used, so I haven't included them here. When it becomes available, I (we) can analyze those messages as well. Denial/Degradation of Service ----------------------------- Destination Unreachable (host, net, port & protocol unreachable, fragmentation needed); Time exceeded; Parameter Problem; Redirect. Force communications to less secure mode ---------------------------------------- o Destination unreachable (port unreachable) - if such an ICMP message is received in response to a Key Management protocol request, could force the source into a fallback key management scheme or mode of operations that is less secure. Force routing of data through inappropriate network --------------------------------------------------- o Redirect - this could be advantageous if the intruder desired to mount an aggregation attack against data that by itself is non-sensitive, but in total releases sensitive data. Increased probability of cryptoanalyzing encryption keying material ------------------------------------------------------------------- This is probably a second or lower order threat that should be noted, but probably not addressed, at least at first. Cryptoanalysis of algorithms is a high work factor activity and normally is only attractive to an intruder in very high value situations (e.g., defense/intelligence, large inter-bank funds transfers). Echo - Certain cryptoanalytic techniques (differential and linear cryptoanalysis) rely on the intruder exercising a chosen plaintext attack. Since the echo message contains data that is returned in the echo reply message, a mechanism is available for carrying out such an attack. However, the amount of data necessary for these attacks is usually very large and so it would be fairly impractical to use echo in this way. Furthermore, proper implementation of the security contexts underlying SAIDs would change keys after a much smaller amount of data has been encrypted. So the problem would only exist for poor implementations. This problem may also exist for other ICMP messages such as the replacements in ICMPv6 for the ICMPv4 Timestamp and Info Request messages. ==== If it is necessary to protect ICMP messages, the following issues become important : o ICMP messages must use an established SAID. From a destination host, this means an SAID must exist or be established on the fly even when an unprotected IP message is source of the ICMP message. o Certain ICMP messages can legitimately arrive from any gateway along the route taken by an IP message from source to destination host. To protect the ICMP message, the source host must have an SAID with that gateway. Potentially, this means a source host must have an SAID with *every* gateway through which its IP packets may pass. o The above two points illustrate the problems with pre-established security contexts identified by existing SAIDs. They suggest that in-band signalling of security context information within the IPv6 header is a practical requirement, if ICMP protection is considered necessary. SKIP is one example of an in-band signalling scheme, but others may exist as well. o As indicated in my previous message, the use of in-band signalling of security context establishment information raises an issue about how the message carrying such information is protected. o Finally, in a global internet we must engineer the ICMP protocols so that vendors can economically supply implementations that meet various export control restrictions as well as use restrictions on cryptographic technology within certain countries. At a minimum the standard should not require a conforming implementation to provide encryption of ICMP data, if that is ever considered useful. Once again, any comments/criticisms of the above are welcome. Regards, Dan Nessett ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 31 16:33:19 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19157; Tue, 31 Jan 95 16:33:19 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19151; Tue, 31 Jan 95 16:33:08 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA16887; Tue, 31 Jan 1995 16:26:34 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA27767; Tue, 31 Jan 95 16:26:09 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07189; 31 Jan 95 14:04 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-mcdonald-ipv6-sec-api-00.txt Date: Tue, 31 Jan 95 14:04:34 -0500 Message-Id: <9501311404.aa07189@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Security API for BSD Sockets Author(s) : D. McDonald Filename : draft-mcdonald-ipv6-sec-api-00.txt Pages : 12 Date : 01/30/1995 Security is a vital new feature in IPv6. Applications should have some control over security, hence the need for API extensions for security. This Internet Draft discusses such extensions, and the open issues associated with security and APIs. 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-mcdonald-ipv6-sec-api-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-mcdonald-ipv6-sec-api-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) 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-mcdonald-ipv6-sec-api-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950130131343.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-mcdonald-ipv6-sec-api-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-mcdonald-ipv6-sec-api-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950130131343.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 31 16:39:02 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19178; Tue, 31 Jan 95 16:39:02 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19166; Tue, 31 Jan 95 16:38:43 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA17248; Tue, 31 Jan 1995 16:32:10 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA28457; Tue, 31 Jan 95 16:30:52 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07533; 31 Jan 95 14:13 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipsec@ans.net, ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-metzger-esp-3des-cbc-00.txt Date: Tue, 31 Jan 95 14:13:51 -0500 Message-Id: <9501311413.aa07533@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ESP Triple DES-CBC Transform Author(s) : P. Metzger, P. Karn, W. Simpson Filename : draft-metzger-esp-3des-cbc-00.txt Pages : 9 Date : 01/30/1995 This document describes the Triple DES-CBC security transform for the Encapsulating Security Payload (ESP). 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-metzger-esp-3des-cbc-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-metzger-esp-3des-cbc-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) 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-metzger-esp-3des-cbc-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950130132325.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-metzger-esp-3des-cbc-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-metzger-esp-3des-cbc-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950130132325.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 31 16:39:07 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19179; Tue, 31 Jan 95 16:39:07 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19172; Tue, 31 Jan 95 16:38:47 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA17258; Tue, 31 Jan 1995 16:32:13 -0800 Received: from by Sun.COM (sun-barr.Sun.COM) id AB28457; Tue, 31 Jan 95 16:32:14 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07578; 31 Jan 95 14:14 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipsec@ans.net, ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-metzger-esp-des-cbc-02.txt Date: Tue, 31 Jan 95 14:14:47 -0500 Message-Id: <9501311414.aa07578@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : The ESP DES-CBC Transform Author(s) : P. Metzger, P. Karn, W. Simpson Filename : draft-metzger-esp-des-cbc-02.txt Pages : 8 Date : 01/30/1995 This document describes the DES-CBC security transform for the Encapsulating Security Payload (ESP). 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-metzger-esp-des-cbc-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-metzger-esp-des-cbc-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) 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-metzger-esp-des-cbc-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950130132940.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-metzger-esp-des-cbc-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-metzger-esp-des-cbc-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950130132940.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 31 16:44:05 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19199; Tue, 31 Jan 95 16:44:05 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19193; Tue, 31 Jan 95 16:43:54 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA17714; Tue, 31 Jan 1995 16:37:20 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA29304; Tue, 31 Jan 95 16:36:24 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa07610; 31 Jan 95 14:15 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipsec@ans.net, ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-metzger-ah-sha-00.txt Date: Tue, 31 Jan 95 14:15:12 -0500 Message-Id: <9501311415.aa07610@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Authentication with Keyed SHA Author(s) : P. Metzger, W. Simpson Filename : draft-metzger-ah-sha-00.txt Pages : 4 Date : 01/30/1995 This document describes the use of SHA with the IPv4 Authentication Header. 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-metzger-ah-sha-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-metzger-ah-sha-00.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) 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-metzger-ah-sha-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950130133646.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-metzger-ah-sha-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-metzger-ah-sha-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950130133646.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com From owner-ipng Tue Jan 31 16:55:52 1995 Return-Path: Received: by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19227; Tue, 31 Jan 95 16:55:52 PST Received: from Eng.Sun.COM (mpkmail1) by sunroof2.Eng.Sun.COM (4.1/SMI-4.1) id AA19219; Tue, 31 Jan 95 16:55:41 PST Received: from Sun.COM by Eng.Sun.COM (SMI-8.6.9/mh1) id QAA18660; Tue, 31 Jan 1995 16:49:07 -0800 Received: from IETF.nri.reston.VA.US (ietf.cnri.reston.va.us) by Sun.COM (sun-barr.Sun.COM) id AA00789; Tue, 31 Jan 95 16:49:05 PST Received: from [127.0.0.1] by IETF.CNRI.Reston.VA.US id aa11118; 31 Jan 95 17:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;@CNRI.Reston.VA.US From: Internet-Drafts@CNRI.Reston.VA.US Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng) I-D ACTION:draft-simpson-ipv6-discov-formats-02.txt Date: Tue, 31 Jan 95 17:41:36 -0500 Message-Id: <9501311741.aa11118@IETF.CNRI.Reston.VA.US> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk Reply-To: ipng@sunroof.Eng.Sun.COM --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Neighbor Discovery -- ICMP Message Formats Author(s) : W. Simpson Filename : draft-simpson-ipv6-discov-formats-02.txt Pages : 26 Date : 01/30/1995 This document specifies ICMP messages for identification of and forwarding to adjacent IPv6 nodes, including Mobility, Next Hop Determination and Router Discovery. 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-simpson-ipv6-discov-formats-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-simpson-ipv6-discov-formats-02.txt Internet-Drafts directories are located at: o Africa Address: ftp.is.co.za (196.4.160.2) o Europe Address: nic.nordu.net (192.36.148.17) 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-simpson-ipv6-discov-formats-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19950130150841.I-D@CNRI.Reston.VA.US> ENCODING mime FILE /internet-drafts/draft-simpson-ipv6-discov-formats-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-simpson-ipv6-discov-formats-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19950130150841.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- ------------------------------------------------------------------------------ IETF IPng Mailing List FTP archive: ftp.parc.xerox.com:/pub/ipng Unsubscribe: unsubscribe ipng (as message body, not subject) Direct all administrative requests to majordomo@sunroof.eng.sun.com