From owner-ipng@sunroof.eng.sun.com Fri Aug 1 09:33:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA13152; Fri, 1 Aug 1997 09:23:50 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA13145; Fri, 1 Aug 1997 09:23:39 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA20340; Fri, 1 Aug 1997 09:25:59 -0700 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA10269; Fri, 1 Aug 1997 09:26:00 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost2.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id JAA20324 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id JAA23040 Posted-Date: Fri, 1 Aug 1997 09:25:56 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id MAA06842; Fri, 1 Aug 1997 12:25:56 -0400 for Message-Id: <3.0.32.19970801122431.006d11cc@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 01 Aug 1997 12:24:32 -0400 To: Erik.Nordmark@Eng (Erik Nordmark) From: Dimitry Haskin Subject: (IPng 4234) Re: ND: Change default prefix Lifetime from infinity? Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3266 At 05:55 PM 7/30/97 -0700, Erik Nordmark wrote: > >> I see. And poorly connected cable can get loose while dusted by an inept >> janitor and get reconnected after the host got kicked the next morning :) >> In any case I don't see how you solve the problem by reducing the default >> prefix lifetime to 60 days (not that I mind). 60 days is infinity for all >> practical purposes. > >There is an example in the updated ND specification that >explains that infinity is a lot longer time than 60 days. > >See the new Renumbering Considerations section. > I understand that you're trying to limit the damage to 60 days rather than infinity. But 60 days is awfully long enough for me to accept that you have provided a solution. >> I guess, hosts that can't detect a loss of connectivity to a router within >> a reasonable period of time are troublesome. Perhaps hosts should be >> required to periodically probe routers if no other indication of >> connectivity is available and flush their prefix caches if a loss of >> connectivity is detected. > >The host would detect that the router isn't present but why should >that make the host discard the autoconfigured addresses that >are still valid (and might be valid for months depending on the >lifetimes in the annoucements). > >Keeping the address causes no harm as long as the host >will not try to use the address for the unplugged network interface >as a source address when sending packets out other network >interfaces. > Isn't there a danger that a host may use inappropriate addresses for a long time after it's plugged back? As Robert pointed out, this is especially true if a host is moved to a different link since there would be no RAs to invalidate stale addresses. >> Perhaps prefix caching in non-volatile memory should be disallowed for >> purpose of stateless autoconfiguration. I.e., if a host gets a prefix and >> subsequently its address from a disk, such an address should be considered >> as statefully configured regardless of how this prefix was learned in a >> previous life. > >Are you saying we should disallow hosts to have robust implementations? Not at all. Why would your think so?! >Having your host be unusable for 10 minutes longer than necessary >just because your host and your router booted faster than than >your switch/hub after a power failure doesn't seem very robust to me. > Having your host stuck with bad addresses for 60 days does not strike me to be robust easer. I believe your problem can be easily solved by making host to re-transmit RS for longer time which would require changing MAX_RTR_SOLICITATION to a higher value. >DHCP allows caching of addresses with lifetimes. Why does stateless >address autoconfig have to behave worse than DHCP in this respect? > Can't speak for DHCP for lack of expertise. Perhaps we want stateless atoconfiguration to do better. > Erik Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 1 11:43:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA13320; Fri, 1 Aug 1997 11:32:24 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA13313; Fri, 1 Aug 1997 11:32:16 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA24991; Fri, 1 Aug 1997 11:34:38 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA24282 for ; Fri, 1 Aug 1997 11:34:37 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id LAA18269; Fri, 1 Aug 1997 11:33:14 -0700 Message-Id: <3.0.3.32.19970801113231.0073875c@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Fri, 01 Aug 1997 11:32:31 -0700 To: jburgan@BayNetworks.com From: Bob Hinden Subject: (IPng 4235) Request to Advance "IPv6 Router Alert Option" Cc: narten@raleigh.ibm.com, scoya@cnri.reston.va.us, deering@cisco.com, ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 987 Jeff, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : IPv6 Router Alert Option Author(s) : D. Katz, R. Atkinson, C. Partridge, A. Jackson Filename : draft-ietf-ipngwg-ipv6router-alert-03.txt Pages : 5 Date : 07/29/1997 A working group last call for this document was completed on July 1, 1997. This draft incorporates changes based on comments received during the w.g. last call. Bob Hinden / Steve Deering IPng Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 1 13:33:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13507; Fri, 1 Aug 1997 13:23:08 -0700 Received: from sunmail1.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA13500; Fri, 1 Aug 1997 13:22:57 -0700 Received: from saturn.Sun.COM by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id NAA24471; Fri, 1 Aug 1997 13:25:21 -0700 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA28465; Fri, 1 Aug 1997 13:25:21 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost2.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id NAA27410 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id NAA29057 Posted-Date: Fri, 1 Aug 1997 13:25:16 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id QAA03337; Fri, 1 Aug 1997 16:25:16 -0400 for Message-Id: <3.0.32.19970801162351.006cba48@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 01 Aug 1997 16:23:52 -0400 To: Erik.Nordmark@Eng (Erik Nordmark) From: Dimitry Haskin Subject: (IPng 4236) Re: security problem: RAs with 0 lifetime prefixes Cc: dth@lucent.com, dhaskin@BayNetworks.COM, ipng@sunroof Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3271 At 10:46 AM 7/31/97 -0700, Erik Nordmark wrote: > >Dimitry Haskin wrote: >> 4) a host receiving RAs from multiple routers should use a higher >> lifetime >> for the same prefix. > >Can you provide some more details on how this would be >implemented? How much state does the host need to keep? >(Does the host have to track every prefix based >on what router is was received from, when it was received, and the >lifetime(s) it contained?) > I should not have include this rule or state it this way. I just wanted to emphasize that it would be required to always use lifetimes from the last received RA. I was not sure if it was already required in the spec. >Without requiring some more state about the prefixes that today >(i.e. just prefix and lifetimes) I don't see how you can implement >the above rule and still be able to lower the lifetime. >Today the state is: > Prefix P1, lifetime 10 days >If you keep > From R1: Prefix P1, lifetime 10 days > From R2: Prefix P1, lifetime 10 days and 3 minutes > From R3: Prefix P1, lifetime 10 days > From R4: Prefix P1, lifetime 10 days and 10 minutes > From R5: Prefix P1, lifetime 10 days > From Rogue R: Prefix P1, lifetime 3 seconds >you can clearly implement your rule by computing the max lifetime >over all routers. > I think it is much simpler. If the above list is in chronological order you'd end up with Prefix P1, lifetime 3 seconds. I believe this is according to the current spec. The difference is that you don't deprecate the prefix for the next 10 seconds. This may require an additional DELAY state associated with the prefix. Now the following rule: 3) if a router receives a multicast RA with a prefix that has a lifetime lower than the receiving router advertises for this prefix, it should immediately send own multicast RA. If this rule is in place R1, R2, R3, R4, and R5 will send their RAs and hosts bump their lifetimes for the prefix to circa 10 days. Now Robert has an excellent point about a possible RA storm. I think it can be avoided by refining the rule: 3) if a router receives a multicast RA with a prefix which has a lifetime significantly (we can quantify it latter) lower than the receiving router advertises for the prefix and the received lifetime would cause the prefix to expire before the router is able to send next three scheduled RAs, it should immediately send own multicast RA. >But there are another problem (apart from the additional state): > If R1 is turned off and later the network manager wants to lower > the lifetime to 1 day it can't be done until the lifetime sent > by R1 has expire. (The R1 entry will remain in the hosts state > until it times out.) You can work around this by having e.g. R2 > send you a RA packet with R1's source address but that is rather > gross. > Would my clarifications take care of this problem? Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 2 06:13:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA14523; Sat, 2 Aug 1997 06:05:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA14516; Sat, 2 Aug 1997 06:05:20 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA19733; Sat, 2 Aug 1997 06:07:40 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA22911; Sat, 2 Aug 1997 06:07:41 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id JAA23987; Sat, 2 Aug 1997 09:02:18 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA27172; Sat, 2 Aug 1997 09:02:08 -0400 Message-Id: <9708021302.AA27172@wasted.zk3.dec.com> To: Dimitry Haskin Cc: Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 4237) Re: ND: Change default prefix Lifetime from infinity? In-Reply-To: Your message of "Fri, 01 Aug 1997 12:24:32 -0400." <3.0.32.19970801122431.006d11cc@pobox> Date: Sat, 02 Aug 1997 09:02:08 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 881 >>DHCP allows caching of addresses with lifetimes. Why does stateless >>address autoconfig have to behave worse than DHCP in this respect? >> >Can't speak for DHCP for lack of expertise. Perhaps we want stateless >atoconfiguration to do better. The reason DHCPv6 permits this is that clients restarting will 90% of the time have to go off link via a relay to get resources. Unlike stateless where the router is on link. Much differnt and we may be comparing apples and oranges in this case. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 2 13:47:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA14812; Sat, 2 Aug 1997 13:39:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA14805; Sat, 2 Aug 1997 13:39:05 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA06911; Sat, 2 Aug 1997 13:41:29 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA07327 for ; Sat, 2 Aug 1997 13:41:31 -0700 Received: from spruce.ipsilon.com ([205.226.22.76]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id NAA05409; Sat, 2 Aug 1997 13:41:29 -0700 Message-Id: <3.0.3.32.19970802134057.00764ce8@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sat, 02 Aug 1997 13:40:57 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: (IPng 4238) Proposed IPng Agenda for Munich IETF Cc: hinden@Ipsilon.COM, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2243 Attached is the proposed agenda for the IPng session at the Munich IETF. Suggestions for changes/additions/etc to us. Bob Hinden / Steve Deering -------------------------------------------- IPng Meeting Agenda ------------------- Wed, 8/13/97, 1530-1730 (opposite ipp, schema, snmpv3, mpls, cat, pint) - Introduction / Deering, Hinden (10 min) - Document Status / Hinden (10 min) - Plan for Advancing Current Drafts / Hinden ( 10 min) o IPv6 Protocol o Addressing Architecture o ICMP o DNS o Neighbor Discovery o Address Auto Configuration o Aggregatable Addresses o IP_over_Ethernet/FDDI/PPP/ARCnet o TLA/NLA Assignment Rules o Testing Address Allocation o Multicast Assignments o Path MTU Discovery o Packet Tunneling - IPv6 Protocol Updates / Deering (30 min) o Restrictions on Routing header reversal o Specification of Class (formerly Priority) field o Inclusion of Class in Flow constant fields? o Neighborness rules for Strict/Loose Bit Map o Encoding of Option types - TLA/NLA Rules / Hinden (20 min) - Neighbor Discovery Issues / Nordmark, Narten (20 min) - Decision on Advancing Current Drafts / Hinden (10 min) Thu, 8/14/97, 1300-1500 (opposite acap, httpng, ptopomib, qosr, saag, mmusic, rtfm) - Mobile IP / Dave Johnson (10 min) - IPv6/NBMA work in the ION group / Grenville Armitage (10 min) - IPv6 Transmission over Frame Relay / Alex Conta (5 min) - IPv6 Transmission over IPv6/IPv4 Tunnels / Alex Conta (5 min) - Inverse Neighbor Discovery for IPv6 / Alex Conta (5 min) - Inverse Neighbor Discovery for IPv6/IPv4 Tunnels / Alex Conta (5 min) - Site prefixes in Neighbor Discovery / Nordmark (10 min) - Router Renumbering / Crawford (10 min) - IPv6 Name Lookups Through ICMP / Crawford (10 min) - Header Compression / ??? (10 min) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 2 14:47:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA14939; Sat, 2 Aug 1997 14:39:24 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA14932; Sat, 2 Aug 1997 14:39:15 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA11331; Sat, 2 Aug 1997 14:41:38 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA12883; Sat, 2 Aug 1997 14:41:40 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id RAA23619; Sat, 2 Aug 1997 17:35:37 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA03126; Sat, 2 Aug 1997 17:35:36 -0400 Message-Id: <9708022135.AA03126@wasted.zk3.dec.com> To: Dimitry Haskin Cc: Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 4239) Re: ND: Change default prefix Lifetime from infinity? In-Reply-To: Your message of "Fri, 01 Aug 1997 12:24:32 -0400." <3.0.32.19970801122431.006d11cc@pobox> Date: Sat, 02 Aug 1997 17:35:35 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2964 Dimitry, I still do not favor changing the RA and even though I saw Bob Hinden's well thoughtout mail I still believe if folks want secure RAs use IPsec. It is not impossible to use IPsec and Key Distribution in the IETF Terminal Room and if someone thinks it is they really ought to tell IPsec WG. But here is an engineer on our IPv6 team who likes your idea and his comments to me before he had to go out of town this week. I am just forwarding it. /jim Return-Path: PowellKen@mail.dec.com Received: from flume.zk3.dec.com by mailhub2.zk3.dec.com; (5.65v3.2/1.1.8.2/18Sep95-0525AM) id AA23553; Fri, 1 Aug 1997 18:27:39 -0400 Received: from [16.35.96.247] by flume.zk3.dec.com (5.65v4.0/1.1.8.2/16Jan95-0946AM) id AA20082; Fri, 1 Aug 1997 18:27:33 -0400 Received: by dashub2.mro.dec.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.996.15) id <01BC9EA8.94BC8B50@dashub2.mro.dec.com>; Fri, 1 Aug 1997 18:27:34 -0400 Message-Id: From: Ken Powell To: "'Jim Bound (E-mail)'" Cc: Subject: Idea for (IPng 4216) Re: security problem: RAs with 0 lifetimeprefixes Date: Fri, 1 Aug 1997 18:27:31 -0400 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.996.15 Encoding: 71 TEXT Jim, I have been watching the mail thread IPng 4216 all along. This is the one where they are trying to prevent trouble from a rouge system injecting a prefix lifetime of zero. I liked Dimitry's idea (below). His idea had two problems, the potential for flooding due to a war between a good router and a rogue, and the potential for dropped packets causing a host to miss the correction. I was reading RFC 1970 (Neighbor Discovery) to understand the existing mechanisms better. I think I stumbled across a simple solution in section 6.2.4. ND has a timer called MAX_INITIAL_RTR_INTERVAL. In effect, the router sends the first few RA's after power-up at a 16 second rate, complete with random variation built in. My suggestion: 1) Start with Dimitry's solution. 2) Use a 60 second delay for deprecation instead of 10 seconds on the host (Dimitry's step 2). 3) Instead of having the good router send a multicast RA immediately after receiving the bad RA (step 3), have the router temporarily set its timers down and follow the same procedures it does on startup. I'm not going to be around for the next week. If this idea looks good to you, feel free to send it along to the IPng list for me. Ken -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 3 15:00:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA16034; Sun, 3 Aug 1997 14:52:43 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA16027; Sun, 3 Aug 1997 14:52:34 -0700 Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id OAA02413; Sun, 3 Aug 1997 14:54:59 -0700 (PDT) Received: from lucknow by lucknow.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA11059; Sun, 3 Aug 1997 14:54:02 -0700 Message-Id: <199708032154.OAA11059@lucknow.eng.sun.com> Date: Sun, 3 Aug 1997 14:54:02 -0700 (PDT) From: Mukesh Kacker Reply-To: Mukesh Kacker Subject: (IPng 4240) draft-stevens-advanced-api-04.txt: CMSG_*() macros and alignment issues To: ipng@sunroof.eng.sun.com Cc: mukesh@jurassic.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: OPsn8bGXfZy9pcNMj8029w== X-Mailer: dtmail 1.2.0 CDE Version 1.2_36 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 6665 The Advanced Socket API specifies the packing of "ancillary data objects" into a flat memory buffer. These objects are variable length a "header" descriptor (struct cmsghdr) is used to delimit the multiple variable length "data" (cmsg_data) parts. The design of the packing also seeks to preserve access to the fields of the "header" and the "data" parts without taking any alignment faults. This is accomplished with the CMSG_FIRSTHDR(), CMSG_NXTHDR(), CMSG_DATA() macros. In addition this draft adds the CMSG_SPACE() and CMSG_LEN() macros. This design of CMSG_FIRSTHDR(), CMSG_NXTHDR(), CMSG_DATA is sound, however the historic implementations of these macros (e.g in BSD derived systems) however have some assumptions about alignment requirements. These assumptions should be explcitly outlined NOW and in this spec since the have also have an impact on the design of CMSG_SPACE() and CMSG_LEN() which are NEW with this spec. Unless these assumptions are clarified, the design of CMSG_SPACE() and CMSG_LEN() is inappropriate under certain set of alignment related assumptions (unless the specification is clarified). The commentary below details the alignment related issues with BSD derived implementations which influence the design of the Socket API and need to be clarified in this draft. (1) CMSG_FIRSTHDR macro implementation in BSD systems assumes that message buffer starts at an aligned boundary. This is true when the message buffer is allocated using malloc(), which guarantees to return a buffer suitable for use on the most strict alignment boundary of a sytems implementation architecture. However, it is not guaranteed to be true when the buffer is is declared as an automatic variable on the stack in many systems architecture (e.g x86 systems). The current text of this draft preserves that limitation/ assumption. This cannot really be fixed by fixing the definition of CMSG_FIRSTHDR since Socket interfaces are most often implemented as system call and the copyout() is done from kernel to user space "control buffer" starting from the first byte. If this buffer is to be parsed successfully by the application, the first byte of control buffer needs to be aligned. My recommendation/suggestion is that this draft should explicitly state that the control buffer is required to start on the strictest alignment boundary on a machine. (2) CMSG_NXTHDR macro implementation in BSD systems returns a pointer to a boundary that is arrived at with the ALIGN() macro. This ALIGN macro (based on comments accompanying its declaration in the header in BSD) is the machine's strictest data type alignment boundary. The current draft does not specify this and allows for an implementation which may take the approach of making this boundary what is minimally sufficient to provide a provide aligned access to fields of "struct cmsghdr". (On 32-bit machines, this "minimally sufficient" boundary is identical to the "machine's strictest" boundary but not necessarily on 64-bit machines). If such an approach is taken however, the CMSG_SPACE() and CMSG_LEN() macros will not be able to compute the value using just the "length" argument alone. They will need a pointer to cmsghdr also as a formal argument. [ e.g. CMSG_SPACE(length) will need to be CMSG_SPACE(cmsg, length) etc.]. I can provide the gory details if anyone is interested in the gory details of scenarios under which this will happen but I hope people can figure this out. The current drafts language about ALIGN says "even multiple of whatever alignment is required". The "whatever alignment" part leaves room for not using the strictest alignment which is not consistent with the design of CMSG_SPACE() and CMSG_LEN(). The language also has a minor semantic problem when it mentions "even multiple" where it probably means "whole multiple" [ if one takes an "even" vs "odd" interpretation, on 32 bit machines and odd multiple of 4 makes a fine alignment boundary ]. My recommendation/suggestion is that this draft should state clearly that ALIGN() be specified as a macro that aligns things along the machine's strictest alignment boundary. It should also state that "struct cmsghdr" needs to start on the strictest alignment boundary [ so that the specified design of CMSG_SPACE() and CMSG_LEN() works.] (3) The BSD sytems implement CMSG_DATA macro using pointer arithmetic on a pointer pointer to "struct cmsghdr" and return the pointer immediately following the header i.e. they do not use the ALIGN macro. (This works fine on 32-bit systems but is not necessarily the "right thing" for 64 bit systems or systems which can have objects with a strictest alignment requirement). This draft includes a definition which uses the ALIGN macro and has the better property of allowing data objects to have the strictest alignment (assuming that BSD definition of ALIGN())and thus allowing ancillary data with the stricter alignment possible. This significant difference is however not pointed out as part of the specification of CMSG_DATA. (Other differences from "existing" practice have been pointed out such as with definition of CMSG_FIRSTHDR and CMSG_NXTHDR). Without that some implementations may assume that the classical BSD header definition is adequate. My suggestion/recommendation is that along with the example definition of CMSG_DATA() a note be added stating that this data part needs to start on the machines strictest alignment boundary. It should also state that the example definition shown is different from that in many existing/historical (BSD derived) implementations (even though the BSD header definition work fine on ILP32 architectures where strictest alignment required is 32 bits). ---------------------------------------------------------------------- Mukesh Kacker | Football incorporates the two worst Sun Microsystems Inc (SunSoft) | characteristics of American society. mukesh.kacker@eng.sun.com | Violence punctuated by committee meetings. 415-786-5156 | -- George Will -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 3 15:27:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA16091; Sun, 3 Aug 1997 15:18:44 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA16084; Sun, 3 Aug 1997 15:18:35 -0700 Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id PAA03280; Sun, 3 Aug 1997 15:21:00 -0700 (PDT) Received: from lucknow by lucknow.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA11067; Sun, 3 Aug 1997 15:20:03 -0700 Message-Id: <199708032220.PAA11067@lucknow.eng.sun.com> Date: Sun, 3 Aug 1997 15:20:03 -0700 (PDT) From: Mukesh Kacker Reply-To: Mukesh Kacker Subject: (IPng 4241) msg_controllen and "padding at end" issue: draft-stevens-advanced-api-04.txt To: ipng@sunroof.eng.sun.com Cc: mukesh@jurassic.eng.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: rszcDthuk1QxIY9tCpNmGw== X-Mailer: dtmail 1.2.0 CDE Version 1.2_36 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2720 This IPng 4188 message from Koji Imada referred to some minor inconsistencies with respect to whether msg_controllen includes the padding in the last "ancillary data object" which were present in some initial copies of draft-stevens-advanced-api-04.txt. This appears to have been fixed in the "current" copy of draft-stevens-advanced-api-04.txt at the FTP site in manner that support the interpretation that msg_controllen DOES include the padding at the end of the last ancillary data in the msg_control buffer. However there are still some portability issues that may affect applications which should be explicitly clarified which center around the interpretation of msg_controllen and whether or not it includes (1) When receiving a control message buffer from kernel to userspace in recvmsg(). - Is MSG_CTRUNC set in msg_flags when msg_controllen is large enough to include the "content" of the last ancillary data but not the padding ? (2) When sending a control message buffer from user space to the kernel in sendmsg() - Is msg_controllen required to include the padding at the end of last ancillary data object in this case ? If so, will the sendmsg() call fail (and so with what errno ?) if that padding is not included in msg_controllen ? [ setting MSG_CTRUNC as in recvmsg() is not an option since msg_flags is not a "return" parameter in this case ]. Or are the implementations required to be "liberal" in what they acceptthis case and not fail ? (I suspect this latter case may predominate in implementations and therefore the spec should specify this). I don't think the formal standards do not affect guidance on these issues. Since the use msg_control/msg_controllen is likely to increase when IPv6 APIs are used, I would like this draft should further clarify the specification keeping existing implemenation practices into account in the cases raised in (1) and (2) above. ---------------------------------------------------------------------- Mukesh Kacker | Football incorporates the two worst Sun Microsystems Inc (SunSoft) | characteristics of American society. mukesh.kacker@eng.sun.com | Violence punctuated by committee meetings. 415-786-5156 | -- George Will -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 3 21:54:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA16658; Sun, 3 Aug 1997 21:46:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA16651; Sun, 3 Aug 1997 21:46:08 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA06030; Sun, 3 Aug 1997 21:48:33 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id VAA02885 for ; Sun, 3 Aug 1997 21:48:34 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id AAA20898; Mon, 4 Aug 1997 00:44:16 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA31393; Mon, 4 Aug 1997 00:43:44 -0400 Message-Id: <9708040443.AA31393@wasted.zk3.dec.com> To: Dave Johnson Cc: mobile-ip@SMALLWORKS.COM, ipng@sunroof.eng.sun.com Subject: (IPng 4243) Re: New Internet-Draft for Mobile IPv6 In-Reply-To: Your message of "Fri, 01 Aug 1997 01:53:25 EDT." <16484.870414805@CHIMAY.MACH.CS.CMU.EDU> Date: Mon, 04 Aug 1997 00:43:44 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4756 dave, >And here is a list of some of the major changes in this draft relative >to the previous version of this same draft: > > - Introduced the Home Address destination option, to allow packets > sent by a mobile node while away from home to pass normally > through routers implementing ingress filtering. In IPNg we agreed to support you to make sure routers could do this yes. > - Added the requirement that all IPv6 nodes MUST be able to > correctly process a Home Address destination option in a received > packet. *** FROM new draft************** >No special authentication of the Home Address option is required, >except that if the IPv6 header of a packet is covered by >authentication, then that authentication MUST also cover the Home >Address option. If the packet carries no IP authentication, then the >contents of the Home Address option, as well as the Source Address >field or any other field in the IPv6 header, may have been forged or >altered during transit. Upon receipt of a packet containing a Home >Address option, the receiving node replaces the Source Address in >the IPv6 header with the Home Address in the Home Address option. >By requiring that any authentication of the IPv6 header also cover >the Home Address option, the security of the Source Address field in >the IPv6 header is not compromised by the presence of a Home Address >option. Security issues related to the Home Address option are >discussed further in Section 11. BIG BIG BIG TIME OBJECTION. No way No way. Your changing the source address of the IPv6 header here on the fly and that cannot be a MUST or even a SHOULD. Without more context and discussion it can't even be a MAY. I won't be around on mail after Tuesday so I will bring this up at IPng. I think once I present my objections you will need more than 10 minutes or we can wait for after the IETF. IPng never agreed to this fyi at this point. You don't address all the problems with doing this on the fly for tcp or udp ? Or the application socket ? or ICMP? etc.. I don't think any DST options can be a MUST in IPv6 as a comment. I think processing them is fine but if they are not supported just dropping them is fine too, so they should all be SHOULDs and in many cases MAY. > - Changed the interpretation of the Binding Update option such > that the home address in the binding is the address in the Home > Address option, not the Source Address in the IPv6 header. I'll say. Like all IPv6 Nodes SHOULD support a BINDING CACHE in the Destination Cache. This will take a lot more explanation of what it looks like in a cache as is done in RFC 1970. I would like technical details it is like hand waving now. Your requiring a cache but don't way what it is? > - Made the Care-of Address field in the Binding Update optional, > controlled by whether or not the new Care-of Address Present (C) > bit is set in the option. With the new use of the Home Address > option, the care-of address for a binding will usually be > specified by the Source Address field in the packet's IPv6 > header, but by retaining this field (and making it optional), > it is possible to send a binding update using a Source Address > different from the care-of address for the binding. This is not just done transparently to the upper layers as the draft suggests. Unless your working on a tcpip implementation I have never heard of? > - Added a description of the dynamic home agent address discovery > procedure and the use of the new Home-Agents anycast address. I need to read again on the plane. But right now an anycast address can only be used by a Router? Are you trying to use it for hosts too, it was not clear to me anyway? I think they should be for hosts too, but that is a different battle that has nothing to do with mobile. I think your binding update is important, but I think that is separate work too that is needed for IPv6. There are several of us working on it but other priorities in IPv6 are taking precedent. I will have a draft out on how to do this in Dec 97 at D.C. meeting right now I can't use your binding update. So I will invent another one. I'd rather not so we should talk offline maybe. Also if you want to be in synch with IPv6 make your lifetime be 32bits not 16 bits. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 3 22:48:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA16688; Sun, 3 Aug 1997 22:39:56 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA16681; Sun, 3 Aug 1997 22:39:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA11085; Sun, 3 Aug 1997 22:42:09 -0700 Received: from CHIMAY.MACH.CS.CMU.EDU (CHIMAY.MACH.CS.CMU.EDU [128.2.222.167]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA10561 for ; Sun, 3 Aug 1997 22:42:10 -0700 Received: from CHIMAY.MACH.CS.CMU.EDU by CHIMAY.MACH.CS.CMU.EDU id aa19052; 4 Aug 97 1:41:32 EDT To: bound@zk3.dec.com Cc: mobile-ip@SMALLWORKS.COM, ipng@sunroof.eng.sun.com In-Reply-To: Your message of "Mon, 04 Aug 97 00:43:44 EDT" <9708040443.AA31393@wasted.zk3.dec.com> From: Dave Johnson Subject: (IPng 4244) Re: New Internet-Draft for Mobile IPv6 Date: Mon, 04 Aug 97 01:40:47 -0400 Message-ID: <19050.870673247@CHIMAY.MACH.CS.CMU.EDU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 7318 Jim, Thanks very much for your comments on the new Mobile IPv6 draft. It is exactly this kind of discussion that we need -- including both Mobile IP and IPng groups -- in order to move forward on this stuff. >>And here is a list of some of the major changes in this draft relative >>to the previous version of this same draft: >> >> - Introduced the Home Address destination option, to allow packets >> sent by a mobile node while away from home to pass normally >> through routers implementing ingress filtering. > >In IPNg we agreed to support you to make sure routers could do this yes. > >> - Added the requirement that all IPv6 nodes MUST be able to >> correctly process a Home Address destination option in a received >> packet. > >*** FROM new draft************** > >No special authentication of the Home Address option is required, > >except that if the IPv6 header of a packet is covered by > >authentication, then that authentication MUST also cover the Home > >Address option. If the packet carries no IP authentication, then the > >contents of the Home Address option, as well as the Source Address > >field or any other field in the IPv6 header, may have been forged or > >altered during transit. Upon receipt of a packet containing a Home > >Address option, the receiving node replaces the Source Address in > >the IPv6 header with the Home Address in the Home Address option. > >By requiring that any authentication of the IPv6 header also cover > >the Home Address option, the security of the Source Address field in > >the IPv6 header is not compromised by the presence of a Home Address > >option. Security issues related to the Home Address option are > >discussed further in Section 11. > > >BIG BIG BIG TIME OBJECTION. No way No way. Your changing the source >address of the IPv6 header here on the fly and that cannot be a MUST or >even a SHOULD. Without more context and discussion it can't even be a >MAY. I won't be around on mail after >Tuesday so I will bring this up at IPng. I think once I present my >objections you will need more than 10 minutes or we can wait for after >the IETF. > >IPng never agreed to this fyi at this point. You don't address >all the problems with doing this on the fly for tcp or udp ? Or the >application socket ? or ICMP? etc.. > >I don't think any DST options can be a MUST in IPv6 as a comment. >I think processing them is fine but if they are not supported just >dropping them is fine too, so they should all be SHOULDs and in many >cases MAY. I don't understand your objections here, mainly since you give no details on what you see as the problem. I well understand that some of this has not been agreed to yet by IPng. Our hope is that by putting it in the draft, we can have things specified well enough that we are all talking about the same thing as we discuss it. Based on what you say above, perhaps I have not succeeded at specifying it clearly enough, though, since I'm not sure you are thinking the same thing here as I am. I look forward to hearing your objections, and think that we shouldn't wait until after the meeting. >> - Changed the interpretation of the Binding Update option such >> that the home address in the binding is the address in the Home >> Address option, not the Source Address in the IPv6 header. > >I'll say. Like all IPv6 Nodes SHOULD support a BINDING CACHE in the >Destination Cache. This will take a lot more explanation of what it >looks like in a cache as is done in RFC 1970. I would like technical >details it is like hand waving now. Your requiring a cache but don't >way what it is? The "SHOULD" has been there for a while now, since draft -02, way back in November 1996. If more detail is needed in the draft (you are probably correct here), it can certainly be added. I think, though, that it is much more than hand waving now. Could you be more specific on what part you are unclear on? The change noted here in the draft is simply on where the various fields are in the packet, since the Home Address option now gives the home address rather than the Souce Address in the IPv6 header, and the care-of address is now the Source Address in the IPv6 header rather than being in the Binding Update option. The "meaning" of a Binding Update, over all, has not changed, nor has the Binding Cache. >> - Made the Care-of Address field in the Binding Update optional, >> controlled by whether or not the new Care-of Address Present (C) >> bit is set in the option. With the new use of the Home Address >> option, the care-of address for a binding will usually be >> specified by the Source Address field in the packet's IPv6 >> header, but by retaining this field (and making it optional), >> it is possible to send a binding update using a Source Address >> different from the care-of address for the binding. > >This is not just done transparently to the upper layers as the draft >suggests. Unless your working on a tcpip implementation I have never >heard of? Again, could you give more specifics here? What do you see as the problem? Perhaps things are simply not specified clearly enough in the draft? > >> - Added a description of the dynamic home agent address discovery >> procedure and the use of the new Home-Agents anycast address. > >I need to read again on the plane. But right now an anycast address >can only be used by a Router? Are you trying to use it for hosts too, >it was not clear to me anyway? I think they should be for hosts too, >but that is a different battle that has nothing to do with mobile. Home agents are routers, and only home agents are intended to be members of the Home-Agents anycast "group". I don't see problem here. >I think your binding update is important, but I think that is >separate work too that is needed for IPv6. There are several of us >working on it but other priorities in IPv6 are taking precedent. >I will have a draft out on how to do this in Dec 97 at D.C. meeting right >now I can't use your binding update. So I will invent another one. >I'd rather not so we should talk offline maybe. Yes, we should defintely talk. I think your input on all of this would be very valuable. What is it about our Binding Update that makes you say you cannot use it? >Also if you want to be in synch with IPv6 make your lifetime be 32bits >not 16 bits. What aspect of IPv6 will this make us in synch with? We could certainly extend the field to 32 bits but would rather not unnecessarily do so since it adds bytes to packets that are already quite large (particularly for mobile hosts on slow wireless links). Could you please clarify your suggestion here? Again, thanks for your comments. I look forward to hearing more from you as you have time to send more specific information on your objections and suggestions. This will be quite helpful for us. Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 4 01:37:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA16824; Mon, 4 Aug 1997 01:29:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA16817; Mon, 4 Aug 1997 01:29:23 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA27043; Mon, 4 Aug 1997 01:31:49 -0700 Received: from gate.ticl.co.uk (gate.ticl.co.uk [193.32.1.5]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id BAA02856 for ; Mon, 4 Aug 1997 01:31:48 -0700 Received: from desktop.ticl.co.uk (desktop.ticl.co.uk [193.32.1.15]) by gate.ticl.co.uk (8.8.5/8.8.5) with SMTP id JAA09299 for ; Mon, 4 Aug 1997 09:28:05 +0100 (BST) Message-Id: <199708040828.JAA09299@gate.ticl.co.uk> From: "Peter Curran" To: Subject: (IPng 4245) Re: Proposed IPng Agenda for Munich IETF Date: Mon, 4 Aug 1997 09:17:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1008.3 X-MimeOle: Produced By Microsoft MimeOLE Engine V4.71.1008.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1014 >Attached is the proposed agenda for the IPng session at the Munich IETF. >Suggestions for changes/additions/etc to us. > >Bob Hinden / Steve Deering > >-------------------------------------------- > >IPng Meeting Agenda >------------------- > >Wed, 8/13/97, 1530-1730 (opposite ipp, schema, snmpv3, mpls, cat, pint) > >- Introduction / Deering, Hinden (10 min) >- Document Status / Hinden (10 min) >- Plan for Advancing Current Drafts / Hinden ( 10 min) > o IPv6 Protocol > o Addressing Architecture > o ICMP > o DNS Can somebody point me at any outstanding drafts relating to DNS please? Cheers Peter Curran TICL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 4 08:55:35 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17517; Mon, 4 Aug 1997 08:46:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA17510; Mon, 4 Aug 1997 08:46:42 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA29696; Mon, 4 Aug 1997 08:49:06 -0700 Received: from mailhost.Ipsilon.COM (mailhost.ipsilon.com [205.226.5.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA27454 for ; Mon, 4 Aug 1997 08:49:07 -0700 Received: from spruce.ipsilon.com (spruce.Ipsilon.COM [205.226.1.63]) by mailhost.Ipsilon.COM (8.6.11/8.6.10) with SMTP id IAA24662; Mon, 4 Aug 1997 08:48:32 -0700 Message-Id: <3.0.3.32.19970804084802.031c4584@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Mon, 04 Aug 1997 08:48:02 -0700 To: "Peter Curran" From: Bob Hinden Subject: (IPng 4247) Re: Proposed IPng Agenda for Munich IETF Cc: In-Reply-To: <199708040828.JAA09299@gate.ticl.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 762 Peter, >>- Introduction / Deering, Hinden (10 min) >>- Document Status / Hinden (10 min) >>- Plan for Advancing Current Drafts / Hinden ( 10 min) >> o IPv6 Protocol >> o Addressing Architecture >> o ICMP >> o DNS >Can somebody point me at any outstanding drafts relating to DNS please? This was in reference to RFC 1886 "DNS Extensions to support IP version 6". Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 4 09:39:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17578; Mon, 4 Aug 1997 09:30:13 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17571; Mon, 4 Aug 1997 09:30:08 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA05284 for ; Mon, 4 Aug 1997 09:32:35 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28937; Mon, 4 Aug 1997 09:30:37 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA10549; Wed, 30 Jul 1997 20:43:18 -0700 From: kazu@Mew.org Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA13320; Wed, 30 Jul 1997 20:45:38 -0700 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id UAA28531 for ; Wed, 30 Jul 1997 20:45:30 -0700 Received: from localhost (kazu@localhost [127.0.0.1]) by mine.aist-nara.ac.jp (8.8.5/8.8.5) with ESMTP id MAA28103 for ; Thu, 31 Jul 1997 12:45:08 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 4248) Re: IPv6 API Update to RFC 2133 In-Reply-To: Your message of "Tue, 29 Jul 1997 11:44:38 -0400" <9707291544.AA06514@wasted.zk3.dec.com> References: <9707291544.AA06514@wasted.zk3.dec.com> X-Mailer: Mew version 1.87 on XEmacs 20.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19970731124506E.kazu@Mew.org> Date: Thu, 31 Jul 1997 12:45:06 +0900 X-Dispatcher: imput version 970730 Lines: 34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1420 Jim, From: bound@zk3.dec.com Subject: (IPng 4199) IPv6 API Update to RFC 2133 Date: Tue, 29 Jul 1997 11:44:38 -0400 > During August I would like to get all to send in functionality not > listed or you now find you need from your prototype experiences or > input from your customers or ISVs. Through my implementation experience of getaddrinfo(), I found one ambiguity in the case of AF_UNSPEC. Suppose "/etc/resolv.conf" has the following entry: search foo.com bar.com And DNS contains the following information: host.foo.com: v6 only host.bar.com: v4 only What should getaddrinfo() return for lookup of "host"? (Ans 1) v6 address of host.foo.com only since that is the first match. (Ans 2) both v6 address of host.foo.com and v4 address host.bar.com I guess some implementation of getaddrinfo() relies on gethostbyname2(). So, gethostbyname2() should conform requirements from getaddrinfo() when the spec is clarified. P.S. My implementation of getaddrinfo() depends on gethostbyname2() and acts as (Ans 2) at present. --Kazu -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 4 09:57:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17622; Mon, 4 Aug 1997 09:47:18 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17615; Mon, 4 Aug 1997 09:47:06 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA09755 for ; Mon, 4 Aug 1997 09:49:33 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28999; Mon, 4 Aug 1997 09:47:36 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA11952; Thu, 31 Jul 1997 14:51:17 -0700 Received: from kebe.eng.sun.com by jurassic.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA23479; Thu, 31 Jul 1997 14:53:40 -0700 Received: by kebe.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA11807; Thu, 31 Jul 1997 14:53:39 -0700 From: Dan.McDonald@eng.sun.com (Dan McDonald) Message-Id: <199707312153.OAA11807@kebe.eng.sun.com> Subject: (IPng 4250) Re: IPv6 Destination options extension header position. To: koji@math.human.nagoya-u.ac.jp (Koji Imada - je4owb/2) Date: Thu, 31 Jul 1997 14:53:39 -0700 (PDT) Cc: ipsec@tis.com, ipng@sunroof.eng.sun.com In-Reply-To: <199707312045.FAA23588@bimota.imada.math.human.nagoya-u.ac.jp> from "Koji Imada - je4owb/2" at Aug 1, 97 05:43:21 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2494 > What is the right description? The IPv6 RFC (1883) is the right description. I remember now having a small exchange with someone else about this. I decided not to pursue it because I figured the drawing in the AH draft was intended to show possibilities, not real positioning. Apparently the AH draft is confusing at least one person, and therefore needs to be clarified. > Any comments? "Destination" options (as opposed to hop-by-hop options) appear in TWO places: 1.) Before the routing header, which affects "per-source-route-hop" semantics. 2.) After AH, which affects "receiver-only" semantics. I'm also sending this to the ipng to make sure I'm not forgetting something. I'll show the original picture in the new AH draft, followed by my proposal for a clearer illustration. Here's the original one. Note the slight inaccuracy in destination options placement... > AFTER APPLYING AH > ------------------------------------------------------------ > IPv6 | |hxh,rtg,frag| dest | | dest | | | > |orig IP hdr |if present**| opt* | AH | opt* | TCP | Data | > ------------------------------------------------------------ > |<---- authenticated except for mutable fields ----------->| > > * = if present, could be before AH, after AH, or both > ** = hop by hop, routing, fragmentation headers Here's my proposed replacement drawing: AFTER APPLYING AH ------------------------------------------------------------ IPv6 | |hop-by-hop, dest*, | | dest | | | |orig IP hdr |routing, frag. | AH | opt* | TCP | Data | ------------------------------------------------------------ |<---- authenticated except for mutable fields ----------->| * = if present, could be before AH, after AH, or both The above replacment text better illustrates (IMHO) AH placement in an IPv6 datagram than does the current text. Dan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 4 10:33:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA17884; Mon, 4 Aug 1997 10:23:38 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA17877; Mon, 4 Aug 1997 10:23:33 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id KAA16381 for ; Mon, 4 Aug 1997 10:25:59 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA29148; Mon, 4 Aug 1997 10:24:04 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA16516; Sun, 3 Aug 1997 20:34:06 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA29072; Sun, 3 Aug 1997 20:36:31 -0700 Received: from mine.aist-nara.ac.jp (mine.aist-nara.ac.jp [163.221.202.12]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id UAA23587 for ; Sun, 3 Aug 1997 20:36:27 -0700 Received: from localhost (kazu@localhost [127.0.0.1]) by mine.aist-nara.ac.jp (8.8.5/8.8.5) with ESMTP id MAA14950 for ; Mon, 4 Aug 1997 12:36:06 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 4251) Forward: Re: IPv6 API Update to RFC 2133 From: Kazu.Yamamoto@Mew.org (=?ISO-2022-JP?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.87 on XEmacs 20.2 Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Mon_Aug__4_12:35:55_1997_997)--" Content-Transfer-Encoding: 7bit Message-Id: <19970804123605I.kazu@Mew.org> Date: Mon, 04 Aug 1997 12:36:05 +0900 X-Dispatcher: imput version 970803 Lines: 69 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2497 ----Next_Part(Mon_Aug__4_12:35:55_1997_997)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit This is a retry message. Attached is the message which I sent some days ago but have not received yet. Sorry if you receive duplicated messages. # Is there any filter for this mailing list? I sent the previous # message with a different address. --Kazu ----Next_Part(Mon_Aug__4_12:35:55_1997_997)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit To: ipng@sunroof.Eng.Sun.COM Subject: Re: (IPng 4199) IPv6 API Update to RFC 2133 In-Reply-To: Your message of "Tue, 29 Jul 1997 11:44:38 -0400" <9707291544.AA06514@wasted.zk3.dec.com> References: <9707291544.AA06514@wasted.zk3.dec.com> X-Mailer: Mew version 1.87 on XEmacs 20.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19970731124506E.kazu@Mew.org> Date: Thu, 31 Jul 1997 12:45:06 +0900 Sender: Kazuhiko YAMAMOTO X-Dispatcher: imput version 970730 Lines: 34 Jim, From: bound@zk3.dec.com Subject: (IPng 4199) IPv6 API Update to RFC 2133 Date: Tue, 29 Jul 1997 11:44:38 -0400 > During August I would like to get all to send in functionality not > listed or you now find you need from your prototype experiences or > input from your customers or ISVs. Through my implementation experience of getaddrinfo(), I found one ambiguity in the case of AF_UNSPEC. Suppose "/etc/resolv.conf" has the following entry: search foo.com bar.com And DNS contains the following information: host.foo.com: v6 only host.bar.com: v4 only What should getaddrinfo() return for lookup of "host"? (Ans 1) v6 address of host.foo.com only since that is the first match. (Ans 2) both v6 address of host.foo.com and v4 address host.bar.com I guess some implementation of getaddrinfo() relies on gethostbyname2(). So, gethostbyname2() should conform requirements from getaddrinfo() when the spec is clarified. P.S. My implementation of getaddrinfo() depends on gethostbyname2() and acts as (Ans 2) at present. --Kazu ----Next_Part(Mon_Aug__4_12:35:55_1997_997)---- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 4 11:23:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17973; Mon, 4 Aug 1997 11:05:25 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA17966; Mon, 4 Aug 1997 11:05:19 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id LAA23591 for ; Mon, 4 Aug 1997 11:07:46 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA29188; Mon, 4 Aug 1997 11:05:50 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA17596; Mon, 4 Aug 1997 09:34:10 -0700 Received: from bobo.eng.sun.com (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA06384 for ; Mon, 4 Aug 1997 09:36:37 -0700 (PDT) Received: by bobo.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08040; Mon, 4 Aug 1997 09:36:33 -0700 Date: Mon, 4 Aug 1997 09:36:33 -0700 From: Erik.Nordmark@eng.sun.com (Erik Nordmark) Message-Id: <199708041636.JAA08040@bobo.eng.sun.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4252) Re: W.G. Last Call on Addressing and IPv6_over_ Documents MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1095 > Title : TLA and NLA Assignment Rules > Author(s) : R. Hinden, M. O'Dell > Filename : draft-ietf-ipngwg-tla-assignment-00.txt > Pages : 5 > Date : 07/16/1997 The text talks about "offer public native IPv6 service ...". First of all I don't think "native" is well-defined; is tunneling IPv6 over frame relay, ATM, or IPv4 considered native or not? Second, does "native" really matter? I think it is the service that matters and if the organization chooses to provide initial IPv6 service at their boundary e.g. by encapsulating IPv6 in IPv4 for some or all of their internal topology they are still providing an IPv6 service. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 4 13:20:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA18349; Mon, 4 Aug 1997 13:11:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA18342; Mon, 4 Aug 1997 13:11:21 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA09402; Mon, 4 Aug 1997 13:13:46 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA27162; Mon, 4 Aug 1997 13:13:46 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id QAA18331; Mon, 4 Aug 1997 16:03:54 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA00008; Mon, 4 Aug 1997 16:03:52 -0400 Message-Id: <9708042003.AA00008@wasted.zk3.dec.com> To: Erik.Nordmark@Eng (Erik Nordmark) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4253) Re: W.G. Last Call on Addressing and IPv6_over_ Documents In-Reply-To: Your message of "Mon, 04 Aug 1997 09:36:33 MST." <199708041636.JAA08040@bobo.eng.sun.com> Date: Mon, 04 Aug 1997 16:03:52 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1715 Erik, >> Title : TLA and NLA Assignment Rules >> Author(s) : R. Hinden, M. O'Dell >> Filename : draft-ietf-ipngwg-tla-assignment-00.txt >> Pages : 5 >> Date : 07/16/1997 >The text talks about "offer public native IPv6 service ...". >First of all I don't think "native" is well-defined; is tunneling >IPv6 over frame relay, ATM, or IPv4 considered native or not? This is a little picky IMHO. But native is a good term. I means I can send IPv6 packet to you. That is native. What one does with it after that is relative from the perspective of performance. Tunneling is a performance and mgmt headache as is NAT. So Native I think is a good term and we should keep it. >Second, does "native" really matter? I think it is the service that matters >and if the organization chooses to provide initial IPv6 service at their >boundary e.g. by encapsulating IPv6 in IPv4 for some or all of >their internal topology they are still providing an IPv6 service. I disagree. It does matter. Competition btw vendor implementations will drive who and how will be interesting, but the most efficient use of IPv6 will win. I think there will be many ways to deploy IPv6, but I want to know if Native IPv6 is supported and the draft does this well for me. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 4 14:37:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA18452; Mon, 4 Aug 1997 14:27:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA18445; Mon, 4 Aug 1997 14:27:19 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA29146; Mon, 4 Aug 1997 14:29:43 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA22575 for ; Mon, 4 Aug 1997 14:29:43 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id RAA27799; Mon, 4 Aug 1997 17:24:43 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA17326; Mon, 4 Aug 1997 17:24:42 -0400 Message-Id: <9708042124.AA17326@wasted.zk3.dec.com> To: Dave Johnson Cc: bound@zk3.dec.com, mobile-ip@SMALLWORKS.COM, ipng@sunroof.eng.sun.com Subject: (IPng 4254) Re: New Internet-Draft for Mobile IPv6 In-Reply-To: Your message of "Mon, 04 Aug 1997 01:40:47 EDT." <19050.870673247@CHIMAY.MACH.CS.CMU.EDU> Date: Mon, 04 Aug 1997 17:24:41 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 12255 Dave, >Thanks very much for your comments on the new Mobile IPv6 draft. >It is exactly this kind of discussion that we need -- including both >Mobile IP and IPng groups -- in order to move forward on this stuff. I agree... Thanks... >> >the IPv6 header with the Home Address in the Home Address option. >> >By requiring that any authentication of the IPv6 header also cover >> >the Home Address option, the security of the Source Address field in >> >the IPv6 header is not compromised by the presence of a Home Address >> >option. Security issues related to the Home Address option are >> >discussed further in Section 11. >I don't understand your objections here, mainly since you give no >details on what you see as the problem. I well understand that some >of this has not been agreed to yet by IPng. Our hope is that by putting >it in the draft, we can have things specified well enough that we are >all talking about the same thing as we discuss it. Based on what you >say above, perhaps I have not succeeded at specifying it clearly enough, >though, since I'm not sure you are thinking the same thing here as I am. >I look forward to hearing your objections, and think that we shouldn't >wait until after the meeting. For this issue here is my objection. The "text" states from my reading: DST OPTION is received as Home Option: Take the address in the DST Home Option and put it in the IPv6 Header replacing the SRC address of the header. If that is not right then ignor the rest of my comments for this thread of the reply, and my input to you is thats how I interpret the spec. If my interpretation is wrong then make it clear in the spec. But..if I am right: Changing the IPv6 Header SRC address when parsing Options means changing it at the layers below the transport and before any Protocol Control Blocks (in BSD inpcb data structure) are updated for the connection. #1 this can break the checksum mandatory for both UDP and TCP in IPv6. #2 What if it is an existing tcp connection awaiting a reply changing the header affects that code base in any implementation. #3 How does the application layer know there is a new address both UDP and TCP. #3 What do we do with duplicate UDP msgs that come in. #4 What about ICMPv6 msgs for the source address in the packet where the src address fro the header was just stepped on. There are other issues but the key objection is that changing the source address of the IPv6 Header has many ramifications to an IP implementation and to the applications. You have not addressed any of them but just said "change the src address in the IPv6 Header". I am saying that this has many side affects, and must be discussed. And on top of all this the draft has MUST. Even if all these issues are addressed a MUST is too strong. No DST option should be a MUST as I stated in my last mail. I know because I am working on those side affects now on BSD 4.4 type implementation. Thats why I did not submit my draft and won't until after Munich cause this has to be checked out from an implementation perspective and its very dangerous to try to solve this problem with pure theory or architecture only hat. >>> - Changed the interpretation of the Binding Update option such >>> that the home address in the binding is the address in the Home >>> Address option, not the Source Address in the IPv6 header. >> >>I'll say. Like all IPv6 Nodes SHOULD support a BINDING CACHE in the >>Destination Cache. This will take a lot more explanation of what it >>looks like in a cache as is done in RFC 1970. I would like technical >>details it is like hand waving now. Your requiring a cache but don't >>way what it is? >The "SHOULD" has been there for a while now, since draft -02, way back >in November 1996. If more detail is needed in the draft (you are >probably correct here), it can certainly be added. I think, though, >that it is much more than hand waving now. Could you be more specific >on what part you are unclear on? The change noted here in the draft is >simply on where the various fields are in the packet, since the Home >Address option now gives the home address rather than the Souce Address >in the IPv6 header, and the care-of address is now the Source Address in >the IPv6 header rather than being in the Binding Update option. The >"meaning" of a Binding Update, over all, has not changed, nor has the >Binding Cache. Sorry about complaining now but I have to (better now than in last call but I know how you feel this just happened to me in DHCPv6 and it sucks and I am sorry but the binding/home option stuff woke me up). The draft should state "explicitly" what a binding cache is designed to do on an implementation and how that cache should be used. For example in ND RFC 1970 the caches are referenced and defined so that an implementor knows how to use them. In addition they are referenced in a conceptual model for implementation and for NUD (Neighbor Unreachability Detection). I would like to see the same for Mobile IPv6. How do I time out a binding cache? What is its lifetime? When it times out I will delete it as no one can keep stuff like this forever in a kernel implementation. Also the draft references that the cache can be part of the ND Destination Cache. But that is all it says???? What does that mean. I know all too well what the ND cache looks like on an IPv6 implementation. I have no guidance of what IPv6 mobile wants me to do if I implement it on IPv6 in my ND Dst cache. Lastly on this topic. The draft is asking IPv6 vendors to put Mobile IP Binding Data into my caches for address resolution, neighbor discovery, and for many of us this means another entry in our routing tables. I am not convinced this can be a SHOULD and it is definitely not a MUST. >>> - Made the Care-of Address field in the Binding Update optional, >>> controlled by whether or not the new Care-of Address Present (C) >>> bit is set in the option. With the new use of the Home Address >>> option, the care-of address for a binding will usually be >>> specified by the Source Address field in the packet's IPv6 >>> header, but by retaining this field (and making it optional), >>> it is possible to send a binding update using a Source Address >>> different from the care-of address for the binding. >> >>This is not just done transparently to the upper layers as the draft >>suggests. Unless your working on a tcpip implementation I have never >>heard of? > >Again, could you give more specifics here? What do you see as the >problem? Perhaps things are simply not specified clearly enough in >the draft? I believe I did above. >>> - Added a description of the dynamic home agent address discovery >>> procedure and the use of the new Home-Agents anycast address. >> >>I need to read again on the plane. But right now an anycast address >>can only be used by a Router? Are you trying to use it for hosts too, >>it was not clear to me anyway? I think they should be for hosts too, >>but that is a different battle that has nothing to do with mobile. > >Home agents are routers, and only home agents are intended to be >members of the Home-Agents anycast "group". I don't see problem here. If they are only routers then your OK. Why can't a Host be a home agent? I don't consider a node that sends a packet to the application layers and then sends it on to another application layer a router. For example in DHCP a Relay can be a Host or Router. Why is this different in Mobile. I don't see it? >>I think your binding update is important, but I think that is >>separate work too that is needed for IPv6. There are several of us >>working on it but other priorities in IPv6 are taking precedent. >>I will have a draft out on how to do this in Dec 97 at D.C. meeting right >>now I can't use your binding update. So I will invent another one. >>I'd rather not so we should talk offline maybe. >Yes, we should defintely talk. I think your input on all of this >would be very valuable. What is it about our Binding Update that makes >you say you cannot use it? First all lifetimes associated with addresses in IPv6 for Router Advertisements, Stateless Addr Conf, or DHCPv6 are 32bits. For my IP Dynamic Address Assignment I will have lifetimes. They will be 32bits. Also need two lifetimes. Valid and Preferred to support Dynamic Renumbering of addresses. need a time stamp of 64bits. only need one address field that is always present. have no need of the H and L bits. But do need bits: M - Member of a set of nodes on some medium other than Broadcast or NBMA. This is needed to support a pointer to hints for failover or loadbalancing. E - Extensions attached which will have a format for functions such as IP address other than this reachable to my interface if IPv6 Host Reachability Adv's are not possible. R - RTT Time hint for the node processing the DYN IP Addr UPDATE. The names of the fields don't apply to the needs for IP Dyn Update of an Address. It could very well be that my work is completely orthogonal which I think it is but someone said use Mobile Binding update. We are doing two different things and I think we should just have to have two DST options. If so then we don't need to talk about this and I am leaning in this direction anyway. But wanted to bring it up if folks want it to be the same. >>Also if you want to be in synch with IPv6 make your lifetime be 32bits >>not 16 bits. >What aspect of IPv6 will this make us in synch with? We could certainly >extend the field to 32 bits but would rather not unnecessarily do so >since it adds bytes to packets that are already quite large (particularly >for mobile hosts on slow wireless links). Could you please clarify >your suggestion here? I think I did above. All life times in our caches now are 32bits. It also aligns nicely on 32 bit or 64bit machines. Another issue I found today? Also why have the link-local address at all in the DST OPTION. Its purpose is not clear to me in the spec. It says in the spec so the node can use it to participate in the IPv6 ND protocol? But again no words or statements of how it participates with ND is discussed. I think the draft states it wants to participate within the ND protocol process for IPv6 but never explains how. I have given you several examples in this mail. ND RFC 1970 is one of the backbone core specs for IPv6. I think if Mobile insists on stating participation with ND it should be described exactly how. I also could not possible let this one to PS without some implementation experience because of the ND statements would be my input to an IESG Last Call for PS. Unless you make this SHOULDs and MAYs. Here is why: Every IPv6 implementation needs ND. Not every IPv6 implementation needs Mobile. Its only a nice to have. What I would like to see is a statement that says something like: If you support IPv6 Mobile you SHOULD (maybe even MUST if you do this) do what this specs says. This is much different than: All IPv6 Nodes MUST support these features for Mobile. I would argue Mobile is not of the same mandatory nature as ND, Addr conf, or IPsec. So I would like to see the WG ask the authors to back off on the MUST strategy they have stated to a softer SHOULD/MUST based on if Mobile is implemented. But if the details of my objections are "technically" satisfied I am open to discussing this but would like to hear others views too. Bottom line a compliant IPv6 node should not have to support Mobile if Mobile is not needed. Many users/customers would also not want any Mobile to exists at all in their environment. Note I differentiate Mobile from Portable Laptops. thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 4 19:21:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA19061; Mon, 4 Aug 1997 19:13:09 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA19054; Mon, 4 Aug 1997 19:13:00 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA27535; Mon, 4 Aug 1997 19:15:24 -0700 Received: from relay2.UU.NET (relay2.UU.NET [192.48.96.7]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA02062; Mon, 4 Aug 1997 19:15:26 -0700 Received: from rodan.UU.NET by relay2.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQdbfl17100; Mon, 4 Aug 1997 22:15:22 -0400 (EDT) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQdbfl19205; Mon, 4 Aug 1997 22:15:21 -0400 (EDT) Message-Id: To: bound@zk3.dec.com cc: Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 4255) Re: W.G. Last Call on Addressing and IPv6_over_ Documents In-reply-to: Your message of "Mon, 04 Aug 1997 16:03:52 EDT." <9708042003.AA00008@wasted.zk3.dec.com> Date: Mon, 04 Aug 1997 22:15:21 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 632 no, i don't think it matters exactly how they carry the IPv6 traffic if they can aggregate a large block of topology to the rest of the world, that's all that matters how they plumb their backbone is no bloody business of yours or anyone elses -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 4 20:03:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA19107; Mon, 4 Aug 1997 19:55:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id TAA19100; Mon, 4 Aug 1997 19:55:20 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id TAA02211; Mon, 4 Aug 1997 19:57:44 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id TAA11213; Mon, 4 Aug 1997 19:57:45 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id WAA22175; Mon, 4 Aug 1997 22:53:11 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA04158; Mon, 4 Aug 1997 22:53:07 -0400 Message-Id: <9708050253.AA04158@wasted.zk3.dec.com> To: "Mike O'Dell" Cc: bound@zk3.dec.com, Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 4256) Re: W.G. Last Call on Addressing and IPv6_over_ Documents In-Reply-To: Your message of "Mon, 04 Aug 1997 22:15:21 -0400." Date: Mon, 04 Aug 1997 22:53:07 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 855 >no, i don't think it matters exactly how they carry the IPv6 traffic yes. >if they can aggregate a large block of topology to the rest of the >world, that's all that matters yes. >how they plumb their backbone is no bloody business of yours or >anyone elses yes. so why do I feel a sense of sarcasim here and I take "yours" to mean "me -> Jim". I just think native is fine so dont jump on me OK. If your having a bad day don't take it out on us on the list. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 5 02:13:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA19375; Tue, 5 Aug 1997 02:05:20 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA19368; Tue, 5 Aug 1997 02:05:11 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id CAA03989; Tue, 5 Aug 1997 02:07:34 -0700 Received: from mserv1.dl.ac.uk (mserv1.dl.ac.uk [148.79.160.65]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA13138 for ; Tue, 5 Aug 1997 02:07:26 -0700 Received: from dla1.dl.ac.uk by mserv1.dl.ac.uk with ESMTP id KAA04863 (8.6.13/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from R.Tasker@dl.ac.uk); Tue, 5 Aug 1997 10:07:52 +0100 Received: by dla1.dl.ac.uk; id KAA11043; Tue, 5 Aug 1997 10:06:55 +0100 (BST) From: Robin Tasker Message-Id: <199708050906.KAA11043@dla1.dl.ac.uk> To: crawdad@fnal.gov cc: ipng@sunroof.eng.sun.com, rt@dla1.dl.ac.uk Subject: (IPng 4257) Comment: IPv6 over FDDI - user_priority Date: Tue, 05 Aug 97 10:06:53 +0100 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1550 Matt Just reading IPv6 over FDDI ID (draft-ietf-ipngwg-trans-fddi-net-02.txt), the discussion in Section 4 (Interaction with Bridges) talks about FDDI adjacency detection. This is achieved by sending a non-zero LLC priority which is, in IEEE 802 language, the user_priority parameter of the M.UNITDATA.request primitive set to non-zero. This relates to Neighbor Solicitation, Neighbor Advertisement and Router Advertisement frames. IEEE 802.1 is near to completing 802.1p which defines mechanisms to provide traffic classes in bridges/switches and therefore prioritised traffic flows in bridged networks. The use of the user_priority parameter is central to this work. The proposal in the above ID does not impinge on this work; these frames are "managing the network" and so need a good priority. However it makes sense to define the level of user priority to be used rather than leaving it unspecified as non-zero. The use of user_priority = 7 (the best you can have) would seem to be a good value. Thanks! Robin Robin Tasker CLRC, Daresbury Laboratory tel: +44 1925 603226 Warrington fax: +44 1925 603230 Cheshire WA4 4AD email: r.tasker@dl.ac.uk UK -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 5 03:13:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA19401; Tue, 5 Aug 1997 03:03:46 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA19394; Tue, 5 Aug 1997 03:03:37 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA08725; Tue, 5 Aug 1997 03:06:02 -0700 Received: from lint.cisco.com (lint.Cisco.COM [171.68.223.44]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA23672 for ; Tue, 5 Aug 1997 03:06:04 -0700 Received: from big-dawgs.cisco.com (herndon-dhcp-109.cisco.com [171.68.53.109]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id DAA10147; Tue, 5 Aug 1997 03:04:16 -0700 (PDT) Message-Id: <3.0.3.32.19970805060410.006ebbf4@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 05 Aug 1997 06:04:10 -0400 To: Robin Tasker From: Paul Ferguson Subject: (IPng 4258) Re: Comment: IPv6 over FDDI - user_priority Cc: crawdad@fnal.gov, ipng@sunroof.eng.sun.com, rt@dla1.dl.ac.uk, issll@mercury.lcs.mit.edu In-Reply-To: <199708050906.KAA11043@dla1.dl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2251 As an aside, it might be worthwhile to also note that some complimentary work has been drafted in the same vein, albeit with regards to IPv4 and Integrated Services: Integrated Services over IEEE 802.1D/802.1p Networks draft-ietf-issll-802-01.txt This draft provides a proposal to map user_priority values carried in 802.1p to one of the integrated service classes: [snip] Proposal: A Simple Scheme user_priority Service 0 "less than" Best Effort 1 Best Effort 2 reserved 3 reserved 4 Controlled Load 5 Guaranteed Service, 100ms bound 6 Guaranteed Service, 10ms bound 7 reserved [snip] FYI, - paul At 10:06 AM 08/05/97 +0100, Robin Tasker wrote: >Matt > >Just reading IPv6 over FDDI ID (draft-ietf-ipngwg-trans-fddi-net-02.txt), >the discussion in Section 4 (Interaction with Bridges) talks about FDDI >adjacency detection. This is achieved by sending a non-zero LLC priority >which is, in IEEE 802 language, the user_priority parameter of the >M.UNITDATA.request primitive set to non-zero. This relates to Neighbor >Solicitation, Neighbor Advertisement and Router Advertisement frames. > >IEEE 802.1 is near to completing 802.1p which defines mechanisms to provide >traffic classes in bridges/switches and therefore prioritised traffic flows >in bridged networks. The use of the user_priority parameter is central to >this work. > >The proposal in the above ID does not impinge on this work; these frames are >"managing the network" and so need a good priority. However it makes sense >to define the level of user priority to be used rather than leaving it >unspecified as non-zero. The use of user_priority = 7 (the best you can have) >would seem to be a good value. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 5 03:18:56 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA19410; Tue, 5 Aug 1997 03:08:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA19403; Tue, 5 Aug 1997 03:08:40 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA09029; Tue, 5 Aug 1997 03:11:05 -0700 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA24410; Tue, 5 Aug 1997 03:11:07 -0700 Received: from rodan.UU.NET by relay5.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQdbgq13417; Tue, 5 Aug 1997 06:11:09 -0400 (EDT) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQdbgq17346; Tue, 5 Aug 1997 06:11:03 -0400 (EDT) Message-Id: To: bound@zk3.dec.com cc: "Mike O'Dell" , Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 4259) Re: W.G. Last Call on Addressing and IPv6_over_ Documents In-reply-to: Your message of "Mon, 04 Aug 1997 22:53:07 EDT." <9708050253.AA04158@wasted.zk3.dec.com> Date: Tue, 05 Aug 1997 06:11:00 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 525 no sarcasm implied at all. you indicated you thought a TLA must provide "native IPv6 service" I was disagreeing (with you and the draft) -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 5 04:47:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA19565; Tue, 5 Aug 1997 04:39:45 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA19558; Tue, 5 Aug 1997 04:39:32 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA16342; Tue, 5 Aug 1997 04:41:57 -0700 Received: from gw-nl1.philips.com (gw-nl1.philips.com [192.68.44.33]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id EAA11545 for ; Tue, 5 Aug 1997 04:41:53 -0700 Received: (from nobody@localhost) by gw-nl1.philips.com (8.6.10/8.6.10-0.994n-08Nov95) id NAA12924 for ; Tue, 5 Aug 1997 13:41:49 +0200 Received: from smtprelay.nl.cis.philips.com(130.139.36.3) by gw-nl1.philips.com via smap (V1.3+ESMTP) with ESMTP id sma012750; Tue Aug 5 13:41:20 1997 Received: from hades.mpn.cp.philips.com (hades.mpn.cp.philips.com [130.139.64.31]) by smtprelay.nl.cis.philips.com (8.6.10/8.6.10-1.2.1m-970402) with ESMTP id NAA25036 for ; Tue, 5 Aug 1997 13:41:20 +0200 Received: from pc239.nwm.wan.philips.com (pc239.nwm.wan.philips.com [161.89.1.239]) by hades.mpn.cp.philips.com (8.8.5/8.6.10-1.2a-960910) with SMTP id NAA03082 for ; Tue, 5 Aug 1997 13:38:56 +0200 (MET DST) Message-Id: <3.0.1.32.19970805134039.0071d4a0@hades.mpn.cp.philips.com> X-Sender: rhunter@hades.mpn.cp.philips.com X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Tue, 05 Aug 1997 13:40:39 +0200 To: ipng@sunroof.eng.sun.com From: Ray Hunter Subject: (IPng 4260) Re: W.G. Last Call on Addressing and IPv6_over_ Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3059 Lately, I have not been lurking on this list as much as I would have liked to. (due to work pressure of course ;-) Sometime ago I made some comments to the addressing architecture docs as an engineer who works on large IP networks, because I did not think it would scale. Now the new versions of the address architecture docs are out, and there is a last call for comments, I thought I should revisit my previous comments. 1) I said the architecture was not scalable because it relied entirely on CIDR from the top level. fixed. The new architecture is built with todays technology (CIDR) but leaves plenty of space for other technology via e.g. exchange aggregation and assignment of new top level format prefixes. 2) I said relying on pure top down hierarchical provider based addressing was a mistake as multi-homing would either break CIDR or require multiple prefixes per user origanisation. fixed. The new scheme of addressing follows the functions that organisations fulfill on the network. There are a number of entry points into the assignment tree depending on what an organisation wants from the internet. You can't ask for any better than that with today's technology. 3) I said 8+8 et al was not a solution for today... but space should definitely be devoted to an unknown future. fixed. dependency on "MUST have 8+8" for IPV6 deployment have been dropped. 4) I raised concern about making the private topology portion fixed and whether it would be large enough. 16 bits for the site level aggregation portion is fine as far as I can tell for all the networks I have seen.... even if you decide to micro-subnet down to the host level on most of today's networks! The optional 2 levels of hierarchy in the site level aggregation will give organisations the ability to deploy routers with different sized tables (i.e. power/memory) as appropriate to their own internal topology. It also allows router vendors to develop value add routing protocols that operate within an organisation. 5) I wanted a clear distinction between private and public topology. fixed. The fixed lengths make this easy for everyone to understand. I do not believe the loss of flexibility/efficiency in address assignments due to these fixed boundaries will be significant compared to the original goals of IPV6. same positive comment as above on flexibility of choice of routing protocols. In conclusion: Excellent work guys! best regards, Ray Hunter, Globis Ltd. on contract to Origin Building VN629, Postbus 218, 5600MD Eindhoven, The Netherlands. email: Ray.Hunter@mpn.cp.philips.com email: Ray.Hunter@globis.net www: http://www.globis.net phone: +31 40 2787988 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 5 06:12:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA19630; Tue, 5 Aug 1997 06:04:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA19623; Tue, 5 Aug 1997 06:04:03 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA25087; Tue, 5 Aug 1997 06:06:27 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA01403; Tue, 5 Aug 1997 06:06:28 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id IAA03787; Tue, 5 Aug 1997 08:53:39 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA18306; Tue, 5 Aug 1997 08:53:30 -0400 Message-Id: <9708051253.AA18306@wasted.zk3.dec.com> To: "Mike O'Dell" Cc: bound@zk3.dec.com, Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 4261) Re: W.G. Last Call on Addressing and IPv6_over_ Documents In-Reply-To: Your message of "Tue, 05 Aug 1997 06:11:00 -0400." Date: Tue, 05 Aug 1997 08:53:29 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1264 >no sarcasm implied at all. OK... My apologies... I will be more careful of your mail next time. >you indicated you thought a TLA must provide "native IPv6 service" > >I was disagreeing (with you and the draft) OK just to make sure I am in synch: Draft in question is: draft-ietf-ipngwg-tla-assignment-00.txt Words in question are: >- Must have a plan to offer public native IPv6 service within 6 > months from assignment. The plan must include plan for NLA ID > allocation. What I interpret Native to mean here is that the org getting the TLA MUST provide support for routing IPv6 packets from subscribers or a plan to do so within 6 months. And NLA ID allocation I don't think anyone should get a TLA unless they are going to use IPv6 as a native service? Why else would anyone want a TLA? So I am not sure what your objecting to or why? thanks /jim -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 5 06:25:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA19644; Tue, 5 Aug 1997 06:14:34 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA19637; Tue, 5 Aug 1997 06:14:23 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA26311; Tue, 5 Aug 1997 06:16:47 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA04678 for ; Tue, 5 Aug 1997 06:16:50 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id JAA22140; Tue, 5 Aug 1997 09:05:17 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA19231; Tue, 5 Aug 1997 09:05:08 -0400 Message-Id: <9708051305.AA19231@wasted.zk3.dec.com> To: Ray Hunter Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4262) Re: W.G. Last Call on Addressing and IPv6_over_ In-Reply-To: Your message of "Tue, 05 Aug 1997 13:40:39 +0200." <3.0.1.32.19970805134039.0071d4a0@hades.mpn.cp.philips.com> Date: Tue, 05 Aug 1997 09:05:08 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 435 ray that was very cool... I wish more did this... /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 5 06:26:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA19653; Tue, 5 Aug 1997 06:15:07 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA19646; Tue, 5 Aug 1997 06:14:50 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA26360; Tue, 5 Aug 1997 06:17:14 -0700 Received: from hursley.ibm.com (mersey.hursley.ibm.com [194.196.110.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA04796 for ; Tue, 5 Aug 1997 06:17:16 -0700 Received: by hursley.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA44678; Tue, 5 Aug 1997 14:17:14 +0100 Date: Tue, 5 Aug 1997 14:17:14 +0100 Message-Id: <9708051317.AA44678@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 4263) re draft-ietf-ipngwg-icmp-name-lookups-01.txt To: ipng@sunroof.eng.sun.com Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1241 Matt, re draft-ietf-ipngwg-icmp-name-lookups-01.txt You state that the icmp reply cannot be trusted. Actually I'm not sure - if we postulate that we know a public key for www.ibm.com, then the icmp reply could be authenticated with the corresponding private key. (Specifically, it's a public key associated with the DNS name that we need, not an IPSEC key. Using IPSEC to authenticate the icmp reply validates that it comes from the IP address you queried, but provides no proof whatever that the host is telling the truth about its DNS name.) Presumably the third party authentication mechanism that you hint at would be to ask DNS to resolve the name and see if you get the same IP address back. Unfortunately, even if you trust DNS, there are several scenarios where the IP address will quite legitimately *not* be the same. Then what? Brian Carpenter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 5 07:59:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA19804; Tue, 5 Aug 1997 07:51:09 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA19797; Tue, 5 Aug 1997 07:51:01 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA22663; Tue, 5 Aug 1997 07:53:26 -0700 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA06168 for ; Tue, 5 Aug 1997 07:53:27 -0700 Received: from [171.69.116.90] ([171.69.116.90]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id HAA05128; Tue, 5 Aug 1997 07:53:23 -0700 X-Sender: deering@cheerios.cisco.com Message-Id: In-Reply-To: <9708051317.AA44678@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Aug 1997 07:53:16 -0700 To: brian@hursley.ibm.com From: Steve Deering Subject: (IPng 4264) Re: re draft-ietf-ipngwg-icmp-name-lookups-01.txt Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1280 At 6:17 AM -0700 8/5/97, (Brian E Carpenter) wrote: > You state that the icmp reply cannot be trusted. Actually > I'm not sure - if we postulate that we know a public key > for www.ibm.com, then the icmp reply could be authenticated > with the corresponding private key. (Specifically, it's > a public key associated with the DNS name that we need, > not an IPSEC key. Using IPSEC to authenticate the icmp reply > validates that it comes from the IP address you queried, > but provides no proof whatever that the host is telling > the truth about its DNS name.) Brian, The sources athenticated by IPSEC may be entities other than IP addresses. If the private key belonging to a DNS name is used to sign (via an AH header) an ICMP message, then the public key of that DNS name can be used by the receiver to verify that the message came from an entity that possesses the name's private key. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 5 11:00:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA20237; Tue, 5 Aug 1997 10:47:11 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA20230; Tue, 5 Aug 1997 10:47:05 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id KAA01033 for ; Tue, 5 Aug 1997 10:49:33 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA01168; Tue, 5 Aug 1997 10:47:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA20213; Tue, 5 Aug 1997 10:45:00 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA06879; Tue, 5 Aug 1997 10:47:23 -0700 Received: from sol.extremenetworks.com (extremenetworks.com [207.94.36.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA06935 for ; Tue, 5 Aug 1997 10:47:11 -0700 Received: by SOL with Internet Mail Service (5.0.1457.3) id ; Tue, 5 Aug 1997 10:45:39 -0700 Message-ID: <116F1CE887F8CF118E2300A0C91368E6249312@SOL> From: Andrew Smith To: Paul Ferguson Cc: ipng@sunroof.eng.sun.com, rt@dla1.dl.ac.uk Subject: (IPng 4266) RE: Comment: IPv6 over FDDI - user_priority Date: Tue, 5 Aug 1997 10:45:38 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3522 FYI, Actually the updated title and URL for the current version of that draft is: "Integrated Service Mappings on IEEE 802 Networks" ftp://ds.internic.net/internet-drafts/draft-ietf-issll-is802-svc-mapping -00.txt This work is complementary to what you are trying to do with these IPv6 packets and the draft does not really discuss "important" data - it focuses more on support for the current int-serv models. Thanks, Andrew *********************************************************************** Andrew Smith tel: +1 (408) 863-2821 Extreme Networks fax: +1 (408) 342-0990 10460 Bandley Drive http://www.extremenetworks.com Cupertino CA 95014 em: andrew@extremenetworks.com *********************************************************************** > ---------- > From: Paul Ferguson[SMTP:pferguso@cisco.com] > Sent: Tuesday, August 05, 1997 3:04 AM > To: Robin Tasker > Cc: crawdad@fnal.gov; ipng@sunroof.Eng.Sun.COM; rt@dla1.dl.ac.uk; > issll@mercury.lcs.mit.edu > Subject: Re: (IPng 4257) Comment: IPv6 over FDDI - user_priority > > As an aside, it might be worthwhile to also note that some > complimentary work has been drafted in the same vein, albeit > with regards to IPv4 and Integrated Services: > > Integrated Services over IEEE 802.1D/802.1p Networks > draft-ietf-issll-802-01.txt > > This draft provides a proposal to map user_priority > values carried in 802.1p to one of the integrated service > classes: > > [snip] > > Proposal: A Simple Scheme > > user_priority Service > 0 "less than" Best Effort > 1 Best Effort > 2 reserved > 3 reserved > 4 Controlled Load > 5 Guaranteed Service, 100ms bound > 6 Guaranteed Service, 10ms bound > 7 reserved > > [snip] > > FYI, > > - paul > > At 10:06 AM 08/05/97 +0100, Robin Tasker wrote: > > >Matt > > > >Just reading IPv6 over FDDI ID > (draft-ietf-ipngwg-trans-fddi-net-02.txt), > >the discussion in Section 4 (Interaction with Bridges) talks about > FDDI > >adjacency detection. This is achieved by sending a non-zero LLC > priority > >which is, in IEEE 802 language, the user_priority parameter of the > >M.UNITDATA.request primitive set to non-zero. This relates to > Neighbor > >Solicitation, Neighbor Advertisement and Router Advertisement frames. > > > >IEEE 802.1 is near to completing 802.1p which defines mechanisms to > provide > >traffic classes in bridges/switches and therefore prioritised traffic > flows > >in bridged networks. The use of the user_priority parameter is > central to > >this work. > > > >The proposal in the above ID does not impinge on this work; these > frames are > >"managing the network" and so need a good priority. However it makes > sense > >to define the level of user priority to be used rather than leaving > it > >unspecified as non-zero. The use of user_priority = 7 (the best you > can have) > >would seem to be a good value. > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 5 15:01:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA20637; Tue, 5 Aug 1997 14:51:17 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA20630; Tue, 5 Aug 1997 14:51:09 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA11984; Tue, 5 Aug 1997 14:53:32 -0700 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA00262; Tue, 5 Aug 1997 14:53:32 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id RAA15386; Tue, 5 Aug 1997 17:50:58 -0400 Date: Tue, 5 Aug 1997 17:50:58 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <970805175058.ZM15384@seawind.bellcore.com> In-Reply-To: bound@zk3.dec.com "(IPng 4261) Re: W.G. Last Call on Addressing and IPv6_over_ Documents" (Aug 5, 8:53am) References: <9708051253.AA18306@wasted.zk3.dec.com> X-Mailer: Z-Mail (4.0.1 13Jan97) To: bound@zk3.dec.com, "Mike O'Dell" Subject: (IPng 4267) Re: W.G. Last Call on Addressing and IPv6_over_ Documents Cc: Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1375 > Draft in question is: > > draft-ietf-ipngwg-tla-assignment-00.txt > > Words in question are: > > >- Must have a plan to offer public native IPv6 service within 6 > > months from assignment. The plan must include plan for NLA ID > > allocation. > I don't think anyone should get a TLA unless they are going to use IPv6 > as a native service? I tend to agree. Getting a TLA is a large commitment of public resource, the addressing plan. To get that, providers should be ready to show some sign of good will. But then, there is a classic objection. The IETF may spec the border but has no business specking the plumbing. If Mike wants to use a large flock of carrier pigeons inside his IPv6 network, he is perfectly entitled to do so. "Native" should be understoud (or rewritten) to mean "native IPv6 connections", through the border, rather than "IPv6 over SONET inside the network." Native, at the border, means one of the standard IPv6 encapsulations. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 5 15:56:52 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA20770; Tue, 5 Aug 1997 15:47:24 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA20763; Tue, 5 Aug 1997 15:47:15 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA26245; Tue, 5 Aug 1997 15:49:39 -0700 Received: from relay4.UU.NET (relay4.UU.NET [192.48.96.14]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA17461; Tue, 5 Aug 1997 15:49:36 -0700 Received: from rodan.UU.NET by relay4.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQdbip25838; Tue, 5 Aug 1997 18:49:19 -0400 (EDT) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQdbip21500; Tue, 5 Aug 1997 18:49:17 -0400 (EDT) Message-Id: To: huitema@bellcore.com (Christian Huitema) cc: bound@zk3.dec.com, "Mike O'Dell" , Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com, mo@UU.NET Subject: (IPng 4268) Re: W.G. Last Call on Addressing and IPv6_over_ Documents In-reply-to: Your message of "Tue, 05 Aug 1997 17:50:58 EDT." <970805175058.ZM15384@seawind.bellcore.com> Date: Tue, 05 Aug 1997 18:49:16 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 445 IPv6-in-IPv4 is one of the standard encapsulations, right? -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 5 20:21:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA21171; Tue, 5 Aug 1997 20:13:04 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA21164; Tue, 5 Aug 1997 20:12:55 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA11383; Tue, 5 Aug 1997 20:15:19 -0700 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id UAA20793; Tue, 5 Aug 1997 20:15:20 -0700 Received: from wasted.zk3.dec.com (brywasted.zk3.dec.com [16.141.40.4]) by mail11.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id XAA28276; Tue, 5 Aug 1997 23:08:53 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA26082; Tue, 5 Aug 1997 23:03:50 -0400 Message-Id: <9708060303.AA26082@wasted.zk3.dec.com> To: huitema@bellcore.com (Christian Huitema) Cc: bound@zk3.dec.com, "Mike O'Dell" , Erik.Nordmark@Eng (Erik Nordmark), ipng@sunroof.eng.sun.com Subject: (IPng 4270) Re: W.G. Last Call on Addressing and IPv6_over_ Documents In-Reply-To: Your message of "Tue, 05 Aug 1997 17:50:58 -0400." <970805175058.ZM15384@seawind.bellcore.com> Date: Tue, 05 Aug 1997 23:03:50 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 812 >The IETF may spec the border but has no business specking the plumbing. > If Mike wants to use a large flock of carrier pigeons inside his IPv6 >network, he is perfectly entitled to do so. "Native" should be understoud >(or rewritten) to mean "native IPv6 connections", through the border, >rather than "IPv6 over SONET inside the network." > >Native, at the border, means one of the standard IPv6 encapsulations. I agree. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 6 06:57:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA21733; Wed, 6 Aug 1997 06:49:27 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA21726; Wed, 6 Aug 1997 06:49:19 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA08355; Wed, 6 Aug 1997 06:51:42 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA08188 for ; Wed, 6 Aug 1997 06:51:43 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id JAA19778; Wed, 6 Aug 1997 09:42:54 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA30794; Wed, 6 Aug 1997 09:42:50 -0400 Message-Id: <9708061342.AA30794@wasted.zk3.dec.com> To: set@thumper.bellcore.com, narten@vnet.ibm.com Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4271) Addrconf Changes Date: Wed, 06 Aug 1997 09:42:50 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2131 Sue and Tom, Per addr conf changes you still do not have consensus on RA life=0. So we need to still discuss but I see you changed the spec??? But also... >5.5.4. Address Lifetime Expiry > > A preferred address becomes deprecated when its preferred lifetime > expires. A deprecated address SHOULD continue to be used as a source > address in existing communications, but SHOULD NOT be used in new > communications if an alternate (non-deprecated) address is available | > and has sufficient scope. IP and higher layers (e.g., TCP, UDP) MUST | > continue to accept datagrams destined to a deprecated address since a > deprecated address is still a valid address for the interface. An > implementation MAY prevent any new communication from using a > deprecated address, but system management MUST have the ability to | > disable such a facility, and the facility MUST be disabled by | > default. You did not discuss this with WG as I recall? I think you should have before changing the spec as a courteousy. But I want it back the way it was. I don't believe "MAY" is a message for users to not permit deprecated addresses to stop all communications. I would argue that the way it was worded as a SHOULD is fine and sends a clear message. I think we need to have a discussion of the use of deprecated before you cast this in stone. I think this change was unecessary and I saw no discussion on the maiil list about it. So why did you change a spec that is PS without any public discussion as you did for RA life=0 issue? This change is not trivial IMHO and I want to question your order here? Unfortuneately I am off to Europe today and it will have to happen for me at the IETF meeting. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 6 07:51:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA21845; Wed, 6 Aug 1997 07:43:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA21838; Wed, 6 Aug 1997 07:43:01 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA25526; Wed, 6 Aug 1997 07:45:26 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA24332 for ; Wed, 6 Aug 1997 07:45:26 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA09674; Wed, 6 Aug 1997 09:44:40 -0500 Message-Id: <199708061444.JAA09674@gungnir.fnal.gov> To: Robin Tasker Cc: Andrew Smith , p8021@hepnrc.hep.net, Paul Ferguson , issll@mercury.lcs.mit.edu, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4273) Re: IPv6 over FDDI - user_priority In-reply-to: Your message of Tue, 05 Aug 1997 09:45:18 BST. <199708050845.JAA11074@dla1.dl.ac.uk> Date: Wed, 06 Aug 1997 09:44:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2558 Robin, Andrew, et al., > >I'd suggest some comment to that WG mailing list along the > >lines of "pick one priority" not just "non-zero". We could > >maybe suggest that they recommend user_priority=7 in all > >IPv6 over 802.X documents. > > Thanks for the response. I will send something to the IPng list on this > subject - your suggestion sounds OK to me. If you could talk to the > people at the IETF that would be useful. Mat Crawford, the author of > the document, is your man. And is also a lurker on the p8021 list. I'd've piped up earlier, but I just got back from vacation. Let me just provide a little background for those not following IPv6 work. ... Some 802.1 bridges have a little bit of IPv4 smarts to enable them to do fragmentation. Historically, some have gotten the details wrong. And some still don't support "path MTU discovery" correctly. In IPv6, intermediate nodes (typically routers) do not do fragmentation; only the source node does. Also, I expect that any support in bridges for the IPv6 version of path MTU discovery would be slow in coming. Therefore, I want to sidestep potential deployment problems by eliminating any reason for bridges to understand IPv6. In a bridged mixed-media network, taking FDDI+Ethernet as an example, IPv6 routers would advertise the lowest MTU of all the connected media, and nodes could use the higher FDDI MTU if they detect that their peer is connected through an FDDI path. This detection consists of receiving certain types of "neighbor discovery" frames with non-zero priority. I'm relying on bridges to set the user_priority to 0 in frames (at least, in IPv6 frames) they forward from Ethernet to FDDI. Is there anything afoot in 802.1p or q which would invalidate my assumption? I'd be happy to change "non-zero" to some specific value for sending neighbor discovery packets on FDDI, with the concurrence of 802.1 and the IETF issll WG. Andrew, the ipng working group doesn't meet until Wednesday, which is also the WG last call end date on this document. Let's get together before that. You can find me at the reception Sunday night or leave me a message on the board. Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 6 08:52:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA22069; Wed, 6 Aug 1997 08:44:03 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA22060; Wed, 6 Aug 1997 08:43:56 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id IAA11112 for ; Wed, 6 Aug 1997 08:46:23 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA03701; Wed, 6 Aug 1997 08:44:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA21103; Tue, 5 Aug 1997 18:36:05 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA00394; Tue, 5 Aug 1997 18:38:28 -0700 Received: from ceres.backyard.wide.toshiba.co.jp (ceres.wide.toshiba.co.jp [202.249.10.113]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA01848; Tue, 5 Aug 1997 18:38:29 -0700 Received: (from mailer@localhost) by ceres.backyard.wide.toshiba.co.jp (8.8.4/8.8.4) id KAA17896; Wed, 6 Aug 1997 10:49:20 +0900 (JST) Received: from samber.backyard.wide.toshiba.co.jp(133.196.2.11) by ceres.backyard.wide.toshiba.co.jp via smap (V1.3) id sma017894; Wed Aug 6 10:49:03 1997 Received: from brian.backyard.wide.toshiba.co.jp (root@brian.backyard.wide.toshiba.co.jp [133.196.2.32]) by samber.backyard.wide.toshiba.co.jp (8.8.4/8.8.4) with ESMTP id KAA29188; Wed, 6 Aug 1997 10:39:05 +0900 (JST) To: Erik.Nordmark@Eng Cc: ipng@sunroof.eng.sun.com, narten@raleigh.ibm.com Subject: (IPng 4274) Re: New draft of Neighbor Discovery specification In-Reply-To: Your message of "Wed, 30 Jul 1997 17:38:26 -0700" References: <199707310038.RAA18296@bobo.eng.sun.com> X-Mailer: Mew version 1.85 on Emacs 19.34.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19970806103451P.jinmei@backyard.wide.toshiba.co.jp> Date: Wed, 06 Aug 1997 10:34:51 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= X-Dispatcher: imput version 970701 Lines: 39 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1980 >>>>> On Wed, 30 Jul 1997 17:38:26 -0700, >>>>> Erik.Nordmark@Eng.Sun.COM (Erik Nordmark) said: > The document has a list of changes since RFC 1970 at the end In this list, I saw the following statement: o Updated the text in section 4.4 to clearly state that an NA must | contain a target link-layer address when the NS was multicast in | order to avoid a potential NS "war" where neither side is able to | send a NA because neither ever obtains the link-layer address of | its peer. | But in section 4.4, the statement simply says that sender of the advertisement. MUST be included on | link layers that have addresses. The link-layer | That is, the word "multicast" isn't explicitly used. And there is a statement in section 7.2.4, which seems to be inconsistent with the above statement: of the solicitation. If the solicitation's IP Destination Address is a unicast or anycast address, the Target Link-Layer Address option SHOULD NOT be included; the neighboring node's cached value must What should we do when sending a Neighbor Advertisement responding to a unicast/anycast Neighbor solicitation? Should we include the target link-layer address option or not? IMO, If we shouldn't then the statement in section 4.4 should explicitly say that it's applied only when NS was multicast. Regards, JINMEI, Tatuya Comm. and Info. Systems Research Labs. Toshiba R&D Center jinmei@backyard.wide.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 6 09:46:13 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA22240; Wed, 6 Aug 1997 09:35:23 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA22233; Wed, 6 Aug 1997 09:35:14 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA21949; Wed, 6 Aug 1997 09:37:40 -0700 Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id JAA02933 for ; Wed, 6 Aug 1997 09:37:37 -0700 Received: from rsm.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.8.5/8.8.5) with SMTP id SAA29071 for ; Wed, 6 Aug 1997 18:37:35 +0200 Received: from bloodmoney by rsm.enst-bretagne.fr (4.1/SMI-4.1) id AA13712; Wed, 6 Aug 97 18:37:35 +0200 Message-Id: <33E8A84B.695678E2@rennes.enst-bretagne.fr> Date: Wed, 06 Aug 1997 18:37:31 +0200 From: Laurent Toutain Organization: =?iso-8859-1?Q?T=E9l=E9com?= Bretagne X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 4275) 6 sec period Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1333 Hi, in draft-ietf-ipngwg-ipv6-spec-v2-00.txt, it is writen | Cached flow-handling state that is set up opportunistically, as | discussed in the preceding paragraph, must be discarded no more than | 6 seconds after it is established, regardless of whether or not | packets of the same flow continue to arrive. If another packet with | the same source address and flow label arrives after the cached state | has been discarded, the packet undergoes full, normal processing (as | if its flow label were zero), which may result in the re-creation of | cached flow state for that flow. If I undertand this paragraph, it means that every 6 sec, even if the flow is active, the router must look at the routing table, and process the packet. Why a 6 sec period have been chosen ? I think this behavior will introduce jitter in the flow since the processing time for packets will not be the same. Laurent Toutain -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 6 14:00:15 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA22639; Wed, 6 Aug 1997 13:50:53 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA22632; Wed, 6 Aug 1997 13:50:47 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id NAA27891 for ; Wed, 6 Aug 1997 13:53:15 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA04354; Wed, 6 Aug 1997 13:51:18 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA22615; Wed, 6 Aug 1997 13:43:54 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA28218; Wed, 6 Aug 1997 13:46:21 -0700 Received: from sol.extremenetworks.com (extremenetworks.com [207.94.36.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA00092 for ; Wed, 6 Aug 1997 13:46:16 -0700 Received: by SOL with Internet Mail Service (5.0.1457.3) id ; Wed, 6 Aug 1997 13:45:01 -0700 Message-ID: <116F1CE887F8CF118E2300A0C91368E6254007@SOL> From: Andrew Smith To: Matt Crawford Cc: p8021@hepnrc.hep.net, issll@mercury.lcs.mit.edu, ipng@sunroof.eng.sun.com Subject: (IPng 4277) RE: IPv6 over FDDI - user_priority Date: Wed, 6 Aug 1997 13:44:59 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2435 Matt, > ---------- > From: Matt Crawford[SMTP:crawdad@fnal.gov] > Sent: Wednesday, August 06, 1997 7:44 AM > To: Robin Tasker > Cc: Andrew Smith; p8021@hepnrc.hep.net; Paul Ferguson; > issll@mercury.lcs.mit.edu; ipng@sunroof.Eng.Sun.COM > Subject: Re: IPv6 over FDDI - user_priority > > In a bridged mixed-media network, taking FDDI+Ethernet as an example, > IPv6 routers would advertise the lowest MTU of all the connected > media, and nodes could use the higher FDDI MTU if they detect that > their peer is connected through an FDDI path. This detection > consists of receiving certain types of "neighbor discovery" frames > with non-zero priority. I'm relying on bridges to set the > user_priority to 0 in frames (at least, in IPv6 frames) they forward > from Ethernet to FDDI. > > Is there anything afoot in 802.1p or q which would invalidate my > assumption? I think that you will find bridges forwarding Tagged 802.1p packets including non-zero user_priority values onto Untagged FDDI. According to the current 802.1p defaults, the FDDI FC byte would then, by default, encode the user_priority received from the incoming 802.1p header (modulo the fact that it collapes 6->6 and 7->6 also). I believe this would invalidate your assumption. In general, I'm not sure that use of user_priority as an indicator of end-to-end media type (and hence MTU capabilities) is a good approach. In particular, 802.1 has always endeavoured to make everything media- independent (we fail quite often but that doesn't stop us trying :-)) which is kind of opposite to what you were hoping for, I believe. > Matt Crawford > Andrew *********************************************************************** Andrew Smith tel: +1 (408) 863-2821 Extreme Networks fax: +1 (408) 342-0990 10460 Bandley Drive http://www.extremenetworks.com Cupertino CA 95014 em: andrew@extremenetworks.com *********************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 6 17:42:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA23234; Wed, 6 Aug 1997 17:31:07 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA23227; Wed, 6 Aug 1997 17:30:55 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA26377; Wed, 6 Aug 1997 17:33:21 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA18207 for ; Wed, 6 Aug 1997 17:33:22 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id TAA11605; Wed, 6 Aug 1997 19:33:19 -0500 Message-Id: <199708070033.TAA11605@gungnir.fnal.gov> To: Steve Deering Cc: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4278) Re: Routing header's Strict/Loose Bit Map In-reply-to: Your message of Mon, 28 Jul 1997 11:36:02 PDT. Date: Wed, 06 Aug 1997 19:33:19 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 914 I know Steve is already off the air until next week, but here's my take on this stale subject. (I'm trying to catch up on email.) The Routing Header blurs the distinction between hosts and routers. If hosts are to forward packets based on the RH, you can say that the RH constitutes explicit addressing to the host and keep the existing definition uninjured. I suggest that the rule be: Routers must obey the strict/loose bit; hosts need not. I think this neatly finesses the question at a very low implementation cost. Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 6 18:49:30 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA23354; Wed, 6 Aug 1997 18:41:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA23347; Wed, 6 Aug 1997 18:41:15 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA08719; Wed, 6 Aug 1997 18:43:40 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id SAA06302 for ; Wed, 6 Aug 1997 18:43:42 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id UAA11973; Wed, 6 Aug 1997 20:43:25 -0500 Message-Id: <199708070143.UAA11973@gungnir.fnal.gov> To: Andrew Smith Cc: p8021@hepnrc.hep.net, issll@mercury.lcs.mit.edu, ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4279) Re: IPv6 over FDDI - user_priority In-reply-to: Your message of Wed, 06 Aug 1997 13:44:59 PDT. <116F1CE887F8CF118E2300A0C91368E6254007@SOL> Date: Wed, 06 Aug 1997 20:43:25 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 840 > According to the current 802.1p defaults, the FDDI FC byte would > then, by default, encode the user_priority received from the > incoming 802.1p header (modulo the fact that it collapes 6->6 and > 7->6 also). I believe this would invalidate your assumption. Elsewhere the constant value 7 was suggested for the priority of IPv6 ND packets. That would seem to avoid this problem very neatly. (But what's the 802.5 issue relating to the use of 7?) Matt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 7 05:57:03 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA23808; Thu, 7 Aug 1997 05:48:06 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA23801; Thu, 7 Aug 1997 05:47:56 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA03342; Thu, 7 Aug 1997 05:50:21 -0700 Received: from mserv1.dl.ac.uk (mserv1.dl.ac.uk [148.79.160.65]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA22429 for ; Thu, 7 Aug 1997 05:50:19 -0700 Received: from dla1.dl.ac.uk by mserv1.dl.ac.uk with ESMTP id NAA29434 (8.6.13/5.3[ref postmaster@dl.ac.uk] for dl.ac.uk from R.Tasker@dl.ac.uk); Thu, 7 Aug 1997 13:50:28 +0100 Received: by dla1.dl.ac.uk; id NAA12377; Thu, 7 Aug 1997 13:49:55 +0100 (BST) From: Robin Tasker Message-Id: <199708071249.NAA12377@dla1.dl.ac.uk> To: crawdad@fnal.gov cc: andrew@extremenetworks.com, p8021@hepnrc.hep.net, ipng@sunroof.eng.sun.com, rt@dla1.dl.ac.uk Subject: (IPng 4281) RE: IPv6 over FDDI - user_priority Date: Thu, 07 Aug 97 13:49:54 +0100 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2352 Matt >In a bridged mixed-media network, taking FDDI+Ethernet as an example, >IPv6 routers would advertise the lowest MTU of all the connected >media, and nodes could use the higher FDDI MTU if they detect that >their peer is connected through an FDDI path. This detection >consists of receiving certain types of "neighbor discovery" frames >with non-zero priority. I'm relying on bridges to set the >user_priority to 0 in frames (at least, in IPv6 frames) they forward >from Ethernet to FDDI. I suspect the issue is more complex than I first thought. I take the above to mean, Neighbor discovery frame transmitted from an FDDI host has a non-zero user_priority encoded in it and if received as such means both transmitter and recipient are directly connected on FDDI. If the neighbor discovery frame transits a bridge connecting different media you are expecting the user_priority encoding to be set to zero and on that basis the recipient knows that it is not directly connected by FDDI with the transmitter. Unfortunately I think the 802.1p work invalidates this operation just as Andrew has said, >I think that you will find bridges forwarding Tagged 802.1p packets >including non-zero user_priority values onto Untagged FDDI. According >to the current 802.1p defaults, the FDDI FC byte would then, by default, >encode the user_priority received from the incoming 802.1p header (modulo >the fact that it collapes 6->6 and 7->6 also). So just choosing a non-zero value won't work either as it will not necessarily distinguish the two cases. I'm coming to conclusion that using this field for something other that what it was intended isn't a good approach. Now that's a pity as interconnection across different media is vital (essential) and maybe bridges are just going to have do "path MTU discovery" to get round this problem. Customers aren't going to like IPv6 if it doesn't work with this configuration. Anyone have other views on this subject? Robin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 7 06:35:22 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA23834; Thu, 7 Aug 1997 06:27:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA23827; Thu, 7 Aug 1997 06:26:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA08127; Thu, 7 Aug 1997 06:29:16 -0700 Received: from mailhost2.BayNetworks.COM (ns1.BayNetworks.COM [134.177.3.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id GAA01752 for ; Thu, 7 Aug 1997 06:29:17 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost2.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id GAA01768 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id GAA02197 Posted-Date: Thu, 7 Aug 1997 06:28:37 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id JAA17624; Thu, 7 Aug 1997 09:28:37 -0400 for Message-Id: <3.0.32.19970807092725.00685c54@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Thu, 07 Aug 1997 09:27:26 -0400 To: "Matt Crawford" From: Dimitry Haskin Subject: (IPng 4282) Re: Routing header's Strict/Loose Bit Map Cc: Steve Deering , ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 691 At 07:33 PM 8/6/97 -0500, Matt Crawford wrote: >I suggest that the rule be: > > Routers must obey the strict/loose bit; hosts need not. > I remember a discussion on whether hosts forward source-routed packets but don't remember outcome. I believe that the latest IPv6 draft does not clarify this issue. Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 7 08:59:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA24083; Thu, 7 Aug 1997 08:49:52 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA24076; Thu, 7 Aug 1997 08:49:47 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id IAA02267 for ; Thu, 7 Aug 1997 08:52:15 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA05464; Thu, 7 Aug 1997 08:50:18 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA23789; Thu, 7 Aug 1997 04:57:09 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA29332; Thu, 7 Aug 1997 04:59:35 -0700 Received: from mail.york.proteon.com (mail.york.proteon.com [195.153.7.52]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id EAA13281 for ; Thu, 7 Aug 1997 04:59:35 -0700 Received: from lion (lion.york.proteon.com [195.153.7.53]) by mail.york.proteon.com (8.8.5/8.8.5) with SMTP id MAA03003; Thu, 7 Aug 1997 12:58:36 +0100 (BST) Received: by lion (4.1/SMI-4.1) id AA09887; Thu, 7 Aug 97 12:58:25 BST Date: Thu, 7 Aug 97 12:58:25 BST Message-Id: <9708071158.AA09887@lion> From: John Messenger To: crawdad@fnal.gov Cc: andrew@extremenetworks.com, p8021@hepnrc.hep.net, issll@mercury.lcs.mit.edu, ipng@sunroof.eng.sun.com In-Reply-To: <199708070143.UAA11973@gungnir.fnal.gov> (crawdad@fnal.gov) Subject: (IPng 4283) Re: IPv6 over FDDI - user_priority X-Attribution: John Reply-To: John.Messenger@york.proteon.com Mime-Version: 1.0 (generated by tm-edit 7.43) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2785 All, Any use of the user-priority by the receiver of a packet to infer anything else is almost bound to be fraught with problems. Its use is defined to be what it is. The other problem with choosing particular values to use for user-priority across different MAC types is that each one has its local restrictions on range, e.g., Ethernet=none; Token-ring=0..6 (but many stacks such as old NDIS/ODI just use zero); 802.12=0..1. So clearly not all MACs will allow the use of 7, say. On token ring, at least in the lastest standard, it is recommended that a user-priority of 7 is not used for LLC traffic. This is becuase *access*-priority 7 is used for critical MAC management traffic (e.g., neighbour notification), which if lost results in ring problems. Additionally there is what I interpret as an optional mechnaism (certainly no stronger) that allows stations to cap the access-priority at a level defined by "management" (the authorised access priority), and some implementations fix this at 3; however should have no effect on the end-to-end user-priority. More seriously, token ring does not mandate the end-to-end signalling of user-priority (which if done, is carried in the FC (Frame Control) octet). It must be understood that only the sender can signal the user-priority end-to-end on token ring, using the FC mechanism. Any attempt by the receiver to infer the user-priority from the received AC (Access Control) octet demonstrates a lack of understanding of the priority mechanism. [At the last count, there were at least two people in the world who understood that mechanism fully, but we can't remember who they were :-)] Matt says: > with non-zero priority. I'm relying on bridges to set the > user_priority to 0 in frames (at least, in IPv6 frames) they forward > from Ethernet to FDDI. Regardless of outgoing media type, there's not much in the bridging standard that helps you here. First, if there is an incoming user-priority (at least some FDDI and token ring), then the bridge shall use that on output (802.1D, 1993, Clause 3.7.4 (1)). Otherwise, (and this covers CMSA/CD without .1p/Q) there is a mapping table, whose default value is zero for .3,.4,.5,FDDI, but which might be set by management to another value. As Andrew Smith states, further contradictions to your assumption will probably be introduced by .1p/Q bridges. Regards, -- John Messenger -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 7 10:21:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA24297; Thu, 7 Aug 1997 10:06:21 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA24290; Thu, 7 Aug 1997 10:06:15 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id KAA11400 for ; Thu, 7 Aug 1997 10:08:42 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA05756; Thu, 7 Aug 1997 10:06:45 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA24182; Thu, 7 Aug 1997 09:59:22 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA02615; Thu, 7 Aug 1997 10:01:47 -0700 Received: from hil-img-2.compuserve.com (hil-img-2.compuserve.com [149.174.177.132]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id KAA04583 for ; Thu, 7 Aug 1997 10:01:47 -0700 Received: (from mailgate@localhost) by hil-img-2.compuserve.com (8.8.6/8.8.6/2.2) id NAA02737; Thu, 7 Aug 1997 13:01:35 -0400 (EDT) Date: Thu, 7 Aug 1997 13:01:11 -0400 From: Tony Jeffree Subject: (IPng 4285) RE: IPv6 over FDDI - user_priority To: Robin Tasker Cc: "[unknown]" , "[unknown]" , "[unknown]" , "[unknown]" , "[unknown]" Message-ID: <199708071301_MC2-1C9A-E816@compuserve.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1246 Message text written by Robin Tasker >So just choosing a non-zero value won't work either as it will not necessarily distinguish the two cases. I'm coming to conclusion that using this field= for something other that what it was intended isn't a good approach. Now that's a pity as interconnection across different media is vital (essential) and maybe bridges are just going to have do "path MTU discovery" to get round this problem. Customers aren't going to like IPv6 if it doesn't wor= k with this configuration. Anyone have other views on this subject?< Robin - I would agree that using priority as a means to signal media type is a ba= d idea. Naive question, not understanding the detail of the protocols here= - why can't this information be encoded *within* the neighbor discovery frame?? Strikes me that this is what is needed here. Regards, Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 7 10:35:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA24321; Thu, 7 Aug 1997 10:17:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA24314; Thu, 7 Aug 1997 10:17:36 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA07409; Thu, 7 Aug 1997 10:20:01 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA10683 for ; Thu, 7 Aug 1997 10:20:02 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id MAA13285; Thu, 7 Aug 1997 12:19:59 -0500 Message-Id: <199708071719.MAA13285@gungnir.fnal.gov> To: Tony Jeffree Cc: "[unknown]" , "[unknown]" From: "Matt Crawford" Subject: (IPng 4286) Re: IPv6 over FDDI - user_priority In-reply-to: Your message of Thu, 07 Aug 1997 13:01:11 EDT. <199708071301_MC2-1C9A-E816@compuserve.com> Date: Thu, 07 Aug 1997 12:19:59 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1055 > I would agree that using priority as a means to signal media type > is a bad idea. Naive question, not understanding the detail of > the protocols here - why can't this information be encoded > *within* the neighbor discovery frame?? If one node sends a packet which says "I am on FDDI" (or, more likely, "the MTU of my attached link is 4352"), and the other end receives that packet on a similar medium, they may be unaware of an intervening ethernet. Considering, for the moment, *only* FDDI and Ethernet, is there any argument against going forward with "non-zero" changed to "7"? I don't want visceral reactions, just reasons why it wouldn't work. Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 7 13:05:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24479; Thu, 7 Aug 1997 12:54:30 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24472; Thu, 7 Aug 1997 12:54:25 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id MAA03615 for ; Thu, 7 Aug 1997 12:56:52 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA06685; Thu, 7 Aug 1997 12:54:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24428; Thu, 7 Aug 1997 12:07:49 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA07771; Thu, 7 Aug 1997 12:10:13 -0700 Received: from sol.extremenetworks.com (extremenetworks.com [207.94.36.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA16989 for ; Thu, 7 Aug 1997 12:10:09 -0700 Received: by SOL with Internet Mail Service (5.0.1457.3) id ; Thu, 7 Aug 1997 12:09:06 -0700 Message-ID: <116F1CE887F8CF118E2300A0C91368E6254085@SOL> From: Andrew Smith To: Matt Crawford Cc: p8021@hepnrc.hep.net, ipng@sunroof.eng.sun.com Subject: (IPng 4289) RE: IPv6 over FDDI - user_priority Date: Thu, 7 Aug 1997 12:09:05 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1975 Actually, I think I misread 802.1p: the collapsing of 7->6 is for AC (access priority) bits, not FC. The user_priority values go through unchanged into the FC bits by default (and can be configured otherwise by management) which would lead to you seeing FC bits of all values on FDDI nets. user_priority 7 would still seem to be the least worst choice though (for FDDI). I'll let John Messenger speak for the 802.5 issues. Andrew *********************************************************************** Andrew Smith tel: +1 (408) 863-2821 Extreme Networks fax: +1 (408) 342-0990 10460 Bandley Drive http://www.extremenetworks.com Cupertino CA 95014 em: andrew@extremenetworks.com *********************************************************************** > ---------- > From: Matt Crawford[SMTP:crawdad@fnal.gov] > Sent: Wednesday, August 06, 1997 6:43 PM > To: Andrew Smith > Cc: p8021@hepnrc.hep.net; issll@mercury.lcs.mit.edu; > ipng@sunroof.Eng.Sun.COM > Subject: Re: IPv6 over FDDI - user_priority > > > According to the current 802.1p defaults, the FDDI FC byte would > > then, by default, encode the user_priority received from the > > incoming 802.1p header (modulo the fact that it collapes 6->6 and > > 7->6 also). I believe this would invalidate your assumption. > > Elsewhere the constant value 7 was suggested for the priority of IPv6 > ND packets. That would seem to avoid this problem very neatly. > (But what's the 802.5 issue relating to the use of 7?) > > Matt > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 7 13:07:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24502; Thu, 7 Aug 1997 12:55:55 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24495; Thu, 7 Aug 1997 12:55:48 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id MAA03721 for ; Thu, 7 Aug 1997 12:58:15 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA06714; Thu, 7 Aug 1997 12:56:19 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA24445; Thu, 7 Aug 1997 12:19:39 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA10517; Thu, 7 Aug 1997 12:22:02 -0700 Received: from sol.extremenetworks.com (extremenetworks.com [207.94.36.2]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA20439 for ; Thu, 7 Aug 1997 12:22:04 -0700 Received: by SOL with Internet Mail Service (5.0.1457.3) id ; Thu, 7 Aug 1997 12:21:01 -0700 Message-ID: <116F1CE887F8CF118E2300A0C91368E625408A@SOL> From: Andrew Smith To: Matt Crawford Cc: ipng , "P802.1" Subject: (IPng 4290) Re: IPv6 over FDDI - user_priority Date: Thu, 7 Aug 1997 12:21:00 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2259 Matt, Of course if one node sends a packet which says "I am on FDDI" which also happens to be, say, 4351 bytes long, the receiver would be aware of any intervening ethernet. But I don't think the whole thing would work 100% reliably with the presence of 802.1p on FDDI as I described in an earlier message, although it might be "good enough". But that to me doesn't sound like the sort of solution that IETF should be using in its proposed standards, particularly one as fundemental as IPv6. Andrew *********************************************************************** Andrew Smith tel: +1 (408) 863-2821 Extreme Networks fax: +1 (408) 342-0990 10460 Bandley Drive http://www.extremenetworks.com Cupertino CA 95014 em: andrew@extremenetworks.com *********************************************************************** > ---------- > From: Matt Crawford[SMTP:crawdad@fnal.gov] > Sent: Thursday, August 07, 1997 10:19 AM > To: Tony Jeffree > Cc: [unknown]; [unknown] > Subject: Re: (IPng 4277) RE: IPv6 over FDDI - user_priority > > > I would agree that using priority as a means to signal media type > > is a bad idea. Naive question, not understanding the detail of > > the protocols here - why can't this information be encoded > > *within* the neighbor discovery frame?? > > If one node sends a packet which says "I am on FDDI" (or, more > likely, "the MTU of my attached link is 4352"), and the other > end receives that packet on a similar medium, they may be unaware > of an intervening ethernet. > > Considering, for the moment, *only* FDDI and Ethernet, is there > any argument against going forward with "non-zero" changed to "7"? > I don't want visceral reactions, just reasons why it wouldn't work. > > Matt Crawford > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 7 14:30:47 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA24776; Thu, 7 Aug 1997 14:17:53 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA24769; Thu, 7 Aug 1997 14:17:45 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA06866; Thu, 7 Aug 1997 14:20:11 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA25054 for ; Thu, 7 Aug 1997 14:20:11 -0700 Received: by mail3.microsoft.com with Internet Mail Service (5.0.1459.27) id ; Thu, 7 Aug 1997 14:23:33 -0700 Message-ID: From: Richard Draves To: "'IPng List'" Cc: "'Thomas Narten'" , "'Erik Nordmark'" Subject: (IPng 4291) comments on draft-ietf-ipngwg-discovery-v2-00 Date: Thu, 7 Aug 1997 14:20:08 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3976 I read the entire draft and have a few comments. Section 6.2.6 - The first sentence of the new paragraph seems to make the next paragraph redundant? Section 7.2.4 - Says that the Target Link-Layer Address option SHOULD NOT be included when the solicitation's destination is a unicast or anycast address. However section 4.4 says (correctly I believe) that the Target Link-Layer Address option MUST always be included. I believe section 7.2.4 should have an added paragraph that clarifies that the sender should do when sending a solicited Neighbor Advertisement and the sender has no link-layer address cached. It may be obvious to some people that the sender should perform ND to send the NA, but that is not obvious to me. (And I think it's undesirable behavior.) This situation can arise because Neighbor Solicitations do not necessarily have a Source Link-Layer Address option. Section 7.2.5 - looks good (but see next point). Section 7.2.6 - Given the revisions in 7.2.5, there's a problem with unsolicited Neighbor Advertisements. The spec says that the Override flag MAY be set to zero or one because in either case, the recipient will change state to STALE. This is no longer true. With the new rules, an unsolicited NA with Override=zero and new/different link-layer address will have no effect. It's possible to fix this by making 7.2.5 more complicated, in the following case: When receiving an NA when current state is not INCOMPLETE, Override=zero, target link-layer address is different from cached link-layer address, THEN - if Solicited=one, then there's something bogus going on - ignore the NA. otherwise: - do not update cached link-layer address, do not update IsRouter - if state is REACHABLE, change to STALE - if state is STALE, DELAY, or PROBE, do not update the state With this change, unsolicited NA do not prevent NUD but they can still be used to prompt NUD. Appendix A - Won't multihomed hosts be very common? Any dual-stack host that implements 6-over-4 is multihomed. If this will be common, then source address selection & multihoming need more thought. Appendix D - looks good. Finally I have a concern with "dead gateway detection". As I understand it, when a router is administratively configured to stop routing, the idea is that NUD will notice that the node is no longer a router because IsRouter will change from true to false and this will cause the Destination Cache to be updated. However, suppose there is an ongoing TCP connection (or some other higher-level protocol that can provide reachability confirmation) to the erstwhile router's link-local address. The implicit reachability confirmations will prevent explicit NUD probes, and so the IsRouter flag will never get updated and the connections that were routed through the erstwhile router will never recover. I have various ideas but how to fix this (assuming that it's considered a problem worth fixing). One idea is to use two Neighbor Cache Entries for a neighbor router's link-local address - one NCE when using it in it's capacity as a router, and another NCE when sending to the router itself. This way NUD with the first NCE will confirm that the router is still routing and NUD with the second NCE will not get in the way. A second idea assumes that the router, when it stops routing, will send ICMP error messages (type 1, code 3) when it receives packets that are no longer addressed to itself. The recipient of such ICMP error messages can use them as a negative reachability indication and transition its NCE for the router to the STALE state (if it's REACHABLE). Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 7 14:39:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA24803; Thu, 7 Aug 1997 14:25:33 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA24796; Thu, 7 Aug 1997 14:25:22 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA08699; Thu, 7 Aug 1997 14:27:46 -0700 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.23]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id OAA27359 for ; Thu, 7 Aug 1997 14:27:46 -0700 Received: by mail3.microsoft.com with Internet Mail Service (5.0.1459.27) id ; Thu, 7 Aug 1997 14:31:08 -0700 Message-ID: From: Richard Draves To: "'IPng List'" Cc: "'Thomas Narten'" , "'Erik Nordmark'" Subject: (IPng 4292) RE: comments on draft-ietf-ipngwg-discovery-v2-00 Date: Thu, 7 Aug 1997 14:27:32 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2153 > Finally I have a concern with "dead gateway detection". As I > understand it, when a router is administratively configured to stop > routing, the idea is that NUD will notice that the node is no longer a > router because IsRouter will change from true to false and this will > cause the Destination Cache to be updated. > > However, suppose there is an ongoing TCP connection (or some other > higher-level protocol that can provide reachability confirmation) to > the erstwhile router's link-local address. The implicit reachability > confirmations will prevent explicit NUD probes, and so the IsRouter > flag will never get updated and the connections that were routed > through the erstwhile router will never recover. > > I have various ideas but how to fix this (assuming that it's > considered a problem worth fixing). One idea is to use two Neighbor > Cache Entries for a neighbor router's link-local address - one NCE > when using it in it's capacity as a router, and another NCE when > sending to the router itself. This way NUD with the first NCE will > confirm that the router is still routing and NUD with the second NCE > will not get in the way. > > A second idea assumes that the router, when it stops routing, will > send ICMP error messages (type 1, code 3) when it receives packets > that are no longer addressed to itself. The recipient of such ICMP > error messages can use them as a negative reachability indication and > transition its NCE for the router to the STALE state (if it's > REACHABLE). > The second idea doesn't quite work as stated - even if you transition to STALE, an implicit reachability confirmation can put the NCE right back to REACHABLE. The NCE has to transition to PROBE to force a Neighbor Solicitation to be sent. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 7 20:23:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA25396; Thu, 7 Aug 1997 20:11:28 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id UAA25389; Thu, 7 Aug 1997 20:11:19 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id UAA11602; Thu, 7 Aug 1997 20:13:47 -0700 Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.29]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id UAA20654 for ; Thu, 7 Aug 1997 20:13:48 -0700 Received: by mail4.microsoft.com with Internet Mail Service (5.0.1459.27) id ; Thu, 7 Aug 1997 20:14:00 -0700 Message-ID: From: Richard Draves To: "'IPng List'" , "'addrconf@cisco.com'" Subject: (IPng 4293) comments on draft-ietf-ipngwg-addrconf-v2-00 Date: Thu, 7 Aug 1997 20:12:59 -0700 X-Priority: 3 X-Mailer: Internet Mail Service (5.0.1459.27) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 569 I read the new draft, and didn't spot much. My only comment is that in section 5.5.4, the discussion in the last paragraph no longer applies given the new 2hr rules in section 5.5.3. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 8 07:56:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA26099; Fri, 8 Aug 1997 07:45:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA26092; Fri, 8 Aug 1997 07:45:20 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA21364; Fri, 8 Aug 1997 07:47:47 -0700 Received: from tbird.cc.bellcore.com (tbird.cc.bellcore.com [128.96.96.114]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA15594 for ; Fri, 8 Aug 1997 07:47:47 -0700 Received: from joker (joker.bellcore.com) by tbird.cc.bellcore.com with SMTP id AA11822 (5.67b/IDA-1.5 for ); Fri, 8 Aug 1997 10:46:57 -0400 Received: from nv-rwarnke.cc.bellcore.com by joker (4.1/4.7) id AA13114; Fri, 8 Aug 97 10:50:03 EDT Date: Fri, 8 Aug 97 10:50:02 EDT X-Station-Sent-From: joker.bellcore.com Message-Id: <3.0.16.19970808104800.432f73f8@joker.bellcore.com> X-Sender: rwarnke@joker.bellcore.com X-Mailer: Windows Eudora Pro Version 3.0 (16) To: ipng@sunroof.eng.sun.com From: Robert Warnke Subject: (IPng 4294) current status of IPv6 tunneling? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 726 What is the current status of IPv6 tunneling? I remember that at the Memphis IETF meeting the IESG wanted to form a new WG in the Internet area for tunneling in general. I looked in the Internet area but I haven't seen a new WG. Has anything happened since then? Is draft-ietf-ipngwg-ipv6-tunnel-07.txt still the latest version? Thanks Rob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 9 14:57:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA28122; Sat, 9 Aug 1997 14:46:36 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA28115; Sat, 9 Aug 1997 14:46:25 -0700 Received: from lillen ([129.157.164.21]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id OAA09899; Sat, 9 Aug 1997 14:48:46 -0700 (PDT) Date: Sat, 9 Aug 1997 14:48:40 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4296) Re: comments on draft-ietf-ipngwg-discovery-v2-00.txt To: richdr@mircosoft.com Cc: ipng@sunroof.eng.sun.com, nordmark@jurassic.eng.sun.com, narten@raleigh.ibm.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3050 > I read the entire draft and have a few comments. The comments are much appreciated. > Section 6.2.6 - The first sentence of the new paragraph seems to make > the next paragraph redundant? I guess the emphasis/repeatition isn't needed. > Section 7.2.4 - Says that the Target Link-Layer Address option SHOULD > NOT be included when the solicitation's destination is a unicast or > anycast address. However section 4.4 says (correctly I believe) that the > Target Link-Layer Address option MUST always be included. Yes. That needs to be fixed. > I believe section 7.2.4 should have an added paragraph that clarifies > that the sender should do when sending a solicited Neighbor > Advertisement and the sender has no link-layer address cached. It may be > obvious to some people that the sender should perform ND to send the NA, > but that is not obvious to me. (And I think it's undesirable behavior.) > This situation can arise because Neighbor Solicitations do not > necessarily have a Source Link-Layer Address option. It would make sense to clarify this. > Section 7.2.6 - Given the revisions in 7.2.5, there's a problem with > unsolicited Neighbor Advertisements. The spec says that the Override > flag MAY be set to zero or one because in either case, the recipient > will change state to STALE. This is no longer true. With the new rules, > an unsolicited NA with Override=zero and new/different link-layer > address will have no effect. I agree that this is a problem. Why can't we just fix it by saying: The Override flag MUST be set to one in order for the receiver to update the address in the Neighbor Cache entry. > Appendix A - Won't multihomed hosts be very common? Any dual-stack host > that implements 6-over-4 is multihomed. If this will be common, then > source address selection & multihoming need more thought. Yes, it is important. It is just out-of-scope for this particula specification. > However, suppose there is an ongoing TCP connection (or some other > higher-level protocol that can provide reachability confirmation) to the > erstwhile router's link-local address. The implicit reachability > confirmations will prevent explicit NUD probes, and so the IsRouter flag > will never get updated and the connections that were routed through the > erstwhile router will never recover. Yes, this a a (small) hole. We could, as an alternative to your fixes, say that the an upper layer reachability confirmation should not be used to update the NUD state when the IsRouter flag is set and the address that is reported reachable (i.e., the destination) is the same as the neighbor (i.e., the router's link-local address). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 9 15:00:54 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA28139; Sat, 9 Aug 1997 14:48:53 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA28132; Sat, 9 Aug 1997 14:48:38 -0700 Received: from lillen ([129.157.164.21]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id OAA10402; Sat, 9 Aug 1997 14:51:01 -0700 (PDT) Date: Sat, 9 Aug 1997 14:50:51 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4297) Re: IPv6 API update to RFC 2133 To: michaelb@stb.info.com Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1677 > I think that REQUIRING (I.e, MUST) the name lookups to be multithreaded > would be a huge win. I agree. The only problem is that the routines standardized by X/Open (gethostbyname, gethostbyaddr, getservbyname, getservbyport) does not easily allow that since they are specified to return a pointer to a static variable. > Consider a system where you have name information that can come from > a bunch of possible places -- local database, network wide database, > or the internet's DNS system. > > Consider the possibility that a system decides to put all of this > in one place; one program that gets RPC calls from all other programs > via the gethostbyname() library routine; this one program gets > updated to add new features/lookup locations. We actually already have this in Solaris. gethostbyname issues a door call to the nscd that handles the lookup and caches responses. But there is all this special code to handle the fact that the BIND resolver isn't internally multithreaded. Thus in order to prevent serializing all DNS lookups it ends up falling back on NOT using the ncsd when a DNS lookup is already pending and instead have the gethostbyname in the application process go through the resolver. It is a pain that would go away if libresolv was multithreaded. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 9 15:08:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA28149; Sat, 9 Aug 1997 14:54:01 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA28142; Sat, 9 Aug 1997 14:53:41 -0700 Received: from lillen ([129.157.164.21]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id OAA11168; Sat, 9 Aug 1997 14:56:01 -0700 (PDT) Date: Sat, 9 Aug 1997 14:55:55 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4298) Re: New Internet-Draft for Mobile IPv6 To: bound@zk3.dec.com Cc: djb@cs.cmu.edu, mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3102 Jim, I agree with your points that the specification can be clarified to specify more in detail how the binding cache works (conceptually) and the home agents interaction with ND. All good points. > Here is why: Every IPv6 implementation needs ND. Not every IPv6 > implementation needs Mobile. Its only a nice to have. What I would > like to see is a statement that says something like: > > If you support IPv6 Mobile you SHOULD (maybe even MUST if > you do this) do what this specs says. > > This is much different than: > > All IPv6 Nodes MUST support these features for Mobile. > > I would argue Mobile is not of the same mandatory nature as ND, Addr > conf, or IPsec. So I would like to see the WG ask the authors to back > off on the MUST strategy they have stated to a softer SHOULD/MUST based > on if Mobile is implemented. But if the details of my objections are > "technically" satisfied I am open to discussing this but would like to > hear others views too. > > Bottom line a compliant IPv6 node should not have to support Mobile if > Mobile is not needed. Many users/customers would also not want any > Mobile to exists at all in their environment. Note I differentiate > Mobile from Portable Laptops. The technical requirements for IPng (RFC 1726) says something (sorry, I don't have it with me on the plane) about requiring support for mobile nodes. I guess you could argue that mobile IPv6 could use the same techniques as mobile IPv4 and not require any additions to IPv6 hosts and routers. But I think the intent was that IPng should make mobility a more integral part of the Internet architecture. Thus I think it it perfectly reasonable to state that all nodes MUST support the new destination option and the conceptual binding cache since this provides much more efficient routing to mobile nodes. The current state of the draft does not require that all IPv6 nodes can be mobile nor does it require that all routers be capable of being home agent. If we really want to make mobile ip unbiqutous perhaps we should require those two as well. But currently the specification only requires what is needed to get efficient routing to and from mobile nodes. As an implementor I have a problem with the mobile ip specifications being late compared to the rest of the specification and I suspect that the first product we ship will not include any support for mobile ip. But I still think we need to figure out what the right thing is for the spec and the future Internet. Thus careful reading of the specification and also implementations of the draft are important in moving this forward. So let the requests for clarifications and fixes to the spec continue. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 9 15:25:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA28160; Sat, 9 Aug 1997 15:03:08 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA28153; Sat, 9 Aug 1997 15:02:44 -0700 Received: from lillen ([129.157.164.21]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id PAA12946; Sat, 9 Aug 1997 15:05:05 -0700 (PDT) Date: Sat, 9 Aug 1997 15:04:58 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4299) Re: IPv6 over FDDI - user_priority To: Andrew Smith Cc: Matt Crawford , p8021@hepnrc.hep.net, issll@mercury.lcs.mit.edu, ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 974 > I think that you will find bridges forwarding Tagged 802.1p packets > including > non-zero user_priority values onto Untagged FDDI. According to the > current > 802.1p defaults, the FDDI FC byte would then, by default, encode the > user_priority > received from the incoming 802.1p header (modulo the fact that it > collapes > 6->6 and 7->6 also). I believe this would invalidate your assumption. Does 802.1p address media with different MTU? Or does 802.1 assume that the problem of differing MTUs will be solved by making the bridges handle upper layer protocols such as IP? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 9 15:30:37 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA28169; Sat, 9 Aug 1997 15:07:28 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA28162; Sat, 9 Aug 1997 15:06:57 -0700 Received: from lillen ([129.157.164.21]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id PAA13823; Sat, 9 Aug 1997 15:09:16 -0700 (PDT) Date: Sat, 9 Aug 1997 15:09:09 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4300) Re: New draft of Neighbor Discovery specification To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: nordmark@jurassic.eng.sun.com, ipng@sunroof.eng.sun.com, narten@raleigh.ibm.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2013 > > The document has a list of changes since RFC 1970 at the end > > In this list, I saw the following statement: > > o Updated the text in section 4.4 to clearly state that an NA must | > contain a target link-layer address when the NS was multicast in | > order to avoid a potential NS "war" where neither side is able to | > send a NA because neither ever obtains the link-layer address of | > its peer. | Oops. We were going back and forth on that one. We ended up not changing anything - only clarifying what was already there. Thus the above item shouldn't be there. > But in section 4.4, the statement simply says that > > sender of the advertisement. MUST be included on | > link layers that have addresses. The link-layer | > > That is, the word "multicast" isn't explicitly used. And there is a > statement in section 7.2.4, which seems to be inconsistent with the > above statement: The statement in 4.4 is the correct one. > of the solicitation. If the solicitation's IP Destination Address is > a unicast or anycast address, the Target Link-Layer Address option > SHOULD NOT be included; the neighboring node's cached value must > > What should we do when sending a Neighbor Advertisement responding to > a unicast/anycast Neighbor solicitation? Should we include the target > link-layer address option or not? Always include a target link-layer address option. But the document is internally inconsistent. Thanks for pointing this out. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 9 15:32:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA28179; Sat, 9 Aug 1997 15:09:19 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA28171; Sat, 9 Aug 1997 15:08:37 -0700 Received: from lillen ([129.157.164.21]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id PAA14134; Sat, 9 Aug 1997 15:10:50 -0700 (PDT) Date: Sat, 9 Aug 1997 15:10:40 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4301) Re: Problem with _res.options in RFC 2133 To: bound@zk3.dec.com Cc: Erik Nordmark , ipng@sunroof.eng.sun.com, paul@vix.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3855 > Fix you propose for #1 and #2 are better than now I agree after working > with RFC 2133. > > But #3 is important. If we want to support #3 (multithreaded applications) perhaps we should define a gethostbyname with 3 arguments in addition (or instead of) gethostbyname2. This function would be gethostbynameafopt(host, family, options). With options being zero it does exactly what gethostbyname2 does today - just return the addresses of the specified address family. Thus gethostbynameafopt(host, AF_INET, 0) would be indentical to gethostbyname(host) and gethostbynameafopt(host, AF_INET6, 0) would just return AAAA records. Then we can define options to do things like: - map A records to IPv4-mapped IPv6 addresses. - if asking for AF_INET6 and no AAAA records are found look for A records as a fallback. - return both AAAA and A records (this would match the old hostname2addr functionality). They would all have to be returned as AF_INET6 since the hostent structure only has a single family member. - if the node does not itself have any configured IPv6 addresses do not return any AAAA records. (The latter is for what I think will be a common case with a dual implementation that is only configured with IPv4 addresses. Applications might want to use this so that connect to an IPv6 address doesn't fail immediately since the kernel can not find an IPv6 source address to use for the connection.) So my high level point is that I think we should include options as a parameter. The name of the function and, whether or not we still want a gethostbyname2, we can discuss further. > If we move a little back to the following strategy: > > gethostbyname(host) -- just does what it dose today and no more. Make sense to me. In particular I find the environment variable dangerous since it can be used to break unsuspecting applications. > gethostbyname2(host, AF_FAMILY) > > If AF_FAMILY = AF_INET > If found return IPv4 Mapped Address Why not just have it return the IPv4 address as an AF_INET? > IF AF_FAMILY = AF_INET6 > If found return IPv6 address > > If your still an IPv4 app not ported to IPv6 gethostbyname() just > continues to work. Yes, we need that to avoid breaking existing applications. > If your an IPv4 app that has been ported to IPv6 and to be cognizant of > both IPv4 and IPv6, but all addresses are treated as IPv6 addresses in > the application when you use gethostbyname2(). > > I think this solves your #1 and #2. > > I think it also solves your #3 if implementors make the libraries > threadsafe so gethostbyname() and gethostbyname() are built to be thread > safe. Its work to diff BIND sources each time to make the resolver APIs > thread saft but works. Then one does not need a gethostbyname_r(). I think different implementors do multithreading support differently. But adding the options to gethostbyname allows implemetors to handle threadsafe consistent with their current gethostbyname. For instance, we have a gethostbyname_r() today since otherwise the returned hostent structure would be a static variable in the library. But other implementors might handle this using some form of thread local storage. Thus by specifying a gethostbynameafopt we can then allow vendors do decide if they in addition need a gethostbynameafopt_r function of if they can make gethostbynameafopt thread safe. But we don't need to specify these thread safe aspects (I think). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 9 15:37:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA28208; Sat, 9 Aug 1997 15:17:25 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA28200; Sat, 9 Aug 1997 15:16:37 -0700 Received: from lillen ([129.157.164.21]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id PAA16144; Sat, 9 Aug 1997 15:18:56 -0700 (PDT) Date: Sat, 9 Aug 1997 15:18:49 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4302) Re: Problem with _res.options in RFC 2133 To: bound@zk3.dec.com Cc: Erik Nordmark , ipng@sunroof.eng.sun.com, paul@vix.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3855 > Fix you propose for #1 and #2 are better than now I agree after working > with RFC 2133. > > But #3 is important. If we want to support #3 (multithreaded applications) perhaps we should define a gethostbyname with 3 arguments in addition (or instead of) gethostbyname2. This function would be gethostbynameafopt(host, family, options). With options being zero it does exactly what gethostbyname2 does today - just return the addresses of the specified address family. Thus gethostbynameafopt(host, AF_INET, 0) would be indentical to gethostbyname(host) and gethostbynameafopt(host, AF_INET6, 0) would just return AAAA records. Then we can define options to do things like: - map A records to IPv4-mapped IPv6 addresses. - if asking for AF_INET6 and no AAAA records are found look for A records as a fallback. - return both AAAA and A records (this would match the old hostname2addr functionality). They would all have to be returned as AF_INET6 since the hostent structure only has a single family member. - if the node does not itself have any configured IPv6 addresses do not return any AAAA records. (The latter is for what I think will be a common case with a dual implementation that is only configured with IPv4 addresses. Applications might want to use this so that connect to an IPv6 address doesn't fail immediately since the kernel can not find an IPv6 source address to use for the connection.) So my high level point is that I think we should include options as a parameter. The name of the function and, whether or not we still want a gethostbyname2, we can discuss further. > If we move a little back to the following strategy: > > gethostbyname(host) -- just does what it dose today and no more. Make sense to me. In particular I find the environment variable dangerous since it can be used to break unsuspecting applications. > gethostbyname2(host, AF_FAMILY) > > If AF_FAMILY = AF_INET > If found return IPv4 Mapped Address Why not just have it return the IPv4 address as an AF_INET? > IF AF_FAMILY = AF_INET6 > If found return IPv6 address > > If your still an IPv4 app not ported to IPv6 gethostbyname() just > continues to work. Yes, we need that to avoid breaking existing applications. > If your an IPv4 app that has been ported to IPv6 and to be cognizant of > both IPv4 and IPv6, but all addresses are treated as IPv6 addresses in > the application when you use gethostbyname2(). > > I think this solves your #1 and #2. > > I think it also solves your #3 if implementors make the libraries > threadsafe so gethostbyname() and gethostbyname() are built to be thread > safe. Its work to diff BIND sources each time to make the resolver APIs > thread saft but works. Then one does not need a gethostbyname_r(). I think different implementors do multithreading support differently. But adding the options to gethostbyname allows implemetors to handle threadsafe consistent with their current gethostbyname. For instance, we have a gethostbyname_r() today since otherwise the returned hostent structure would be a static variable in the library. But other implementors might handle this using some form of thread local storage. Thus by specifying a gethostbynameafopt we can then allow vendors do decide if they in addition need a gethostbynameafopt_r function of if they can make gethostbynameafopt thread safe. But we don't need to specify these thread safe aspects (I think). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Aug 9 18:45:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA28383; Sat, 9 Aug 1997 18:35:54 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id SAA28376; Sat, 9 Aug 1997 18:35:42 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id SAA12761; Sat, 9 Aug 1997 18:38:04 -0700 Received: from gw.home.vix.com (gw.home.vix.com [192.5.5.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA14297; Sat, 9 Aug 1997 17:03:59 -0700 Received: from wisdom.rc.vix.com (wisdom.rc.vix.com [204.152.187.1]) by gw.home.vix.com (8.8.6/) via ESMTP id RAA00273; Sat, 9 Aug 1997 17:03:59 -0700 (PDT) env-from (vixie@wisdom.rc.vix.com) Received: by wisdom.rc.vix.com; id RAA31614; Sat, 9 Aug 1997 17:03:58 -0700 Message-Id: <199708100003.RAA31614@wisdom.rc.vix.com> X-Authentication-Warning: wisdom.rc.vix.com: localhost [127.0.0.1] didn't use HELO protocol To: Erik Nordmark cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 4303) Re: Problem with _res.options in RFC 2133 In-reply-to: Your message of "Sat, 09 Aug 1997 15:10:40 PDT." Date: Sat, 09 Aug 1997 17:03:58 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1823 > If we want to support #3 (multithreaded applications) perhaps we should > define a gethostbyname with 3 arguments in addition (or instead of) > gethostbyname2. options aren't what make multithreading hard in this case. the problem is that the pointer returned by gethostby*() is in static storage. if we want to sign up for a "free*()" (freehost(), freenet(), etc) then the pointer can be returned to a malloc()'d (or other dynamic) location. the svr4 api's "gethostbyname_r" wreckage is just too hopeless to standardize further. (if caller-allocates is to be the rule, then the caller has to know how big to allocate and it has to know when to retry-with-larger-buffer when the first one doesn't fly.) personally i prefer a separate free*() function. as for the options, i'd like to do what BIND's IRS does, which is to allocate a "resolver context" inside which options can be set. this will allow different parts of an application to set, use, keep, and depend on differing options at differing levels/libraries/callsites. as for the overall API, there are a lot of event driven systems out there who would like to be able to visit the resolver asynchronously. BIND will shortly offer an "eventlib"-driven resolver, since eventlib can be retargetted to Xt or Win/NT or POSIX threads -- which makes it a standardizable and portable pathway to resolver asynchrony. in other words if we're going to discuss this, let's DISCUSS it. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 10 03:04:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA28632; Sun, 10 Aug 1997 02:55:57 -0700 Received: from sunmail1.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id CAA28625; Sun, 10 Aug 1997 02:55:47 -0700 Received: from saturn.Sun.COM by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id CAA20177; Sun, 10 Aug 1997 02:58:14 -0700 Received: from paddington.london.uk.eu.org (tazenda.demon.co.uk [158.152.220.239]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id CAA04437; Sun, 10 Aug 1997 02:58:10 -0700 Received: from paddington.london.uk.eu.org [::ffff:127.0.0.1] by paddington.london.uk.eu.org with esmtp (Exim 1.62 #3) id 0wxMk5-0002JO-00; Sun, 10 Aug 1997 02:24:25 +0100 X-Mailer: exmh version 2.0zeta 7/24/97 To: Erik Nordmark cc: bound@zk3.dec.com, ipng@sunroof, paul@vix.com Subject: (IPng 4304) Re: Problem with _res.options in RFC 2133 In-reply-to: Your message of "Sat, 09 Aug 1997 15:10:40 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Aug 1997 02:24:24 -0000 From: Philip Blundell Message-Id: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1715 >Make sense to me. In particular I find the environment variable dangerous >since it can be used to break unsuspecting applications. Worse, it's (as far as I can see) useless. You can't set it until all the applications in your environment support IPv6, otherwise they may break. Until then, each application has to internally set the option or call gethostbyname2(). This means that, even if we consider a future time when all applications support IPv6, the chances are that the environment variable by then will be essentially ignored because all applications will take one of the measures I just mentioned. >> gethostbyname2(host, AF_FAMILY) >> >> If AF_FAMILY = AF_INET >> If found return IPv4 Mapped Address > >Why not just have it return the IPv4 address as an AF_INET? I think that's more sensible. If you asked for an AF_INET that's what you should get - you might be a dual-protocol application temporarily running in an IPv4-only environment. >Thus by specifying a gethostbynameafopt we can then allow vendors >do decide if they in addition need a gethostbynameafopt_r function >of if they can make gethostbynameafopt thread safe. But we don't need >to specify these thread safe aspects (I think). I agree. Thread safety, and the way in which it's done, are pretty much an implementation issue. p. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 10 03:41:53 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA28666; Sun, 10 Aug 1997 03:32:47 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA28659; Sun, 10 Aug 1997 03:32:36 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA22648; Sun, 10 Aug 1997 03:35:04 -0700 Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA07018 for ; Sun, 10 Aug 1997 03:35:03 -0700 Received: from Laptop-dhcp-056.ietf.de by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.51) id AA19904; Sun, 10 Aug 1997 20:34:54 +1000 (from kre@cs.mu.oz.au) Received: from aussie.cs.mu.OZ.AU (kre@localhost [127.0.0.1]) by aussie.cs.mu.OZ.AU (8.8.5/8.8.5) with ESMTP id LAA02261; Sat, 9 Aug 1997 11:38:06 +0200 (MET DST) X-Mailer: exmh version 1.6.5 12/8/95 To: "Matt Crawford" Cc: Steve Deering , ipng@sunroof.eng.sun.com Subject: (IPng 4305) Re: Routing header's Strict/Loose Bit Map In-Reply-To: Your message of "Wed, 06 Aug 1997 19:33:19 CDT." <199708070033.TAA11605@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Aug 1997 11:38:06 +0200 Message-Id: <2257.871119486@aussie.cs.mu.OZ.AU> From: Robert Elz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1332 | I know Steve is already off the air until next week, but here's my | take on this stale subject. (I'm trying to catch up on email.) So am I, but I fetched your mail before leaving... | I suggest that the rule be: | Routers must obey the strict/loose bit; hosts need not. Sounds good to me (at least reasonable enough) - anyone planning on routing through hosts (other than perhaps to discover which way a host is sending packets to some address, which is the sole use I can see for having hosts obey routing headers at all) deserves anything they get. For the strict/loose distinction (in routers, or for a host that chooses to obey the bit, if we go that way) I'd say that if you do (now or in the past) ND on the address in the dest header, then that's OK for strict routing - if you substitute another address (say from a routing table) and do ND on that, then that is not strict routing, and the packet should be dropped (icmp'd etc). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 10 15:34:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28930; Sun, 10 Aug 1997 09:33:12 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA28923; Sun, 10 Aug 1997 09:31:32 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA26639; Sun, 10 Aug 1997 09:33:58 -0700 Received: from ha1.rdc1.sfba.home.com (ha1.rdc1.sfba.home.com [24.0.0.66]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA01586 for ; Sun, 10 Aug 1997 09:34:00 -0700 Received: from c8-a.snvl1.sfba.home.com ([24.1.16.12]) by ha1.rdc1.sfba.home.com (Netscape Mail Server v2.02) with SMTP id AAA2881; Sun, 10 Aug 1997 09:33:59 -0700 Date: Sun, 10 Aug 97 16:20:42 GMT Daylight Time From: Ran Atkinson Subject: (IPng 4308) Re: Question on Extension Header Order To: ipng@sunroof.eng.sun.com, ipsec@tis.com X-Mailer: Chameleon ATX 6.0, Standards Based IntraNet Solutions, NetManage Inc. X-Priority: 3 (Normal) References: <199708101343.JAA29980@relay.hq.tis.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1303 Charles Lynn made an important observation. To followup... In IPv6-land, I believe that IPsec AH should appear before (outside) ESP. If one desires both integrity/authentication and confidentiality on data contained by IPsec ESP, then one should use an ESP transform that incorporates those features. [1] IPsec AH inside ESP is incapable of providing the intended protections (namely: to protect the invariant fields of the IPv6 header in addition to the upper-protocol data). To the extent that the current IPsec drafts do not say this, I believe those drafts would be technically flawed. I would be interested in hearing what other IPv6 IPsec implementers believe, if there are any other IPv6 IPsec implementers. Ran rja@inet.org [1] Because of the published attack in [Bellovin96], I personally am of the opinion that ESP should _always_ require an integrated strong integrity/authentication mechanism. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 10 15:35:27 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA28975; Sun, 10 Aug 1997 12:07:49 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA28968; Sun, 10 Aug 1997 12:04:01 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA07875; Sun, 10 Aug 1997 12:06:27 -0700 Received: from gw.home.vix.com (gw.home.vix.com [192.5.5.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA14296 for ; Sun, 10 Aug 1997 12:06:29 -0700 Received: from wisdom.rc.vix.com (wisdom.rc.vix.com [204.152.187.1]) by gw.home.vix.com (8.8.6/) via ESMTP id MAA15967 for ; Sun, 10 Aug 1997 12:06:28 -0700 (PDT) env-from (vixie@wisdom.rc.vix.com) Received: by wisdom.rc.vix.com; id MAA00846; Sun, 10 Aug 1997 12:06:28 -0700 Message-Id: <199708101906.MAA00846@wisdom.rc.vix.com> X-Authentication-Warning: wisdom.rc.vix.com: localhost [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: (IPng 4311) Re: Problem with _res.options in RFC 2133 In-reply-to: Your message of "Sun, 10 Aug 1997 11:06:00 PDT." Date: Sun, 10 Aug 1997 12:06:28 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2396 thread safety is not just about global options. neither posix threads or nt threads allow per-thread globals the way digital unix (and solaris?) does. that means the return value from a getFOObyBAR has to be dynamic or caller- allocated. what this turns into in common (modern) practice is like BIND IRS, which if applied to gethostby*() would look something like: #ifndef RESOLVER_H #define RESOLVER_H typedef struct resolver *resolver; /* Opaque. */ typedef struct res_stats { int nqueries, nresponses, nbadsrcaddrs, nFOO, nBAR; /* etc */ } *res_stats; typedef struct res_rrset { const char *name; /* privately dynamic, must use res_freerrset */ ns_type type; ns_class class; int nrdatas; struct { int rdlen; const u_char *rdata; } *rdatas; /* privately dynamic, must use res_freerrset */ } *res_rrset; /* NULL means error, see errno. */ resolver *res_create(int initial_options, struct sin_addr *initial_nameservers, int number_of_initial_nameservers, evContext); /* 0 means OK, nonzero is an errno. */ int res_getoptions(resolver, int *old_options); int res_setoptions(resolver, int new_options); int res_getservers(resolver, struct sin_addr *servers, int *nservers); int res_setservers(resolver, struct sin_addr *servers, int nservers); int res_clearstats(resolver); int res_getstats(resolver, res_stats); int res_getrrset(resolver, const char *name, ns_type, ns_class, res_rrset); int res_freerrset(resolver, res_rrset); int res_destroy(resolver); #endif /*RESOLVER_H*/ Note that this assumes the use of eventlib, which as I said two days ago in this forum is the only portable asynchronous interface I know if (it has been ported from select() to poll() and we expect no trouble getting it to work under native posix or nt or even os/2 threads.) This also leaves it to the caller to actually parse the rdatas. A similar interface for gethostby*() that was just a wrapper around the above is not a huge problem to imagine, I hope. getaddrinfo() doesn't seem useful. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 10 15:36:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA28955; Sun, 10 Aug 1997 11:07:11 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA28948; Sun, 10 Aug 1997 11:04:05 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA03316; Sun, 10 Aug 1997 11:06:29 -0700 Received: from stb.info.com (usr4-dialup22.mix1.Bloomington.mci.net [166.55.19.214]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA09192 for ; Sun, 10 Aug 1997 11:06:30 -0700 Received: by stb.info.com (Smail3.1.28.1 #4) id m0wxcNZ-000ZHaC; Sun, 10 Aug 97 11:06 PDT Message-Id: Date: Sun, 10 Aug 97 11:06 PDT From: Michael Gersten To: Erik.Nordmark@Eng, Philip.Blundell@pobox.com Subject: (IPng 4309) Re: Problem with _res.options in RFC 2133 Cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, paul@vix.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1288 I may have missed something here, but to say >Thread safety, and the way in which it's done, are pretty much an >implementation issue. is a really bad idea. Lets say you're writting a portable application, and you are told that some systems have a thread safe routine, and others do not. Are you going to write it assuming that it will be thread safe? Saying that the way to make it thread safe is implementation dependent is just as bad. What if the calling sequence to get a hostname was implementation dependent? Thread unsafe routines that require the program to set globals before calling a library routine, or that communicate back to the caller by globals, violate everything learned in the last 20 years about bug free, maintainable programming. Lets not make another standard that has the same problems as the last standard. Lets make the V6 api thread safe from the beginning, please. Michael -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 10 15:37:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA28965; Sun, 10 Aug 1997 11:44:24 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA28958; Sun, 10 Aug 1997 11:42:32 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA06242; Sun, 10 Aug 1997 11:44:58 -0700 Received: from paddington.london.uk.eu.org (tazenda.demon.co.uk [158.152.220.239]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA12507 for ; Sun, 10 Aug 1997 11:44:57 -0700 Received: from paddington.london.uk.eu.org [::ffff:127.0.0.1] by paddington.london.uk.eu.org with esmtp (Exim 1.62 #3) id 0wxUuq-0000BJ-00; Sun, 10 Aug 1997 11:08:04 +0100 X-Mailer: exmh version 2.0zeta 7/24/97 To: Paul A Vixie cc: Erik Nordmark , bound@zk3.dec.com, ipng@sunroof.eng.sun.com Subject: (IPng 4310) Re: Problem with _res.options in RFC 2133 In-reply-to: Your message of "Sat, 09 Aug 1997 17:03:58 PDT." <199708100003.RAA31614@wisdom.rc.vix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Aug 1997 11:08:04 -0000 From: Philip Blundell Message-Id: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 957 >that the pointer returned by gethostby*() is in static storage. if we want >to sign up for a "free*()" (freehost(), freenet(), etc) then the pointer >can be returned to a malloc()'d (or other dynamic) location. the svr4 api's >"gethostbyname_r" wreckage is just too hopeless to standardize further. (if POSIX already has getaddrinfo(), of course, and this does indeed have a seperate `freeaddrinfo' function. Personally I think it's a bit of a shame they decided to glue service and host lookups into the same function, but otherwise it seems a fairly good idea. p. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 10 15:37:49 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA29226; Sun, 10 Aug 1997 14:42:04 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA29215; Sun, 10 Aug 1997 14:40:31 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA21097; Sun, 10 Aug 1997 14:43:00 -0700 Received: from paddington.london.uk.eu.org (tazenda.demon.co.uk [158.152.220.239]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA29744; Sun, 10 Aug 1997 14:42:57 -0700 Received: from paddington.london.uk.eu.org [::ffff:127.0.0.1] by paddington.london.uk.eu.org with esmtp (Exim 1.62 #3) id 0wxd38-0000kv-00; Sun, 10 Aug 1997 19:49:10 +0100 X-Mailer: exmh version 2.0zeta 7/24/97 To: Michael Gersten cc: Erik.Nordmark@Eng, bound@zk3.dec.com, ipng@sunroof.eng.sun.com, paul@vix.com Subject: (IPng 4312) Re: Problem with _res.options in RFC 2133 In-reply-to: Your message of "Sun, 10 Aug 1997 11:06:00 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 10 Aug 1997 19:49:09 -0000 From: Philip Blundell Message-Id: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 851 >I may have missed something here, but to say >>Thread safety, and the way in which it's done, are pretty much an >>implementation issue. >is a really bad idea. > >Lets say you're writting a portable application, and you are told that some >systems have a thread safe routine, and others do not. Are you going to >write it assuming that it will be thread safe? You're quite right. I must have been writing in my sleep or something. I take back what I said there. p. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 11 00:57:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA29858; Mon, 11 Aug 1997 00:48:11 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA29851; Mon, 11 Aug 1997 00:48:02 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA19289; Mon, 11 Aug 1997 00:50:29 -0700 Received: from mailrelay.ipsilon.com (mailrelay.ipsilon.com [205.226.0.201]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA18250 for ; Mon, 11 Aug 1997 00:50:32 -0700 Received: from spruce.ipsilon.com (Laptop-dhcp-189.ietf.de [195.27.195.189]) by mailrelay.ipsilon.com (8.6.10/8.6.10) with SMTP id BAA05215; Mon, 11 Aug 1997 01:33:09 -0700 Message-Id: <3.0.3.32.19970810053204.00762d50@mailhost.ipsilon.com> X-Sender: hinden@mailhost.ipsilon.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Sun, 10 Aug 1997 05:32:04 -0700 To: Robert Warnke From: Bob Hinden Subject: (IPng 4313) Re: current status of IPv6 tunneling? Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3.0.16.19970808104800.432f73f8@joker.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 908 Rob, >What is the current status of IPv6 tunneling? I remember that at the >Memphis IETF meeting the IESG wanted to form a new WG in the Internet area >for tunneling in general. I looked in the Internet area but I haven't seen >a new WG. Has anything happened since then? Is >draft-ietf-ipngwg-ipv6-tunnel-07.txt still the latest version? It is the hands of the IESG. I think they may move the IPv6 tunneling draft forward independently of the IPv4 tunneling approaches. I will ping our AD's and find out for sure. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 11 09:22:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA00296; Mon, 11 Aug 1997 09:11:07 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA00289; Mon, 11 Aug 1997 09:11:02 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA01446 for ; Mon, 11 Aug 1997 09:13:32 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA13145; Mon, 11 Aug 1997 09:11:31 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA28717; Sun, 10 Aug 1997 06:28:12 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA01548; Sun, 10 Aug 1997 06:30:37 -0700 Received: from CLYNN.BBN.COM (CLynn.BBN.COM [128.89.1.209]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA17441 for ; Sun, 10 Aug 1997 06:30:39 -0700 Message-Id: <199708101330.GAA17441@saturn.Sun.COM> Date: Sun, 10 Aug 97 9:28:35 EDT From: Charles Lynn To: Dan McDonald cc: Koji Imada - je4owb/2 , ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: (IPng 4315) Re: IPv6 Destination options extension header position. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4839 Dan, Thanks for your feedback on the issue of placement of the Destination Options header. The position before the Routing Header was omitted, I feel to reduce distractions. However, it has instead pointed out the need for an explanation of the rationale that resulted in the original diagram. The requirements stated in RFC 1883 Section "4.1 Extension Header Order", i.e., "IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet, except for the Hop-by-Hop Options header which is restricted to appear immediately after an IPv6 header only. Nonetheless, it is strongly advised that sources of IPv6 packets adhere to the above recommended order until and unless subsequent specifications revise that recommendation." Thus the recommendation that the Destination Options header appear in only two places (before the Routing Header and before the upper-layer header) is to be used until a subsequent specifications revises that recommendation. That is what the AH/ESP drafts were trying to reflect. The extension headers are processed in the order that they appear. Extension headers are generally orthogonal, except, potentially, in the case of the Destination Options (and Hop-by-Hop Options) header(s). As an example not related to IPSec, a destination option is being defined that will divorce the IP addresses in the IP header from the tokens used to perform demultiplexing at the transport layer. This has utility, e.g., to preserve a long duration connection when a system's addresses are dynamically changed. It may also be used to support migratory processes, etc. A similar argument may be made for the IPSec headers, as they, too, have bound (user/application) security to IP addresses. Consider a destination option that has the semantics of "change the source and destination IP addresses, for all subsequent processing, to SRC and DST. Use this option before an AH/ESP header would effectively change the SA that is referenced by the SPI, since an SA is identified by the triple . The placement of the Destination Options header carrying this option cannot be after the AH/ESP header (as that would lead to use of the wrong SA and (if the secrets are any good) the discard of the packet). One wouldn't want it before the Routing Header, as there is no need for it to be processed at each hop in the source route (in addition to potentially causing mis-delivery of the packet). This functionality may be useful in the context of multihomed hosts (that do not forward packets), migratory processes, redundant servers, evolution of the routing system, or, as was mentioned on one of the mailing lists recently, for use with NAT boxes that change between IP header versions 4 and 6, and IP addresses. I feel we should remind folks that things keep evolving, and some of the directions that that evolution might be taken, so that they don't unnecessarily constrain their implementations (short cuts) in ways that might prove to be a burden to the whole system later on. The bottom line for implementors is to be aware that not everything has been invented yet. It should have little real impact on systems that do not implement such an option. So how much space should we devote in the specs for it? Do you think it should be mentioned at all? We should certainly consider the security implications of such an option, but given that changing the option presents the same level of difficulty of attack to an adversary as, e.g., changing the IP destination address itself (or any bit that is protected by an integrity mechanism), I suspect that it would not introduce disproportional vulnerabilities. Consequently, I think that the "right diagram" would be something like: +------------+-------------------+---------------------+------+-----+------+ | Orig IP v4 | hop-by-hop, dest, | some combination of | dest | | | | or v6 hdr | routing, frag. | dest opt*, AH, ESP | opt* | TCP | Data | +------------+-------------------+---------------------+------+-----+------+ |<------------- authenticated by AH except for mutable fields ------------>| * = if present, could be before AH, after AH, or both To borrow your text, the above replacement text better illustrates (IMHO) AH placement in an IP datagram than does the current text. Charlie -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 11 09:31:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA00337; Mon, 11 Aug 1997 09:19:49 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA00330; Mon, 11 Aug 1997 09:19:42 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA02295 for ; Mon, 11 Aug 1997 09:22:12 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA13187; Mon, 11 Aug 1997 09:20:13 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA28741; Sun, 10 Aug 1997 06:38:16 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA03731; Sun, 10 Aug 1997 06:40:40 -0700 Received: from CLYNN.BBN.COM (CLynn.BBN.COM [128.89.1.209]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA18089 for ; Sun, 10 Aug 1997 06:40:42 -0700 Message-Id: <199708101340.GAA18089@saturn.Sun.COM> Date: Sun, 10 Aug 97 9:39:52 EDT From: Charles Lynn To: ipsec@tis.com, ipng@sunroof.eng.sun.com Subject: (IPng 4316) Question on Extension Header Order Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1908 Folks, I noticed that the recommended order of extension headers shown in section 4.1 has changed from IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Fragment header Authentication header (note 2) Encapsulating Security Payload header (note 2) Destination Options header (note 3) upper-layer header in RFC 1883 to IPv6 header Hop-by-Hop Options header Destination Options header (note 1) Routing header Fragment header Encapsulating Security Payload header (note 2) Authentication header (note 2) Destination Options header (note 3) upper-layer header in the draft. My question is why the order of the Authentication header and the Encapsulating Security Payload header were switched. My understanding of the direction of the IPSec WG leads me to conclude that either order may appear, based on the security policy being implemented, and that the order in RFC 1883 would be the order most often encountered. I suggest changing note 2 to: note 2: the order of the two security headers is based on security policy. Additional recommendations regarding the relative order of the Authentication and Encapsulating Security Payload headers are given in [draft-ietf-ipsec-arch-sec-01.txt], Charlie -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 11 12:55:24 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA00546; Mon, 11 Aug 1997 12:41:10 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA00539; Mon, 11 Aug 1997 12:41:01 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA06657; Mon, 11 Aug 1997 12:43:27 -0700 Received: from milou.comp.lancs.ac.uk (milou.comp.lancs.ac.uk [194.80.34.7]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA08286 for ; Mon, 11 Aug 1997 12:43:23 -0700 Received: from tina.comp.lancs.ac.uk by milou.comp.lancs.ac.uk; Mon, 11 Aug 1997 20:36:35 +0100 From: "Randa" Message-Id: <19323.199708111941@tina.comp.lancs.ac.uk> Received: by tina.comp.lancs.ac.uk; Mon, 11 Aug 1997 20:41:07 +0100 Subject: (IPng 4317) Re: Question on Extension Header Order To: rja@inet.org (Ran Atkinson) Date: Mon, 11 Aug 1997 20:41:07 +0100 (BST) Cc: ipng@sunroof.eng.sun.com, ipsec@tis.com In-Reply-To: from "Ran Atkinson" at Aug 10, 97 04:20:42 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 379 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 11 15:17:00 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA00763; Mon, 11 Aug 1997 15:04:53 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA00756; Mon, 11 Aug 1997 15:04:42 -0700 Received: from lillen ([129.157.164.20]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id PAA28359; Mon, 11 Aug 1997 15:07:05 -0700 (PDT) Date: Sun, 10 Aug 1997 16:18:00 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4318) Re: Problem with _res.options in RFC 2133 To: Paul A Vixie Cc: Erik Nordmark , bound@zk3.dec.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199708100003.RAA31614@wisdom.rc.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2950 > options aren't what make multithreading hard in this case. the problem is > that the pointer returned by gethostby*() is in static storage. if we want > to sign up for a "free*()" (freehost(), freenet(), etc) then the pointer > can be returned to a malloc()'d (or other dynamic) location. the svr4 api's > "gethostbyname_r" wreckage is just too hopeless to standardize further. (if > caller-allocates is to be the rule, then the caller has to know how big to > allocate and it has to know when to retry-with-larger-buffer when the first > one doesn't fly.) personally i prefer a separate free*() function. >From the mail I've seen so far it seems like folks are advocating making sure that the new gethostbyname interface is MT safe. So what would such an interface look like? Do you want what we currently have with just a new freehostent() call that frees the structure returned by the new gethostbyname? I'd like to make the new call all accept per-call options, but I'd also like to find out what the "resolver context" below is all about. > as for the options, i'd like to do what BIND's IRS does, which is to > allocate a "resolver context" inside which options can be set. this will > allow different parts of an application to set, use, keep, and depend on > differing options at differing levels/libraries/callsites. Is this a context that is hidden inside the library or does it mean that - there will be a new call to create a context, and - the gethost* calls will take the context as an argument? If the latter I think it is simpler for the applications to pass the options with every call. If the library desires to internally effectively cache information associated with the options as a context I don't see a problem with that. > as for the overall API, there are a lot of event driven systems out there > who would like to be able to visit the resolver asynchronously. BIND will > shortly offer an "eventlib"-driven resolver, since eventlib can be > retargetted to Xt or Win/NT or POSIX threads -- which makes it a > standardizable and portable pathway to resolver asynchrony. Would such an effort have an impact on the non-event driven resolver interfaces i.e. can it be done as a separate effort from the "IPv6 work" (which seems to entail supporting different AFs better and better MT support)? > in other words if we're going to discuss this, let's DISCUSS it. I agree. We should get it right. The only large issue is whether the event mechanisms is separately and can be persuide in parallel with the other changes. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 11 22:47:09 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA01187; Mon, 11 Aug 1997 22:37:10 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA01180; Mon, 11 Aug 1997 22:36:59 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA04533; Mon, 11 Aug 1997 22:39:28 -0700 Received: from gw.home.vix.com (gw.home.vix.com [192.5.5.1]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA20282 for ; Mon, 11 Aug 1997 22:39:30 -0700 Received: from wisdom.rc.vix.com (wisdom.rc.vix.com [204.152.187.1]) by gw.home.vix.com (8.8.6/) via ESMTP id WAA15148 for ; Mon, 11 Aug 1997 22:39:29 -0700 (PDT) env-from (vixie@wisdom.rc.vix.com) Received: by wisdom.rc.vix.com; id WAA01978; Mon, 11 Aug 1997 22:39:29 -0700 Message-Id: <199708120539.WAA01978@wisdom.rc.vix.com> X-Authentication-Warning: wisdom.rc.vix.com: localhost [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: (IPng 4319) Re: Problem with _res.options in RFC 2133 In-reply-to: Your message of "Sun, 10 Aug 1997 16:18:00 PDT." Date: Mon, 11 Aug 1997 22:39:29 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2946 > From the mail I've seen so far it seems like folks are advocating > making sure that the new gethostbyname interface is MT safe. someone else said that there was a freeaddrinfo() to go along with the getaddrinfo(), so i'm now left wondering why any of us care about gethostby*() at all. > So what would such an interface look like? Do you want > what we currently have with just a new freehostent() call > that frees the structure returned by the new gethostbyname? to the extent that gethostby*() and getnetby*() still matter, they need a freehostent() and a freenetent(), yes. > I'd like to make the new call all accept per-call options, but I'd > also like to find out what the "resolver context" below is all about. getaddrinfo() doesn't seem to have any options. its api design assumes that resolver configuration will be per-system rather than per-callsite or per-process. i don't know if that's a good or bad design but it's not the way i personally write code. i'm a per-callsite guy myself. > > as for the options, i'd like to do what BIND's IRS does, which is to > > allocate a "resolver context" inside which options can be set. this will > > allow different parts of an application to set, use, keep, and depend on > > differing options at differing levels/libraries/callsites. > > Is this a context that is hidden inside the library or does it > mean that > - there will be a new call to create a context, and > - the gethost* calls will take the context as an argument? > > If the latter I think it is simpler for the applications to pass > the options with every call. If the library desires to internally > effectively cache information associated with the options > as a context I don't see a problem with that. passing options is better than passing a context? what if the options grow over time? seems like a functional interface to options is better than a data based one. > Would such an effort have an impact on the non-event driven resolver > interfaces i.e. can it be done as a separate effort from the "IPv6 work" > (which seems to entail supporting different AFs better and better MT > support)? an evContext of NULL causes the interface to behave synchronously. > > in other words if we're going to discuss this, let's DISCUSS it. > > I agree. We should get it right. The only large issue is whether the event > mechanisms is separately and can be persuide in parallel with the other > changes. most of the code for this is written already, since i want to use it in the name server and some other eventlib apps. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 12 09:48:44 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01514; Tue, 12 Aug 1997 09:38:41 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA01507; Tue, 12 Aug 1997 09:38:30 -0700 Received: from lillen ([129.157.164.21]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA05627; Tue, 12 Aug 1997 09:40:54 -0700 (PDT) Date: Mon, 11 Aug 1997 16:35:26 -0700 (PDT) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 4320) Re: Problem with _res.options in RFC 2133 To: Paul A Vixie Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <199708101906.MAA00846@wisdom.rc.vix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1618 > thread safety is not just about global options. neither posix threads or nt > threads allow per-thread globals the way digital unix (and solaris?) does. Solaris has what is known as thread local storage. It is used for things like the global errno variable. > that means the return value from a getFOObyBAR has to be dynamic or caller- > allocated. what this turns into in common (modern) practice is like BIND > IRS, which if applied to gethostby*() would look something like: [omitted] > This also leaves it to the caller to actually parse the rdatas. A similar > interface for gethostby*() that was just a wrapper around the above is not > a huge problem to imagine, I hope. The above resolver interfaces seem reasonable would one have the choice to define an interface from scratch. However, the introducion of the context and the associated create and destroy routines would make it harder for the folks that need to port applications to IPv6. I think it is possible to get something reasonable by having struct dynhostent *gethostbynameafopt(char *name, int af, int options); void freedynhostent(struct dynhostent *); These interfaces are MT safe without introducing the notion of a context to the programmer. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 12 11:17:01 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01642; Tue, 12 Aug 1997 11:05:34 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA01635; Tue, 12 Aug 1997 11:05:22 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA17118; Tue, 12 Aug 1997 11:07:51 -0700 Received: from gw.home.vix.com (gw.home.vix.com [192.5.5.1]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA13693 for ; Tue, 12 Aug 1997 11:07:51 -0700 Received: from wisdom.rc.vix.com (wisdom.rc.vix.com [204.152.187.1]) by gw.home.vix.com (8.8.6/) via ESMTP id LAA21341 for ; Tue, 12 Aug 1997 11:07:50 -0700 (PDT) env-from (vixie@wisdom.rc.vix.com) Received: by wisdom.rc.vix.com; id LAA02213; Tue, 12 Aug 1997 11:07:50 -0700 Message-Id: <199708121807.LAA02213@wisdom.rc.vix.com> X-Authentication-Warning: wisdom.rc.vix.com: localhost [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com Subject: (IPng 4321) Re: Problem with _res.options in RFC 2133 In-reply-to: Your message of "Mon, 11 Aug 1997 16:35:26 PDT." Date: Tue, 12 Aug 1997 11:07:50 -0700 From: Paul A Vixie Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1053 > The above resolver interfaces seem reasonable would one have the choice > to define an interface from scratch. However, the introducion of > the context and the associated create and destroy routines would make > it harder for the folks that need to port applications to IPv6. getaddrinfo (and presumably freeaddrinfo) will appear in BIND 8.1.2. > I think it is possible to get something reasonable by having > struct dynhostent *gethostbynameafopt(char *name, int af, int options); > void freedynhostent(struct dynhostent *); > > These interfaces are MT safe without introducing the notion of > a context to the programmer. so are the POSIX functions suggested above. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 13 02:05:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA02165; Wed, 13 Aug 1997 01:56:40 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA02158; Wed, 13 Aug 1997 01:56:32 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA24841; Wed, 13 Aug 1997 01:59:01 -0700 Received: from cheerios.cisco.com (cheerios.Cisco.COM [171.69.192.213]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id BAA01015 for ; Wed, 13 Aug 1997 01:59:02 -0700 Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by cheerios.cisco.com (8.6.10/8.6.5) with SMTP id BAA09928; Wed, 13 Aug 1997 01:58:56 -0700 Message-Id: <199708130858.BAA09928@cheerios.cisco.com> To: Charles Lynn Cc: ipsec@tis.com, ipng@sunroof.eng.sun.com, deering@cisco.com Subject: (IPng 4322) Re: Question on Extension Header Order In-reply-to: clynn@bbn.com's message of Sun, 10 Aug 97 09:39:52 -0500. <199708101340.GAA18089@saturn.Sun.COM> Date: Wed, 13 Aug 97 01:58:56 PDT From: Steve Deering Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2855 > From: Charles Lynn > > I noticed that the recommended order of extension headers shown in section > 4.1 has changed... My question is why the order of the Authentication > header and the Encapsulating Security Payload header were switched. Because I got confused. The new ESP draft (draft-ietf-ipsec-esp-v2-00.txt) says on page 8, 2nd paragraph, that the ESP header should precede the AH header, so I concluded that the ipsec wg had changed their recommended order. When I went looking for the ipsec architecture draft to find out what the real story was, all I found was draft-ietf-ipsec-arch-sec-01.txt which contains only the note saying that that draft has expired. I now see that the new AH draft (draft-ietf-ipsec-auth-header-01.txt) says on page 6, 3rd paragraph, that the AH header should precede the ESP header, so the AH and ESP documents appear to be contradictory (looks like a simple editing error, when moving text from one document to the other). It is still the case that there is no ipsec-arch document in the internet- drafts directory. I guess the editors missed the pre-IETF drafts deadline. I have been informed that a new arch draft was posted to the ipsec list, but that doesn't help those of us ipngwg folks who are not on the ipsec list. Anyway, from reading the new ESP draft, it looks like the ipsec wg prefers receivers to do authentication first, then decryption, in the case where both functions are bundled into ESP. So I would guess that, in the unbundled case (i.e., separate AH and ESP headers), AH should normally precede ESP, as you suggest. So, unless I hear otherwise, I will undo the change I made in the new IPv6 draft. (Though it certainly seems counter- intuitive to me: after all, it's the integrity of the plaintext that a receiver cares about, not the integrity of the gibberish.) > I suggest changing note 2 to: > > note 2: the order of the two security headers is based on > security policy. Additional recommendations > regarding the relative order of the Authentication > and Encapsulating Security Payload headers are given > in [draft-ietf-ipsec-arch-sec-01.txt], I'll consider this change once I have a chance to read the ipsec-arch draft, to see what it actually says. (Actually, a friendly ipsec-er emailed me a copy of that document yesterday, but I've been too busy at IETF to read it yet.) Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 13 12:55:45 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA02637; Wed, 13 Aug 1997 12:43:24 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA02630; Wed, 13 Aug 1997 12:43:13 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA17681; Wed, 13 Aug 1997 12:45:41 -0700 Received: from zafu.bbn.com (ZAFU.BBN.COM [192.1.50.38]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA29592 for ; Wed, 13 Aug 1997 12:45:03 -0700 Received: from [128.89.30.19] (ARA19.BBN.COM [128.89.30.19]) by zafu.bbn.com (8.7.5/8.6.5) with ESMTP id PAA23543; Wed, 13 Aug 1997 15:45:22 -0400 (EDT) X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <199708131119.HAA03146@portal.ex.tis.com> References: clynn@bbn.com's message of Sun, 10 Aug 97 09:39:52 -0500. <199708101340.GAA18089@saturn.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 13 Aug 1997 15:36:36 -0500 To: Steve Deering From: Stephen Kent Subject: (IPng 4323) Re: Question on Extension Header Order Cc: Charles Lynn , ipsec@tis.com, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1360 Steve, The Architecture Document was submitted "approximately" on time, e.g., no more than 5 minutes late. Since we've seen a lot of documents being posted long after the deadline, I suspect ours just fell through the cracks. Just to be sure, we copied it to the list, so the WG members have had it for a couple of weeks, but the rest of the community has not. I apologize for the confusion. We'll fix the editing error in ESP. Yes, when both encryption and authenticaion are peformed in ESP, the encryption is done first, then the authentication. This allows for parellelism at the receiver and alos allows for faster rejection of various sorts of denial of service attacks. If AH and ESP and both employed in transport mode, AH is the outer header, i.e., the first security protocol above IP, and ESP would follow AH. Here the rationale for the positioning is even stronger, since ESP is an encapsulation protocol and thus AH inside of ESP does not work well. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 13 15:25:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA02943; Wed, 13 Aug 1997 15:14:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA02933; Wed, 13 Aug 1997 15:13:51 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA22563; Wed, 13 Aug 1997 15:16:21 -0700 Received: from bbmail1.unisys.com (192-63-2005.unisys.com [192.63.200.5]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA23176 for ; Wed, 13 Aug 1997 15:16:14 -0700 Received: from slc-exchange-1.slc.unisys.com ([192.60.145.26]) by bbmail1.unisys.com (8.8.5/8.8.5) with SMTP id WAA27284 for ; Wed, 13 Aug 1997 22:16:07 GMT Received: by slc-exchange-1.slc.unisys.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCA803.195D1470@slc-exchange-1.slc.unisys.com>; Wed, 13 Aug 1997 16:08:12 -0600 Message-ID: From: "Harsch, Tom" To: "'IPng List'" , "'addrconf@cisco.com'" Subject: (IPng 4324) comments on draft-ietf-ipngwg-addrconf-v2-00 Date: Wed, 13 Aug 1997 16:08:10 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1009 Sue and Tom, page 8, valid lifetime definition (latent typo): ...greater than... vice ...greater then... ^ ^ page 15, first sentence: The current addressing architecture I-D requires (sections 2.4[note 2], 2.5.8) a 64-bit prefix and 64-bit interface identifier for link-local addresses. Why should the link-local address description here be any different? page 20: Either list item e) is missing or items f), g) and h) should be relabeled. -- Tom Harsch Unisys, Salt Lake City, UT mailto:Thomas.Harsch@UNISYS.com mailto:tcharsch@acm.org > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 13 15:41:39 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA03113; Wed, 13 Aug 1997 15:29:44 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA03106; Wed, 13 Aug 1997 15:29:26 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA26100; Wed, 13 Aug 1997 15:31:56 -0700 Received: from sol.extremenetworks.com (extremenetworks.com [207.94.36.2]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA29419 for ; Wed, 13 Aug 1997 15:31:51 -0700 Received: by SOL with Internet Mail Service (5.0.1457.3) id ; Wed, 13 Aug 1997 15:30:09 -0700 Message-ID: <116F1CE887F8CF118E2300A0C91368E60522D0@SOL> From: Andrew Smith To: "'Erik Nordmark '" Cc: "'p8021@hepnrc.hep.net '" , "'ipng@sunroof.eng.Sun.COM '" Subject: (IPng 4325) Re: IPv6 over FDDI - user_priority Date: Wed, 13 Aug 1997 15:30:08 -0700 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2686 Erik, I think that the 802 architecture assumes that upper-layers will sort out their MTU requirements without help from the MAC layer. Up to now this has not been a major problem because the MTU information has been available from one or more of (a) local configuration (b) upper-layer MTU discovery protocols. One existing exception to this was 802.5 bridging which does actually have a MAC-layer MTU discovery built in to source-routing. It has been a minor problem for e.g. FDDI<->Ethernet bridging and some kind bridge vendors helped out by doing the IP fragmentation kludge (but that is not something that can be relied upon and certainly cannot be assumed into any standards). Now, for IPv6 MTU discovery, I think it would be appropriate to use some mechanism related to packet size but not one related to user_priority: this has several advantages: (1) the "test" packets can have the same form as the real data packets (same user_priority, same sorts of packet lengths) (2) it is media-independant - I think this reason is *very important* (3) bridges might be able to do something similar to the FDDI kludge if they wanted to: they could intercept a too-big test packet and, in addition to their normal action which would be to drop it, they could generate an appropriate ICMP error message. I think this IPv6-MTU-kludge would likely not be much more complex than the current IPv4-fragment kludge although I don't think it appropriate to standardise. Andrew ---------- From: Erik Nordmark To: Andrew Smith Cc: Matt Crawford; p8021@hepnrc.hep.net; issll@mercury.lcs.mit.edu; ipng@sunroof.eng.Sun.COM Sent: 8/9/97 3:04 PM Subject:Re: (IPng 4277) RE: IPv6 over FDDI - user_priority > I think that you will find bridges forwarding Tagged 802.1p packets > including > non-zero user_priority values onto Untagged FDDI. According to the > current > 802.1p defaults, the FDDI FC byte would then, by default, encode the > user_priority > received from the incoming 802.1p header (modulo the fact that it > collapes > 6->6 and 7->6 also). I believe this would invalidate your assumption. Does 802.1p address media with different MTU? Or does 802.1 assume that the problem of differing MTUs will be solved by making the bridges handle upper layer protocols such as IP? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 14 07:45:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA04028; Thu, 14 Aug 1997 07:35:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA04021; Thu, 14 Aug 1997 07:35:43 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA20644; Thu, 14 Aug 1997 07:38:13 -0700 Received: from eamail1.unisys.com (eamail1.unisys.com [192.61.103.80]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id HAA15915 for ; Thu, 14 Aug 1997 07:38:13 -0700 Received: from unislc.slc.unisys.com ([192.60.224.1]) by eamail1.unisys.com (8.8.5/8.8.5) with SMTP id OAA28155 for ; Thu, 14 Aug 1997 14:38:07 GMT Received: from slc-exchange-1 by unislc.slc.unisys.com (5.61/1.35) id AA17029; Thu, 14 Aug 97 08:35:53 -0600 Received: by slc-exchange-1.slc.unisys.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52) id <01BCA88C.65162850@slc-exchange-1.slc.unisys.com>; Thu, 14 Aug 1997 08:31:00 -0600 Message-Id: From: "Harsch, Tom" To: "'IPng List'" Subject: (IPng 4326) comments on draft-ietf-ipngwg-addrconf-v2-00 Date: Thu, 14 Aug 1997 08:30:58 -0600 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.995.52 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1069 Sue and Tom, section 5.5: (IMHO) The sentence "Creation of global ... SHOULD be locally configurable." is open to misinterpretation. Does this mean there SHOULD be a configuration switch to suppress global and site-local address creation? And which parameters SHOULD be locally configurable? None are specifically mentioned in the rest of section 5.5, although there is one MAY case in section 5.5.2 and one MUST case in section 5.5.4. page 20: Do you intend to change "2 hours" to a protocol constant (e.g., MIN_PREFIX_LIFETIME) reference - presumably defined in the Neighbor Discovery document? It's not one of those parameters that SHOULD be locally configurable, is it? -- Tom > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 15 04:36:12 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA05627; Fri, 15 Aug 1997 04:27:09 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA05620; Fri, 15 Aug 1997 04:26:58 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA02932; Fri, 15 Aug 1997 04:29:29 -0700 Received: from hitiij.hitachi.co.jp (hitiij.hitachi.co.jp [133.145.224.3]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA11505 for ; Fri, 15 Aug 1997 04:29:30 -0700 Received: from isrdgw.isrd.hitachi.co.jp by hitiij.hitachi.co.jp (8.8.5+2.7Wbeta5/3.5W-hitiij) id UAA18233; Fri, 15 Aug 1997 20:25:18 +0900 (JST) Received: from magic.33g.isrd.hitachi.co.jp by isrdgw.isrd.hitachi.co.jp (8.6.9+2.4W/2.7W-ISRD) id UAA00997; Fri, 15 Aug 1997 20:26:31 +0900 Message-Id: <9708151132.AA00074@magic.33g.isrd.hitachi.co.jp> From: tsuchiya Date: Fri, 15 Aug 1997 20:32:54 +0900 To: ipng@sunroof.eng.sun.com Subject: (IPng 4327) ICMPv6 Echo reply MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1703 Dear all, My name is Kazuaki Tsuchiya. I work at Hitachi, Ltd. in Japan and I develop IPv6 router now. But when I tried to implement ICMPv6 Echo reply, I was confused. In RFC1885 page 16: >The data received in the ICMPv6 Echo Request message MUST be returned >entirely and unmodified in the ICMPv6 Echo Reply message, unless the >Echo Reply would exceed the MTU of the path back to the Echo >requester, in which case the data is truncated to fit that path MTU. > Ethernet +-----+ MTU=1500 +------+ |Host 1+--------------+Host 2| +-----+ +------+ If Host1 send ICMPv6 Echo request(=2000bytes > MTU) to Host2, What should Host2 do? Which is correct? (1) Host2 should return ICMPv6 Echo reply to Host1, only top of 1500bytes in ICMP Echo request. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (2) Host2 should return ICMPv6 Echo reply to Host1, all of 2000bytes in ICMP Echo request. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I know, some implements are (1), and some implements are (2). But I think, unifying is necessary for communication with one another by ICMPv6 Echo request and reply. Kind regards. ---------------------------------------------------------- Kazuaki Tsuchiya(E-mail:tsuchi@isrd.hitachi.co.jp) Hitachi, Ltd. in Japan. Phone:044-549-1714 Fax:044-549-1721 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 15 09:52:11 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA05889; Fri, 15 Aug 1997 09:39:11 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA05882; Fri, 15 Aug 1997 09:39:02 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA01081; Fri, 15 Aug 1997 09:41:33 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA00369 for ; Fri, 15 Aug 1997 09:40:46 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA18988; Fri, 15 Aug 97 09:39:32 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id JAA12891; Fri, 15 Aug 1997 09:41:17 -0700 Date: Fri, 15 Aug 1997 09:41:17 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199708151641.JAA12891@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4328) Re: ICMPv6 Echo reply X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1631 Kazuaki, > >The data received in the ICMPv6 Echo Request message MUST be returned > >entirely and unmodified in the ICMPv6 Echo Reply message, unless the > >Echo Reply would exceed the MTU of the path back to the Echo > >requester, in which case the data is truncated to fit that path MTU. > > I am not really sure what the rational was for forcing truncation of echo replies. If one wanted to eliminate fragmentation of echo requests and replies then it would have been simpler to require that echo requests and replies be no larger than 576 bytes. > > Ethernet > +-----+ MTU=1500 +------+ > |Host 1+--------------+Host 2| > +-----+ +------+ > > If Host1 send ICMPv6 Echo request(=2000bytes > MTU) to Host2, > What should Host2 do? > > Which is correct? > (1) Host2 should return ICMPv6 Echo reply to Host1, > only top of 1500bytes in ICMP Echo request. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > (2) Host2 should return ICMPv6 Echo reply to Host1, > all of 2000bytes in ICMP Echo request. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > We implement (2) at the moment. If we are going to allow echo requests to be fragmented it the first place then it seems like the correct thing to do. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 15 10:33:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA05968; Fri, 15 Aug 1997 10:21:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA05961; Fri, 15 Aug 1997 10:21:05 -0700 From: gaurang@VNET.IBM.COM Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA12156; Fri, 15 Aug 1997 10:23:35 -0700 Received: from VNET.IBM.COM (vnet.ibm.com [204.146.168.194]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA17771 for ; Fri, 15 Aug 1997 10:23:20 -0700 Message-Id: <199708151723.KAA17771@saturn.Sun.COM> Received: from RALVM29 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 0668; Fri, 15 Aug 97 13:23:00 EDT Date: Fri, 15 Aug 97 13:19:13 EDT To: ipng@sunroof.eng.sun.com Subject: (IPng 4329) Re: ICMPv6 Echo reply Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 792 Kazuaki, > If Host1 send ICMPv6 Echo request(=2000bytes > MTU) to Host2, > What should Host2 do? > > Which is correct? > (1) Host2 should return ICMPv6 Echo reply to Host1, > only top of 1500bytes in ICMP Echo request. > (2) Host2 should return ICMPv6 Echo reply to Host1, > all of 2000bytes in ICMP Echo request. > I think, it has to be (2), otherwise round-trip time from ping is invalid. Gaurang Shah -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 17 17:58:28 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA07456; Sun, 17 Aug 1997 17:49:47 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA07449; Sun, 17 Aug 1997 17:49:37 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA29847; Sun, 17 Aug 1997 17:52:08 -0700 Received: from dcn.soongsil.ac.kr (dcn.soongsil.ac.kr [203.253.2.104]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA16475 for ; Sun, 17 Aug 1997 17:52:10 -0700 Received: from dcnnt.soongsil.ac.kr ([203.253.3.85]) by dcn.soongsil.ac.kr (8.6.9H1/8.9.11h) with SMTP id KAA08130 for ; Mon, 18 Aug 1997 10:56:19 +1000 Message-Id: <3.0.1.32.19970818094329.006a45e8@dcn.soongsil.ac.kr> X-Sender: leewb@dcn.soongsil.ac.kr X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 18 Aug 1997 09:43:29 +0900 To: ipng@sunroof.eng.sun.com From: Lee Wangbong Subject: (IPng 4330) about link local address Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 757 Hi! I have one question about link local address. That is, I wonder about whether IPv6 hosts can communicate with link-local address or not. examples) telnet fe80::20:ad30:1200 or ping fe80::20:ad30:1200 or ftp fe80::20:ad30:1200 or somthing like that. I think it is possible. Am I right ? Lee Wangbong. DCN-SSU-KOREA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 18 02:02:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA07648; Mon, 18 Aug 1997 01:54:22 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA07641; Mon, 18 Aug 1997 01:54:12 -0700 Received: from flame (flame.Sweden.Sun.COM [129.159.128.98]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id BAA11925; Mon, 18 Aug 1997 01:56:40 -0700 (PDT) Date: Mon, 18 Aug 1997 10:57:47 +0200 (MET DST) From: Erik Nordmark - Sun Sweden Reply-To: Erik Nordmark - Sun Sweden Subject: (IPng 4331) Mobile IPv6 requirements on all nodes To: mobile-ip@hosaka.smallworks.com, ipng@sunroof.eng.sun.com Cc: nordmark@jurassic.eng.sun.com, solomon@comm.mot.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 833 At both the mobile-ip and ipngwg meetings in Munich there was consensus on requiring that all IPv6 nodes be able to process the new home address option specified in draft-ietf-mobileip-ipv6-03.txt. We will issue a mobile-ip WG last call on the above draft as soon as some editorial changes have been taken care of. Thus please review the draft and make any comments to the authors and/or the mobile-ip mailing list. Erik & Jim Mobile-ip chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 18 07:09:31 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA07850; Mon, 18 Aug 1997 07:01:13 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA07843; Mon, 18 Aug 1997 07:01:03 -0700 Received: from flame (flame.Sweden.Sun.COM [129.159.128.98]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id HAA19735; Mon, 18 Aug 1997 07:03:11 -0700 (PDT) Date: Mon, 18 Aug 1997 16:04:20 +0200 (MET DST) From: Erik Nordmark - Sun Sweden Reply-To: Erik Nordmark - Sun Sweden Subject: (IPng 4332) Re: IPv6 over FDDI - user_priority To: Andrew Smith Cc: "'Erik Nordmark '" , "'p8021@hepnrc.hep.net '" , "'ipng@sunroof.eng.Sun.COM '" In-Reply-To: "Your message with ID" <116F1CE887F8CF118E2300A0C91368E60522D0@SOL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4413 The original thread of this message (how to handle FDDI and Ethernet bridging) has been resolved by relying of manual configuration of the routers when 802 links of different MTU are bridged. Thus this is far off tha above IPv6 topic but I can help but bring it up. (And no intent to shoot the messanger.) If the 802 architecture endorses the bridging of 802 media with different MTU without providing a mechanism for detecting the link layer (802 level) path MTU it seems to me that the 802 architecture has a significant hole! Relying on upper layer protocols e.g. by having IPv4 fragmentation in bridges, manual configuration, or bridges taking part of IPv4/IPv6 path MTU discovery are nothing but hacks in my opinion. I'm surprised that, to the extend this kind of bridging is endorsed by the architecture, that none of the 802 groups have stepped up to the plate to fix the problem by providing an 802 level path MTU discovery service. End of soapbox. Erik >----- Begin Included Message -----< Date: Wed, 13 Aug 1997 15:30:08 -0700 From: "Andrew Smith" Subject: (IPng 4325) Re: IPv6 over FDDI - user_priority To: "'Erik Nordmark '" Cc: "'p8021@hepnrc.hep.net '" , "'ipng@sunroof.eng.Sun.COM '" Erik, I think that the 802 architecture assumes that upper-layers will sort out their MTU requirements without help from the MAC layer. Up to now this has not been a major problem because the MTU information has been available from one or more of (a) local configuration (b) upper-layer MTU discovery protocols. One existing exception to this was 802.5 bridging which does actually have a MAC-layer MTU discovery built in to source-routing. It has been a minor problem for e.g. FDDI<->Ethernet bridging and some kind bridge vendors helped out by doing the IP fragmentation kludge (but that is not something that can be relied upon and certainly cannot be assumed into any standards). Now, for IPv6 MTU discovery, I think it would be appropriate to use some mechanism related to packet size but not one related to user_priority: this has several advantages: (1) the "test" packets can have the same form as the real data packets (same user_priority, same sorts of packet lengths) (2) it is media-independant - I think this reason is *very important* (3) bridges might be able to do something similar to the FDDI kludge if they wanted to: they could intercept a too-big test packet and, in addition to their normal action which would be to drop it, they could generate an appropriate ICMP error message. I think this IPv6-MTU-kludge would likely not be much more complex than the current IPv4-fragment kludge although I don't think it appropriate to standardise. Andrew ---------- From: Erik Nordmark To: Andrew Smith Cc: Matt Crawford; p8021@hepnrc.hep.net; issll@mercury.lcs.mit.edu; ipng@sunroof.eng.Sun.COM Sent: 8/9/97 3:04 PM Subject:Re: (IPng 4277) RE: IPv6 over FDDI - user_priority > I think that you will find bridges forwarding Tagged 802.1p packets > including > non-zero user_priority values onto Untagged FDDI. According to the > current > 802.1p defaults, the FDDI FC byte would then, by default, encode the > user_priority > received from the incoming 802.1p header (modulo the fact that it > collapes > 6->6 and 7->6 also). I believe this would invalidate your assumption. Does 802.1p address media with different MTU? Or does 802.1 assume that the problem of differing MTUs will be solved by making the bridges handle upper layer protocols such as IP? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- >----- End Included Message -----< -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 18 08:16:57 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA07919; Mon, 18 Aug 1997 08:08:15 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA07912; Mon, 18 Aug 1997 08:08:05 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA17490; Mon, 18 Aug 1997 08:10:38 -0700 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA28556 for ; Mon, 18 Aug 1997 08:10:37 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id LAA21648 for ipng@sunroof.eng.Sun.COM; Mon, 18 Aug 1997 11:10:36 -0400 Date: Mon, 18 Aug 1997 11:10:36 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <970818111035.ZM21646@seawind.bellcore.com> X-Mailer: Z-Mail (4.0.1 13Jan97) To: ipng@sunroof.eng.sun.com Subject: (IPng 4333) Following DNS record discussion in Munich... MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 7012 At the IETF meeting in Munich, during the second session meeting of the IPng working group, we decided to revisit the organization of DNS records, to facilitate renumbering. In the current specification (RFC 1886), the IPv6 address of a station is documented as a 16 octets value in an AAAA record. When an interface is renumbered, the corresponding AAAA record and the reverse mappings have to be updated in the DNS. If a site is renumbered, all AAAA records have to be updated. The addresses are composed of a prefix, that enables Internet routers to forward the packet to a subnetwork, and of an identifier, that uniquely identifies the station within this subnetwork. The identifier is supposedly very stable. It could even be globally unique, world wide, if we really trust the UID assignments. Classic database organization principles teach us that if we want to guaranty consistency, we should only store atoms, not complex relations. According to these principles, instead of storing prefix and identifier in an AAAA record, we should really have two components: 1) in the host entry, we should have an "interface identification" record containing the interface identifier and some pointer to the subnetwork, for example a domain name of that subnetwork. 2) in the subnetwork entry, identified by a domain name, we should have a prefix record that contains the prefix. But database principles could go against network efficiency. These two records would have to be automatically combined by the "gethostbyname" procedure, which means that this procedure would have to perform two accesses instead of one. This would arguably be much slower, and also more error prone. What if, for example, updates to the two entries are not propagated simultaneously to the various DNS caches throughout the Internet? Moreover, the proposal would request the creation of new DNS domains to represent the various subnets. This is an additional management task. After much debate, during the Memphis meeting of the IETF in April 1997, the IPv6 working group decided to keep a single entry, accessible by a single transaction. The main argument was that we could have the best of both worlds if local databases represented addresses as the jointure of two local records, and performed two database accesses whenever the DNS is queried. They could also keep the prefix and interface identifications separated in a master data base, and simply combine them whenever the DNS master files are updated. But, between the Memphis and Munich meetings, we realized that this recombination was far from simple. In order to thwart attacks in which hackers inject phony data in the distributed database, the DNS security enhancements define electronic signatures of DNS records. These signatures are accessible as separate records. They can be used to prove that the value returned by a DNS server, maybe from its cache, is exactly the value that the manager of the original record injected. When we modify a record, we have to compute the new signature, which is a complex operation, involving the exponentiation of very long integers. If we renumber a site and modify thousands of records, we may have to compute thousands of signatures, which may well require several hours. If the AAAA record is split between two components, we only need to recompute the signatures of a few subnet entries, which last seconds, not hours. I believe that it is in fact possible to combine the best of both worlds by simply extending the current definition of AAAA records. Instead of just storing 16 octets of address, we can store in the same record a prefix length and the name of a subnet. +--------------+-------------+-----------------------+ | Address | Pre. length | Domain name of subnet | | (16 octets) | (1 octet) | (variable) | +--------------+-------------+-----------------------+ -- proposed new format of the AAAA record -- The processing, to obtain the , would be as follow: * access each AAAA record. * if the prefix length is set to zero, return. We have found a valid entry. * if the prefix length, L, is larger than zero, access the AAAA records of the named subnet. Combine the L first bits of each of the subnet addresses with the (128 - L) bits of the initial AAAA record. The extension of the AAAA record to contain an optional subnet pointer allows us to experiment with several structures of the DNS entries: * when the number of hosts is small, managers may opt for a simple structure where the prefix length is set to zero. In this case, they only incur two bytes of overhead per AAAA record, one octet of length and one octet to indicate a null length domain name. * when the number of subnet is small, or if renumbering individual subnets is not a concern, managers can set the prefix length to 48 and document in the AAAA records the name of the site. The site's records will be "self sufficient", their prefix length will be set to zero. * for complex sites whose subnets are individually renumbered, managers will set the prefix length to 64 and document in the AAAA records the name of the subnet. The subnet's records should normally be "self sufficient", but we could envisage to let them point to the name of the site, in which case we would have to recurse twice when accessing a station's address. These extensions lead to very simple processing rules in DNS servers. When an AAAA record contains a domain name, the AAAA records of that domain should be added in the "additional information" section. This is similar to existing processing rules for names in NS or MX records. This means that in most cases, the host and site records will be obtained in a single transaction, alleviating the concern for access speed. The main drawback of unification is that messages will be somewhat longer, carrying 128 bits when 48, 64 or 80 would have sufficed. We could reduce that overhead by adopting a variable length format, but this would be more complex and possibly more error prone. A small drawback is that we have to made up "non significant" bits for the host. I propose to use either the site local format, when the record points to a site name, or the link local format, when the record point to subnet name. In fact, this structure can help resolvers recognize that the destination belongs to the same site, or subnet, than the requesting host. In this case, they may well decide to just use the site local address. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 18 11:58:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08377; Mon, 18 Aug 1997 11:48:18 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08370; Mon, 18 Aug 1997 11:48:12 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id LAA27194 for ; Mon, 18 Aug 1997 11:50:46 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA06884; Mon, 18 Aug 1997 11:48:41 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA08336; Mon, 18 Aug 1997 11:39:27 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA11628; Mon, 18 Aug 1997 11:41:55 -0700 Received: from mailhost1.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id LAA08047; Mon, 18 Aug 1997 11:41:56 -0700 Received: from ns2.BayNetworks.COM (screen2r.BayNetworks.COM [134.177.3.1]) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id LAA10508 Received: from pobox.corpwest.BayNetworks.COM (mailhost.corpwest.baynetworks.com [134.177.1.95]) by ns2.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id LAA19868 Posted-Date: Mon, 18 Aug 1997 11:41:52 -0700 (PDT) Received: from sc-mail1.corpwest.BayNetworks.com (sc-mail1-hme0.corpwest.baynetworks.com [134.177.64.91]) by pobox.corpwest.BayNetworks.COM (SMI-8.6/BNET-97/05/05-S) with SMTP id LAA06007; Mon, 18 Aug 1997 11:41:48 -0700 for Received: from [134.177.35.104] by sc-mail1.corpwest.BayNetworks.com (post.office MTA v2.0 0529 ID# 0-13459) with ESMTP id AAB26905; Mon, 18 Aug 1997 11:41:45 -0700 X-Sender: gthompso@sc-mail1.corpwest.baynetworks.com Message-Id: In-Reply-To: References: "Your message with ID" <116F1CE887F8CF118E2300A0C91368E60522D0@SOL> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Aug 1997 11:32:59 -0700 To: Erik Nordmark - Sun Sweden From: Geoff_Thompson@BayNetworks.COM (Geoff Thompson) Subject: (IPng 4336) Re: IPv6 over FDDI - user_priority Cc: "'p8021@hepnrc.hep.net '" , "'ipng@sunroof.eng.Sun.COM '" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2276 Erik- If you think this is an "802 Architecture issue" then immediately is the time to bring it up as a DISAPPROVE comment on the 802 Overview and Architecture (Draft 23) that is in ballot. A quick review of sub-clause 6.3.2 doesn't turn up any text that addresses this issue although figure 5 shows a network where this issue would come up. Geoff At 7:04 AM -0700 8/18/97, Erik Nordmark - Sun Sweden wrote: >The original thread of this message (how to handle FDDI and Ethernet bridging) >has been resolved by relying of manual configuration of the routers >when 802 links of different MTU are bridged. > >Thus this is far off tha above IPv6 topic but I can help but bring it up. >(And no intent to shoot the messanger.) > >If the 802 architecture endorses the bridging of 802 media with different >MTU without providing a mechanism for detecting the link layer (802 level) >path MTU it seems to me that the 802 architecture has a significant hole! >Relying on upper layer protocols e.g. by having IPv4 fragmentation >in bridges, manual configuration, or bridges taking part of IPv4/IPv6 path >MTU discovery are nothing but hacks in my opinion. > >I'm surprised that, to the extend this kind of bridging is endorsed >by the architecture, that none of the 802 groups have stepped up to the >plate to fix the problem by providing an 802 level path MTU discovery >service. > >End of soapbox. > > Erik > > |=========================================| | Geoffrey O. Thompson | | Chair IEEE 802.3 | | Bay Networks, Inc. | | 4401 Great America Parkway | | P. O. Box 58185 | | Santa Clara, CA 95052-8185 USA | | Phone: +1 408 495 1339 | | Fax: +1 408 988 5525 | | E-Mail: geoff_thompson@baynetworks.com | |=========================================| -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 18 16:59:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA09068; Mon, 18 Aug 1997 16:48:55 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id QAA09061; Mon, 18 Aug 1997 16:48:47 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id QAA00611; Mon, 18 Aug 1997 16:51:18 -0700 Received: from relay7.UU.NET (relay7.UU.NET [192.48.96.17]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id QAA19152 for ; Mon, 18 Aug 1997 16:51:18 -0700 Received: from rodan.UU.NET by relay7.UU.NET with ESMTP (peer crosschecked as: rodan.UU.NET [153.39.130.10]) id QQddet24146; Mon, 18 Aug 1997 19:51:10 -0400 (EDT) Received: from localhost by rodan.UU.NET with SMTP (peer crosschecked as: mo@localhost) id QQddet19342; Mon, 18 Aug 1997 19:50:51 -0400 (EDT) Message-Id: To: huitema@bellcore.com (Christian Huitema) cc: ipng@sunroof.eng.sun.com Subject: (IPng 4337) Re: Following DNS record discussion in Munich... In-reply-to: Your message of "Mon, 18 Aug 1997 11:10:36 EDT." <970818111035.ZM21646@seawind.bellcore.com> Date: Mon, 18 Aug 1997 19:50:51 -0400 From: "Mike O'Dell" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 759 the *semantics* of AAAA records does not preclude actually storing the information differently a DNS server can return a AAAA record query while storing the data internally in two distinct pieces, putting them together when the query is answered the notion that DNS is somehow dictating precise implementations when completely unecessary seems somewhat suspect at best -mo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 18 17:11:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA09224; Mon, 18 Aug 1997 17:00:20 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id RAA09217; Mon, 18 Aug 1997 17:00:09 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id RAA03316; Mon, 18 Aug 1997 17:02:40 -0700 Received: from seawind.bellcore.com (seawind.bellcore.com [192.4.18.101]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id RAA22633 for ; Mon, 18 Aug 1997 17:02:41 -0700 Received: (from huitema@localhost) by seawind.bellcore.com (8.6.9/8.6.10) id UAA21781; Mon, 18 Aug 1997 20:02:38 -0400 Date: Mon, 18 Aug 1997 20:02:38 -0400 From: huitema@bellcore.com (Christian Huitema) Message-Id: <970818200238.ZM21779@seawind.bellcore.com> In-Reply-To: "Mike O'Dell" "Re: (IPng 4333) Following DNS record discussion in Munich..." (Aug 18, 7:50pm) References: X-Mailer: Z-Mail (4.0.1 13Jan97) To: "Mike O'Dell" , huitema@bellcore.com (Christian Huitema) Subject: (IPng 4338) Re: Following DNS record discussion in Munich... Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1161 Mike, As explained in my note, the problem arises when you have to sign the DNS records, to avoid various name server spoofing attacks. Signing requires computing at least one RSA signature per record, which could be horrendeously long if you have to change the 10000 records of a site at the same time. That argument carried the day in Munich, and the decision was made to separate the AAAA into a prefix and an ESD records. My proposal merely aims at "letting the manager choose". If signature turns out to not be a problem, the only cost is 2 additional null bytes per AAAA record -- in fact, we could even finess that. On the contrary, if renumbering is hampered by signature, managers can decide at any stage to revisit the partition of the data. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Aug 18 22:55:16 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA09606; Mon, 18 Aug 1997 22:47:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id WAA09599; Mon, 18 Aug 1997 22:46:53 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id WAA15390; Mon, 18 Aug 1997 22:49:26 -0700 Received: from hitiij.hitachi.co.jp (hitiij.hitachi.co.jp [133.145.224.3]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id WAA03738 for ; Mon, 18 Aug 1997 22:49:27 -0700 Received: from isrdgw.isrd.hitachi.co.jp by hitiij.hitachi.co.jp (8.8.5+2.7Wbeta5/3.5W-hitiij) id OAA01549; Tue, 19 Aug 1997 14:45:01 +0900 (JST) Received: from magic.33g.isrd.hitachi.co.jp by isrdgw.isrd.hitachi.co.jp (8.6.9+2.4W/2.7W-ISRD) id OAA12630; Tue, 19 Aug 1997 14:46:23 +0900 Message-Id: <9708190552.AA00097@magic.33g.isrd.hitachi.co.jp> From: tsuchiya Date: Tue, 19 Aug 1997 14:52:52 +0900 To: gaurang@VNET.IBM.COM, thartric@mentat.com, conta@zk3.dec.com, deering@parc.xerox.com, ipng@sunroof.eng.sun.com Cc: tsuchi@isrd.hitachi.co.jp Subject: (IPng 4340) ICMP Echo MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2372 Dear all, Thanks Tim and Gaurang Shah. My problem is below. >> Ethernet >> +-----+ MTU=1500 +------+ >> |Host 1+--------------+Host 2| >> +-----+ +------+ >> >> If Host1 send ICMPv6 Echo request(=2000bytes > MTU) to Host2, >> What should Host2 do? >> >> Which is correct? >> (1) Host2 should return ICMPv6 Echo reply to Host1, >> only top of 1500bytes in ICMP Echo request. >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> (2) Host2 should return ICMPv6 Echo reply to Host1, >> all of 2000bytes in ICMP Echo request. >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > thartric@mentat.com (Tim Hartrick) wroute: >We implement (2) at the moment. If we are going to allow >echo requests to be fragmented it the first place then it >seems like the correct thing to do. gaurang@VNET.IBM.COM wroute: >I think, it has to be (2), otherwise round-trip time from ping >is invalid. I think it should be (2), too. Dear RFC1885 auther I read RFC1885 page16 and have a question above. ~~~~~~~~~~~~~~ When Host1 send ICMPv6 Echo request(=2000bytes > MTU) to Host2, Host2 should retuen ICMPv6 Echo reply, which is all of 2000bytes, not top of 1500bytes in ICMPv6 Echo request. ^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^ Is that right? In RFC1885 page 16: >> >The data received in the ICMPv6 Echo Request message MUST be returned >> > >> >entirely and unmodified in the ICMPv6 Echo Reply message, unless the >> > ~~~~~~~~~~ >> >Echo Reply would exceed the MTU of the path back to the Echo >> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> >requester, in which case the data is truncated to fit that path MTU. >> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Kind regards. ---------------------------------------------------------- Kazuaki Tsuchiya(E-mail:tsuchi@isrd.hitachi.co.jp) Hitachi, Ltd. in Japan. Phone:044-549-1714 Fax:044-549-1721 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 19 03:53:26 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA09892; Tue, 19 Aug 1997 03:45:49 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA09885; Tue, 19 Aug 1997 03:45:40 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id DAA09031; Tue, 19 Aug 1997 03:48:13 -0700 Received: from tera.csl.sony.co.jp (tera.csl.sony.co.jp [133.138.1.13]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id DAA21992; Tue, 19 Aug 1997 03:48:11 -0700 Received: from vega.csl.sony.co.jp (vega-43.csl.sony.co.jp [43.27.98.24]) by tera.csl.sony.co.jp (8.8.4/3.3W3) with SMTP id TAA09383; Tue, 19 Aug 1997 19:47:35 +0900 (JST) Message-Id: <199708191047.TAA09383@tera.csl.sony.co.jp> X-Sender: tera@tera.csl.sony.co.jp X-Mailer: Windows Eudora Pro Version 3.0.1-J (32) Date: Tue, 19 Aug 1997 19:44:25 +0900 To: Erik Nordmark - Sun Sweden From: Fumio Teraoka Subject: (IPng 4343) Re: (mobile-ip) Mobile IPv6 requirements on all nodes Cc: mobile-ip@hosaka.SmallWorks.COM, ipng@sunroof.eng.sun.com, nordmark@jurassic.eng.sun.com, solomon@comm.mot.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1658 Erik & Jim, draft-ietf-mobileip-ipv6-03.txt introduces "source home address" destination option to allow a mobile node to send a packet that has the topologically correct source address. According to this idea, it is more reasonable to introduce "destination home address" destination option to allow a correnspondent node to send a packet to the care-of address of the mobile node, instead of using the routing header. Fumio Teraoka At 10:57 97/08/18 +0200, Erik Nordmark - Sun Sweden wrote: > > At both the mobile-ip and ipngwg meetings in Munich there was consensus > on requiring that all IPv6 nodes be able to process the new home address > option specified in draft-ietf-mobileip-ipv6-03.txt. > > We will issue a mobile-ip WG last call on the above draft as soon as > some editorial changes have been taken care of. > Thus please review the draft and make any comments to the authors and/or the > mobile-ip mailing list. > > Erik & Jim > Mobile-ip chairs > > ----------------------------------------------------------------------------- > IETF Mobile IP Working Group Mailing List - Archives: software.watson.ibm.com > Unsubscribe: unsubscribe mobile-ip (as message body, not subject) > Direct all administrative requests to majordomo@smallworks.com > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 19 04:07:48 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA09906; Tue, 19 Aug 1997 03:58:47 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id DAA09899; Tue, 19 Aug 1997 03:58:30 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA09756; Tue, 19 Aug 1997 04:01:04 -0700 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA24040 for ; Tue, 19 Aug 1997 04:01:05 -0700 Received: from big-dawgs.cisco.com (herndon-dhcp-121.cisco.com [171.68.53.121]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id EAA00119 for ; Tue, 19 Aug 1997 04:01:03 -0700 (PDT) Message-Id: <3.0.3.32.19970819070101.006c104c@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 19 Aug 1997 07:01:01 -0400 To: ipng@sunroof.eng.sun.com From: Paul Ferguson Subject: (IPng 4344) Proposed mod. to v6 Priority Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 745 Out of curiousity, does it appear that the 'class' semantics outlined in draft-ietf-ipngwg-ipv6-spec-v2-00.txt will be adopted? I missed this session in Munich and would like to understand if there is consensus to adopt this specific filed semantics, adopt all of the changes in the draft, or adopt portions of the draft to update RFC1883 ad hoc. Thanks, - paul -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 19 07:15:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA10019; Tue, 19 Aug 1997 07:06:38 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA10012; Tue, 19 Aug 1997 07:06:29 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA02203; Tue, 19 Aug 1997 07:09:04 -0700 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA05403 for ; Tue, 19 Aug 1997 07:09:04 -0700 Received: from big-dawgs.cisco.com (herndon-dhcp-121.cisco.com [171.68.53.121]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with SMTP id HAA12385; Tue, 19 Aug 1997 07:08:57 -0700 (PDT) Message-Id: <3.0.3.32.19970819100855.006d23c4@lint.cisco.com> X-Sender: pferguso@lint.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 19 Aug 1997 10:08:55 -0400 To: slblake@raleigh.ibm.com From: Paul Ferguson Subject: (IPng 4346) Re: Proposed mod. to v6 Priority Cc: ipng@sunroof.eng.sun.com In-Reply-To: <9708191352.AA28172@vision.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 621 At 09:52 AM 08/19/97 EDT, Steven L Blake wrote: > Of course, if a working group is formed to >standardize differentiated services encodings then they ought to be >consistent between IPv4 and IPv6. > Agreed. Makes life much easier. - paul -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 19 07:27:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA10029; Tue, 19 Aug 1997 07:17:24 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA10022; Tue, 19 Aug 1997 07:17:08 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA05350; Tue, 19 Aug 1997 07:19:42 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA08778 for ; Tue, 19 Aug 1997 07:19:41 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id JAA02905; Tue, 19 Aug 1997 09:19:15 -0500 Message-Id: <199708191419.JAA02905@gungnir.fnal.gov> To: huitema@bellcore.com (Christian Huitema) Cc: "Mike O'Dell" , ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4347) Re: Following DNS record discussion in Munich... In-reply-to: Your message of Mon, 18 Aug 1997 20:02:38 EDT. <970818200238.ZM21779@seawind.bellcore.com> Date: Tue, 19 Aug 1997 09:19:15 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2164 > As explained in my note, the problem arises when you have to sign the DNS > records, to avoid various name server spoofing attacks. Signing requires > computing at least one RSA signature per record, which could be > horrendeously long if you have to change the 10000 records of a site > at the same time. That argument carried the day in Munich, and the > decision was made to separate the AAAA into a prefix and an ESD records. > [...] Christian Huitema Whoa! Did I suffer a short coma? I do not recall *any* argument "carrying the day in Munich" -- there was no time. We did think separating the AAAA was a good idea in Palo Alto, and Jim Bound wrote it up by Memphis, at which meeting it was one of those topics crammed in near the end-of-session rush and did not get a clear go-ahead or no-go. I myself agree that it would be a good thing, except for the dnssec obstacle. But the dnssec difficulty is not, I claim, in the generation of the new, signed zone file. For example, if I had to renumber my site and sign a new A version of each of my 9325 current A records, and if it took an unimaginable 5 seconds per record to sign them (although PGP 2.6.2 on my system can sign the text form of an A record in an unresolved time less than 0.1 of a CPU-second), that would take 12 hours. I'm sure I have more than 12 hours notice for renumbering. The difficulty lies in the DNS client which tries to check the signature of a AAAA record which has been synthesized from parts by a server which has no access to the secret key. That client must get the parts with their signatures, and hence must know of the AAAA synthesis method. Therefore, this "AAAA synthesis" requires all DNSSEC clients to understand the details. Is this requirement timely? Matt Crawford -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 19 09:12:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA10162; Tue, 19 Aug 1997 08:58:02 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA10155; Tue, 19 Aug 1997 08:57:56 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA06390 for ; Tue, 19 Aug 1997 09:00:32 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA08232; Tue, 19 Aug 1997 08:58:27 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id AAA09778; Tue, 19 Aug 1997 00:10:34 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id AAA23639; Tue, 19 Aug 1997 00:13:05 -0700 Received: from ietf.org ([132.151.1.19]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id AAA16634 for ; Tue, 19 Aug 1997 00:13:04 -0700 Received: by ietf.org id aa00786; 19 Aug 97 3:08 EDT Received: from ietf.org by ietf.org id aa06306; 18 Aug 97 9:41 EDT Received: from info.dsv.su.se by ietf.org id aa06127; 18 Aug 97 9:34 EDT Received: from [130.237.150.138] (jph1.dsv.su.se [130.237.150.138]) by info.dsv.su.se (8.8.5/8.8.5) with ESMTP id PAA27479; Mon, 18 Aug 1997 15:34:00 +0200 (MET DST) X-Sender: jpalme@dsv.su.se (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Aug 1997 15:34:05 +0200 To: IETF general mailing list From: Jacob Palme Subject: (IPng 4348) Personal notes from some IETF working group meetings in Munich Cc: Web4Groups technical , TERENA WG on e-mail Source-Info: From (or Sender) name not authenticated. Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1124 My personal notes (not official minutes) from some of the applications area working groups during the IETF meeting in Munich, August 1997, is available at URL http://www.dsv.su.se/~jpalme/ietf/ietf-august-97-notes.html. The notes cover partially the following working groups and BOFs: Hypertext Transfer Protocol WG Webdav - WWW Distributed Authoring and Versioning WG A character set policy for the IETF BOF Drums - revision of the e-mail standards WG Registry Information Database Exchange Formats and Protocols BOF Sending HTML in e-mail - MHTML WG ------------------------------------------------------------------------ Jacob Palme (Stockholm University and KTH) for more info see URL: http://www.dsv.su.se/~jpalme -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 19 09:13:10 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA10171; Tue, 19 Aug 1997 08:58:38 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA10164; Tue, 19 Aug 1997 08:58:33 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA06476 for ; Tue, 19 Aug 1997 09:01:08 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA08259; Tue, 19 Aug 1997 08:59:03 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id BAA09834; Tue, 19 Aug 1997 01:42:22 -0700 Received: from sunmail1.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id BAA00905; Tue, 19 Aug 1997 01:44:57 -0700 Received: from sun.Eng.Sun.COM by sunmail1.Sun.COM (SMI-8.6/SMI-4.1) id BAA03006; Tue, 19 Aug 1997 01:44:55 -0700 Received: from fujitsuI.UUCP by sun.Eng.Sun.COM (4.1/SMI-4.1) id AA04162; Tue, 19 Aug 97 01:44:55 PDT Received: from fdmmail.fujitsu.co.jp ([133.161.11.2]) by fujitsuI.fujitsu.com (8.8.5/8.7.3) with ESMTP id AAA04001 for ; Tue, 19 Aug 1997 00:56:27 -0700 (PDT) Received: from guitarman.nd.net.fujitsu.co.jp by fdmmail.fujitsu.co.jp (8.8.5+2.7Wbeta5/3.5Wpl3-970815-Fujitsu Domain Mail Master) id QAA05031; Tue, 19 Aug 1997 16:56:25 +0900 (JST) Received: from guitarman (localhost [127.0.0.1]) by guitarman.nd.net.fujitsu.co.jp (8.7.4/8.6.9) with ESMTP id RAA04746 for ; Tue, 19 Aug 1997 17:01:43 +0900 (JST) Message-Id: <199708190801.RAA04746@guitarman.nd.net.fujitsu.co.jp> To: fujitsuI!isrd.hitachi.co.jp!tsuchi@Eng Cc: fujitsuI!VNET.IBM.COM!gaurang@Eng, fujitsuI!mentat.com!thartric@Eng, fujitsuI!zk3.dec.com!conta@Eng, fujitsuI!parc.xerox.com!deering@Eng, fujitsuI!sunroof.Eng.Sun.COM!ipng@Eng Subject: (IPng 4349) Re: ICMP Echo From: Yoshinobu Inoue In-Reply-To: Your message of "Tue, 19 Aug 1997 14:52:52 +0900" References: <9708190552.AA00097@magic.33g.isrd.hitachi.co.jp> X-Mailer: Mew version 1.06 on Emacs 19.28.1, Mule 2.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Tue, 19 Aug 1997 15:56:49 +0900 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3044 Hello, all, I have another comment about this topic, that each of host and router should be able to choose different option, and router should be able to choose option (1) in Mr. Tsuchiya's figure, at least in some condition. Because, copying back full big ICMP Echo packet will be an extra burden for a router, and sending many big ICMP packet to a router by fragmentation is possibly some kind of security attack. So I think router should be able to choose option (1) to protect its resouces, at least by some manual configuration. Regards, Yoshinobu Inoue > Dear all, > > Thanks Tim and Gaurang Shah. > > My problem is below. > >> Ethernet > >> +-----+ MTU=1500 +------+ > >> |Host 1+--------------+Host 2| > >> +-----+ +------+ > >> > >> If Host1 send ICMPv6 Echo request(=2000bytes > MTU) to Host2, > >> What should Host2 do? > >> > >> Which is correct? > >> (1) Host2 should return ICMPv6 Echo reply to Host1, > >> only top of 1500bytes in ICMP Echo request. > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> (2) Host2 should return ICMPv6 Echo reply to Host1, > >> all of 2000bytes in ICMP Echo request. > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > thartric@mentat.com (Tim Hartrick) wroute: > >We implement (2) at the moment. If we are going to allow > >echo requests to be fragmented it the first place then it > >seems like the correct thing to do. > > gaurang@VNET.IBM.COM wroute: > >I think, it has to be (2), otherwise round-trip time from ping > >is invalid. > > I think it should be (2), too. > > Dear RFC1885 auther > > I read RFC1885 page16 and have a question above. > ~~~~~~~~~~~~~~ > When Host1 send ICMPv6 Echo request(=2000bytes > MTU) to Host2, > Host2 should retuen ICMPv6 Echo reply, which is all of 2000bytes, > not top of 1500bytes in ICMPv6 Echo request. ^^^^^^^^^^^^^^^^^ > ^^^^^^^^^^^^^^^^^^^^ > Is that right? > > In RFC1885 page 16: > >> >The data received in the ICMPv6 Echo Request message MUST be returned > >> > > >> >entirely and unmodified in the ICMPv6 Echo Reply message, unless the > >> > ~~~~~~~~~~ > >> >Echo Reply would exceed the MTU of the path back to the Echo > >> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> >requester, in which case the data is truncated to fit that path MTU. > >> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Kind regards. > > ---------------------------------------------------------- > Kazuaki Tsuchiya(E-mail:tsuchi@isrd.hitachi.co.jp) > Hitachi, Ltd. in Japan. > Phone:044-549-1714 Fax:044-549-1721 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 19 09:14:32 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10180; Tue, 19 Aug 1997 09:00:28 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA10173; Tue, 19 Aug 1997 09:00:18 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA06703 for ; Tue, 19 Aug 1997 09:02:54 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA08290; Tue, 19 Aug 1997 09:00:48 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id GAA09996; Tue, 19 Aug 1997 06:50:04 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id GAA27735; Tue, 19 Aug 1997 06:52:37 -0700 Received: from socks1.raleigh.ibm.com (socks1b.raleigh.ibm.com [204.146.167.124]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id GAA29601 for ; Tue, 19 Aug 1997 06:52:38 -0700 Received: from rtpmail02.raleigh.ibm.com by socks1.raleigh.ibm.com (AIX 4.1/UCB 5.64/RTP-FW1.0) id AA27832; Tue, 19 Aug 1997 09:52:27 -0400 Received: from vision.raleigh.ibm.com (vision.raleigh.ibm.com [9.37.177.224]) by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id JAA23052; Tue, 19 Aug 1997 09:52:29 -0400 Received: by vision.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA28172; Tue, 19 Aug 1997 09:52:12 -0400 Message-Id: <9708191352.AA28172@vision.raleigh.ibm.com> X-Mailer: exmh version 1.6.9 8/22/96 To: Paul Ferguson Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4350) Re: Proposed mod. to v6 Priority Reply-To: slblake@raleigh.ibm.com In-Reply-To: Your message of "Tue, 19 Aug 1997 07:01:01 EDT." <3.0.3.32.19970819070101.006c104c@lint.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Aug 1997 09:52:09 EDT From: Steven L Blake Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1911 Paul Ferguson wrote: > Out of curiousity, does it appear that the 'class' semantics > outlined in draft-ietf-ipngwg-ipv6-spec-v2-00.txt will be > adopted? While I was still in the room for the first session, the WG agreed to expand the class field to eight bits (by stealing four from the flow label), and to retain the semantics from draft-ietf-ipngwg-ipv6-spec-v2-00 in the top four bits, so that the first word of the IPv6 header would look like: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VER | CLASS | FLOW LABEL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D| Prio| Resv | (this may have changed after I left). Interestingly, the first four bits of the IPv4 Precedence/TOS field look like this [RFC1349]: +-+-+-+-+-+-+-+-+ | Pre |D| ... |0| +-+-+-+-+-+-+-+-+ One could argue that for consistency's sake, D and Prio should be reversed in the IPv6 Class field. Of course, if a working group is formed to standardize differentiated services encodings then they ought to be consistent between IPv4 and IPv6. Regards, /*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | Steven L. Blake slblake@raleigh.ibm.com | | Internetworking Technology (919)254-2030 (work) | | IBM Networking Hardware Division (919)254-5483 (fax) | | "You like the 'Net? You ain't seen nothin' yet!" | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 20 15:31:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA12253; Wed, 20 Aug 1997 15:22:16 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA12241; Wed, 20 Aug 1997 15:18:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA22993; Wed, 20 Aug 1997 15:21:20 -0700 Received: from gungnir.fnal.gov (gungnir.fnal.gov [131.225.80.1]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id PAA22661 for ; Wed, 20 Aug 1997 15:21:24 -0700 Received: from gungnir.fnal.gov by gungnir.fnal.gov (SMI-8.6/SMI-SVR4) id RAA07149; Wed, 20 Aug 1997 17:21:22 -0500 Message-Id: <199708202221.RAA07149@gungnir.fnal.gov> To: ipng@sunroof.eng.sun.com From: "Matt Crawford" Subject: (IPng 4351) v6-over-{ethernet,fddi} Date: Wed, 20 Aug 1997 17:21:22 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 751 Once again, I have sent new drafts of ipv6-over-ethernet and -fddi to internet-drafts. The changes consist of: Ethernet: Fix one spelling error FDDI: Ditch the MTU-discovery trick which relies on the LLC priority field. Forthcoming IEEE 802.1p work will allow bridges to preserve the priority field across an intervening ethernet, which destroys any such method. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 22 07:42:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA13698; Fri, 22 Aug 1997 07:33:51 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA13691; Fri, 22 Aug 1997 07:33:42 -0700 Received: from venus.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id HAA22061; Fri, 22 Aug 1997 07:36:17 -0700 Received: from ayax.uniandes.edu.co (Ayax.uniandes.edu.co [157.253.50.3]) by venus.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA03442 for ; Fri, 22 Aug 1997 07:36:05 -0700 Received: from isis.uniandes.edu.co by ayax.uniandes.edu.co (SMI-8.6/SMI-SVR4) id JAA26887; Fri, 22 Aug 1997 09:51:11 +0500 Date: Fri, 22 Aug 1997 09:31:02 +0500 (GMT) From: Yezid Enrique Donoso Meisel To: ipng@sunroof.eng.sun.com Subject: (IPng 4352) Question about the firewall in IPng Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 585 Hi, I am a student of the computer science Magister at the Andes University in Colombia, my research is about firewall in IPv6. I am needing information about the design in this subject. Thank you. Yezid -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Aug 26 21:49:34 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA17821; Tue, 26 Aug 1997 21:41:23 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id VAA17814; Tue, 26 Aug 1997 21:41:15 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id VAA19553; Tue, 26 Aug 1997 21:43:51 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id VAA03898 for ; Tue, 26 Aug 1997 21:43:55 -0700 Received: by smtp.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 27 Aug 1997 00:46:53 -0400 Message-ID: From: "Conta, Alex" To: gaurang@VNET.IBM.COM, thartric@mentat.com, conta@zk3.dec.com, deering@parc.xerox.com, ipng@sunroof.eng.sun.com Cc: tsuchi@isrd.hitachi.co.jp Subject: (IPng 4355) RE: ICMP Echo Date: Wed, 27 Aug 1997 00:46:50 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 4055 This has been discussed at length at the time of writing the specifications. Which, as this shows, does not mean it is no longer discussed.... The current text of the ICMP specification reflects the fact that the ICMP Echo message is designed to rather check the IP connectivity between two nodes, hosts or routers. The fragmentation in hosts, in particular of a reply on a path with a smaller MTU, presents the probability of dropping one or more fragments of the reply, which wrongly would be interpreted by the receiver of the incomplete ICMP datagram (the sender of the Echo) as an absence of connectivity. Fragmentation in routers is not mandatory. The ICMP specification allows routers to return ICMP Echo Replies even when the size of an ICMP message would, by exceeding the MTU of the return path, result, in the absence of fragmentation, in a no reply. Alex > -----Original Message----- > From: owner-ipng@sunroof.Eng.Sun.COM > [SMTP:owner-ipng@sunroof.Eng.Sun.COM] > Sent: Tuesday, August 19, 1997 7:53 AM > To: gaurang@VNET.IBM.COM; thartric@mentat.com; conta@zk3.dec.com; > deering@parc.xerox.com; ipng@sunroof.Eng.Sun.COM > Cc: tsuchi@isrd.hitachi.co.jp > Subject: (IPng 4340) ICMP Echo > > Dear all, > > > Thanks Tim and Gaurang Shah. > > My problem is below. > >> Ethernet > >> +-----+ MTU=1500 +------+ > >> |Host 1+--------------+Host 2| > >> +-----+ +------+ > >> > >> If Host1 send ICMPv6 Echo request(=2000bytes > MTU) to Host2, > >> What should Host2 do? > >> > >> Which is correct? > >> (1) Host2 should return ICMPv6 Echo reply to Host1, > >> only top of 1500bytes in ICMP Echo request. > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> (2) Host2 should return ICMPv6 Echo reply to Host1, > >> all of 2000bytes in ICMP Echo request. > >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> > > > > thartric@mentat.com (Tim Hartrick) wroute: > >We implement (2) at the moment. If we are going to allow > >echo requests to be fragmented it the first place then it > >seems like the correct thing to do. > > gaurang@VNET.IBM.COM wroute: > >I think, it has to be (2), otherwise round-trip time from ping > >is invalid. > > I think it should be (2), too. > > > > Dear RFC1885 auther > > I read RFC1885 page16 and have a question above. > ~~~~~~~~~~~~~~ > When Host1 send ICMPv6 Echo request(=2000bytes > MTU) to Host2, > Host2 should retuen ICMPv6 Echo reply, which is all of 2000bytes, > not top of 1500bytes in ICMPv6 Echo request. ^^^^^^^^^^^^^^^^^ > ^^^^^^^^^^^^^^^^^^^^ > Is that right? > > In RFC1885 page 16: > >> >The data received in the ICMPv6 Echo Request message MUST be > returned > >> > > >> >entirely and unmodified in the ICMPv6 Echo Reply message, unless > the > >> > > ~~~~~~~~~~ > >> >Echo Reply would exceed the MTU of the path back to the Echo > >> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> >requester, in which case the data is truncated to fit that path > MTU. > >> > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > Kind regards. > > ---------------------------------------------------------- > Kazuaki Tsuchiya(E-mail:tsuchi@isrd.hitachi.co.jp) > Hitachi, Ltd. in Japan. > Phone:044-549-1714 Fax:044-549-1721 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 27 04:12:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA18072; Wed, 27 Aug 1997 04:04:02 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id EAA18065; Wed, 27 Aug 1997 04:03:52 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id EAA21785; Wed, 27 Aug 1997 04:06:31 -0700 Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA12712 for ; Wed, 27 Aug 1997 04:06:31 -0700 Received: from [203.154.130.30] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.51) id AA17378; Wed, 27 Aug 1997 21:06:15 +1000 (from kre@cs.mu.oz.au) Received: from aussie.cs.mu.OZ.AU (kre@localhost [127.0.0.1]) by aussie.cs.mu.OZ.AU (8.8.5/8.8.5) with ESMTP id QAA00591; Wed, 27 Aug 1997 16:00:42 +0700 (ICT) From: Robert Elz To: huitema@bellcore.com (Christian Huitema) Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4356) Re: Following DNS record discussion in Munich... In-Reply-To: Your message of "Mon, 18 Aug 1997 11:10:36 -0400." <970818111035.ZM21646@seawind.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 27 Aug 1997 16:00:39 +0700 Message-Id: <587.872672439@aussie.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 16468 Date: Mon, 18 Aug 1997 11:10:36 -0400 From: huitema@bellcore.com (Christian Huitema) Message-ID: <970818111035.ZM21646@seawind.bellcore.com> Apologies for taking so long to getting around to replying to this stream, but at the same time, perhaps this is useful, as the discussion seems to have tailed off, and this one almost certainly should not, as it is something which should be pursued. But database principles could go against network efficiency. These two records would have to be automatically combined by the "gethostbyname" procedure, which means that this procedure would have to perform two accesses instead of one. This is not usually going to be true with just a modicum of rational DNS design - any more than it is for MX record lookups, or NS record lookups, which return a name, which must subsequently (to be useful as more than an ornament) be translated into an A record. In practice the vast majority of MX or A record lookups return the answer to the A request in the same packet, as doing so costs almost nothing where it is available already, and the information is almost always necessary and useful. The same can clearly be done for an AAAA record lookup, if that is composed of two parts just as easily, and in most cases the only extra overhead is a trivial amount of CPU to extract the extra data from the response (and to insert it initially) and then combine the parts to make the final record. You made that point lower down in your message, so I am not sure why you seem to make the opposite point in the lead in, which would tend to prejudice the scheme in the minds of the readers before realising that it really isn't the case at all. Note one important element though - just as for MX and NS record lookups, the additional data is returned only when it is readily available to the server (usually it is, but not always), in other cases you want the client to perform the extra lookup for two reasons - one is that it might already have the missing data, and so no extra query is needed anywhere at all, and where doesn't it might be more convenient for the client to perform the lookup (there's no way to know for sure). The signature issue isn't relevant here unless one postulated the combined record being returned rather than its parts, which I think is simply not worth considering for more reasons than this. This would arguably be much slower, and also more error prone. It would only rarely be slower, and not at all more error prone. What if, for example, updates to the two entries are not propagated simultaneously to the various DNS caches throughout the Internet? I'm not sure what you're getting at here, the DNS has always had a window of inconsistent results from caches that are yet to time out stale data, this is not new, and this proposal makes it no worse. A cache that had old data for some part of the two part scheme (or all of it) would have been just as likely to have old data for the AAAA record, and for the results to have been old. Any two part name scheme makes it actually more likely for some kind of consistency to be retained, as in the event of a renumbering of a site, in most cases, only one record will need to be updated, that record will either be correct, or old, at any particular cache, meaning that all of a site's addresses will either be new or old, and change (as viewed by any particular client) together, rather than piecemeal as the various individual names time out of various caches (largely depending upon when they were last accessed before the change). This also makes it easier for the DNS admin to properly plan to time out the prefix address record at the same time as the prefix is actally withdrawn. Manipulating the timer on one (or a few) records is a much less daunting prospect that attempting to make all AAAA records time out together (hundreds, thousands, or more, of them). So I submit that the divided AAAA record scheme actually improves the chances of a consistent DNS than reduces them. (Of course, anyone can publish bogus data, deliberately or by accident, attempting to prevent that is hopeless). Moreover, the proposal would request the creation of new DNS domains to represent the various subnets. This is an additional management task. This is true, though I find it a little hard to see it as a significant extra burden - and it would have the advantage of simultaneously providing labels that can be accessed rationally for networks, something sorely lacking in practice since the hosts file was abandoned (a method exists now, but is little used, people see no benefit in doing the extra work, as simple as it is, when things work well enough without it - with a two part name scheme things wouldn't work without it, so people would spend that initial extra 10 seconds per subnet, and then reap the rewards when a renumbering occurs). In your scheme, even that can be finessed away, by simply noting that the name given can simply be the name of another host with an AAAA record giving all 64 bits, one would presume a popular host on the same subnet whose address is likely to be usefully known anyway. Your recombination rules would work correctly in that case, and allow a renumbering of the popular host to simultaneously affect all the other hosts on the same subnet (for a renumbering that affected its prefix anyway - simply changing its ID, as when installing replacement hardware would have no affect on other hosts). They could also keep the prefix and interface identifications separated in a master data base, and simply combine them whenever the DNS master files are updated. This exposes another common fallacy, that also showed up in Matt Crawford's response to your message (where he calculated how long would be required in practice to worst case sign a new zone file and decided that individual AAAA records containing entire records was acceptable). That is that the zone containing the AAAA records that need to be updated is in any way related to the network that is being renumbered. There is no necessary relationship there at all... true, in most cases there will be, and the domain name and the net number will be administered by the one organisation, that is what makes a split DNS record for AAAA not require two lookups in the majority of cases, but while we can optimise for the common case, we cannot design to cater only for that case. Eg: during the Munich (and Memphis) IETF meetings my laptop was still in the cs.mu.oz.au zone file, even though its address came from those terminal room address blocks. Had the terminal room decided to undergo a renumbering rampage, how on earth would they have known to go update (and somehow sign) some zone file in Australia? It doesn't matter how many cpu cycles this might take, the issue is that the numbering, and the naming, are not under one administrative control, and can't be maintained together. On the other hand, had I had an AAAA record in AU which said that my identifier was 00:...:FF (whatever it is) and that my prefix is from laptops.ietf.de then all the renumbering would have required would have been an update to the name that managed the prefix, and I would have had my DNS entry updated in sync with everyone else (old enties for the prefix would have timed out of everyone's caches at the rate set by the time to live of the name, set by the ietf.de management, no doubt in some rational relationship to the lifetimes they're setting on addresses they're handing out). Further, no-one in AU would have needed to be roused from their sleep in the middle of the night to go sign this updated record. I believe that it is in fact possible to combine the best of both worlds by simply extending the current definition of AAAA records. I actually very much like this proposal, though I would make two small changes. Instead of this... Instead of just storing 16 octets of address, we can store in the same record a prefix length and the name of a subnet. +--------------+-------------+-----------------------+ | Address | Pre. length | Domain name of subnet | | (16 octets) | (1 octet) | (variable) | +--------------+-------------+-----------------------+ Do this instead .. +--------------+------------------+-----------------------+ | Pre. length | Address low bits | Domain name of subnet | | (1 octet) | (0..16 octets) | (variable, 0..256) | +--------------+------------------+-----------------------+ There's nothing at all to be gained in the DNS by starting on any imagined aligned boundary, the RRs start anywhere in the packet, so beginning the address part at the start gains nothing at all. Starting with the prefix length allows only the relevant bits of the address to be carried though, that is far more important. In most cases we can imagine now, those low bits will be 64 bits, meaning just 8 adress bytes need to be lugged around in the entries that carry the domain name, all 16 bytes would be needed in entries with no domain name (though one could design a more complex format which would allow only the upper 8 bytes to be transmitted in those cases where an 8 byte prefix is all that is required, with the low 64 bits all zeroes, or irrelevant - I doubt that complexity would be worth the gain though). The address contains the low bits (128 - prefix length) in just enough octets to fully contain them, right justified in the field (ie: up to 7 leading bits in the first octet might be padding, and would be expected to be set to 0). That's the first change. The second is to simply omit the domain name part when it is not required. There are three reasons for this - the first is that it saves one byte per AAAA record, making the cost of your proposal just one byte instead of two (that's a trivial reason). Second even if the presence of the domain name couldn't be calculated from the format of the record itself (and it can, as it isn't needed when there are 128 prefix bits, and is when there are less), it certainly can from the length field, which all DNS RRs carry. And third, the domain name of a single 0 byte refers to the root domain everywhere else in the DNS, it would be a mess to make this one special case (not that anyone would want to name the root domain in this spot, but special cases are a nuisance). The processing, to obtain the , would be as follow: * access each AAAA record. * if the prefix length is set to zero, return. We have found a valid entry. * if the prefix length, L, is larger than zero, access the AAAA records of the named subnet. Combine the L first bits of each of the subnet addresses with the (128 - L) bits of the initial AAAA record. Yes you didn't explicitly point out that another advantage of this scheme is that the secondary records would apply to many hosts in a domain, and would be cached nearby in most cases, and one such name could list all relevant prefixes for the subnet, meaning that instead of multiple AAAA records for every host on the subnet, in many cases just one would be required, with the subnet name containing the multiplier. This will make zone files smaller, and much easier to maintain. The extension of the AAAA record to contain an optional subnet pointer allows us to experiment with several structures of the DNS entries: Yes. * when the number of hosts is small, managers may opt for a simple structure where the prefix length is set to zero. In this case, they only incur two bytes of overhead per AAAA record, one octet of length and one octet to indicate a null length domain name. One byte in my variation of your scheme. * when the number of subnet is small, or if renumbering individual subnets is not a concern, managers can set the prefix length to 48 and document in the AAAA records the name of the site. The site's records will be "self sufficient", their prefix length will be set to zero. Yes. * for complex sites whose subnets are individually renumbered, managers will set the prefix length to 64 and document in the AAAA records the name of the subnet. The subnet's records should normally be "self sufficient", but we could envisage to let them point to the name of the site, in which case we would have to recurse twice when accessing a station's address. Yes, this potential is actually more of a possible advantage than you indicate, and should certainly not be dismissed. Of course, as will all adantages, there will be costs in making use of it, but there seems to be no cost at all in allowing for the possibility. These extensions lead to very simple processing rules in DNS servers. When an AAAA record contains a domain name, the AAAA records of that domain should be added in the "additional information" section. This is similar to existing processing rules for names in NS or MX records. This means that in most cases, the host and site records will be obtained in a single transaction, alleviating the concern for access speed. Exactly. The main drawback of unification is that messages will be somewhat longer, carrying 128 bits when 48, 64 or 80 would have sufficed. We could reduce that overhead by adopting a variable length format, but this would be more complex and possibly more error prone. More complex? Well, I don't think so, not in any way that matters, one trivial expression to generate the length of the address sub-field instead of a constant "16". I doubt that would be any more error prone either, it isn't as if there are thousands of DNS implementations out there that would all need to be debugged... For the zone file writer (the error prone part) this can trivially all be made irrelevant, there's no reason they need see the internal compression any more than they see DNS name compression now. A small drawback is that we have to made up "non significant" bits for the host. I propose to use either the site local format, when the record points to a site name, or the link local format, when the record point to subnet name. A small drawback indeed, and not one that would be worth worrying about, but one that is no longer relevant in my variation. In fact, this structure can help resolvers recognize that the destination belongs to the same site, or subnet, than the requesting host. Now you're indulging in fancifulness - not only is this starting to get much more complex, it also doesn't work. The address part of the name can't reveal anything at all like this, as site local addresses are (by design) not unique. That is, you can't, from inspection, of a site local address tell anything at all about the site to which it belongs. If anything, it may be the domain name part which could hold this information is resolvers started wanting to get fancy - various conventions could be developed which would allow the resolver to deduce things from the subnet name used (the obvious one being that if the subnet name looked up and the subnet name of my own address are the same, then the addresses must have the same prefixes, and then by using the prefix length implied I could tell that a link local or site local address might be appropriate to use). But I think here we're stepping into the realms of what might be possible sometime in the future, and we don't need to go there for this scheme to appear to be a useful way to go. The real drawback with any split scheme is that (for security) each split AAAA record is going to need to carry two signatures, instead of one, and involve two validations of the signature, not one (though in many cases the prefix will be known good from a previous lookup and not need re-validation). That is the real cost of the scheme, but is certainly one I believe we should be planning to pay. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 27 08:42:33 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA18493; Wed, 27 Aug 1997 08:32:14 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id IAA18486; Wed, 27 Aug 1997 08:31:58 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id IAA08392; Wed, 27 Aug 1997 08:34:38 -0700 Received: from mailhost1.BayNetworks.COM (ns2.BayNetworks.COM [134.177.3.16]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id IAA20916 for ; Wed, 27 Aug 1997 08:34:39 -0700 Received: from mailhost.BayNetworks.COM ([134.177.1.107] (may be forged)) by mailhost1.BayNetworks.COM (8.8.6/BNET-97/07/07-E) with ESMTP id IAA29471 Received: from pobox.engeast.BayNetworks.COM (pobox.corpeast.baynetworks.com [192.32.151.199]) by mailhost.BayNetworks.COM (8.8.6/BNET-97/07/07-I) with ESMTP id IAA22777 Posted-Date: Wed, 27 Aug 1997 08:25:04 -0700 (PDT) Received: from greenfield.engeast.baynetworks.com (greenfield [192.32.170.19]) by pobox.engeast.BayNetworks.COM (SMI-8.6/BNET-97/04/24-S) with SMTP id LAA23642; Wed, 27 Aug 1997 11:24:53 -0400 for Message-Id: <3.0.32.19970827112130.006d9c28@pobox> X-Sender: dhaskin@pobox X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 27 Aug 1997 11:21:42 -0400 To: "Conta, Alex" From: Dimitry Haskin Subject: (IPng 4357) Re: ICMP Echo Cc: gaurang@VNET.IBM.COM, thartric@mentat.com, conta@zk3.dec.com, deering@parc.xerox.com, ipng@sunroof.eng.sun.com, tsuchi@isrd.hitachi.co.jp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2125 Alex, The following is an excerpt from the IPNG minutes at 34th IETF: ICMP Echo Response Truncation Text should be changed [to] suggest [that] host should try to send back all data. Document editor will talk to RFC editor to see if this change can be made before RFC is published. Since I believe you're going to re-issue ICMPv6 spec any way, it would be a good time to bring the document in compliance with the KG decision. At 12:46 AM 8/27/97 -0400, Contact, Alex wrote: >This has been discussed at length at the time of writing the >specifications. >Which, as this shows, does not mean it is no longer discussed.... > >The current text of the ICMP specification reflects the fact that the >ICMP Echo message is designed to rather check the IP connectivity >between two nodes, hosts or routers. > Connectivity with small packets does not necessary imply connectivity with large packets that need fragmentation. >The fragmentation in hosts, in particular of a reply on a path with a >smaller MTU, presents the probability of dropping one or more fragments >of the reply, which wrongly would be interpreted by the receiver of the >incomplete ICMP datagram (the sender of the Echo) as an absence of >connectivity. > This is exactly what someone may want to determine. Otherwise he/she wouldn't bother sending large ICBM Reqs in the first place. >Fragmentation in routers is not mandatory. The ICMP specification allows >routers to return ICMP Echo Replies even when the size of an ICMP >message would, by exceeding the MTU of the return path, result, in the >absence of fragmentation, in a no reply. > I don't believe this is a correct statement. In sending Echo Replies routers follow host requirements. >Alex > Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 27 09:41:50 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA18598; Wed, 27 Aug 1997 09:28:52 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA18591; Wed, 27 Aug 1997 09:28:42 -0700 From: gaurang@VNET.IBM.COM Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA22056; Wed, 27 Aug 1997 09:31:21 -0700 Received: from VNET.IBM.COM (vnet.ibm.com [204.146.168.194]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA11228 for ; Wed, 27 Aug 1997 09:31:17 -0700 Message-Id: <199708271631.JAA11228@saturn.Sun.COM> Received: from RALVM29 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 5615; Wed, 27 Aug 97 12:31:04 EDT Date: Wed, 27 Aug 97 12:21:11 EDT To: AConta@Lucent.com cc: tsuchi@isrd.hitachi.co.jp, thartric@mentat.com, deering@parc.xerox.com, ipng@sunroof.eng.sun.com Subject: (IPng 4358) RE: ICMP Echo Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 685 >The current text of the ICMP specification reflects the fact that the >ICMP Echo message is designed to rather check the IP connectivity >between two nodes, hosts or routers. If user of ICMP Echo is only interested in IP connectivity then he should not send more than 576 bytes (min MTU). Gaurang Shah -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 27 09:53:51 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA18614; Wed, 27 Aug 1997 09:42:29 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA18607; Wed, 27 Aug 1997 09:42:18 -0700 From: gaurang@VNET.IBM.COM Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA25338; Wed, 27 Aug 1997 09:44:54 -0700 Received: from VNET.IBM.COM (vnet.ibm.com [204.146.168.194]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA15863 for ; Wed, 27 Aug 1997 09:44:18 -0700 Message-Id: <199708271644.JAA15863@saturn.Sun.COM> Received: from RALVM29 by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 6460; Wed, 27 Aug 97 12:44:09 EDT Date: Wed, 27 Aug 97 12:28:16 EDT To: dhaskin@BayNetworks.COM cc: tsuchi@isrd.hitachi.co.jp, thartric@mentat.com, deering@parc.xerox.com, ipng@sunroof.eng.sun.com, AConta@Lucent.com Subject: (IPng 4359) Re: ICMP Echo Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 751 >Alex, > >The following is an excerpt from the IPNG minutes at 34th IETF: > > ICMP Echo Response Truncation > > Text should be changed [to] suggest [that] host should try to > send back all data. Document editor will talk to RFC editor > to see if this change can be made before RFC is published. and originating host should not expect all data back. Gaurang Shah -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 27 10:23:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18794; Wed, 27 Aug 1997 10:12:18 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id KAA18787; Wed, 27 Aug 1997 10:12:08 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id KAA03501; Wed, 27 Aug 1997 10:14:46 -0700 Received: from mentat.com (mentat.com [192.88.122.129]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id KAA26258 for ; Wed, 27 Aug 1997 10:14:45 -0700 Received: from feller.mentat.com ([192.88.122.144]) by mentat.com (4.1/SMI-4.1) id AA05931; Wed, 27 Aug 97 10:13:22 PDT Received: by feller.mentat.com (SMI-8.6/SMI-SVR4) id KAA23368; Wed, 27 Aug 1997 10:15:16 -0700 Date: Wed, 27 Aug 1997 10:15:16 -0700 From: thartric@mentat.com (Tim Hartrick) Message-Id: <199708271715.KAA23368@feller.mentat.com> To: ipng@sunroof.eng.sun.com Subject: (IPng 4360) RE: ICMP Echo X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1076 Alex, > > >The current text of the ICMP specification reflects the fact that the > >ICMP Echo message is designed to rather check the IP connectivity > >between two nodes, hosts or routers. > > If user of ICMP Echo is only interested in IP connectivity then he > should not send more than 576 bytes (min MTU). > Or more than 0 bytes of data for that matter. If pure connectivity is all we are interested in then the ICMPv6 header should be sufficient to determine that. I believe echo requests and replies were intended to have a broader range of uses than you suggest. Testing fragment- ation and reassembly would be one other use. Testing path mtu discovery would be another. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 27 12:26:14 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA19132; Wed, 27 Aug 1997 12:10:42 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA19125; Wed, 27 Aug 1997 12:10:29 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA04097; Wed, 27 Aug 1997 12:12:58 -0700 Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA06433 for ; Wed, 27 Aug 1997 12:11:47 -0700 Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (AIX4.2/UCB 8.7/8.7RTP-FW1.1) with ESMTP id PAA18680; Wed, 27 Aug 1997 15:08:51 -0400 (EDT) Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [9.37.83.123]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with SMTP id PAA29222; Wed, 27 Aug 1997 15:08:51 -0400 Received: from localhost.raleigh.ibm.com by cichlid.raleigh.ibm.com (AIX 4.1/UCB 5.64/4.03-RAL) id AA19512; Wed, 27 Aug 1997 15:08:46 -0400 Message-Id: <9708271908.AA19512@cichlid.raleigh.ibm.com> To: bound@zk3.dec.com Cc: set@thumper.bellcore.com, ipng@sunroof.eng.sun.com Subject: (IPng 4361) Re: Addrconf Changes In-Reply-To: Your message of "Wed, 06 Aug 1997 09:42:50 EDT." <9708061342.AA30794@wasted.zk3.dec.com> Date: Wed, 27 Aug 1997 15:08:46 -0400 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 2306 Jim, > >5.5.4. Address Lifetime Expiry > > > > A preferred address becomes deprecated when its preferred lifetime > > expires. A deprecated address SHOULD continue to be used as a source > > address in existing communications, but SHOULD NOT be used in new > > communications if an alternate (non-deprecated) address is available | > > and has sufficient scope. IP and higher layers (e.g., TCP, UDP) MUST | > > continue to accept datagrams destined to a deprecated address since a > > deprecated address is still a valid address for the interface. An > > implementation MAY prevent any new communication from using a > > deprecated address, but system management MUST have the ability to | > > disable such a facility, and the facility MUST be disabled by | > > default. > You did not discuss this with WG as I recall? I think you should have > before changing the spec as a courteousy. > But I want it back the way it was. I don't believe "MAY" is a message > for users to not permit deprecated addresses to stop all communications. > I would argue that the way it was worded as a SHOULD is fine and sends a > clear message. Exactly what changes are you referring to that you think shouldn't have been made? Lines 4-5 above are an editorial clarification that I assume isn't what you are refering to. The change in the last sentence appends the words "and the facility MUST be disabled by default". (Compare the above with what is in RFC 1971). I don't understand your comment about "the way it was worded as a SHOULD is fine". FYI, I actually added this line many months (a year?) back as a clarification after some WG discussion about deprecated addresses. My recollection is that the intention had always been to require the above behavior but the exact words somehow didn't make it into the draft. I don't recall now exactly which meeting prompted the change. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 27 12:51:43 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA19158; Wed, 27 Aug 1997 12:41:00 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA19151; Wed, 27 Aug 1997 12:40:42 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA10885; Wed, 27 Aug 1997 12:43:20 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA16706; Wed, 27 Aug 1997 12:43:17 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id PAA20116; Wed, 27 Aug 1997 15:32:47 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA08954; Wed, 27 Aug 1997 15:32:27 -0400 Message-Id: <9708271932.AA08954@wasted.zk3.dec.com> To: Erik Nordmark Cc: michaelb@stb.info.com, ipng@sunroof.eng.sun.com Subject: (IPng 4362) Re: IPv6 API update to RFC 2133 In-Reply-To: Your message of "Sat, 09 Aug 1997 14:50:51 MST." Date: Wed, 27 Aug 1997 15:32:26 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 869 Erik, Sorry just back from Europe so this is a response to old mail. >> I think that REQUIRING (I.e, MUST) the name lookups to be multithreaded >> would be a huge win. >I agree. The only problem is that the routines standardized by X/Open >(gethostbyname, gethostbyaddr, getservbyname, getservbyport) >does not easily allow that since they are specified to return a pointer >to a static variable. I think Chris Harding and XNET would update the X/Open pieces if we made the case. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 27 13:22:02 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA19332; Wed, 27 Aug 1997 13:07:42 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA19325; Wed, 27 Aug 1997 13:07:30 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA16363; Wed, 27 Aug 1997 13:10:07 -0700 Received: from snoopy.lucentmmit.com (smtp.lucentmmit.com [38.160.171.35]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id NAA25141 for ; Wed, 27 Aug 1997 13:10:05 -0700 Received: by smtp.lucentmmit.com with Internet Mail Service (5.0.1457.3) id ; Wed, 27 Aug 1997 16:13:05 -0400 Message-ID: From: "Conta, Alex" To: "'dhaskin@BayNetworks.COM'" Cc: gaurang@VNET.IBM.COM, thartric@mentat.com, deering@parc.xerox.com, ipng@sunroof.eng.sun.com, tsuchi@isrd.hitachi.co.jp, "'hinden@ipsilon.com'" Subject: (IPng 4363) Re: ICMP Echo Date: Wed, 27 Aug 1997 16:13:04 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1703 Dimitry, While writing the yesterday's answer, I remembered you as one of the last ones having an issue with this, but was not sure which way. Certainly it seems obvious now.... I also knew we went back and forth on this for quite sometime. Thanks for your points, and your going back to the minutes, which I double checked myself. Change will be done. Thanks everyone. By the way I liked (your typos) ICBM instead of ICMP, and KG(B) instead of WG (-:.... Alex > -----Original Message----- > From: dhaskin@BayNetworks.COM [SMTP:dhaskin@BayNetworks.COM] > Sent: Wednesday, August 27, 1997 5:22 PM > To: Conta, Alex > Cc: gaurang@VNET.IBM.COM; thartric@mentat.com; conta@zk3.dec.com; > deering@parc.xerox.com; ipng@sunroof.Eng.Sun.COM; > tsuchi@isrd.hitachi.co.jp > Subject: Re: (IPng 4355) RE: ICMP Echo > > Alex, > > The following is an excerpt from the IPNG minutes at 34th IETF: > > ICMP Echo Response Truncation > > Text should be changed [to] suggest [that] host should try to > send back all data. Document editor will talk to RFC editor > to see if this change can be made before RFC is published. > > > Since I believe you're going to re-issue ICMPv6 spec any way, it would > be a > good time to bring the document in compliance with the KG decision. > > > [Alex C. ] ... > > > Dimitry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Aug 27 14:41:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA19469; Wed, 27 Aug 1997 14:32:04 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id OAA19462; Wed, 27 Aug 1997 14:31:55 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id OAA07338; Wed, 27 Aug 1997 14:34:34 -0700 Received: from relay01.iafrica.com (relay01.iafrica.com [196.7.0.160]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id OAA22512 for ; Wed, 27 Aug 1997 14:34:15 -0700 Received: from 196-31-64-205.iafrica.com [196.31.64.75] by relay01.iafrica.com with smtp (Exim 1.59 #1) id 0x3pj6-0004vG-00; Wed, 27 Aug 1997 23:34:09 +0200 Received: by 196-31-64-205.iafrica.com with Microsoft Mail id <01BCB342.7578DD80@196-31-64-205.iafrica.com>; Wed, 27 Aug 1997 23:39:27 +-200 Message-ID: <01BCB342.7578DD80@196-31-64-205.iafrica.com> From: Hamish Whittal To: "'ipng@sunroof.eng.sun.com'" Subject: (IPng 4364) Is this a forum for asking... Date: Wed, 27 Aug 1997 23:31:39 +-200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 616 I am trying to understand IPv6. I am wading through the RFC, but do need some clarification and assistance in understanding some stuff. Is this the forum in which I can do this? Thanks for your understanding! Kindest regards Hamish -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 28 05:19:05 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA20070; Thu, 28 Aug 1997 05:08:36 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA20063; Thu, 28 Aug 1997 05:08:26 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA27571; Thu, 28 Aug 1997 05:11:00 -0700 Received: from hitiij.hitachi.co.jp (hitiij.hitachi.co.jp [133.145.224.3]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA18684 for ; Thu, 28 Aug 1997 05:11:04 -0700 Received: from isrdgw.isrd.hitachi.co.jp by hitiij.hitachi.co.jp (8.8.5+2.7Wbeta5/3.5W-hitiij) id VAA20021; Thu, 28 Aug 1997 21:06:05 +0900 (JST) Received: from magic.33g.isrd.hitachi.co.jp by isrdgw.isrd.hitachi.co.jp (8.6.9+2.4W/2.7W-ISRD) id VAA19027; Thu, 28 Aug 1997 21:07:45 +0900 Message-Id: <9708281214.AA00168@magic.33g.isrd.hitachi.co.jp> From: tsuchiya Date: Thu, 28 Aug 1997 21:14:09 +0900 To: Dimitry Haskin Cc: "Conta, Alex" , gaurang@VNET.IBM.COM, thartric@mentat.com, conta@zk3.dec.com, deering@parc.xerox.com, ipng@sunroof.eng.sun.com Subject: (IPng 4365) Re: ICMP Echo In-Reply-To: <3.0.32.19970827112130.006d9c28@pobox> MIME-Version: 1.0 X-Mailer: AL-Mail 1.32 Content-Type: text/plain; charset=iso-2022-jp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1471 Dear all Thanks for a lot of reply. Dimitry Haskin wrote： >The following is an excerpt from the IPNG minutes at 34th IETF: > > ICMP Echo Response Truncation > > Text should be changed [to] suggest [that] host should try to > send back all data. Document editor will talk to RFC editor > to see if this change can be made before RFC is published. > . > . > . >In sending Echo Replies routers follow host requirements. > Let me see if I understand. When node(host or router) recieves ICMP echo request which exceeds the MTU size, (1)host should try to send back all data. (2)router should try to send back all data, too. and (3)originating host of ICMP echo request can expect all data back. Is that right? # Finally I solved my question. Thanks for a lot of reply again. I can sleep well tonight. Zu, zu, zu ....... ---------------------------------------------------------- Kazuaki Tsuchiya(E-mail:tsuchi@isrd.hitachi.co.jp) Hitachi, Ltd. in Japan. Phone:044-549-1714 Fax:044-549-1721 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 28 05:37:58 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA20087; Thu, 28 Aug 1997 05:28:01 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id FAA20080; Thu, 28 Aug 1997 05:27:51 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id FAA29203; Thu, 28 Aug 1997 05:30:29 -0700 Received: from neteracy.instructors.net (neteracy.instructors.net [204.57.120.144]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id FAA22472 for ; Thu, 28 Aug 1997 05:30:33 -0700 Received: from ts002d08.sat-tx.concentric.net [206.173.134.44] (HELO dni-master) by neteracy.instructors.net (AltaVista Mail V1.0/1.0 BL18 listener) id 0000_004c_3405_7094_a614; Thu, 28 Aug 1997 07:35:32 -0500 Message-ID: <34056E93.45C7@instructors.net> Date: Thu, 28 Aug 1997 07:26:59 -0500 From: Ted Rohling Reply-To: trohling@instructors.net X-Mailer: Mozilla 3.01Gold (WinNT; I) MIME-Version: 1.0 To: gaurang@VNET.IBM.COM, ipng@sunroof.eng.sun.com Subject: (IPng 4366) RE: ICMP Echo References: <199708271631.JAA11228@saturn.Sun.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1475 gaurang@VNET.IBM.COM wrote: > > >The current text of the ICMP specification reflects the fact that the > >ICMP Echo message is designed to rather check the IP connectivity > >between two nodes, hosts or routers. > > If user of ICMP Echo is only interested in IP connectivity then he > should not send more than 576 bytes (min MTU). > > Gaurang Shah > Please bear in mind that the traditional use of ping has served a number of purposes. 1. Test connectivity at layer 2 (for sure) 2. Determine round trip times under varying circumstances (big pings take longer than smaller ones) 3. Network congestion (dropped packets) 4. Emulate upper layer traffic loads, ie bigger datagrams, without the mess of using the upper layer applications. While IP is evolving, please remember why some of these tools are present and how some of us more traditional users USE them. If you have ever used the Microsoft Ping, with all of the wonderful options, you would understand. They left off the drop/successful percentages that we know and love from the UNIX implementation. thanks Ted Rohling -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 28 09:53:17 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20317; Thu, 28 Aug 1997 09:33:25 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20310; Thu, 28 Aug 1997 09:32:59 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id JAA03546 for ; Thu, 28 Aug 1997 09:35:24 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA22491; Thu, 28 Aug 1997 09:32:53 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20299; Thu, 28 Aug 1997 09:30:04 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA27361; Thu, 28 Aug 1997 09:32:44 -0700 Received: from ayax.uniandes.edu.co (Ayax.uniandes.edu.co [157.253.50.3]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA03765 for ; Thu, 28 Aug 1997 09:32:43 -0700 Received: from isis.uniandes.edu.co by ayax.uniandes.edu.co (SMI-8.6/SMI-SVR4) id LAA11894; Thu, 28 Aug 1997 11:48:35 +0500 Date: Thu, 28 Aug 1997 11:28:01 +0500 (GMT) From: Yezid Enrique Donoso Meisel To: ipng@sunroof.eng.sun.com Subject: (IPng 4368) Re: Information about MTU (Yezid) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 537 Hi, In this moment, i am needing information about PMTU (Discovery of Path MTU) in IPv4 and IPv6. Where can I found information about this ?? Thank... YD -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 28 10:01:41 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20331; Thu, 28 Aug 1997 09:45:49 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA20324; Thu, 28 Aug 1997 09:45:35 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA01312; Thu, 28 Aug 1997 09:48:14 -0700 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA09183 for ; Thu, 28 Aug 1997 09:48:16 -0700 Received: from wasted.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA19883; Thu, 28 Aug 1997 12:35:43 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA06680; Thu, 28 Aug 1997 12:35:17 -0400 Message-Id: <9708281635.AA06680@wasted.zk3.dec.com> To: Thomas Narten Cc: set@thumper.bellcore.com, ipng@sunroof.eng.sun.com Subject: (IPng 4369) Re: Addrconf Changes In-Reply-To: Your message of "Wed, 27 Aug 1997 15:08:46 -0400." <9708271908.AA19512@cichlid.raleigh.ibm.com> Date: Thu, 28 Aug 1997 12:35:16 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1574 Thomas, I don't recall much discussion on this but I am very confident that users will use a "deprecated" address to disallow all "new" connections. This will permit sysadm folks to force clients to seek a new address actively. I will have to supply a configuration option in both Addr Conf and DHCPv6 at system start up to permit this behavior for customers. Having the spec say SHOULD permit new connections for deprecated addresses I think is a better way to satisfy the requirement for both needs. Today in our implementation new connections over deprecated addresses is the default and I coded this from the spec when it was a SHOULD. I see no reason for a MUST and would like to hear from others in the WG before I give up on this issue. As I am being required to live with NO RESPONSES is not consensus in DHCPv6 WG within the IETF I will not assume the wording should not change in Addr Conf without some discussion and would bring it up as an issue in any IESG last call for PS (I hope though we are going to DS). As I stated at the IESG Plenary in Munich I insist upon consistency where possible in our community as an active contributor to these processes. Sincerely, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Aug 28 11:18:46 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA20584; Thu, 28 Aug 1997 11:08:49 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA20577; Thu, 28 Aug 1997 11:08:40 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA28157; Thu, 28 Aug 1997 11:11:08 -0700 Received: from blaze-net.com (h161.blaze-net.com [199.103.209.161]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA08332 for ; Thu, 28 Aug 1997 11:10:17 -0700 Received: from fenway.blaze-net.com by blaze-net.com (SMI-8.6/SMI-SVR4) id OAA18949; Thu, 28 Aug 1997 14:15:37 -0400 Received: from fenway by fenway.blaze-net.com (SMI-8.6/SMI-SVR4) id OAA05331; Thu, 28 Aug 1997 14:09:54 -0400 Message-ID: <3405BEF1.1852@blaze-net.com> Date: Thu, 28 Aug 1997 14:09:53 -0400 From: Frank Solensky Organization: BlazeNet Inc X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 i86pc) MIME-Version: 1.0 To: Yezid Enrique Donoso Meisel CC: ipng@sunroof.eng.sun.com Subject: (IPng 4371) Re: Information about MTU (Yezid) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 656 Yezid Enrique Donoso Meisel wrote: > > Hi, > In this moment, i am needing information about PMTU (Discovery of Path > MTU) in IPv4 and IPv6. Where can I found information about this ?? RFC-1191: Path MTU Discovery RFC-1981: Path MTU Discovery for IP version 6 -- Frank -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 29 09:50:18 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA21504; Fri, 29 Aug 1997 09:34:38 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA21497; Fri, 29 Aug 1997 09:34:29 -0700 From: bound@zk3.dec.com Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA19513; Fri, 29 Aug 1997 09:37:07 -0700 Received: from mail12.digital.com (mail12.digital.com [192.208.46.20]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA02127; Fri, 29 Aug 1997 09:37:12 -0700 Received: from wasted.zk3.dec.com (bwasted.zk3.dec.com [16.140.128.41]) by mail12.digital.com (8.7.5/UNX 1.5/1.0/WV) with SMTP id MAA21766; Fri, 29 Aug 1997 12:17:05 -0400 (EDT) Received: from localhost by wasted.zk3.dec.com (5.65v4.0/1.1.8.2/18Feb95-1123AM) id AA00771; Fri, 29 Aug 1997 12:16:56 -0400 Message-Id: <9708291616.AA00771@wasted.zk3.dec.com> To: Fumio Teraoka Cc: Erik Nordmark - Sun Sweden , mobile-ip@hosaka.SmallWorks.COM, ipng@sunroof.eng.sun.com, solomon@comm.mot.com Subject: (IPng 4372) Re: (mobile-ip) Mobile IPv6 requirements on all nodes In-Reply-To: Your message of "Tue, 19 Aug 1997 19:44:25 +0900." <199708191047.TAA09383@tera.csl.sony.co.jp> Date: Fri, 29 Aug 1997 12:16:56 -0400 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1489 Fumio et al........... >draft-ietf-mobileip-ipv6-03.txt introduces "source home address" >destination option to allow a mobile node to send a packet that >has the topologically correct source address. > >According to this idea, it is more reasonable to introduce >"destination home address" destination option to allow a >correnspondent node to send a packet to the care-of address of >the mobile node, instead of using the routing header. I think last call is premature. I spoke now with Dave, Jim, Erik, and Charlie. I also will join the mobile mail list for IPv6 stuff once I figure out how to do that. I think we need to do the following for IPv6 mobile: 1. Revisit if we can avoid the src route header. 2. Describe in a conceptual model how the binding update interacts with the Home option once applied. What the potential affect is to NUD algorithm in IPv6. We at least need to understand the affect to implementations. 3. I also think that the Anycast address is now not needed. More as I get it together from just getting back from 3 weeks in Europe. /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 29 11:52:25 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA21821; Fri, 29 Aug 1997 11:42:30 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id LAA21814; Fri, 29 Aug 1997 11:42:21 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id LAA21002; Fri, 29 Aug 1997 11:44:59 -0700 Received: from lint.cisco.com (lint.cisco.com [171.68.223.44]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id LAA13847 for ; Fri, 29 Aug 1997 11:45:05 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by lint.cisco.com (8.8.5/CISCO.SERVER.1.2) with ESMTP id LAA17962 for ; Fri, 29 Aug 1997 11:44:59 -0700 (PDT) Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id LAA08416; Fri, 29 Aug 1997 11:44:05 -0700 (PDT) Date: Fri, 29 Aug 1997 11:44:05 -0700 (PDT) Message-Id: <199708291844.LAA08416@pedrom-ultra.cisco.com> From: Pedro Marques To: ipng@sunroof.eng.sun.com Subject: (IPng 4373) /127 Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 789 This is kind of a silly question but here it goes... Assuming one does not consider that all subnets must be /64s (which is an argument which i really wouldn't like to go into)... Is a /127 a valid subnet length for a point to point numbered link or should the minumum subnet length be /126 so that you can have an all subnet bits set to 0 address that corresponds to the link's anycast address. Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 29 12:34:38 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA21900; Fri, 29 Aug 1997 12:16:08 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id MAA21893; Fri, 29 Aug 1997 12:15:59 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id MAA28715; Fri, 29 Aug 1997 12:18:37 -0700 Received: from santacruz.org (santacruz.org [207.86.120.165]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id MAA23943 for ; Fri, 29 Aug 1997 12:18:41 -0700 Received: from rns.ml.org (1Cust67.max17.seattle.wa.ms.uu.net [153.34.43.67]) by santacruz.org (8.8.5/8.8.5) with SMTP id MAA10310; Fri, 29 Aug 1997 12:31:08 -0700 Message-ID: <3406C127.297D21FA@santacruz.org> Date: Fri, 29 Aug 1997 05:31:35 -0700 From: Gregory Taylor Organization: 4D Interactive Designs, Inc. X-Mailer: Mozilla 3.0 (X11; I; Linux 2.1.9 i486) MIME-Version: 1.0 To: Pedro Marques CC: ipng@sunroof.eng.sun.com Subject: (IPng 4374) Re: /127 References: <199708291844.LAA08416@pedrom-ultra.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1521 Pedro Marques wrote: > > This is kind of a silly question but here it goes... > > Assuming one does not consider that all subnets must be /64s (which is an > argument which i really wouldn't like to go into)... > > Is a /127 a valid subnet length for a point to point numbered link or should > the minumum subnet length be /126 so that you can have an all subnet bits set > to 0 address that corresponds to the link's anycast address. > > Pedro. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Pedro, you might wanna test out the /127 length, it might do some good, but /126 seems more realistic.. Try both of them and let everyone know about it, I personally vote for /126 Thank You, Gregory Taylor Network Developement and UNIX Specialist RNS Networking Services, Incorporated. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 29 13:40:42 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21963; Fri, 29 Aug 1997 13:31:26 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id NAA21956; Fri, 29 Aug 1997 13:31:16 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id NAA13802; Fri, 29 Aug 1997 13:33:55 -0700 Received: from trix.cisco.com (trix.cisco.com [171.69.1.218]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id NAA15595 for ; Fri, 29 Aug 1997 13:33:58 -0700 Received: from pedrom-ultra.cisco.com (pedrom-ultra.cisco.com [171.69.57.43]) by trix.cisco.com (8.6.12/8.6.5) with ESMTP id NAA02735; Fri, 29 Aug 1997 13:33:57 -0700 Received: (roque@localhost) by pedrom-ultra.cisco.com (8.8.4-Cisco.1/CISCO.WS.1.2) id NAA08511; Fri, 29 Aug 1997 13:32:55 -0700 (PDT) Date: Fri, 29 Aug 1997 13:32:55 -0700 (PDT) Message-Id: <199708292032.NAA08511@pedrom-ultra.cisco.com> From: Pedro Marques To: Gregory Taylor Cc: ipng@sunroof.eng.sun.com Subject: (IPng 4375) Re: /127 In-Reply-To: <3406C127.297D21FA@santacruz.org> References: <199708291844.LAA08416@pedrom-ultra.cisco.com> <3406C127.297D21FA@santacruz.org> Mime-Version: 1.0 (generated by tm-edit 7.105) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1920 >>>>> "Gregory" == Gregory Taylor writes: >> This is kind of a silly question but here it goes... >> >> Assuming one does not consider that all subnets must be /64s >> (which is an argument which i really wouldn't like to go >> into)... >> >> Is a /127 a valid subnet length for a point to point numbered >> link or should the minumum subnet length be /126 so that you >> can have an all subnet bits set to 0 address that corresponds >> to the link's anycast address. >> >> Pedro. >> >> -------------------------------------------------------------------- >> IETF IPng Working Group Mailing List IPng Home Page: >> http://playground.sun.com/ipng FTP archive: >> ftp://playground.sun.com/pub/ipng Direct all administrative >> requests to majordomo@sunroof.eng.sun.com >> -------------------------------------------------------------------- Gregory> -- Gregory> Pedro, you might wanna test out the /127 length, it Gregory> might do some good, but /126 seems more realistic.. Try Gregory> both of them and let everyone know about it, I personally Gregory> vote for /126 Gregory, They both will work on the particular test case... the question is if we should or not always account for the subnet anycast address. Puting it in another way: "must all subnets have an anycast address ?"... if so why ? we already know that it might be useful for identification but will some obscure feature break otherwise ? Pedro. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Aug 29 16:07:59 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA22301; Fri, 29 Aug 1997 15:57:16 -0700 Received: from jurassic.eng.sun.com by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA22294; Fri, 29 Aug 1997 15:57:10 -0700 Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.8.7+Sun.Alpha.7/8.8.7) with SMTP id PAA18720 for ; Fri, 29 Aug 1997 15:59:50 -0700 (PDT) Received: by stinker.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA24239; Fri, 29 Aug 1997 15:57:39 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id PAA22282; Fri, 29 Aug 1997 15:39:57 -0700 Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id PAA13328; Fri, 29 Aug 1997 15:42:35 -0700 Received: from ns1.eds.com (ns1.eds.com [192.85.154.78]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with ESMTP id PAA19544 for ; Fri, 29 Aug 1997 15:42:41 -0700 Received: from nnsa.eds.com (nnsa.eds.com [130.174.31.78]) by ns1.eds.com (8.8.6/8.8.5) with ESMTP id SAA23646; Fri, 29 Aug 1997 18:42:30 -0400 (EDT) Received: from info1.iscg.eds.com (info1.iscg.eds.com [130.174.31.76]) by nnsa.eds.com (8.8.5/8.8.5) with SMTP id SAA16257; Fri, 29 Aug 1997 18:42:00 -0400 (EDT) Received: by info1.iscg.eds.com (5.65/DEC-Ultrix/4.3) id AA11336; Fri, 29 Aug 1997 18:41:59 -0400 X-Sender: jcutle01@info1.iscg.eds.com Message-Id: In-Reply-To: <3406C127.297D21FA@santacruz.org> References: <199708291844.LAA08416@pedrom-ultra.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 29 Aug 1997 18:39:59 -0400 To: Gregory Taylor From: "James R. Cutler" Subject: (IPng 4377) Re: /127 Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 1661 Pedro, This is actually a very serious question. Thank you for asking. Here is my response: Any other approach than n-2 maximum creates difficulties in address assignment processes (human and automated) where we identify a particular subnet by its base address and /mask. Use of /127 makes the broadcast address require special case treatment as well. Recommendation: Limit mask to /126 maximum and always treat 'host 0' as the anycast address (consistent with IPv4 subnet address) and 'host all-ones' as the broadcast address (again, consistent with IPv4 usage). Then, a serial link (IPv4 or IPv6) with the longest mask will always have host '1' and host '2'; and, many of us will be less confused. (The implementation code may well be simpler.) James R. Cutler >Pedro Marques wrote: >> >> This is kind of a silly question but here it goes... >> >> Assuming one does not consider that all subnets must be /64s (which is an >> argument which i really wouldn't like to go into)... >> >> Is a /127 a valid subnet length for a point to point numbered link or should >> the minumum subnet length be /126 so that you can have an all subnet bits set >> to 0 address that corresponds to the link's anycast address. >> >> Pedro. >> EDS Postmaster postmaster@eds.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Aug 31 09:56:40 1997 Return-Path: Received: by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA23329; Sun, 31 Aug 1997 09:42:28 -0700 Received: from Eng.Sun.COM by sunroof.eng.sun.com (SMI-8.6/SMI-SVR4) id JAA23322; Sun, 31 Aug 1997 09:42:19 -0700 From: bmanning@ISI.EDU Received: from saturn.Sun.COM by Eng.Sun.COM (SMI-8.6/SMI-5.3) id JAA13274; Sun, 31 Aug 1997 09:45:00 -0700 Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by saturn.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id JAA07518 for ; Sun, 31 Aug 1997 09:45:07 -0700 Received: from zed.isi.edu by zephyr.isi.edu (5.65c/5.61+local-26) id ; Sun, 31 Aug 1997 09:45:01 -0700 Posted-Date: Sun, 31 Aug 1997 09:42:25 -0700 (PDT) Message-Id: <199708311642.AA10104@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-6) id ; Sun, 31 Aug 1997 09:42:25 -0700 Subject: (IPng 4378) Re: /127 To: jcutle01@iscg.eds.com (James R. Cutler) Date: Sun, 31 Aug 1997 09:42:25 -0700 (PDT) Cc: jest@santacruz.org, ipng@sunroof.eng.sun.com In-Reply-To: from "James R. Cutler" at Aug 29, 97 06:39:59 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk content-length: 3536 Attached is a snippet from the pre-pedro cisco code team... ----------------------------------------------- Subject: Re: loopback? Date: Tue, 25 Feb 97 12:10:35 PST Sender: bmanning@ISI.EDU > bah(config-if)#ipv6 address ::1 127 > Invalid address > > Per RFC 1884, the above is legal. Agreed. The address parses just fine. The piece of code that is objecting also forbids setting the unspecified address or any multicast address as an interface address. I believe we can relax that check to allowing ::1 to be set only on loopback interfaces. > bah(config-if)#ipv6 address ::192.0.2.10 127 > bah(config-if)# > > Also, the syntax for prefixlength is different in this load than "normal" > conventions. I would expect something like this: > > bah(config-if)#ipv6 address ::192.0.2.10/127 being the desired format. > > bah(config-if)#ipv6 address ::192.0.2.10/127 > ^ > % Invalid input detected at '^' marker. I agree, it is surprising at first. There is a parsing problem, however. The prefix notation x::y/z indicates that the first z bits are relevant; the remaining bits are ignored and typically set to zero. For an address, however, we want all 128 bits. In other words, we have one set of functions for parsing prefixes and another set for parsing addresses. Kirk -------------------------------------------- > Pedro, > > This is actually a very serious question. Thank you for > asking. Here is my response: > > Any other approach than n-2 maximum creates difficulties in > address assignment processes (human and automated) where we > identify a particular subnet by its base address and /mask. > > Use of /127 makes the broadcast address require special case > treatment as well. > > Recommendation: Limit mask to /126 maximum and always treat > 'host 0' as the anycast address (consistent with IPv4 subnet > address) and 'host all-ones' as the broadcast address (again, > consistent with IPv4 usage). > > Then, a serial link (IPv4 or IPv6) with the longest mask > will always have host '1' and host '2'; and, many of us > will be less confused. (The implementation code may well > be simpler.) > > James R. Cutler > > > >Pedro Marques wrote: > >> > >> This is kind of a silly question but here it goes... > >> > >> Assuming one does not consider that all subnets must be /64s (which is an > >> argument which i really wouldn't like to go into)... > >> > >> Is a /127 a valid subnet length for a point to point numbered link or should > >> the minumum subnet length be /126 so that you can have an all subnet bits set > >> to 0 address that corresponds to the link's anycast address. > >> > >> Pedro. > >> > > EDS Postmaster > postmaster@eds.com > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------