From owner-ipng@sunroof.eng.sun.com Tue Feb 2 01:56:27 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id BAA09042 for ipng-dist; Tue, 2 Feb 1999 01:53:07 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id BAA09026; Tue, 2 Feb 1999 01:52:49 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id BAA03204; Tue, 2 Feb 1999 01:52:48 -0800 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by earth.sun.com (8.9.1/8.9.1) with SMTP id BAA13451; Tue, 2 Feb 1999 01:52:47 -0800 (PST) Received: by mailgate.rdg.opengroup.org; id AA26657; Tue, 2 Feb 1999 09:49:43 GMT Received: from cjh.rdg.opengroup.org [192.153.166.111] by mailgate.rdg.opengroup.org via smtpd V1.26 (98/11/23 13:59:56) for ; Tue Feb 02 09:49 GMT 1999 Message-Id: <3.0.3.32.19990202093658.007dcb20@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 02 Feb 1999 09:36:58 +0000 To: Jim Bound , ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@isi.edu, v6-deployment-cabal@alpha.zk3.dec.com From: Chris Harding Subject: (IPng 7146) Re: (c.harding 24483) UPDATED AGENDA - V6 Deploy 3rd Day Cc: xnet@opengroup.org In-Reply-To: <199901281636.LAA0000003320@wasted.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi - I very much regret that I can't be in Grenoble for this meeting. I believe that The Open Group can make a significant contribution to IPv6 deployment (in addition to incorporating the Basic API in the official sockets spec) by providing a bridge between the user and vendor communities to help the users get to grips with the issues. We had a great session at our members' meeting last week where LDAP users and vendors got together, and I would like to do the same for IPv6. From the discussions at the ad-hoc in Orlando, I feel that Q2/Q3 this year is likely to be the earliest that this would be useful - which at least gives some time to prepare. Meanwhile, I'll look forward to the results of Thursday. Have a good meeting! At 11:36 28/01/99 -0500, Jim Bound wrote: >Folks, > >OK I added the last three requests including the one Bob F got on >ngtrans just now. > >Any more changes will have to be done on the fly folks. > >A saying for IPv6'ers: > > Poor or late Planning on your part does not constitute an emergency > on the WG, Authors, IESG, or Chairs part -----).... > >/jim > >=== >Thursday, February 4 -- IPv6 Deployment and Promotion >----------------------------------------------------- >The purpose of this day will be to review current deployment >activities, potential additional efforts, and opportunities for >educating and influencing developers, ISPs, network managers, and >users. This will include answering the following questions: >- Why would anyone run IPv6 now? >- Why would anyone ever run IPv6? >- Who will deploy IPv6 first? >- Will the Internet lead Corporate networks or follow as IPv6 is >deployed? >- How to get ISPs to deploy IPv6? > >We would like to request that each attendee come with answers to the >above questions for discussion on this 3rd day. > >This is the Final Agenda before Grenbole. We will do Agenda Bashing at >Grenoble and select order and times. > >Agenda: >(1) Discussion of the questions above. >(2) Existing deployment efforts: >- 6BONE (who?) >- 6REN (who?) >(3) Potential efforts: >- IPv6 Exchanges (who?) >- Corporate Plans (who?) >- ISP Plans (who?) >- ... >(4) Promotion >- IPv6.org (who?) >- Influencing developers, vendors, etc. (who?) >(5) Presentations: >- Bob Fink - 6REN and 6TAP >- Jim Bound - The Palo Alto Gateway and IPv6 and sub-TLA Request Strategy >- Marc Blanchet - IPv6 Deployment Issues >- Henk Steenman - Amsterdam Internet Exchange (AMS-IX) native IPv6 environment >- Jim Bound for Perry Metzger - Status of the V6 Deployment List Activities >- Jun Murai - IPv6 Deployment in Japan >- Paula Caslav - Proposed Guidelines RIPE NCC Regional Registries for IPv6 >- Jun-ichiro itojun Hagino - IPv6 verification technologies and open > result by FREE see: > http://www.tahil.org/ >- Latif LADID - Influencing IPv6 Developers and Promotion >- Kenji OTA - IETF Terminal Room Experiences with IPv6 >(6) Public Domain Code Needs for IPv6 Discussion >- Appache Web Server >- Sendmail >- BIND >- BSD Network Utilities > >thanks >/jim > > Regards, Chris +++++ ------------------------------------------------------------------------- Chris Harding T H E Development Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Fx: +44 118 950 0110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 2 10:23:13 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id KAA09494 for ipng-dist; Tue, 2 Feb 1999 10:15:16 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id KAA09487 for ; Tue, 2 Feb 1999 10:14:44 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA27773 for ; Tue, 2 Feb 1999 10:14:42 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA23252 for ; Tue, 2 Feb 1999 10:14:42 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA27528; Tue, 2 Feb 1999 13:14:02 -0500 (EST) Message-Id: <199902021814.NAA27528@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 7147) Protocol Action: Transmission of IPv6 over IPv4 Domains without Explicit Tunnels to Proposed Standard Date: Tue, 02 Feb 1999 13:14:02 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approvedTransmission of IPv6 over IPv4 Domains without Explicit Tunnels as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary This document specifies how to run IPv6 over an IPv4 multicast domain. The entire IPv4 cloud is treated as a virtual local link. The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. It uses IPv4 multicast as a "virtual Ethernet." This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link- layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network. Working Group Summary There was consensus in the WG for this approach. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. Note to RFC Editor: RFC 1972 is mentioned in the text, but is not listed in the references. Please add a reference. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 2 10:56:08 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id KAA09566 for ipng-dist; Tue, 2 Feb 1999 10:50:58 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id KAA09559 for ; Tue, 2 Feb 1999 10:50:47 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA06077 for ; Tue, 2 Feb 1999 10:50:46 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA16655 for ; Tue, 2 Feb 1999 10:50:35 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA29265; Tue, 2 Feb 1999 13:49:55 -0500 (EST) Message-Id: <199902021849.NAA29265@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 7148) Protocol Action: Reserved IPv6 Subnet Anycast Addresses to Proposed Standard Date: Tue, 02 Feb 1999 13:49:55 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Reserved IPv6 Subnet Anycast Addresses' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. Technical Summary The IP Version 6 addressing architecture defines an "anycast" address as an IPv6 address that is assigned to one or more network interfaces (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance. This document defines a set of reserved anycast addresses within each subnet prefix, and lists the initial allocation of these reserved subnet anycast addresses. Working Group Summary There was strong WG support for this document. Other documents in the pipeline (e.g., Mobile IP for IPv6) make use of anycast addresses. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 2 12:29:26 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id MAA09711 for ipng-dist; Tue, 2 Feb 1999 12:21:15 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id MAA09704 for ; Tue, 2 Feb 1999 12:20:55 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA13994 for ; Tue, 2 Feb 1999 12:20:52 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA15820 for ; Tue, 2 Feb 1999 12:20:49 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA02838; Tue, 2 Feb 1999 15:20:09 -0500 (EST) Message-Id: <199902022020.PAA02838@ietf.org> To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: (IPng 7149) Document Action: Basic Socket Interface Extensions for IPv6 to Informational Date: Tue, 02 Feb 1999 15:20:09 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Basic Socket Interface Extensions for IPv6' as a Informational. This document is the product of the IPNG Working Group. The IESG contact persons are Jeffrey Burgan and Thomas Narten. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 4 05:03:48 1999 Received: by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) id FAA11297 for ipng-dist; Thu, 4 Feb 1999 05:00:44 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3.Beta0+Sun/8.9.3.Beta0) with SMTP id FAA11290 for ; Thu, 4 Feb 1999 05:00:35 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id FAA07463 for ; Thu, 4 Feb 1999 05:00:34 -0800 Received: from kame200.kame.net (kame200.kame.net [203.178.141.200]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA12976 for ; Thu, 4 Feb 1999 05:00:33 -0800 (PST) Received: from localhost (localhost.kame.net [127.0.0.1]) by kame200.kame.net (8.8.8/8.8.8) with ESMTP id WAA12690 for ; Thu, 4 Feb 1999 22:03:18 +0900 (JST) (envelope-from kazu@kame.net) To: ipng@sunroof.eng.sun.com Subject: (IPng 7151) the 5th announcement of KAME stable release Mime-Version: 1.0 From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 1.94b2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990204220318X.kazu@kame.net> Date: Thu, 04 Feb 1999 22:03:18 +0900 X-Dispatcher: imput version 981124(IM104) Lines: 49 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As usual, KAME Project has released "stable" packages of IPv6/IPsec network code for FreeBSD 2.2.8, NetBSD 1.3.3, and BSD/OS 3.1. These packages are free of charge but absolutely no warranty. They are avaiable from the following web site: http://www.kame.net/ Here is a summary of the differences between KAME stable 19981130 and 19990131. <> - ATM PVC pseudo device support for NetBSD - ALTQ 1.1.3 support - if_xl.c(FreeBSD 2.2.8) update <> - ND6 works properly as expected. - bug fix of preventing non-link local multicast packets receipt - introduced IPv6 only protosw, and backout KAME changes to sys/protosw.h - changed *_input() return value from IPPROTO_NONE to IPPROTO_DONE. (this fix mbuf leak bug at receiving a packet with "no next header") <> - setsockopt(IPV6_CHECSUM) was stabilized. - changed the member name of sockaddr_strage as bsd-api-new-05 <> - removed confilict of KMALLOC/KFREE macro between ipsec and ip filter <> - telnet supports source route for both IPv4 and IPv6: (@gw1@gw2@dest). - many bug fixes and enhancements of bgpd - rewrote tcp_relay() of faithd(for more stability) - kame-send-pr is provieded for submitting KAME problems - kit/src is confirmed or patched to work on FreeBSD 3.0 <> - "bind8" is ready to talk IPv6. - "apache13" was updated to use new patch which fixed args for freeaddrinfo(). - upgraded many ports' base version - ports tcptrace support - ports wbd support(multicast shared whiteboard) - pkgsrc support for NetBSD, many pkgsrc added to NetBSD - NetBSD ftp, ftpd EPRT/EPSV support - altq package support for NetBSD --KAME Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 5 08:53:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA12613 for ipng-dist; Fri, 5 Feb 1999 08:49:47 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA12606 for ; Fri, 5 Feb 1999 08:49:36 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA27700 for ; Fri, 5 Feb 1999 08:49:35 -0800 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA05477 for ; Fri, 5 Feb 1999 08:49:32 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with ESMTP id BAA15676 for ; Sat, 6 Feb 1999 01:49:28 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: (IPng 7155) neighbor discovery spec hole (link-layer addr) X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Hagino Date: Sat, 06 Feb 1999 01:49:28 +0900 Message-ID: <15672.918233368@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As I commented at interm meeting, I would like to raise this again. I believe this is serious (or not minor) problem, not an implementation issue, because: - If an implementation initializes state into STALE on receipt of RA, that host will not be able to communicate with the router for certain period of time. Spec must clearly describe this situation. - NDP module has to be implemented in link-layer independent manner. We'll have serious problem if we once start using some link-layer without explicit link-layer address. I'll try to come up with concrete changes to the spec. (i.e. diff) itojun ------- Forwarded Messages Return-Path: Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with SMTP id VAA26185 for ; Thu, 5 Nov 1998 21:27:38 +0900 (JST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id EAA27890; Thu, 5 Nov 1998 04:14:53 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id EAA23980; Thu, 5 Nov 1998 04:14:50 -0800 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id EAA16156 for ipng-dist; Thu, 5 Nov 1998 04:09:04 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id EAA16149 for ; Thu, 5 Nov 1998 04:08:53 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id EAA11542 for ; Thu, 5 Nov 1998 04:08:51 -0800 Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id EAA10580; Thu, 5 Nov 1998 04:08:51 -0800 (PST) Received: from localhost (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with ESMTP id VAA24755; Thu, 5 Nov 1998 21:08:33 +0900 (JST) To: nordmark@Sun.COM, narten@raleigh.ibm.com, bsimpson@MorningStar.com cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 6697) discovery-v2-03 questions (neighbor cache handling) X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 From: Jun-ichiro itojun Itoh Date: Thu, 05 Nov 1998 21:08:33 +0900 Message-ID: <24751.910267713@coconut.itojun.org> Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk X-Filter: mailagent [version 3.0 PL56] for itojun@itojun.org I got several questions related to ND6 protocol spec, namely discovery-v2-03. In the following, "lladdr" means "link-layer address", such as ethernet MAC address. I would like to know opinions from implementers, how UNH interop test understands the spec, and so forth. Thanks, itojun@kame.net itojun@iijlab.net jun-ichiro itoh 1. neighbor cache processing rule when no lladdr is attached. ============================================================= ND6 specification defines the following conditions for src/dst lladdr option, for each ND6 packet type: RS: medium w/o lladdr: not needed (can't attach) medium with lladdr: source lladdr option SHOULD be included, if lladdr is known RA: medium w/o lladdr: not needed (can't attach) medium with lladdr: router MAY attach source lladdr option, MAY omit it for load balancing NS: medium w/o lladdr: not needed (can't attach) medium with lladdr: source lladdr option MUST be attached for multicast solicitation, SHOULD be attached for unicast solicitation redirect: medium w/o lladdr: not needed (can't attach) medium with lladdr: target lladdr option SHOULD be included if known. (ATM) MUST be included on some medium. As seen in the above list, it is not rare to see RS/RA/NS/redirect packet, WITHOUT source/target lladdr option. However, the following sections in discovery-v2-03 assume that source/target lladdr is attached to ND packet: 6.2.6(RS) 6.3.4(RA) 7.2.3(NS) 8.3(redirect) appendix C, second state transition chart (p87 to p88) must be clarified for the following 3 cases: medium without lladdr medium with lladdr, packet with lladdr medium with lladdr, packet without lladdr This should be fixed. Also, 6.2.6, 6.3.4, 7.2.3 and 8.3 has almost the same textual description for neighbor cache updates. I believe these duplicates should be merged into one section somewhere. It is not very trivial to clarify. Choices might be: 1. do not make neighbor cache if there's no lladdr, or 2. make neighbor cache with some state. However, these ways do not work very well. 1. If you do not make neighbor cache entry: You cannot record IsRouter flag, and you will have chances for stale entry on default router list. For example, the following list of event will create a stale entry: router X transmits RA without lladdr. Host Y will install default router list entry for X. No neighbor cache entry created. router X becomes host. host X (previously router X) transmits NS with lladr. Default router list entry for X remains on the host Y. Neighbor cache entry will be created, with IsRouter 0, based on NS processing rule. Now, you got a problem. If you try to send a packet to off-link destination, you will be sending packet to host X. If host Y ignores "RA without lladdr", there will be no stale default router list entry. However, in this case, router X can never achieve load balancing among the routers by sending "RA without lladdr" from routers. The source of the problem is recaped in the second question, "neighbor cache entry and default router list". See the last part of the email. What should on medium without lladdr? It is still unclear for us. 2a. If you make neighbor cache entry with INCOMPLETE state: INCOMPLETE state does not really fit this situation. INCOMPLETE is defined as: Address resolution is in progress and the link-layer address of the neighbor has not yet been determined. However, we have never performed address resolution for this entry. It is not good to require address resolution for every "RA without lladdr". 2b. If you make neighbor cache entry with some state other than INCOMPLETE If there is an entry with non-INCOMLETE state, it is assumed that the entry once has lladdr for the target in the past. Therefore, it is not very suitable for this situation. If you set the state to STALE you have a big problem --- DELAY state will defer your future address resolution. Here are solutions we came up with. Solution 1: (from jinmei@kame.net) If a node receives ND packet without lladdr, do not make neighbor cache. If node is about to send a pacet to off-link destination, and router X is chosen from default router list, and there is no neighbor cache entry for router X, node should perform the following. - make neighbor cache entry - set it INCOMPLETE - set IsRouter bit for the entry - perform neighbor discovery - transmit packet if ND completed /* * new entry: neighbor cache entrys is created * olladdr: neighbor cache entry got old lladdr * lladdr: packet contains lladdr option * llchange: olladdr != lladdr * * newentry olladdr lladdr llchange (*=record lladdr) * 0 n n -- (1) * 0 y n -- (2) * 0 n y -- (3) * set state to STALE * 0 y y n (4) * * 0 y y y (5) * set state to STALE * 1 -- n -- (6) (don't create entry) * 1 -- y -- (7) * set state to STALE */ Solution 2: (from itojun@kame.net) Define a new neighbor cache state, PASSIVE. PASSIVE entry will be made when a node received ND packets without lladdr. If a node received RA/RS/NS/redirect without lladdr option, 1. create neighbor cache entry, 2. make it PASSIVE state, and 3. set IsRouter flag properly. You MUST NOT remove neighbor cache entry for node A, if node A is listed in default router list. The above rule still works if there's no lladdr defined for the medium. /* * new entry: neighbor cache entrys is created * olladdr: neighbor cache entry got old lladdr * lladdr: packet contains lladdr option * llchange: olladdr != lladdr * * newentry olladdr lladdr llchange (*=record lladdr) * 0 n n -- (1) * 0 y n -- (2) * 0 n y -- (3) * set state to STALE * 0 y y n (4) * * 0 y y y (5) * set state to STALE * 1 -- n -- (6) set state to PASSIVE * 1 -- y -- (7) * set state to STALE */ /* * ICMP6 type dependent behavior. * * NS: clear IsRouter if new entry * RS: clear IsRouter * RA: set IsRouter if there's lladdr * redir: clear IsRouter if new entry * * newentry olladdr lladdr llchange NS RS RA redir * 0 n n -- (1) c s? * 0 y n -- (2) c s * 0 n y -- (3) c s * 0 y y n (4) c s * 0 y y y (5) c s * 1 -- n -- (6) c c s? c * 1 -- y -- (7) c c s c * * (c=clear s=set) */ Clarification 1: To make implementations easy, rules for source/target lladdr option for ND packets should be: - on medium with lladdr: MUST attach one - on medium w/o lladdr: not needed (and cannot attach) 2. neighbor cache entry and default router list =============================================== Rules for IsRouter bit is "edge trigger" in nature. Therefore, IsRouter rule works only if the following statement is satisfied: For a node that is listed onto default router list, there always be a neighbor cache entry. This must be clearly stated somewhere in document. (What happens on medium ithout lladdr?? We still need to make neighbor cache entry just for IsRouter bit) IsRouter bit must be revisited, really. - -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com - -------------------------------------------------------------------- ------- Message 2 Return-Path: Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by coconut.itojun.org (8.9.1+3.1W/3.7W) with SMTP id FAA03028 for ; Fri, 6 Nov 1998 05:53:17 +0900 (JST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA18273; Thu, 5 Nov 1998 12:49:56 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id MAA17667; Thu, 5 Nov 1998 12:49:52 -0800 Received: by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) id MAA16897 for ipng-dist; Thu, 5 Nov 1998 12:42:48 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.1+Sun/8.9.1) with SMTP id MAA16890 for ; Thu, 5 Nov 1998 12:42:40 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA16323 for ; Thu, 5 Nov 1998 12:41:51 -0800 Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA29146 for ; Thu, 5 Nov 1998 12:41:45 -0800 (PST) Received: by mail3.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Thu, 5 Nov 1998 12:41:32 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81607@RED-MSG-50> From: Richard Draves To: "'Jun-ichiro itojun Itoh'" , nordmark@Sun.COM, narten@raleigh.ibm.com, bsimpson@MorningStar.com Cc: ipng@sunroof.Eng.Sun.COM Subject: (IPng 6702) RE: discovery-v2-03 questions (neighbor cache handlin g) Date: Thu, 5 Nov 1998 12:41:30 -0800 X-Mailer: Internet Mail Service (5.5.2232.9) Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk X-Filter: mailagent [version 3.0 PL56] for itojun@itojun.org Our MSR IPv6 implementation follows your second suggested solution. Our INCOMPLETE state has two flavors, one which corresponds to your PASSIVE state (no soliciting) and one in which we are actively soliciting to resolve the address. So for the case of receiving an RA without a source link-layer address option, the end result is that we create an NCE in the "passive" INCOMPLETE state with IsRouter = TRUE. If we should try to send to that neighbor, then we start soliciting at that point. As you suggest, we also keep permanently NCEs corresponding to routers on the default router list. This is done with a reference count - we only reclaim NCEs that have zero references, and the default router list holds a reference for the corresponding NCEs. However this appears to me to be an implementation choice. Rich > -----Original Message----- > From: Jun-ichiro itojun Itoh [mailto:itojun@iijlab.net] > Sent: Thursday, November 05, 1998 4:09 AM > To: nordmark@Sun.COM; narten@raleigh.ibm.com; bsimpson@MorningStar.com > Cc: ipng@sunroof.Eng.Sun.COM > Subject: (IPng 6697) discovery-v2-03 questions (neighbor > cache handling) > > > I got several questions related to ND6 protocol spec, namely > discovery-v2-03. In the following, "lladdr" means "link-layer > address", such as ethernet MAC address. > > I would like to know opinions from implementers, how UNH interop > test understands the spec, and so forth. Thanks, > > itojun@kame.net > itojun@iijlab.net > jun-ichiro itoh > > > 1. neighbor cache processing rule when no lladdr is attached. > ============================================================= > ND6 specification defines the following conditions for > src/dst lladdr option, > for each ND6 packet type: > RS: medium w/o lladdr: not needed (can't attach) > medium with lladdr: source lladdr option SHOULD be included, > if lladdr is known > RA: medium w/o lladdr: not needed (can't attach) > medium with lladdr: router MAY attach source lladdr option, > MAY omit it for load balancing > NS: medium w/o lladdr: not needed (can't attach) > medium with lladdr: > source lladdr option MUST be attached for multicast > solicitation, SHOULD be attached for > unicast solicitation > redirect: > medium w/o lladdr: not needed (can't attach) > medium with lladdr: > target lladdr option SHOULD be included if known. > (ATM) MUST be included on some medium. > > As seen in the above list, it is not rare to see RS/RA/NS/redirect > packet, WITHOUT source/target lladdr option. > > However, the following sections in discovery-v2-03 assume > that source/target > lladdr is attached to ND packet: > 6.2.6(RS) > 6.3.4(RA) > 7.2.3(NS) > 8.3(redirect) > appendix C, second state transition chart (p87 to p88) must be > clarified for the following 3 cases: > medium without lladdr > medium with lladdr, packet with lladdr > medium with lladdr, packet without lladdr > This should be fixed. Also, 6.2.6, 6.3.4, 7.2.3 and 8.3 has almost > the same textual description for neighbor cache updates. I believe > these duplicates should be merged into one section somewhere. > > It is not very trivial to clarify. Choices might be: > 1. do not make neighbor cache if there's no lladdr, or > 2. make neighbor cache with some state. > However, these ways do not work very well. > > > 1. If you do not make neighbor cache entry: > You cannot record IsRouter flag, and you will have chances for > stale entry on default router list. > For example, the following list of event will create a > stale entry: > router X transmits RA without lladdr. > Host Y will install default router list > entry for X. > No neighbor cache entry created. > router X becomes host. > host X (previously router X) transmits NS with lladr. > Default router list entry for X remains > on the host Y. > Neighbor cache entry will be created, > with IsRouter 0, > based on NS processing rule. > Now, you got a problem. If you try to send a packet to off-link > destination, you will be sending packet to host X. > > If host Y ignores "RA without lladdr", there will be no > stale default > router list entry. However, in this case, router X can > never achieve > load balancing among the routers by sending "RA without lladdr" > from routers. > > The source of the problem is recaped in the second question, > "neighbor cache entry and default router list". See the last > part of the email. > > What should on medium without lladdr? It is still > unclear for us. > > 2a. If you make neighbor cache entry with INCOMPLETE state: > INCOMPLETE state does not really fit this situation. > INCOMPLETE is > defined as: > Address resolution is in progress and the link-layer > address of the neighbor has not yet been determined. > However, we have never performed address resolution for > this entry. > > It is not good to require address resolution for every > "RA without > lladdr". > > 2b. If you make neighbor cache entry with some state other > than INCOMPLETE > If there is an entry with non-INCOMLETE state, it is assumed > that the entry once has lladdr for the target in the past. > Therefore, it is not very suitable for this situation. > If you set the state to STALE you have a big problem > --- DELAY state > will defer your future address resolution. > > > Here are solutions we came up with. > Solution 1: (from jinmei@kame.net) > If a node receives ND packet without lladdr, do not > make neighbor > cache. > > If node is about to send a pacet to off-link > destination, and router X > is chosen from default router list, and there is no > neighbor cache > entry for router X, node should perform the following. > - make neighbor cache entry > - set it INCOMPLETE > - set IsRouter bit for the entry > - perform neighbor discovery > - transmit packet if ND completed > > /* > * new entry: neighbor cache entrys is created > * olladdr: neighbor cache entry got old lladdr > * lladdr: packet contains lladdr option > * llchange: olladdr != lladdr > * > * newentry olladdr lladdr llchange (*=record lladdr) > * 0 n n -- (1) > * 0 y n -- (2) > * 0 n y -- (3) * set state to STALE > * 0 y y n (4) * > * 0 y y y (5) * set state to STALE > * 1 -- n -- (6) (don't > create entry) > * 1 -- y -- (7) * set state to STALE > */ > > Solution 2: (from itojun@kame.net) > Define a new neighbor cache state, PASSIVE. PASSIVE > entry will be > made when a node received ND packets without lladdr. > If a node received RA/RS/NS/redirect without lladdr option, > 1. create neighbor cache entry, > 2. make it PASSIVE state, and > 3. set IsRouter flag properly. > You MUST NOT remove neighbor cache entry for node A, if > node A is > listed in default router list. > > The above rule still works if there's no lladdr defined > for the medium. > > /* > * new entry: neighbor cache entrys is created > * olladdr: neighbor cache entry got old lladdr > * lladdr: packet contains lladdr option > * llchange: olladdr != lladdr > * > * newentry olladdr lladdr llchange (*=record lladdr) > * 0 n n -- (1) > * 0 y n -- (2) > * 0 n y -- (3) * set state to STALE > * 0 y y n (4) * > * 0 y y y (5) * set state to STALE > * 1 -- n -- (6) set state > to PASSIVE > * 1 -- y -- (7) * set state to STALE > */ > /* > * ICMP6 type dependent behavior. > * > * NS: clear IsRouter if new entry > * RS: clear IsRouter > * RA: set IsRouter if there's lladdr > * redir: clear IsRouter if new entry > * > * newentry olladdr lladdr llchange NS RS RA redir > * 0 n n -- (1) c s? > * 0 y n -- (2) c s > * 0 n y -- (3) c s > * 0 y y n (4) c s > * 0 y y y (5) c s > * 1 -- n -- (6) c c s? c > * 1 -- y -- (7) c c s c > * > * (c=clear s=set) > */ > > Clarification 1: > To make implementations easy, rules for source/target > lladdr option > for ND packets should be: > - on medium with lladdr: MUST attach one > - on medium w/o lladdr: not needed (and cannot attach) > > > 2. neighbor cache entry and default router list > =============================================== > Rules for IsRouter bit is "edge trigger" in nature. > Therefore, IsRouter > rule works only if the following statement is satisfied: > > For a node that is listed onto default router list, > there always be a neighbor cache entry. > > This must be clearly stated somewhere in document. (What > happens on medium > ithout lladdr?? We still need to make neighbor cache entry just for > IsRouter bit) > > IsRouter bit must be revisited, really. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 - -------------------------------------------------------------------- ------- End of Forwarded Messages -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 5 09:36:29 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA12672 for ipng-dist; Fri, 5 Feb 1999 09:27:27 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12665 for ; Fri, 5 Feb 1999 09:27:22 -0800 (PST) Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA20683 for ; Fri, 5 Feb 1999 09:27:22 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.9.1b+Sun/8.9.1) id JAA26950 for ipng@sunroof.eng.sun.com; Fri, 5 Feb 1999 09:26:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA12132; Thu, 4 Feb 1999 21:40:12 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA14317; Thu, 4 Feb 1999 21:40:11 -0800 Received: from research.gate.nec.co.jp (research.gate.nec.co.jp [202.32.8.49]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA24162; Thu, 4 Feb 1999 21:40:12 -0800 (PST) Received: from leek.nwk.cl.nec.co.jp (root@leek.nwk.cl.nec.co.jp [10.56.32.7]) by research.gate.nec.co.jp (8.8.8+2.7Wbeta7/971104) with ESMTP id OAA15836; Fri, 5 Feb 1999 14:40:11 +0900 (JST) Received: from dresden.nwk.cl.nec.co.jp by leek.nwk.cl.nec.co.jp (8.9.2/NWK-980903) with ESMTP id OAA15895; Fri, 5 Feb 1999 14:40:10 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by dresden.nwk.cl.nec.co.jp (8.8.8/3.6W98052515HK) with ESMTP id OAA08154; Fri, 5 Feb 1999 14:35:35 +0900 (JST) To: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: (IPng 7156) Release announcement of the SOCKS-based IPv6/IPv4 Translator X-Mailer: Mew version 1.93 on Emacs 19.28 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <19990205143534F.kitamura@ccm.cl.nec.co.jp> Date: Fri, 05 Feb 1999 14:35:34 +0900 From: Hiroshi KITAMURA X-Dispatcher: imput version 980905(IM100) Lines: 54 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All: This is release announcement of the SOCKS-based IPv6/IPv4 Translator that was explained at Orlando meeting. This package provides heterogeneous connections between IPv4 and IPv6 nodes. If you would like to communicate from your IPv4 node to IPv6 node or from your IPv6 node to IPv4 node, please download this package and evaluate it. What you have to do are: 1. download packages 2. compile them on IPv4/IPv6 dual stack node. 3. install enhanced socks5 sever to dual stack node. 4. install enhanced socks5 library to IPv4 or IPv6 node. 5. setup configuration files. 6. socksify applications when you execute them. That's all You don't have to modify the DNS system at all. You don't have to prepare address mapping servers. etc. Now, the source code of this package is available from following URL: http://www.socks.nec.com/ Please visit this site. Click "Translator" button to see brief explanation. Download Instruction: Click "Download socks5" button at http://www.socks.nec.com/ Go down to the bottom of the download page. Select "socks5 v1.0 release 8 - translator patch 1.1" package at pull down form. Click "Download" button. If you don't have "socks5 v1.0 release 8 - UNIX Source" package, do the same procedure to download it. Details of the SOCKS-based IPv6/IPv4 Translator is explained by following Internet-Draft. http://www.ietf.org/internet-drafts/draft-kitamura-socks-ipv6-trans-arch-00.txt Regards, Hiroshi / / / / Hiroshi KITAMURA __ / __/ __ __/ __ __/ C&C Media Research Laboratories / / _ _ /__/ / NEC Corporation _____/ _____/ __/__/__/ ___/ Tel +81-44-856-2123 Fax +81-44-856-2230 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 9 09:15:40 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA15455 for ipng-dist; Tue, 9 Feb 1999 09:06:06 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA15448 for ; Tue, 9 Feb 1999 09:05:54 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA25417 for ; Tue, 9 Feb 1999 09:05:40 -0800 Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA15262 for ; Tue, 9 Feb 1999 08:59:26 -0800 (PST) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Tue, 9 Feb 1999 08:59:15 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81C3C@RED-MSG-50> From: Richard Draves To: "'Jun-ichiro itojun Hagino'" Cc: ipng@sunroof.eng.sun.com Subject: (IPng 7158) RE: neighbor discovery spec hole (link-layer addr) Date: Tue, 9 Feb 1999 08:59:12 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As I commented at interm meeting, I would like to raise > this again. > > I believe this is serious (or not minor) problem, not > an implementation > issue, because: > - If an implementation initializes state into STALE on > receipt of RA, > that host will not be able to communicate with the router for > certain period of time. Spec must clearly describe > this situation. > - NDP module has to be implemented in link-layer > independent manner. > We'll have serious problem if we once start using > some link-layer > without explicit link-layer address. You describe a situation where the implementation would like to create a Neighbor Cache Entry (NCE) for a neighbor, to record some state (IsRouter bit) and perhaps so other data structures (eg Default Router List) and point to the NCE. However the implementation does not have a link-layer address with which to initialize the NCE. And the interface is on a link that uses link-layer addresses. You note that the INCOMPLETE state implies that link-layer address resolution is active, while the non-INCOMPLETE states (eg STALE) imply knowledge of a link-layer address. So none of the defined states are appropriate. My solution for this situation in our implementation is to have two flavors of the INCOMPLETE state, an "active" mode in which link-layer address resolution is proceeding and a "passive" mode in which it is not. An attempt to send a packet to the neighbor transitions the NCE from the passive INCOMPLETE state to the active INCOMPLETE state, causing a Neighbor Solicitation to be sent. Now the question is whether this needs to be specified. It's not clear to me that it must be specified. For example an alternative implementation might not create an NCE in this situation. The spec needs to be clear about an implementation's observable behavior, or explicitly allow different observable behaviors. It's desirable that it also be a good guide to implementators but it can and should leave some room for creativity in that department. Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 9 09:48:14 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA15510 for ipng-dist; Tue, 9 Feb 1999 09:40:39 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA15487; Tue, 9 Feb 1999 09:37:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA27709; Tue, 9 Feb 1999 09:37:48 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id JAA14857; Tue, 9 Feb 1999 09:37:12 -0800 (PST) Received: from flume.zk3.dec.com (brrflume.zk3.dec.com [16.141.56.6]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id MAA23824; Tue, 9 Feb 1999 12:36:09 -0500 (EST) Received: from wasted.zk3.dec.com by flume.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000005854; Tue, 9 Feb 1999 12:35:42 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id MAA0000005879; Tue, 9 Feb 1999 12:35:42 -0500 (EST) From: Jim Bound Message-Id: <199902091735.MAA0000005879@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: deployment@ipv6.org cc: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@isi.edu, bound@zk3.dec.com Subject: (IPng 7159) V6 Deployment Slides Date: Tue, 09 Feb 1999 12:35:42 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, We are working on the minutes now bear with us..... Here are the slides from the deployment meeting. I am still missing Dale Finkelson's slides on Internet2/vBNS network. I sent Dale mail. You can ftp these via anon ftp from sipper.zk3-x.dec.com (cd to /pub dir) except www.6ren and www.nttv6 where you can go to those URLs to get them. [Note you should be able to access sipper with IPv6 by accessing sipper.ipv6.zk3-x.dec.com via the 6bone] Henk Steenman - Amsterdam IX IPv6 Native ams_ix_ipv6.pdf Jim Bound Compaq sub-TLA Analysis and Request (our Palo Alto Gateway) compaq_subTLA.ppt Marc Blanchet - IPv6 Deployment Tools etc.. freenet6.pdf Latif Ladd - Influencing IPv6 and Promoting (DEFINITELY CHECK THESE SLIDES OUT THEY ARE A WAKE UP CALL to us all on the Internet) ipv6_influence.zip Itojun - IPv6 Verification Tools ipv6_verification.txt Jun Murai - IPv6 Deployment in Japan japan_deploy.ppt japan_deployment.txt (back up text) Bob Fink - 6REN and 6TAP (real Ipv6 Deployment) www.6ren.net (click on "introduction and 6TAP") 6ren-Orlando.pdf 6tap.pdf Kenji OTA - IETF Terminal Room Experiences with IPv6 www.nttv6.net/Grenoble/ p.s. Historical Note sipper is the node we put our first IPng kit on supporting the sip protocol in 1994 which was designed by Steve Deering and the predecessor to IPv6] /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 Feb 9 10:05:22 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA15628 for ipng-dist; Tue, 9 Feb 1999 10:02:41 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA15590; Tue, 9 Feb 1999 10:01:00 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA12087; Tue, 9 Feb 1999 10:00:58 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id KAA26015; Tue, 9 Feb 1999 10:00:55 -0800 (PST) Received: from quarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id MAA14558; Tue, 9 Feb 1999 12:59:35 -0500 (EST) Received: from wasted.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000030681; Tue, 9 Feb 1999 12:59:36 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id MAA0000009078; Tue, 9 Feb 1999 12:59:35 -0500 (EST) From: Jim Bound Message-Id: <199902091759.MAA0000009078@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: deployment@ipv6.org cc: bound@zk3.dec.com, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@isi.edu Subject: (IPng 7162) V6 Deployment Slides Internet2 and IPv6 Date: Tue, 09 Feb 1999 12:59:35 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dale sent me his slides. Dale Finkelson's slides on Internet2/vBNS network. I sent Dale mail. You can ftp these via anon ftp from sipper.zk3-x.dec.com (cd to /pub dir). [Note you should be able to access sipper with IPv6 by accessing sipper.ipv6.zk3-x.dec.com via the 6bone] Dale Finkelson - Internet2 and IPv6 internet2_ipv6.ppt /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 Feb 9 10:05:27 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA15579 for ipng-dist; Tue, 9 Feb 1999 09:59:51 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA15572 for ; Tue, 9 Feb 1999 09:59:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA11810 for ; Tue, 9 Feb 1999 09:59:33 -0800 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by saturn.sun.com (8.9.1/8.9.1) with SMTP id JAA25326 for ; Tue, 9 Feb 1999 09:59:31 -0800 (PST) Received: by mailgate.rdg.opengroup.org; id AA16242; Tue, 9 Feb 1999 17:58:50 GMT Received: from cjh.rdg.opengroup.org [192.153.166.111] by mailgate.rdg.opengroup.org via smtpd V1.26 (98/11/23 13:59:56) for ; Tue Feb 09 17:58 GMT 1999 Message-Id: <3.0.3.32.19990209174605.007b8c10@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Tue, 09 Feb 1999 17:46:05 +0000 To: "Perry E. Metzger" From: Chris Harding Subject: (IPng 7161) IPv6 in UNIX sockets Cc: deployment@ipv6.org, ipng@sunroof.eng.sun.com, xnet@opengroup.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Perry, A new draft of the Open Group XNS specification, incorporating the Basic API to IPv6 per the recently announced RFC, is now on the web. There is an introductory page at http://www.opengroup.org/platform/xnetipv6.htm and it would probably be best to point to this page from http://www.ipv6.org Comments from the ipng and ipv6 deployment communities are most welcome, with one proviso - we don't want to re-visit issues that have already been settled in the RFC! Regards, Chris +++++ ------------------------------------------------------------------------- Chris Harding T H E Development Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Fx: +44 118 950 0110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 9 10:05:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA15550 for ipng-dist; Tue, 9 Feb 1999 09:55:35 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA15543; Tue, 9 Feb 1999 09:55:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA09255; Tue, 9 Feb 1999 09:55:16 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id JAA23329; Tue, 9 Feb 1999 09:55:13 -0800 (PST) Received: by jekyll.piermont.com (Postfix, from userid 1000) id C6E93166; Tue, 9 Feb 1999 12:53:57 -0500 (EST) To: 6ren@es.net, 6bone@isi.edu, ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, ietf@ietf.org Subject: (IPng 7160) IPv6 Users Mailing List Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 09 Feb 1999 12:53:57 -0500 Message-ID: <87hfsv31l6.fsf@jekyll.piermont.com> Lines: 18 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Please forward this message to places that might be interested in it.] A mailing list has been established for early adopters of IPv6 who need help setting up their IPv6 based networks and network stacks, connecting to the 6bone, getting applications to work with IPv6 and similar problems. The mailing list, users@ipv6.org, may be subscribed to by sending mail to majordomo@ipv6.org with the words "subscribe users" in the body of the message. Note that although developers of IPv6 stacks are strongly encouraged to join the mailing list to help the early adopters, this list is not intended for discussions of IPv6 stack development issues -- it is there to help the users of the technology. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 9 12:32:19 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA20314 for ipng-dist; Tue, 9 Feb 1999 12:22:42 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA20299; Tue, 9 Feb 1999 12:22:15 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA16861; Tue, 9 Feb 1999 12:22:14 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA04360; Tue, 9 Feb 1999 12:22:11 -0800 (PST) Received: by jekyll.piermont.com (Postfix, from userid 1000) id EE725166; Tue, 9 Feb 1999 15:22:03 -0500 (EST) To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@isi.edu Cc: Jim Bound Subject: (IPng 7163) Grenoble Slides Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 09 Feb 1999 15:22:02 -0500 Message-ID: <87vhhbz5sl.fsf@jekyll.piermont.com> Lines: 9 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've put copies of the Grenoble meeting slides Jim Bound put up on sipper in ftp://ftp.ipv6.org/pub/meetings/grenoble99/ I'll put up the meeting minutes as soon as they become available. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 9 13:04:02 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA20561 for ipng-dist; Tue, 9 Feb 1999 12:52:43 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA20546 for ; Tue, 9 Feb 1999 12:52:22 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA09190 for ; Tue, 9 Feb 1999 12:52:21 -0800 Received: from popmail.space.net (popmail.Space.Net [195.30.0.14]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA25927 for ; Tue, 9 Feb 1999 12:52:19 -0800 (PST) Received: (qmail 6311 invoked from network); 9 Feb 1999 20:52:14 -0000 Received: from router.cam-comp.de (HELO websrv1.cam-comp.de) (195.30.54.222) by popmail.space.net with SMTP; 9 Feb 1999 20:52:14 -0000 Received: from websrv1 ([192.168.200.76]) by websrv1.cam-comp.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1RNX91G8; Tue, 9 Feb 1999 21:54:43 +0100 Delivered-To: cam-comp.de-Rolf.Kozlowski@cam-comp.de Received: (qmail 4536 invoked from network); 9 Feb 1999 20:37:44 -0000 Received: from mail.space.net (194.59.182.8) by popmail.space.net with SMTP; 9 Feb 1999 20:37:44 -0000 Received: (qmail 18077 invoked from network); 9 Feb 1999 20:37:43 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.space.net with SMTP; 9 Feb 1999 20:37:43 -0000 Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA09319; Tue, 9 Feb 1999 12:36:07 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id MAA06835; Tue, 9 Feb 1999 12:36:04 -0800 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA20482 for ngtrans-dist; Tue, 9 Feb 1999 12:32:41 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA20299; Tue, 9 Feb 1999 12:22:15 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA16861; Tue, 9 Feb 1999 12:22:14 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA04360; Tue, 9 Feb 1999 12:22:11 -0800 (PST) Received: by jekyll.piermont.com (Postfix, from userid 1000) id EE725166; Tue, 9 Feb 1999 15:22:03 -0500 (EST) To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@isi.edu Cc: Jim Bound Subject: (IPng 7164) (ngtrans) Grenoble Slides X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 09 Feb 1999 15:22:02 -0500 Message-ID: <87vhhbz5sl.fsf@jekyll.piermont.com> Lines: 9 Reply-To: ngtrans@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've put copies of the Grenoble meeting slides Jim Bound put up on sipper in ftp://ftp.ipv6.org/pub/meetings/grenoble99/ I'll put up the meeting minutes as soon as they become available. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 9 13:04:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA20562 for ipng-dist; Tue, 9 Feb 1999 12:52:50 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA20548 for ; Tue, 9 Feb 1999 12:52:23 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA24493 for ; Tue, 9 Feb 1999 12:52:19 -0800 Received: from popmail.space.net (popmail.Space.Net [195.30.0.14]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA25901 for ; Tue, 9 Feb 1999 12:52:17 -0800 (PST) Received: (qmail 6288 invoked from network); 9 Feb 1999 20:52:13 -0000 Received: from router.cam-comp.de (HELO websrv1.cam-comp.de) (195.30.54.222) by popmail.space.net with SMTP; 9 Feb 1999 20:52:13 -0000 Received: from websrv1 ([192.168.200.76]) by websrv1.cam-comp.de with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 1RNX91G6; Tue, 9 Feb 1999 21:54:41 +0100 Delivered-To: cam-comp.de-Rolf.Kozlowski@cam-comp.de Received: (qmail 4476 invoked from network); 9 Feb 1999 20:37:14 -0000 Received: from mail.space.net (194.59.182.8) by popmail.space.net with SMTP; 9 Feb 1999 20:37:14 -0000 Received: (qmail 18019 invoked from network); 9 Feb 1999 20:37:12 -0000 Received: from mercury.sun.com (192.9.25.1) by mail.space.net with SMTP; 9 Feb 1999 20:37:12 -0000 Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id MAA08587; Tue, 9 Feb 1999 12:34:10 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with ESMTP id MAA19859; Tue, 9 Feb 1999 12:34:09 -0800 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA20314 for ipng-dist; Tue, 9 Feb 1999 12:22:42 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA20299; Tue, 9 Feb 1999 12:22:15 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA16861; Tue, 9 Feb 1999 12:22:14 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA04360; Tue, 9 Feb 1999 12:22:11 -0800 (PST) Received: by jekyll.piermont.com (Postfix, from userid 1000) id EE725166; Tue, 9 Feb 1999 15:22:03 -0500 (EST) To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@isi.edu Cc: Jim Bound Subject: (IPng 7165) Grenoble Slides Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 09 Feb 1999 15:22:02 -0500 Message-ID: <87vhhbz5sl.fsf@jekyll.piermont.com> Lines: 9 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've put copies of the Grenoble meeting slides Jim Bound put up on sipper in ftp://ftp.ipv6.org/pub/meetings/grenoble99/ I'll put up the meeting minutes as soon as they become available. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 10 07:52:57 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA24278 for ipng-dist; Wed, 10 Feb 1999 07:44:44 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA24247; Wed, 10 Feb 1999 07:40:40 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA11361; Wed, 10 Feb 1999 07:40:35 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA18594; Wed, 10 Feb 1999 07:40:37 -0800 (PST) Received: from quarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id KAA27238; Wed, 10 Feb 1999 10:40:35 -0500 (EST) Received: from wasted.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000024516; Wed, 10 Feb 1999 10:40:36 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id KAA0000005537; Wed, 10 Feb 1999 10:40:34 -0500 (EST) From: Jim Bound Message-Id: <199902101540.KAA0000005537@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: ipng@sunroof.eng.sun.com, ngtrans@sunroof.eng.sun.com, 6bone@isi.edu cc: bound@zk3.dec.com, deployment@ipv6.org Subject: (IPng 7168) V6 Deployment Work and Mail List Activity Date: Wed, 10 Feb 1999 10:40:34 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, At this time we cannot continue to bombard ipng, ngtrans, and 6bone with IPv6 deployment mail. There is a new IPv6 workers list set up that is a NON-IETF list. One cannot get on this list without being supported by an existing person on that list. We want to be able to speak freely and it is a workers list. For users and folks who need information on how to get Ipv6 deployed we have set up an IPv6 users list (see attached mail) which anyone can join. To request being on the IPv6 deployment workers list send mail to deployment@ipv6.org. Somone will respond to you. We will continue to send relevant information to the ipng, ngtrans, and 6bone list such as meeting minutes that are public and any technical work we want to share. But we need to chill as many of us are now getting 4 messages each time we talk about IPv6 deployment. We also will have other services like WEB Server, Deployment Scenarios, Marketing Presentations, Public Domain Code Pointers, Implementation Roll-Out Status, etc. We also will be setting up an IPv6 World Wide forum to promote and explain the deployment of IPv6, which is in process now. Our objective is to reach the CTO level of Fortune 500 Worldwide Companies in time to assist them to adopt and deploy IPv6. This work also does not replace the fine work being done on the IPv6 Implementors list which is also a NON-IETF list. p.s. Thank You Perry Metzger.................. Sincerely, /jim --------------------------------------- [Please forward this message to places that might be interested in it.] A mailing list has been established for early adopters of IPv6 who need help setting up their IPv6 based networks and network stacks, connecting to the 6bone, getting applications to work with IPv6 and similar problems. The mailing list, users@ipv6.org, may be subscribed to by sending mail to majordomo@ipv6.org with the words "subscribe users" in the body of the message. Note that although developers of IPv6 stacks are strongly encouraged to join the mailing list to help the early adopters, this list is not intended for discussions of IPv6 stack development issues -- it is there to help the users of the technology. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 10 13:38:10 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA24743 for ipng-dist; Wed, 10 Feb 1999 13:26:06 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA24735; Wed, 10 Feb 1999 13:25:55 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id NAA09778; Wed, 10 Feb 1999 13:25:54 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA22143; Wed, 10 Feb 1999 13:25:44 -0800 (PST) Received: from quarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id QAA13433; Wed, 10 Feb 1999 16:25:36 -0500 (EST) Received: from wasted.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id QAA0000016927; Wed, 10 Feb 1999 16:25:37 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id QAA0000002192; Wed, 10 Feb 1999 16:25:35 -0500 (EST) From: Jim Bound Message-Id: <199902102125.QAA0000002192@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, 6bone@isi.edu cc: deployment@ipv6.org Subject: (IPng 7170) V6 Deployment List is now an Open List Date: Wed, 10 Feb 1999 16:25:35 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, See attached. It is now an open list. /jim ------- Forwarded Message Return-Path: perry@piermont.com Received: from brbflume.zk3.dec.com by mailhub1.zk3.dec.com (5.65v4.0/1.1.10.5/24Sep96-0323PM) id AA24052; Wed, 10 Feb 1999 12:49:07 -0500 Received: from mail11.digital.com by flume.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id MAA0000007472; Wed, 10 Feb 1999 12:49:06 -0500 (EST) Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id MAA26185 for ; Wed, 10 Feb 1999 12:48:56 -0500 (EST) Received: by jekyll.piermont.com (Postfix, from userid 1000) id 3575D155; Wed, 10 Feb 1999 12:46:04 -0500 (EST) To: deployment@ipv6.org Cc: bound@zk3.dec.com Subject: list is now open Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 10 Feb 1999 12:46:03 -0500 Message-Id: <87soce884k.fsf@jekyll.piermont.com> Lines: 10 Based on the general sentiment expressed, the list is now open. Jim, if you could re-mail to the places you just sent mail about deployment to and tell them to subscribe using majordomo@ipv6.org instead of sending to the list (which ends up bouncing to me -- as an anti-spam feature only subscribed addresses can post), it would be appreciated. Perry ------- End of Forwarded 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 Thu Feb 11 06:34:11 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA25809 for ipng-dist; Thu, 11 Feb 1999 06:23:11 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA25802; Thu, 11 Feb 1999 06:23:02 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id GAA15558; Thu, 11 Feb 1999 06:22:59 -0800 Received: from om2.gto.net.om (om2.gto.net.om [206.49.101.40]) by earth.sun.com (8.9.1/8.9.1) with SMTP id GAA27208; Thu, 11 Feb 1999 06:22:59 -0800 (PST) Received: from default(as12-19.gto.net.om[212.72.7.146]) (1413 bytes) by om2.gto.net.om via sendmail with P:esmtp/R:inet_hosts/T:smtp (sender: ) id for ; Thu, 11 Feb 1999 18:16:54 +0400 (OMAN) (Smail-3.2.0.102 1998-Aug-2 #21 built 1998-Aug-20) Message-ID: <36C2E89F.B2BACD05@gto.net.om> Date: Thu, 11 Feb 1999 18:26:40 +0400 From: Peter Dawson X-Mailer: Mozilla 4.0 [en] (Win95; I) MIME-Version: 1.0 To: ngtrans@sunroof.eng.sun.com CC: ipng@sunroof.eng.sun.com, 6bone@isi.edu, bound@zk3.dec.com, deployment@ipv6.org, USER-IPV6 Subject: (IPng 7171) Re: (ngtrans) V6 Deployment Work and Mail List Activity X-Priority: 3 (Normal) References: <199902101540.KAA0000005537@wasted.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim , Perry I'm a little confused ....clarifications requested. Jim Bound wrote: > To request being on the IPv6 deployment workers list send mail > to > deployment@ipv6.org. Somone will respond to you. > Perry wrote : > The mailing list, users@ipv6.org, may be subscribed to by > sending mail > to majordomo@ipv6.org with the words "subscribe users" in the > body of > the message. > DO I read two seperate lists here : deployment@ipv6.org andusers@ipv6.org ?? are there two different lists here, if so whats the difference ?? /pete ps. I subscribed to users.. should I also subcribe to deployment ?? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 11 09:08:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA25990 for ipng-dist; Thu, 11 Feb 1999 09:01:04 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA25983; Thu, 11 Feb 1999 09:00:35 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA06782; Thu, 11 Feb 1999 09:00:32 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA10631; Thu, 11 Feb 1999 09:00:20 -0800 (PST) Received: by jekyll.piermont.com (Postfix, from userid 1000) id CB614167; Thu, 11 Feb 1999 12:00:07 -0500 (EST) To: Peter Dawson Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, 6bone@isi.edu, bound@zk3.dec.com, deployment@ipv6.org, USER-IPV6 Subject: (IPng 7172) Re: (ngtrans) V6 Deployment Work and Mail List Activity References: <199902101540.KAA0000005537@wasted.zk3.dec.com> <36C2E89F.B2BACD05@gto.net.om> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 11 Feb 1999 12:00:07 -0500 In-Reply-To: Peter Dawson's message of "Thu, 11 Feb 1999 18:26:40 +0400" Message-ID: <87aeyk510o.fsf@jekyll.piermont.com> Lines: 15 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Peter Dawson writes: > DO I read two seperate lists here : deployment@ipv6.org > andusers@ipv6.org ?? are there two different lists here, if so > whats the difference ?? "deployment" is for people discussing how to market v6, how to make it easier for people to use, how to get our web site snazzier, etc. It really isn't intended for the general public, although it is now open. "users" is for people who want to deploy v6 in their environments (even if that environment is just their home!) and need help doing so. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 11 09:22:12 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA26048 for ipng-dist; Thu, 11 Feb 1999 09:12:27 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA26037; Thu, 11 Feb 1999 09:11:58 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA03065; Thu, 11 Feb 1999 09:11:55 -0800 Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.58.53]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA18720; Thu, 11 Feb 1999 09:11:55 -0800 (PST) Received: from technocat (CHCGB103-01.splitrock.net [209.156.10.47]) by pimout1-int.prodigy.net (8.8.5/8.8.5) with SMTP id MAA65152; Thu, 11 Feb 1999 12:10:47 -0500 Message-ID: <015401be55e1$9106d820$2f0a9cd1@technocat> From: "Jim Fleming" To: , "Peter Dawson" Cc: , , <6bone@isi.edu>, , , "USER-IPV6" Subject: (IPng 7173) Re: (ngtrans) V6 Deployment Work and Mail List Activity Date: Thu, 11 Feb 1999 11:11:27 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk cool !!! -----Original Message----- From: Perry E. Metzger To: Peter Dawson Cc: ngtrans@sunroof.Eng.Sun.COM ; ipng@sunroof.Eng.Sun.COM ; 6bone@isi.edu <6bone@isi.edu>; bound@zk3.dec.com ; deployment@ipv6.org ; USER-IPV6 Date: Thursday, February 11, 1999 11:03 AM Subject: Re: (ngtrans) V6 Deployment Work and Mail List Activity > >Peter Dawson writes: >> DO I read two seperate lists here : deployment@ipv6.org >> andusers@ipv6.org ?? are there two different lists here, if so >> whats the difference ?? > >"deployment" is for people discussing how to market v6, how to make it >easier for people to use, how to get our web site snazzier, etc. It >really isn't intended for the general public, although it is now open. > >"users" is for people who want to deploy v6 in their environments >(even if that environment is just their home!) and need help doing >so. > >Perry > >--------------------------------------------------------------------- >The IPv6 Users Mailing List >Unsubscribe by sending "unsubscribe users" to majordomo@ipv6.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 Thu Feb 11 09:36:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA26163 for ipng-dist; Thu, 11 Feb 1999 09:27:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA26156; Thu, 11 Feb 1999 09:27:46 -0800 (PST) From: scot@speedlan.com Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA18340; Thu, 11 Feb 1999 09:27:29 -0800 Received: from speedcom22.gte.net ([209.241.32.32]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA28708; Thu, 11 Feb 1999 09:27:07 -0800 (PST) Received: from scott - 209.241.32.32 by speedcom22.gte.net with Microsoft SMTPSVC(5.5.1774.114.11); Thu, 11 Feb 1999 12:25:56 -0500 Reply-To: To: , , <6bone@isi.edu>, , , "'USER-IPV6'" Subject: (IPng 7176) Using "Reply to All" within e-mail lists Date: Thu, 11 Feb 1999 12:19:13 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal Disposition-Notification-To: "Scot Mc Pherson" X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would please ask everyone who likes to use the "reply to all" button, to remove individuals' names from the to: and cc: field. When you are on a list, and you are addressed directly in the e-mail. You end up receiving every e-mail twice. I apologize to those who take offense to this. It is only a request to help alleviate traffic on the MTAs and also so that we all don't have to receive e-mail twice. This is kind of like "spam" in an oblique way, because some of us have to pay for the amount of information being transmitted to us, and we all don't have the money to pay for every message twice. Thank you for taking the time to read this. Scot Mc Pherson -----Original Message----- From: owner-deployment@ipv6.org [mailto:owner-deployment@ipv6.org]On Behalf Of Perry E. Metzger Sent: Thursday, February 11, 1999 12:00 PM To: Peter Dawson Cc: ngtrans@sunroof.Eng.Sun.COM; ipng@sunroof.Eng.Sun.COM; 6bone@isi.edu; bound@zk3.dec.com; deployment@ipv6.org; USER-IPV6 Subject: Re: (ngtrans) V6 Deployment Work and Mail List Activity Peter Dawson writes: > DO I read two seperate lists here : deployment@ipv6.org > andusers@ipv6.org ?? are there two different lists here, if so > whats the difference ?? "deployment" is for people discussing how to market v6, how to make it easier for people to use, how to get our web site snazzier, etc. It really isn't intended for the general public, although it is now open. "users" is for people who want to deploy v6 in their environments (even if that environment is just their home!) and need help doing so. Perry --------------------------------------------------------------------- The IPv6 Deployment Mailing List Unsubscribe by sending "unsubscribe deployment" to majordomo@ipv6.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 Fri Feb 12 14:30:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA27906 for ipng-dist; Fri, 12 Feb 1999 14:21:02 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA27899 for ; Fri, 12 Feb 1999 14:20:51 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA09316 for ; Fri, 12 Feb 1999 14:20:50 -0800 Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA25656 for ; Fri, 12 Feb 1999 14:20:49 -0800 (PST) Received: from spruce.iprg.nokia.com (spruce.iprg.nokia.com [205.226.1.63]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with SMTP id OAA29431 for ; Fri, 12 Feb 1999 14:20:40 -0800 (PST) Message-Id: <3.0.5.32.19990212141834.00838210@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 12 Feb 1999 14:18:34 -0800 To: ipng@sunroof.eng.sun.com From: The IESG (by way of Bob Hinden ) Subject: (IPng 7180) Last Call: Transmission of IPv6 Packets over Frame Relay Networks Specification to Proposed Standard Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the Internetworking Over NBMA Working Group to consider Transmission of IPv6 Packets over Frame Relay Networks Specification as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by February 26, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ion-ipv6-fr-02.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 12 15:25:15 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA28031 for ipng-dist; Fri, 12 Feb 1999 15:17:28 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA28024 for ; Fri, 12 Feb 1999 15:16:58 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA21561 for ; Fri, 12 Feb 1999 15:16:51 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA28561 for ; Fri, 12 Feb 1999 15:16:51 -0800 (PST) Received: by jekyll.piermont.com (Postfix, from userid 1000) id 70413167; Fri, 12 Feb 1999 18:16:43 -0500 (EST) To: ipng@sunroof.eng.sun.com Subject: (IPng 7181) www.ipv6.org updated Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 12 Feb 1999 18:16:43 -0500 Message-ID: <8790e3w6uc.fsf@jekyll.piermont.com> Lines: 7 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm slowly getting http://www.ipv6.org/ up to speed. I'd very much appreciate content submissions for the applications and "web sites that speak v6 natively" portions of the site, as well as any other content people might care to give me. Every bit helps. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 16 15:19:56 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA01026 for ipng-dist; Tue, 16 Feb 1999 15:04:50 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA01019 for ; Tue, 16 Feb 1999 15:04:37 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA10699 for ; Tue, 16 Feb 1999 12:27:03 -0800 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA16581 for ; Tue, 16 Feb 1999 12:26:59 -0800 (PST) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id UAA01365; Tue, 16 Feb 1999 20:07:34 GMT Message-Id: <199902162007.UAA01365@inner.net> To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: (IPng 7185) sockaddr_storage nit X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Tue, 16 Feb 1999 15:25:38 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The spec fails to name the first two fields: - It has the initial field(s) isomorphic to the fields of the "struct sockaddr" data structure on that implementation which can be used as a discriminants for deriving the protocol in use. These initial field(s) would on most implementations either be a single field of type "sa_family_t" (isomorphic to sa_family field, 16 bits) or two fields of type uint8_t and sa_family_t respectively, (isomorphic to sa_len and sa_family_t, 8 bits each). So there's no requirement that you even use the names given in the example, which is bad. I propose that this second paragraph be amended with: The family field is named "ss_family," and the length field, if present, is named "ss_len." Note that this is also a change from the example (and, I'm guessing, what people have implemented), which names them __ss_family and __ss_len. The entire point of having those fields in the structure is for the basic sockaddr preamble fields to be accessable without a cast. Therefore, they should not be "hidden." -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 17 07:47:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA01590 for ipng-dist; Wed, 17 Feb 1999 07:40:30 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA01583 for ; Wed, 17 Feb 1999 07:40:21 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id HAA09737 for ; Wed, 17 Feb 1999 07:40:19 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id HAA00643 for ; Wed, 17 Feb 1999 07:40:17 -0800 (PST) Received: from quarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id KAA25179; Wed, 17 Feb 1999 10:39:59 -0500 (EST) Received: from wasted.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id KAA0000032514; Wed, 17 Feb 1999 10:39:27 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id KAA0000012783; Wed, 17 Feb 1999 10:39:26 -0500 (EST) From: Jim Bound Message-Id: <199902171539.KAA0000012783@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Craig Metz cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: (IPng 7186) Re: sockaddr_storage nit In-reply-to: Your message of "Tue, 16 Feb 1999 15:25:38 EST." <199902162007.UAA01365@inner.net> Date: Wed, 17 Feb 1999 10:39:26 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, I have reviewed your request and feel the upcoming XNET IPv6 Base API doc can address it. Our Base API spec is frozen and will have a new RFC number anyday. The sockaddr_storage for most is informational only and folks can alter as they need. So unless we hear overwhelming statements from the WG implementors I do not think we need to make this change to the TBD RFC for this API. p.s. Chris Harding - Can this be addressed by XNET and can you connect with Craig offline? /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 Feb 17 08:18:04 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA01640 for ipng-dist; Wed, 17 Feb 1999 08:10:17 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA01633 for ; Wed, 17 Feb 1999 08:10:03 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA13464 for ; Wed, 17 Feb 1999 08:10:03 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA17615 for ; Wed, 17 Feb 1999 08:10:02 -0800 (PST) Received: by jekyll.piermont.com (Postfix, from userid 1000) id 1FC45171; Wed, 17 Feb 1999 11:09:48 -0500 (EST) To: ipng@sunroof.eng.sun.com Subject: (IPng 7187) request for up-to-date implementation information Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 17 Feb 1999 11:09:47 -0500 Message-ID: <87soc5m2pg.fsf@jekyll.piermont.com> Lines: 31 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For those that don't know, We are building a "user oriented" IPv6 web site on www.ipv6.org. As of last night, I have a REALLY skeletal implementations page, designed to let a user quickly navigate to implementations that will work on their system or to find information on the built in version in their system. I really need contributions for this page. The data on the playground web page for systems like Apple Macs, Solaris, etc., is all either really out of date or not very useful for someone who would like to "download and play". (For instance, on the Mac side, knowing that Mentat showed a v6 stack a few years ago doesn't help someone actually get a stack they might want to use *now*). If people could please send updates, either to me or to webmaster@ipv6.org, I'd appreciate it. I'll accept patches to existing web pages, new web pages to link in, etc. I'll also accept requests to mirror implementations and other information on our new anonymous ftp site, ftp.ipv6.org. I'd like the web page to be "one stop shopping" for users, if at all possible. If you have some time on your hands and can *really* help contribute to maintaining the site, I can make arrangements for you to help with that, too. Anyway, this is a bit of a "call for help". If there is anything you can do, please get in touch. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 17 14:18:17 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA01993 for ipng-dist; Wed, 17 Feb 1999 11:34:44 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA01986 for ; Wed, 17 Feb 1999 11:34:19 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id LAA15836 for ; Wed, 17 Feb 1999 11:34:17 -0800 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA14804 for ; Wed, 17 Feb 1999 11:34:16 -0800 (PST) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id TAA03487; Wed, 17 Feb 1999 19:05:09 GMT Message-Id: <199902171905.TAA03487@inner.net> To: Jim Bound cc: ipng@sunroof.eng.sun.com Subject: (IPng 7188) Re: sockaddr_storage nit In-reply-to: Your message of "Wed, 17 Feb 1999 10:39:26 EST." <199902171539.KAA0000012783@wasted.zk3.dec.com> X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Wed, 17 Feb 1999 14:23:46 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199902171539.KAA0000012783@wasted.zk3.dec.com>, you write: >I have reviewed your request and feel the upcoming XNET IPv6 Base API >doc can address it. Our Base API spec is frozen and will have a new RFC >number anyday. The sockaddr_storage for most is informational only and >folks can alter as they need. > >So unless we hear overwhelming statements from the WG implementors I do >not think we need to make this change to the TBD RFC for this API. > >p.s. Chris Harding - Can this be addressed by XNET and can you connect >with Craig offline? Speaking as a non-vendor implementor on a tight budget, POSIX and TOG specs are, as a whole, not accessable to me and therefore I don't write code from them. Especially when there is a freely available document that describes the same feature set. Having the freely available documentation of this API and the TOG version of this API out of sync seems to be a recipe for disaster. I understand the pressures not to change the spec at this point. I hate to see the spec change at this point. But this piece of the spec is broken, and it either gets fixed or we have an interoperability problem (which is what the spec is supposed to solve). If what you're saying is that interoperability is not important, then I can just do my thing without further concern as to whether code I add IPv6 support to will run on your implementation. The good news here is, as you have observed, that few people if anyone actually use sockaddr_storage, which means that it can probably be done without requiring a lot of work. Is there anyone out there for whom this change would affect more than removing two or four underscores from a header file? For those in that set, is there anything more than a quick Perl script needed to s//g some sources? -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 17 14:18:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA02129 for ipng-dist; Wed, 17 Feb 1999 12:29:21 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA02122 for ; Wed, 17 Feb 1999 12:28:31 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id MAA03440 for ; Wed, 17 Feb 1999 12:28:30 -0800 Received: from [208.196.3.178] (portal.kenan.com [208.196.3.178]) by earth.sun.com (8.9.1/8.9.1) with SMTP id MAA15791 for ; Wed, 17 Feb 1999 12:28:29 -0800 (PST) Received: from camb-mail.kenan.com by [208.196.3.178] via smtpd (for earth.Sun.COM [192.9.25.3]) with SMTP; 17 Feb 1999 20:28:29 UT Received: from kenan.com ([198.187.249.71]) by camb-mail.kenan.com (Netscape Messaging Server 3.6) with ESMTP id 629 for ; Wed, 17 Feb 1999 15:18:39 -0500 Message-ID: <36CB264D.7A67B0E0@kenan.com> Date: Wed, 17 Feb 1999 15:27:57 -0500 From: "Eben Scanlon" Organization: Kenan Systems Corp. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: (IPng 7189) IPv6 Packet Accounting Schemes Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I am on the ipng mailing list and I am also currently setting up a Linux box to connect to the 6Bone. So far, I have had no problems, and I have appreciated the wealth of information that is available on this topic. Lately, I have started to wonder what sort of packet accounting schemes are set up on the 6Bone. I know that IPv6 enables packet prioritization and QoS through the flow label in the packet header. However, it seems that no one has talked about the capabilities of routers to keep track of these packets and potentially apply some sort of mediation as the packets flow across heterogeneous networks. Are the IPv6 routers capable of keeping track of packets with different flow labels, and if so, what schemes are currently in place for this accounting mechanism? Thank you in advance for your replies. Sorry if this question is naive or silly. Cheers, Eben -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 17 16:30:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA02380 for ipng-dist; Wed, 17 Feb 1999 14:38:54 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA02371 for ; Wed, 17 Feb 1999 14:37:59 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id OAA21155 for ; Wed, 17 Feb 1999 14:37:57 -0800 Received: from jekyll.piermont.com (jekyll.piermont.com [206.1.51.15]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA29422 for ; Wed, 17 Feb 1999 14:37:49 -0800 (PST) Received: by jekyll.piermont.com (Postfix, from userid 1000) id E597A171; Wed, 17 Feb 1999 17:37:22 -0500 (EST) To: Craig Metz Cc: Jim Bound , ipng@sunroof.eng.sun.com Subject: (IPng 7190) Re: sockaddr_storage nit References: <199902171905.TAA03487@inner.net> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: "Perry E. Metzger" Date: 17 Feb 1999 17:37:22 -0500 In-Reply-To: Craig Metz's message of "Wed, 17 Feb 1999 14:23:46 -0500" Message-ID: <877ltgirml.fsf@jekyll.piermont.com> Lines: 19 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig Metz writes: > Speaking as a non-vendor implementor on a tight budget, POSIX and TOG specs > are, as a whole, not accessable to me Actually, that isn't true. If you register, you can see all of the Open Group's XPG documents on line off their web site. I do this all the time. On the other hand, I agree with you that having a set of accurate specs available officially for free would be a really big win, and... > Having the freely available documentation of this API and the > TOG version of this API out of sync seems to be a recipe for disaster. ...I also agree with this. We should have *consistent* docs, and having this nit fixed will also make for more interoperable apps. Perry -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 17 16:40:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA02431 for ipng-dist; Wed, 17 Feb 1999 15:01:55 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id PAA02424 for ; Wed, 17 Feb 1999 15:00:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id PAA07610; Wed, 17 Feb 1999 15:00:29 -0800 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by saturn.sun.com (8.9.1/8.9.1) with ESMTP id PAA22395; Wed, 17 Feb 1999 15:00:26 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id XAA28976; Wed, 17 Feb 1999 23:59:04 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id XAA03390; Wed, 17 Feb 1999 23:59:04 +0100 (MET) Message-Id: <199902172259.XAA03390@givry.inria.fr> From: Francis Dupont To: David Johnson , Charles Perkins Cc: Erik Nordmark , Jim Solomon , ipng@sunroof.eng.sun.com, mobile-ip@smallworks.com Subject: (IPng 7191) proxy neighbor advertisement for mobile IPv6 *node* Date: Wed, 17 Feb 1999 23:59:02 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There are three sections about proxy neighbor advertisement: - "9.5 Intercepting ..." (draft-ietf-mobileip-ipv6-07.txt) - 10.17 "Returning Home" (the same document) - "7.2.8 Proxy Neighbor Advertisements" (RFC 2461 "Neighbor Discovery") There are many details about the S (Solicited) flag and the O (Override) flag (which exists mainly for proxy/anycasts) but nothing about the value of the third R (Router) flag! I can see only three possibilities: - always put zero (0), why? - always put one (1), for instance because the sender of the packet is a router but the Router flag is relative to the target not to the source (sender is an ambiguous term but the processing of Neighbor Advertisement in "7.2.5 Receipt of Neighbor Advertisements" (RFC 2461) is accurate) - put one if and only if the target is a router. Obviously the third is the correct one but there is two cases where the target and the source are not the same: - anycast but nodes with anycast addresses MUST be routers then in this case the problem is solved (set the Router flag) - proxy, especially when the target is a mobile node which has moved off-link In the second case there is *no* way to know if the node is a host or a router. I can propose two solutions: - restrict mobile IPv6 to hosts, we don't really know how to manage mobile routers with IPv6 but I believe this is a bit drastic - add a new flag in home registration Regards Francis.Dupont@inria.fr PS: I am not on the mobile IP mailing list then this mail can be reject by anti-spam stuff and of course I'll get no answer to the list (I expect to find the discussion on ipngwg list). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 17 20:26:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA02628 for ipng-dist; Wed, 17 Feb 1999 20:19:00 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id UAA02621 for ; Wed, 17 Feb 1999 20:18:51 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id UAA21130 for ; Wed, 17 Feb 1999 20:18:51 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA04799 for ; Wed, 17 Feb 1999 20:18:52 -0800 (PST) Received: from flume.zk3.dec.com (brrflume.zk3.dec.com [16.141.56.6]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id XAA18812; Wed, 17 Feb 1999 23:18:36 -0500 (EST) Received: from wasted.zk3.dec.com by flume.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id XAA0000020827; Wed, 17 Feb 1999 23:18:35 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id XAA0000010223; Wed, 17 Feb 1999 23:18:35 -0500 (EST) From: Jim Bound Message-Id: <199902180418.XAA0000010223@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: perry@piermont.com cc: Craig Metz , Jim Bound , ipng@sunroof.eng.sun.com Subject: (IPng 7192) Re: sockaddr_storage nit In-reply-to: Your message of "17 Feb 1999 17:37:22 EST." <877ltgirml.fsf@jekyll.piermont.com> Date: Wed, 17 Feb 1999 23:18:34 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Folks, I am not changing the spec. It stands as is. I got to hear from a lot of folks to make this change. I do not feel it is an interoperability problem either. All the impelementors checked this out and it was quite a lengthy discussion to get where we are and there we defined reaons for __sslen, et al. If the chairs want to poke me on this that is fine. If this did need a change I would suggest we remove the entire 3.10 section from the Base API spec and if XNET wants it they can keep it. sorry, /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 Feb 17 21:36:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA02677 for ipng-dist; Wed, 17 Feb 1999 21:26:24 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA02670 for ; Wed, 17 Feb 1999 21:26:12 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id VAA03167 for ; Wed, 17 Feb 1999 21:26:07 -0800 Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA02920 for ; Wed, 17 Feb 1999 21:26:08 -0800 (PST) Received: by mail1.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Wed, 17 Feb 1999 21:26:07 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D30@RED-MSG-50> From: Richard Draves To: "'Mobile IP'" , "'IPng List'" , "'IPsec'" Subject: (IPng 7193) RE: Last Call: Mobility Support in IPv6 to Proposed Standard Date: Wed, 17 Feb 1999 21:26:03 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (Is the draft http://www.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-07.txt still under consideration by the IESG?) One of my concerns with the draft is that the interaction between mobility and IPsec is barely mentioned (one paragraph at the end of section 10.1) - not nearly enough is said to ensure interoperability, I think. And yet the spec requires the use of IPsec for mobility. At the interim WG meeting in Grenoble I got into a discussion with Brian Zill, Allison Mankin, Aaron Griggs, & others about the mobility/IPsec interaction. I think it's fairly complex. I'm hoping to start a discussion by looking at routing headers. I couldn't find anything in the IPsec architecture spec mentioning interactions with v6 routing headers or the source routing option in v4. Mobility uses routing headers. How should routing headers interact with IPsec? I believe that an IPsec-enabled node that is processing a routing header with non-zero Segments Left should do inbound IPsec processing (SPD lookup & policy verification) when it gets to the routing header and outbound IPsec processing before sending the updated packet. This should be just the same as a security gateway that is forwarding a packet. The routing header should not make it possible to bypass security policies. Carrying forward the analogy with security gateways, the IPsec processing associated with a routing header should only support tunnel-mode associations. Otherwise it makes life too difficult for the node processing the routing header, because it would have to be finding & removing & inserting headers in strange places. Security gateways must only support tunnel-mode associations. To make this concrete, suppose we have four nodes A, B, C, D. Node A sends a packet with a routing header through nodes B and C to node D. Node A can have tunnel and/or transport mode associations with node D, say for example transport-mode AH. Node A can only have a tunnel mode association with node B, say for example tunnel-mode ESP. The packets sent by node A will look like IPv6 hdr - dst B, src A ESP IPv6 hdr - dst B, src A Routing hdr, segments left = 2, addrs C, D AH Transport hdr There might be further tunnel-mode associations between nodes B & C, nodes C & D but node A won't know about that. Note that this means that outbound IPsec processing on node A has to happen *twice*, first for the final destination node D, and then again for the first intermediate destination node B. Does this sound reasonable? Applying this to the mobility case, there's only one intermediate destination address and the final destination and the intermediate destination address happen to both be assigned to the mobile node. Suppose the correspondent node has an active transport-mode AH association for a TCP connection with the mobile node. Then the mobile node wanders off and acquires a care-of address behind a security gateway. The correspondent node needs to use tunnel-mode ESP to the security gateway to reach the care-of address, and then transport-mode AH for the home address. This demonstrates the example above: when the correspondent node sends to the mobile node, it needs to do outbound IPsec processing twice, first for the home address, then for the care-of address. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 17 23:04:10 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA02749 for ipng-dist; Wed, 17 Feb 1999 22:55:37 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA02742 for ; Wed, 17 Feb 1999 22:55:27 -0800 (PST) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA28644; Wed, 17 Feb 1999 22:55:28 -0800 (PST) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1b+Sun/8.9.1) id WAA29260; Wed, 17 Feb 1999 22:52:24 -0800 (PST) Date: Wed, 17 Feb 1999 22:52:24 -0800 (PST) From: Mukesh Kacker Message-Id: <199902180652.WAA29260@lucknow.eng.sun.com> To: bound@wasted.zk3.dec.com, cmetz@inner.net Subject: (IPng 7194) Re: sockaddr_storage nit Cc: ipng@sunroof.eng.sun.com, mukesh@lucknow.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Subject: (IPng 7185) sockaddr_storage nit ..Not that thing again :-) Craig, you are right that when we discussed it on emails the field was called ss_family, I am not sure when it got the leading underscores. However, if now it is tough to change, there is another way to look at things. You wrote: > The entire > point of having those fields in the structure is for the basic sockaddr > preamble fields to be accessable without a cast. Therefore, they should not be > "hidden." > The point of having those fields was also to affect how in its implementation the alignment issues get handled. Note that the structure is to get large enough aligned storage for socket address data structures. We already have the old "struct sockaddr" which can be used to a access what you call the "preamble fields" This you can declare struct sockaddr_storage ss; struct sockaddr *sassp = (struct sockaddr *) &ss; Then you can access the preamble fields through sockaddr (e.g. above , sassp->sa_family) and have portable code. (And to correct the terms, there is no "interoperabilty" issue here... ...only a portability issue). I must admit I don't have strong feelings against using type casts in general. In Socket API you have to use them implicitly in parameters to functions in any case (i.e sockaddr * arguments are usually sockaddr_in or sockaddr_in6 etc). Another unexpected benefit might be that the we save the entire ss_ namespace for applications which in the usual Posix/TOG spec methodology is taken away from applications because it is a field name prefix and I hate that. :-) - Mukesh Kacker Internet Engineering Solaris Software Sun Microsystems Inc +1-650-786-5156 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 17 23:36:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id XAA02794 for ipng-dist; Wed, 17 Feb 1999 23:27:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA02787 for ; Wed, 17 Feb 1999 23:27:28 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id XAA19834; Wed, 17 Feb 1999 23:27:24 -0800 Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id XAA13156; Wed, 17 Feb 1999 23:27:18 -0800 (PST) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id HAA04176; Thu, 18 Feb 1999 07:07:04 GMT Message-Id: <199902180707.HAA04176@inner.net> To: Mukesh Kacker cc: ipng@sunroof.eng.sun.com Subject: (IPng 7195) Re: sockaddr_storage nit In-reply-to: Your message of "Wed, 17 Feb 1999 22:52:24 PST." <199902180652.WAA29260@lucknow.eng.sun.com> X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Thu, 18 Feb 1999 02:25:59 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <199902180652.WAA29260@lucknow.eng.sun.com>, you write: >Craig, you are right that when we discussed it on emails the field >was called ss_family, I am not sure when it got the leading underscores. Nor am I. A *lot* of proposals went back and forth in those discussions, and I suspect both of us were sick and tired of tweaking it... >However, if now it is tough to change, there is another way to look at things. Jim declared that he isn't changing the spec. >> The entire >> point of having those fields in the structure is for the basic sockaddr >> preamble fields to be accessable without a cast. Therefore, they should not >> "hidden." >The point of having those fields was also to affect how in its implementation >the alignment issues get handled. Note that the structure is to get >large enough aligned storage for socket address data structures. We already >have the old "struct sockaddr" which can be used to a access what >you call the "preamble fields" My original statement was correct as made. The entire point of having those fields -- which are there primarily because I kept pushing for them -- was to be able to access the sa_len and sa_family equivalents without the need for a cast, just like you can with any other struct sockaddr_foo. If there is no accessability for the preamble fields, then why do we have them at all (and the somewhat messy definition that results)? The fields should either be there as first-class members or not be there at all. The current spec puts them somewhere in between. >I must admit I don't have strong feelings against using type casts >in general. One of the original motivations behind the sockaddr_union was that lots of type casts (and, IMO worse, aliases of different types) create less readable code and more potential for programmer errors that the compiler frequently can't catch. >Another unexpected benefit might be that the we save the entire ss_ namespace >for applications which in the usual Posix/TOG spec methodology is taken >away from applications because it is a field name prefix and I hate that. :-) Would this really take away the global ss_ namespace? That's icky. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 18 02:32:23 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA02998 for ipng-dist; Thu, 18 Feb 1999 02:23:35 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA02991 for ; Thu, 18 Feb 1999 02:23:27 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id CAA00179 for ; Thu, 18 Feb 1999 02:23:27 -0800 Received: from mailgate.rdg.opengroup.org (mailgate.rdg.opengroup.org [192.153.166.4]) by earth.sun.com (8.9.1/8.9.1) with SMTP id CAA10164 for ; Thu, 18 Feb 1999 02:23:25 -0800 (PST) Received: by mailgate.rdg.opengroup.org; id AA06593; Thu, 18 Feb 1999 10:23:09 GMT Received: from cjh.rdg.opengroup.org [192.153.166.111] by mailgate.rdg.opengroup.org via smtpd V1.26 (98/11/23 13:59:56) for ; Thu Feb 18 10:23 GMT 1999 Message-Id: <3.0.3.32.19990218100101.00808d70@mailhome.rdg.opengroup.org> X-Sender: cjh@mailhome.rdg.opengroup.org X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32) Date: Thu, 18 Feb 1999 10:01:01 +0000 To: Craig Metz From: Chris Harding Subject: (IPng 7196) Re: (c.harding 25255) Access to Specs Cc: ipng@sunroof.eng.sun.com In-Reply-To: <877ltgirml.fsf@jekyll.piermont.com> References: <199902171905.TAA03487@inner.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 17:37 17/02/99 -0500, Perry E. Metzger wrote: > >Craig Metz writes: >> Speaking as a non-vendor implementor on a tight budget, POSIX and TOG specs >> are, as a whole, not accessable to me > >Actually, that isn't true. If you register, you can see all of the >Open Group's XPG documents on line off their web site. I do this all >the time. > You can register for and access the current published version of the networking services spec at http://www.opengroup.org/pubs/catalog/c523.htm (the IPv6 stuff isn't in this version, it will be in the next published version). >On the other hand, I agree with you that having a set of accurate >specs available officially for free would be a really big win, and... > >> Having the freely available documentation of this API and the >> TOG version of this API out of sync seems to be a recipe for disaster. > >...I also agree with this. We should have *consistent* docs, and >having this nit fixed will also make for more interoperable apps. > You can also get to the current draft of the spec. This is what we are currently working on. It will probably result in a new published version round about the end of this year. It contains the IPv6 material plus other changes that have been agreed. This draft plus the changes to it that are currently proposed are on the web at http://www.opengroup.org/orc/DOCS/XNS/ and they are FREELY AVAILABLE. Once the dust has settled on your sockaddr_storage proposal this will be posted as a proposed change. If you want to, you can post it yourself (I did think of asking you to do this but then thought I'd save you the trouble). XNET does NOT want to restrict access to its specs. On the contrary, it WANTS to encourage comments from ALL interested parties. Regards, Chris +++++ ------------------------------------------------------------------------- Chris Harding T H E Development Manager O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:c.harding@opengroup.org Ph: +44 118 950 8311 x2262 WWW: http://www.opengroup.org Fx: +44 118 950 0110 OSF/1, Motif, UNIX and the "X" device are registered trademarks in the US and other countries, and IT DialTone and The Open Group are trademarks of The Open Group. ------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 18 08:58:26 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA03470 for ipng-dist; Thu, 18 Feb 1999 08:55:07 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA03463 for ; Thu, 18 Feb 1999 08:54:58 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA25988; Thu, 18 Feb 1999 08:54:58 -0800 Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA02459; Thu, 18 Feb 1999 08:54:57 -0800 (PST) Received: from quarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by mail1.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id IAA30372; Thu, 18 Feb 1999 08:54:31 -0800 (PST) Received: from wasted.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000010168; Thu, 18 Feb 1999 11:54:29 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id LAA0000000007; Thu, 18 Feb 1999 11:54:29 -0500 (EST) From: Jim Bound Message-Id: <199902181654.LAA0000000007@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Craig Metz cc: Mukesh Kacker , ipng@sunroof.eng.sun.com Subject: (IPng 7197) Re: sockaddr_storage nit In-reply-to: Your message of "Thu, 18 Feb 1999 02:25:59 EST." <199902180707.HAA04176@inner.net> Date: Thu, 18 Feb 1999 11:54:29 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Craig, I did not declare I would not change the spec. I declared I would not change the spec without a lot of implementors telling me they can't live with this. As Mukesh pointed out it is a portability issue you raise and I just want to hear from all the implementors on this because the spec completed last call and is getting a new RFC at this time. So I would have to hear from Sun, Compaq (I will keep myself out of this and let my colleagues at Compaq respond), HP, IBM, Mentat, et al "implementors" and the other non-Vendor OS's implementors to change this spec and recall the IETF process updating the spec as we speak. Also you were part of the folks to help define 3.10 and I recorded that in tact. The __SS... were put into to avoid name space pollution for sockaddr_storage as I recall. I think that still stands. But there are work arounds for portability folks can do as Mukesh pointed out. If those will work I think that is better for IPv6 is if we leave the spec in tact for now. It has been worked on for so long we got to put it to bed. Also I believe XNET specs can update the spec and possibly generate later another Informational RFC called XNET Version of the API if it cannot be made publicly. To reiterate it is not that I will not change the spec it is I will not change the spec lightly. Also I want to add that many users of UNIX require the UNIX 95 and soon the UNIX 98 standards. If the public domain of UNIX does not support those they will not be used by those customers. But maybe that is OK. /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 Feb 18 09:02:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA03509 for ipng-dist; Thu, 18 Feb 1999 08:59:37 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA03502 for ; Thu, 18 Feb 1999 08:59:28 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id IAA26312 for ; Thu, 18 Feb 1999 08:59:26 -0800 Received: from mail11.digital.com (mail11.digital.com [192.208.46.10]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA05541 for ; Thu, 18 Feb 1999 08:59:27 -0800 (PST) Received: from quarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by mail11.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id LAA10195; Thu, 18 Feb 1999 11:59:41 -0500 (EST) Received: from wasted.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id LAA0000010843; Thu, 18 Feb 1999 11:59:07 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id LAA0000020247; Thu, 18 Feb 1999 11:59:07 -0500 (EST) From: Jim Bound Message-Id: <199902181659.LAA0000020247@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: Chris Harding cc: Craig Metz , ipng@sunroof.eng.sun.com Subject: (IPng 7198) Re: (c.harding 25255) Access to Specs In-reply-to: Your message of "Thu, 18 Feb 1999 10:01:01 GMT." <3.0.3.32.19990218100101.00808d70@mailhome.rdg.opengroup.org> Date: Thu, 18 Feb 1999 11:59:07 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Chris, This is great. Forget my idea about an updated info rfc in my mail to Craig. As long as all this is available as you stated that is not needed and only a duplication of work. 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 Thu Feb 18 09:19:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA03548 for ipng-dist; Thu, 18 Feb 1999 09:12:38 -0800 (PST) Received: from kebe.Eng.Sun.COM (kebe [129.146.86.51]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA03533 for ; Thu, 18 Feb 1999 09:12:26 -0800 (PST) Received: (from danmcd@localhost) by kebe.Eng.Sun.COM (8.9.2+Sun/8.9.1) id JAA16111; Thu, 18 Feb 1999 09:12:25 -0800 (PST) From: Dan McDonald Message-Id: <199902181712.JAA16111@kebe.Eng.Sun.COM> Subject: (IPng 7199) Re: Last Call: Mobility Support in IPv6 to Proposed Standard To: richdr@microsoft.com (Richard Draves) Date: Thu, 18 Feb 1999 09:12:25 -0800 (PST) Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D30@RED-MSG-50> from "Richard Draves" at Feb 17, 99 09:26:03 pm X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I'm hoping to start a discussion by looking at routing headers. I couldn't > find anything in the IPsec architecture spec mentioning interactions with v6 > routing headers or the source routing option in v4. Mobility uses routing > headers. How should routing headers interact with IPsec? See the AH spec. Unfortunately, the precise wording of the LSRR option for IPv4 exempts it from inclusion in AH's ICV, but the IPv6 routing header 0 is perfect for AH inclusion. > I believe that an IPsec-enabled node that is processing a routing header > with non-zero Segments Left should do inbound IPsec processing (SPD lookup & > policy verification) when it gets to the routing header and outbound IPsec > processing before sending the updated packet. This should be just the same > as a security gateway that is forwarding a packet. The routing header should > not make it possible to bypass security policies. Why? The proper use of AH allows authenticated source routes. This is why AH still exists, even after ESP had an ICV added to it. Also, how? Are you going to distribute keys along each hop? That's a lot of IKE negotiations. You can do end-to-end AH on a source routed packet in IPv6. It's why we still HAVE AH, y'know. > Carrying forward the analogy with security gateways, the IPsec processing > associated with a routing header should only support tunnel-mode > associations. Otherwise it makes life too difficult for the node processing > the routing header, because it would have to be finding & removing & > inserting headers in strange places. Security gateways must only support > tunnel-mode associations. If you wish to have every intermediate node process the packet, yes, you'll _probably_ need tunnel mode. > To make this concrete, suppose we have four nodes A, B, C, D. Node A sends a > packet with a routing header through nodes B and C to node D. Node A can > have tunnel and/or transport mode associations with node D, say for example > transport-mode AH. Great example! The packet would look like: IPv6 hdr dst B, src A Routing hdr, segments left = 2, addrs C, D AH (with SA residing on D) Transport hdr That's all you need to do! The source route in question can be authenticated using AH. > Does this sound reasonable? It sounds like you're adding levels of complexity where you don't need any. 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 Thu Feb 18 09:59:28 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA03795 for ipng-dist; Thu, 18 Feb 1999 09:49:20 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id JAA03788 for ; Thu, 18 Feb 1999 09:49:09 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id JAA04877 for ; Thu, 18 Feb 1999 09:49:06 -0800 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA11516 for ; Thu, 18 Feb 1999 09:49:07 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA03652; Thu, 18 Feb 1999 12:49:04 -0500 (EST) Message-Id: <199902181749.MAA03652@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;@ns.cnri.reston.va.us; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: (IPng 7200) I-D ACTION:draft-ietf-ipngwg-esd-analysis-04.txt Date: Thu, 18 Feb 1999 12:49:04 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 Author(s) : M. Crawford, A. Mankin, T. Narten, J. Stewart, L. Zhang Filename : draft-ietf-ipngwg-esd-analysis-04.txt Pages : 50 Date : 17-Feb-99 On February 27-28, 1997, the IPng Working Group held an interim meeting in Palo Alto, California to consider adopting Mike O'Dell's 'GSE - An Alternate Addressing Architecture for IPv6' proposal [GSE]. In GSE, 16-byte IPv6 addresses are split into distinct portions for global routing, local routing and end-point identification. GSE includes the feature of configuring a node internal to a site with only the local routing and end-point identification portions of the address, thus hiding the full address from the node. When such a node generates a packet, only the low-order bytes of the source address are specified; the high-order bytes of the address are filled in by a border router when the packet leaves the site. There is a long history of a vague assertion in certain circles that IPv4 'got it wrong' by treating its addresses simultaneously as locators and identifiers. Despite these claims, however, there was never a complete proposal for a scaleable network protocol which separated the functions. As a result, it wasn't possible to do a serious analysis comparing and contrasting a 'separated' architecture and an 'overloaded' architecture. The GSE proposal serves as a vehicle for just such an analysis, and that is the purpose of this paper. We conclude that an architecture that clearly separates locators and identifiers in addresses introduces new issues and problems that do not have an easy or clear solution. Indeed, the alleged disadvantages of overloading addresses turn out to provide some significant benefits over the non-overloaded approach. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-esd-analysis-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipngwg-esd-analysis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-esd-analysis-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990217093839.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-esd-analysis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-esd-analysis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990217093839.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 18 10:10:34 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id KAA03916 for ipng-dist; Thu, 18 Feb 1999 10:03:21 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id KAA03905; Thu, 18 Feb 1999 10:03:06 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (SMI-8.6/SMI-5.3) with SMTP id KAA08805; Thu, 18 Feb 1999 10:03:05 -0800 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id KAA21590; Thu, 18 Feb 1999 10:03:03 -0800 (PST) Received: from quarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id NAA04255; Thu, 18 Feb 1999 13:02:58 -0500 (EST) Received: from wasted.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id NAA0000026753; Thu, 18 Feb 1999 13:02:57 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id NAA0000005487; Thu, 18 Feb 1999 13:02:56 -0500 (EST) From: Jim Bound Message-Id: <199902181802.NAA0000005487@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: deployment@ipv6.org cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, 6bone@isi.edu Subject: (IPng 7201) IPv6 Deployment Meeting Grenoble Final Minutes Date: Thu, 18 Feb 1999 13:02:56 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk IPv6 Deployment meeting IMAG, Grenoble, France February 4, 1999 Integrated Notes as taken by Jack McCann, Tony Hain, and Yanick Pouffary. The chair of this meeting (Jim Bound) expresses extreme thanks to these folks for taking these minutes. For agenda items where we "Ran out of Time" below we can discuss on the IPv6 Deployment List as a set of additional "action items" from the meeting and if we meet at IETF 44 in Minneapolis. Other action items from the meeting are listed at the end of these minutes. - - Agenda review - -------------------------------------------------- The purpose of this day will be to review current deployment activities, potential additional efforts, and opportunities for educating and influencing developers, ISPs, network managers, and users. Dicussion Questions: Why would anyone run IPv6 Now? (see ipng/ngtrans minutes too) Why would anyone ever run IPv6? (see ipng/ngtrans minutes too) Applicable to both questions above: - Plug and Play - Deadline (similar to Y2K issue) the YV4 issue. No addresses left. - Application Reqs to have Global Addresses - Renumbering and multihoming site for robustness - Ease of management: Routing Efficiency, Lower cost of routing complexity, hidden cost of private addresses on the network and firewalls. - End to End IPsec out of the box. - Extensibility of the IPv6 Protocol via Extension Headers so the protocol can adapt and evolve for tomorrows business needs. - New applications which take advantage of flow-label and Mobile IPv6. - NAT is not a long term solution. - IPv4 addresses space is limited. - IPv6 is more scalable and could perform better - IPsec is mandatory and required for all Hosts. Who will deploy IPv6 first? - Research Community, Educational, and Commodity Markets which will drive ISPs. - New devices like IEEE Sensornet, NCs, Embedded Systems which converge and IPv4 addresses are old solution. - Large organizations with not enough IPv4 addresses who need end-to-end IPsec and Mobility. - Those who can benefit from IPv6 new features like VOIP, Mobile, Security, and Plug-and-Play. - Europe and Asia ISP/Telcos will deploy first, U.S. will lag. But this is not like OSI with completely different variants because these two markets never had enough IPv4 address to begin with. - 3rd world markets who are just starting Internet connectivity. - by geography or market sector? -> market sector - research community - good research projects - this is another reason why anyone would deploy now - manufacturers (e.g. auto), retail (every aisle is a subnet), banks - these sound like people with complete administrative control of environment - anyone thinking about deploying large numbers of devices in new efforts; don't have to interact with existing legacy applications because not general purpose computers - multicast IETF sessions over IPv6 (IETF people are early adopters) - need public domain code Will the Internet Lead Corporate Networks or follow as IPv6 is deployed? - Most input that corporate networks will lead in the U.S. and ISPs in most cases will follow. But in Europe, Asia, and elsewhere ISPs will lead and at least equal corporate deployment. How to get ISPs to deploy IPv6? - Most important vendors must ship IPv6 products. - Work like 6REN/Internet2/6TAP/WIDE Japan will cause ISPs to begin adoption. - Large corporate customers seeking IPv6 connectivity across the V4 Oceans. Even with Tunnels Native IPv6 is needed. - Network Management parts must be supported by IPv6. - Tools to tune the IPv6 Network will be needed. - IPv6 router renumbering and multihoming more solidified because as ISPs can use the plug and play to renumber subscribers with IPv6 will be a plus which cannot be done with IPv4. - It is cheaper to run IPv6 than IPv4. - New market segments can be attained by IPv6. - Competitive pressure from other ISPs taking subsribers especially in the U.S. as the ISPs feel pressure from Worldwide long haul ISP providers/carriers. - Supporting new technology markets that want IPv6 for the address space: Mobility, VOIP, Cell Phones, Network Appliances (the Internet Car, the Internet Refridgerator) - Cable companies support new IPv6 Multicast model. See discussion below for these and you can locate the presentations at: ftp://ftp.ipv6.org/pub/meetings/grenoble99/ - ---------------------------------------------------------- Bob Fink - 6REN and 6TAP Jim Bound - The Palo Alto Gateway and IPv6 and sub-TLA Request Strategy Marc Blanchet - IPv6 Deployment Issues Henk Steenman - Amsterdam Internet Exchange (AMS-IX) native IPv6 environment Jim Bound for Perry Metzger - Status of the V6 Deployment List Activities Jun Murai - IPv6 Deployment in Japan Jun-ichiro itojun Hagino - IPv6 verification technologies and open result by FREE see: http://www.tahi.org/ Latif LADID - Influencing IPv6 Developers and Promotion Kenji OTA - IETF Terminal Room Experiences with IPv6 Dale Finkelson - Internet2 and IPv6 Deployment Status of ipv6.org work Public Domain Code Discussion: (Ran out of Time) Appached Web Server Browser Client Sendmail BIND/DNS BSD Network Utilities Transition Mechanisms Review IPv6 Initial deployment implementation requirements (Ran out of Time). WINsock API consortia work on IPv6 status? QOS and Flowlabel Support for IPv6? (Ran out of Time) Mobile and IPv6 Deployement? (Ran out of Time) IP Future Conference for 1998. Why would CTO not want to deploy IPv6? (Ran out of Time) - --------------------------------------------- - - Presentation: Native IPv6 on AMS-IX (Henk Steenman) - participants: Surfnet, AT&T Netherlands, UUnet, Dutch research network - experiment was successful - recommendation for IPv6 deployment to AMS-IX - IX as address space provider requires change in business model With multiple ISP's in Amsterdam using tunnels to interconnect it made sense to think about how to do native interconnect Test environment was VLAN; routing protocol BGP4+ in full mesh Testing 2 addressing models; 6bone pTLA, & pNLA NLA announced to 6bone via UUnet & AT&T. Within the single vendor environment there were not any problems. The model of single NLA worked. Will propose to extend the native Ipv6 environment to pre-production Will coordinate with other exchanges - - Presentation: 6REN (Bob Fink) - RENs deploying native IPv6: - AARNET (Australia) - CERNET (China) - 1,075 universities; 36,000 high schools; 160,000 elementary schools Attempt to kick-start IPv6 production deployments October 98 initiated peering between research and education networks 6ren is a coordination effort, not a network. NANOG style QWEST will provide registry services ESnet will provide transit between production peering points and the 6bone if necessary Talks with content-level networks to develop plans for production IPv6 service Internet surveyors will change to use IPv6 as transport for collecting IPv4 data. Web site 6ren.net 6tap cross connect at StarTAP project of ESnet and Canarie goal is to provide a large scale interconnect registry & route server colocated with 6tap router at StarTAP early deployment provides opportunity to influence quality and service levels ESnet will provide operational monitoring Canarie will provide route server functions Provides single point of measurement to allow early analysis of usage Single-point-of-failure is minimal issue since the StarTAP is a single switch Plan to deploy production 'allocated' addresses. This does not effect 6bone Initial connection to StarTAP is ATM, but other locations may provide various technologies vBNS will also provide transit MCI is providing commercial services - - Presentation: 6TAP (Bob Fink) - StarTAP exchange in Chicago has ATM links to Europe and Asia - will colocate IPv6 router and server and provide native IPv6 over ATM PVCs starting in Spring 1999 (coinciding with availability of real IPv6 addresses) - www.6ren.net/6tap 6tap cross connect at StarTAP goal is to provide a large scale interconnect registry & route server colocated with 6tap router at StarTAP early deployment provides opportunity to influence quality and service levels ESnet will provide operational monitoring Provides single point of measurement to allow early analysis of usage Single-point-of-failure is minimal issue since the StarTAP is a single switch Plan to deploy production 'allocated' addresses. This does not effect 6bone Initial connection to StarTAP is ATM, but other locations may provide various technologies vBNS will also provide transit MCI is providing commercial services - - Presentation: Compaq IPv6 Analysis of sub-TLA request (Jim Bound) Slide with commercial IX's in US Inter-IX communication slide Compaq provides Palo Alto Internet Exchange which is separate from Palo Alto Gateway as native IPv6 exchange Showed 6bone Hub connect to Tunnels and non-Listed Native IPv6 connections. Considering a request for sub-TLA and peering with 6REN. - - Presentation: Tunnel server (Marc Blanchet) - another tunnel server - www.freenet6.net - points out scaling issue, how many tunnels per node? 64K? - needs https (secure http so user can authenticate server) - maybe merge with Alain Durand's tunnel broker effort Plug-n-play using IPv4 as link technology: freenet6.net as website with pointers to most implementations independent implementation like IMAG sign-up, tunnel server - - Presentation: Internet2 IPv6 Backbone issues (Dale Finkelson) - www.vbns.net/presentations/IPv6_plans - "Abilene" - can't run native IPv6 because net is all IP over PPP over SONET, links all connected to cisco 12000(?) routers, IPv6 stack not available for this equipment (at least not one Abilene feels it can trust) - you can buy native IPv6 connection to "NGS" network from MCI/Worldcom - make it simple for users to install and use - researchers want to take measurements, make tools available, make it easy to instrument Internet 2 Goals - deploying a testbed for researchers, and understanding the role of IPpv6. Native IPv6 on mesh of ATM pvc connected routers. Abilene Goals - IP over Sonet at OC3, 12, & 48 for University research Qwest provided pops to minimize local loop costs There may be fiber for additional private networks NGnet from MCI provides native commercial IPv6 Make it simple & instrument heavily. - - Presentation: IPv6: Unneeded, unwanted, unlikely (Jun Murai) - www.wide.ad.jp/10th - slides by Paul Francis (NTT) for WIDE 10th anniversary symposium - takes devil's advocate view - - Presentation: IPv6 Deployment in Asia/Japan (Jun Murai) - Panasonic developing IPv6 internet fax machine - 40,000,000 fax machines - "Internet car" - 1,000,000,000 cars by 2010 - "Internet refridgerator" - "C'est Bone" (IPv6 backbone) project - KAME has done mozilla6, sendmail6, ssh6, apache6 and submitted patches back to developers - Japanese government contributing $3 million to WIDE, $7-8 million to vendors for IPv6 development - Asian networks (APAN, APII, AII) encouraging IPv6 R&D activities WIDE working on R&D, and testbed Discussions with government Addressing need for IPv6 to children (non-technical arguments also carry with CEO's & Gov. Collecting various devs into KEIO funded by government to create kame Mobile IPv6 in a car with GPS as research project (expect all cars to eventually be on Internet) Need for 1Billion cars to have an address Internet refrigerator shown as example of potential devices TAHI project evaluating kame implementations Goal - reference implementation Available from ftp.kame.net 250 people in WIDE camp with laptops working 20hrs/day on a variety of areas APAN provides native IPv6 for Asian region - - Presentation: "6REN Bestseller: IPv6" (Latif Ladid) - banking sector may be first adopters of IPv6 due to mandated security; also government/military for classified data (again due to security) - need sense of urgency for IPv6 deployment - "nobody knows about IPv6" Marketing oriented discussions Nothing happens overnight Historical perspective, all new technologies take 20 years After 125 years telephone only reaches 12% of world population What is wrong with v6, it is not a US issue Its engineering driven rather than market driven Mindset is free, ATM forum is backed by money and that results in a driver CIDR & NAT killed the urgency No IPv6 specific applications No promotion money - creates the best kept secret in the world Success legacy Standard exists; may be overkilled; usual model is ship first and fix later Field trials show it works It is the Y2K problem for the Internet Provide the real thing, not CIDR + NAT Message to banking sector that security is mandated IPv4 Internet supports only non-classified data; basically advertising and non-value data Make the big bang happen The message has to be different - make it aggressive and set a hard limit Need compliance and certification Create a 'fellow program' samuri's of the new Internet; build a global team to evangelize Create a 'logo' program Conferences & Road Shows - - Presentation: TAHI Project - toward IPv6 verification technologies (Nobuo Okabe and Jun-ichiro Hagino) - www.tahi.org - one goal is set of publically available tests - - Presentation: IPv6 in IETF-43 terminal room (Kenji Ota) - tunnel to NTTv6net, NTT IPv6 test bed - - Presentation: Report on IP Future conference (Alain Durand) - 3 day conference in Paris in December 1998 - approximately 100 participants, audience from all over Europe - 2 days devoted to IPv6, 1 day to other topics - feeling is IPv6 may not start in U.S., U.S. has more addresses, IPv6 will start in Europe or Asia - planning another conference for December 1999 in Paris - - Other Discussions - will IPv6 be first in corporate networks or in Internet backbone? - Jim Bound: may depend on where you are - Bob Hinden: U.S. ISPs are under profit pressure, can't take longer term view; ISPs elsewhere might have different business model (e.g. government funded) that allows longer term view - Jim Bound read list of items handed in by attendees (Jim has list) - Jim Bound: again points out that mandatory security is wanted by some customers - Steve Deering: will corporations open firewalls to IPsec? - Erik Nordmark: some sites may want central control of security policy - Jim Bound: met with U.S. ISPs in October 1996 to discuss what was their concern with IPv6? They said "you need to ship it". - someone: how to get HDTV to deploy with IPv6? - Jim Bound: step toward this by having "IPv6 readiness" in IETF specs - Jim Bound: look at HDTV as potential target market; have them deploy with IPv6 - Yanick Pouffary: don't miss HDTV deployment the way we missed mobile phone deployment - Deployment work issues - status of ipv6.org, mailing lists, web server - Perry Metzger has web site, mail list set up - should it be an open mailing list? - Jim thinks yes, but Marc Blanchet points out Perry questioned request to join list from one of Marc's colleagues - should have two lists, help list open to public, closed (or less open) list for workers - Alain Durand: will ipv6.org have IPv6 stack? -> yes - Alain Durand: should also have IPv6 for other IPv6 related web sites (e.g. sunroof.eng.sun.com) - Public domain code discussion - KAME/INRIA/NRL merge status? they are reviewing each others code - Jim Bound: must be careful about what we call "public domain" code; make sure it really is free to use/redistribute - Francis Dupont: INRIA code has BSD license, KAME is the same, this should be good enough - Peter Curran: need binary distribution, not source; make it easier for someone to install - someone: there will be a new version of merged KAME/INRIA/NRL code this summer with IPv6 and IPsec for FreeBSD - Alain Durand: INRIA license is in separate file so you don't have to look at code to read license - Alain Durand: goal is to have KAME/INRIA/NRL merge go into main FreeBSD release - Marc Blanchet: has script for automatic install of FreeBSD - Jun Murai: World Trade Organization defining import/export process for software, maybe we should tell them what we want to do with IPv6 to influence them - Itohjun: can do IPv4 <-> IPv6 web proxy with Apache; squid not available for IPv6, hard port, using 'int' to hold IP address; - someone: someone has agreed to port squid - What transition mechanisms should we implement first? - Jim Bound: 6over4, AIIH; not SIIT or NAT-PT or SOCKS initially like the first year, then we will need the rest . - Itohjun: would prefer to avoid tunnels (automatic) including 6over4 due to difficulty diagnosing problems - Erik Nordmark: maybe need ability to remotely invoke traceroute on a tunnel? - Jim Bound: need to quickly define set of transition mechanisms needed later this year for deployment - Winsock consortium - Jim Bound: windows is important, what is this issue? - Rich Draves: some winsock header files have bogus IPv6 definitions - Rich took action to look into this - Should we meet at IETF 44? -> yes - meeting adjourned Action Items: - Develop two papers: What the Internet will be without IPv6. Why someone should deploy IPv6. - Get IETF to use IPv6 Multicast as feed. - Look for emerging HDTV and Cable businesses to look at IPv6. - Get all IPv6 related Web Sites to use IPv6. - Contact World Trade Organization and get them to adopt IPv6. - Complete discussion items we ran out of time one. - Followup on WINSOCK API efforts needed. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 18 14:10:06 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA04403 for ipng-dist; Thu, 18 Feb 1999 14:06:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04396 for ; Thu, 18 Feb 1999 14:05:51 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id OAA25400 for ; Thu, 18 Feb 1999 14:05:50 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id OAA16676 for ; Thu, 18 Feb 1999 14:05:50 -0800 (PST) Received: by mail4.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Thu, 18 Feb 1999 14:05:50 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D3E@RED-MSG-50> From: Richard Draves To: "'Dan McDonald'" Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Subject: (IPng 7202) RE: Last Call: Mobility Support in IPv6 to Proposed Standard Date: Thu, 18 Feb 1999 14:05:40 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I'm hoping to start a discussion by looking at routing > headers. I couldn't > > find anything in the IPsec architecture spec mentioning > interactions with v6 > > routing headers or the source routing option in v4. > Mobility uses routing > > headers. How should routing headers interact with IPsec? > > See the AH spec. Unfortunately, the precise wording of the > LSRR option for > IPv4 exempts it from inclusion in AH's ICV, but the IPv6 > routing header 0 is > perfect for AH inclusion. I'm sorry, I wasn't clear. I understand that the AH header's ICV calculation includes the routing header, so it provides end-to-end authentication of the routing header contents. The interaction between routing headers & IPsec & mobility that I'm concerned with is: - what kind of IPsec processing should a node processing a router header do? I think the answer is, it should be analogous to the processing done by a security gateway that is forwarding a packet. - what kind of IPsec processing should a node sending a packet with a routing header do? I think the answer is there should be an outbound SPD lookup based on the final destination address, and the appropriate SAs should be applied to the packet, then there should be another outbound SPD lookup based on the first intermediate destination address, and this could result in additional tunnel-mode SAs that should be applied to the packet. > > To make this concrete, suppose we have four nodes A, B, C, > D. Node A sends a > > packet with a routing header through nodes B and C to node > D. Node A can > > have tunnel and/or transport mode associations with node D, > say for example > > transport-mode AH. > > Great example! The packet would look like: > > IPv6 hdr dst B, src A > Routing hdr, segments left = 2, addrs C, D > AH (with SA residing on D) > Transport hdr > > That's all you need to do! The source route in question can > be authenticated > using AH. But suppose the outbound SPD in node A says that when A sends a packet to B, it should be sent via tunnel-mode ESP to a security gateway SG. Then the packet sent by A will look like: IPv6 hdr dst SG, src A ESP (SA between A and SG) IPv6 hdr dst B, src A AH (SA between A and D) Transport hdr The point being that node A will need to do two separate lookups in its outbound SPD when it sends a packet with a routing header. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Feb 18 14:33:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA04465 for ipng-dist; Thu, 18 Feb 1999 14:29:18 -0800 (PST) Received: from kebe.Eng.Sun.COM (kebe [129.146.86.51]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04450 for ; Thu, 18 Feb 1999 14:29:06 -0800 (PST) Received: (from danmcd@localhost) by kebe.Eng.Sun.COM (8.9.2+Sun/8.9.1) id OAA17257; Thu, 18 Feb 1999 14:29:05 -0800 (PST) From: Dan McDonald Message-Id: <199902182229.OAA17257@kebe.Eng.Sun.COM> Subject: (IPng 7203) Re: Last Call: Mobility Support in IPv6 to Proposed Standard To: richdr@microsoft.com (Richard Draves) Date: Thu, 18 Feb 1999 14:29:05 -0800 (PST) Cc: danmcd@Eng, mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D3E@RED-MSG-50> from "Richard Draves" at Feb 18, 99 02:05:40 pm X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. 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 Sorry for my misunderstanding the question, Richard. > The interaction between routing headers & IPsec & mobility that I'm > concerned with is: > - what kind of IPsec processing should a node processing a router header do? > > I think the answer is, it should be analogous to the processing done by a > security gateway that is forwarding a packet. I can understand sometimes wanting to do this. But do you want this to happen all of the time? > - what kind of IPsec processing should a node sending a packet with a > routing header do? > > I think the answer is there should be an outbound SPD lookup based on the > final destination address, and the appropriate SAs should be applied to the > packet, then there should be another outbound SPD lookup based on the first > intermediate destination address, and this could result in additional > tunnel-mode SAs that should be applied to the packet. Are you sure you want to do this? What problem does protecting the packet a second time solve? If you have IPsec end-to-end, it is supposed to protect you against bad guys along your path, even if the bad guys are explicitly stated in a routing header (or are between your paths in an explicitly stated routing header). > But suppose the outbound SPD in node A says that when A sends a packet to B, > it should be sent via tunnel-mode ESP to a security gateway SG. Then the > packet sent by A will look like: > > IPv6 hdr dst SG, src A > ESP (SA between A and SG) > IPv6 hdr dst B, src A > AH (SA between A and D) > Transport hdr > > The point being that node A will need to do two separate lookups in its > outbound SPD when it sends a packet with a routing header. I understand why you'd want to default to a self-encapsulation if you need to doubly-protect the packet. One _could_, however, do something like: IPv6 hdr dst B, src A ESP (SA dst B) Routing Hdr (B, C, D) AH (SA dst D) Transport but that would get really confusing in an implementation. I may have policy that says protect traffix between A and B with transport ESP (or none-specified, which could default to transport). Let's hear more on this one, folks. Thanks to Richard for bringing it up! 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 Thu Feb 18 15:07:05 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA04597 for ipng-dist; Thu, 18 Feb 1999 15:03:36 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04590 for ; Thu, 18 Feb 1999 15:03:28 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id PAA29261 for ; Thu, 18 Feb 1999 15:03:27 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id PAA29302 for ; Thu, 18 Feb 1999 15:03:26 -0800 (PST) Received: by mail4.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Thu, 18 Feb 1999 15:03:26 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D44@RED-MSG-50> From: Richard Draves To: "'Dan McDonald'" Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Subject: (IPng 7204) RE: Last Call: Mobility Support in IPv6 to Proposed Standard Date: Thu, 18 Feb 1999 15:03:21 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The interaction between routing headers & IPsec & mobility that I'm > > concerned with is: > > - what kind of IPsec processing should a node processing a > router header do? > > > > I think the answer is, it should be analogous to the > processing done by a > > security gateway that is forwarding a packet. > > I can understand sometimes wanting to do this. But do you > want this to > happen all of the time? Yes I think an IPsec-enabled node should do inbound & outbound IPsec processing when it hits a routing header. Otherwise the routing header will be a mechanism for bypassing the security policies on the node. For example if the node is a security gateway connecting an internal net and an external net, and the security gateway receives a packet with a routing header that directs the packet from the external net to the internal net, then security processing should happen! Just the same as security processing when forwarding packets. > > - what kind of IPsec processing should a node sending a > packet with a > > routing header do? > > > > I think the answer is there should be an outbound SPD > lookup based on the > > final destination address, and the appropriate SAs should > be applied to the > > packet, then there should be another outbound SPD lookup > based on the first > > intermediate destination address, and this could result in > additional > > tunnel-mode SAs that should be applied to the packet. > > Are you sure you want to do this? What problem does > protecting the packet a > second time solve? If you have IPsec end-to-end, it is > supposed to protect > you against bad guys along your path, even if the bad guys > are explicitly > stated in a routing header (or are between your paths in an > explicitly stated > routing header). Yes I'm sure :-) Go back to the mobility example: I (node A) have a security association with a mobile node using its home address HA. My SPD tells me to use transport-mode AH when talking to HA. I have a TCP connection in progress to the mobile node, protected by transport-mode AH. Now the mobile node moves. It goes behind a security gateway SG. It has a care-of address CA. My SPD tells me to use tunnel-mode ESP via SG when talking to address CA. When I send a packet to the mobile node, it needs to look like IPv6 hdr, dst SG, src A ESP (SA with SG) IPv6 hdr, dst CA, src A routing hdr, segments left = 1, addr HA AH (SA with HA) TCP hdr Otherwise the scenario will break. Now how do I generate this packet? The only thing that makes sense to me is to do the outbound IPsec processing twice, first with destination address HA and then with destination address CA. > I understand why you'd want to default to a > self-encapsulation if you need to > doubly-protect the packet. One _could_, however, do something like: > > IPv6 hdr dst B, src A > ESP (SA dst B) > Routing Hdr (B, C, D) > AH (SA dst D) > Transport > > but that would get really confusing in an implementation. Yes, this would be awful to implement. It would be like having a transport-mode SA with a security gateway, which is a painful for a security gateway to support and hence the IPsec arch spec disallows it. I think for the same reason, only tunnel-mode SAs with the intermediate destination should be supported. Note also that this arrangement of headers runs counter to the preferred ordering in the IPv6 arch spec. 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 Feb 18 15:43:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id PAA04733 for ipng-dist; Thu, 18 Feb 1999 15:38:53 -0800 (PST) Received: from kebe.Eng.Sun.COM (kebe [129.146.86.51]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04726 for ; Thu, 18 Feb 1999 15:38:44 -0800 (PST) Received: (from danmcd@localhost) by kebe.Eng.Sun.COM (8.9.2+Sun/8.9.1) id PAA17712; Thu, 18 Feb 1999 15:38:34 -0800 (PST) From: Dan McDonald Message-Id: <199902182338.PAA17712@kebe.Eng.Sun.COM> Subject: (IPng 7205) Re: Last Call: Mobility Support in IPv6 to Proposed Standard To: richdr@microsoft.com (Richard Draves) Date: Thu, 18 Feb 1999 15:38:32 -0800 (PST) Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D44@RED-MSG-50> from "Richard Draves" at Feb 18, 99 03:03:21 pm X-Legal-Disclaimer: Please note that the information being provided does not constitute a warranty or a modification of any agreement you may have with Sun Microsystems, Inc., its subsidiaries or its customers. 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 > Yes I think an IPsec-enabled node should do inbound & outbound IPsec > processing when it hits a routing header. Otherwise the routing header will > be a mechanism for bypassing the security policies on the node. Okay, you got me there... > Yes I'm sure :-) > > Go back to the mobility example: I (node A) have a security association with > a mobile node using its home address HA. My SPD tells me to use > transport-mode AH when talking to HA. I have a TCP connection in progress to > the mobile node, protected by transport-mode AH. > > Now the mobile node moves. It goes behind a security gateway SG. It has a > care-of address CA. My SPD tells me to use tunnel-mode ESP via SG when > talking to address CA. Okay. Your example below... > When I send a packet to the mobile node, it needs to look like > IPv6 hdr, dst SG, src A > ESP (SA with SG) > IPv6 hdr, dst CA, src A > routing hdr, segments left = 1, addr HA > AH (SA with HA) > TCP hdr Was different from your previous example where the inner and outer IPv6 headers had the same destination. I was assuming you were focussing on that case. When you have to transit via a security gateway, you have no choice but to tunnel. > Otherwise the scenario will break. Now how do I generate this packet? The > only thing that makes sense to me is to do the outbound IPsec processing > twice, first with destination address HA and then with destination address > CA. > Yes, this would be awful to implement. It would be like having a > transport-mode SA with a security gateway, which is a painful for a > security gateway to support and hence the IPsec arch spec disallows it. For dst SG != dst CA, you're right, and even dst SG == dst CA, it works. > I think for the same reason, only tunnel-mode SAs with the intermediate > destination should be supported. Note also that this arrangement of headers > runs counter to the preferred ordering in the IPv6 arch spec. I know it runs counter to the IPv6 arch spec, but that spec says that the order is a suggested one, not a mandatory one. 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 Thu Feb 18 22:48:13 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id WAA05353 for ipng-dist; Thu, 18 Feb 1999 22:44:37 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.82.166] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA05346 for ; Thu, 18 Feb 1999 22:44:28 -0800 (PST) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA18633; Thu, 18 Feb 1999 22:44:29 -0800 (PST) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1b+Sun/8.9.1) id WAA00031; Thu, 18 Feb 1999 22:41:25 -0800 (PST) Date: Thu, 18 Feb 1999 22:41:25 -0800 (PST) From: Mukesh Kacker Message-Id: <199902190641.WAA00031@lucknow.eng.sun.com> To: Mukesh.Kacker@Eng, cmetz@inner.net Subject: (IPng 7206) Re: sockaddr_storage nit Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > My original statement was correct as made. The entire point of having those > fields -- which are there primarily because I kept pushing for them -- was to > be able to access the sa_len and sa_family equivalents without the need for > a cast, just like you can with any other struct sockaddr_foo. > That might have been your motivation for proposing sockaddr_union. But when you combine various sockaddr_foo, you bring together the issues of extensibility, binary compatibility, alignment, and maximal size and sockaddr_storage tries to solve all that avoiding some of the potential pitfalls of unions. I don't have any problem with having ss_family (and ss_len where applicable) though. If not, that was a workaround to the situation. It is not unheard of to have nits and bugs in specs....and I am not sure what the process is to fix such things in IETF in such an advanced stage. > > Would this really take away the global ss_ namespace? That's icky. > Yes, that is my understanding. Perhaps I don't understand/remember all the reasons there but I do feel it is overkill. One of the the reasons there are that people use field names in #defines to abbreviate when there are strucutures within structures or for other reasons (e.g. the s6_addr define in the draft). I would rather reserve it in those exceptional cases and limit the prefix reservation to within that structure. But there may be more to it. If not, it is an optimzation for far out scenarios while burdening the common case. With this current practice, formal standards make it extremely hard to write any code that strictly follows all the rules of the formal standards :-) - Mukesh Kacker Internet Engineering Solaris Software Sun Microsystems Inc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 19 00:58:36 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id AAA05452 for ipng-dist; Fri, 19 Feb 1999 00:50:00 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05445 for ; Fri, 19 Feb 1999 00:49:45 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id AAA10092 for ; Fri, 19 Feb 1999 00:49:39 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id AAA24464 for ; Fri, 19 Feb 1999 00:49:40 -0800 (PST) Received: from kiwi.itojun.org (itojun@localhost.itojun.org [127.0.0.1]) by coconut.itojun.org (8.9.3+3.1W/3.7W) with ESMTP id RAA07553; Fri, 19 Feb 1999 17:49:36 +0900 (JST) To: Richard Draves cc: ipng@sunroof.eng.sun.com In-reply-to: richdr's message of Tue, 09 Feb 1999 08:59:12 PST. <4D0A23B3F74DD111ACCD00805F31D8100AF81C3C@RED-MSG-50> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: (IPng 7208) Re: neighbor discovery spec hole (link-layer addr) From: Jun-ichiro itojun Hagino Date: Fri, 19 Feb 1999 17:49:36 +0900 Message-ID: <7549.919414176@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry for my delayed reply, I was on vacation... >You describe a situation where the implementation would like to create a >Neighbor Cache Entry (NCE) for a neighbor, to record some state (IsRouter >bit) and perhaps so other data structures (eg Default Router List) and point >to the NCE. However the implementation does not have a link-layer address >with which to initialize the NCE. And the interface is on a link that uses >link-layer addresses. (snip) >Now the question is whether this needs to be specified. It's not clear to me >that it must be specified. For example an alternative implementation might >not create an NCE in this situation. The spec needs to be clear about an >implementation's observable behavior, or explicitly allow different >observable behaviors. It's desirable that it also be a good guide to >implementators but it can and should leave some room for creativity in that >department. RFC2461 describes the neighbor discovery by taking neighbor cache entry with 5 states, and IsRouter bit in it, as example. I believe RFC2461 itself must present complete working example. Most of implementers will start designing their NDP code by using the example. If the example is incomplete, they will get very confused. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 19 12:23:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA06251 for ipng-dist; Fri, 19 Feb 1999 12:13:36 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06244 for ; Fri, 19 Feb 1999 12:13:23 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id MAA26334; Fri, 19 Feb 1999 12:13:19 -0800 (PST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA27499; Fri, 19 Feb 1999 12:13:20 -0800 (PST) Received: from [128.33.238.58] (TC074.BBN.COM [128.33.238.74]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id PAA24071; Fri, 19 Feb 1999 15:13:14 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D3E@RED-MSG-50> Date: Fri, 19 Feb 1999 10:13:50 -0500 To: Richard Draves From: Stephen Kent Subject: (IPng 7209) RE: Last Call: Mobility Support in IPv6 to Proposed Standard Cc: "'Dan McDonald'" , mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, The IPsec architecture does not envision processing by intermediate nodes in the fashion you allude to. Only end systems and security gateways perform IPsec processing, and they are arranged in pairs to bracket SAs. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 19 13:30:20 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA06311 for ipng-dist; Fri, 19 Feb 1999 13:15:37 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06304 for ; Fri, 19 Feb 1999 13:14:55 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id NAA18934; Fri, 19 Feb 1999 13:14:51 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA05861; Fri, 19 Feb 1999 13:14:50 -0800 (PST) Received: from quarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id QAA29161; Fri, 19 Feb 1999 16:14:24 -0500 (EST) Received: from wasted.zk3.dec.com by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id QAA0000010904; Fri, 19 Feb 1999 16:14:23 -0500 (EST) Received: from localhost by wasted.zk3.dec.com (8.8.8/1.1.22.2/08Sep98-0251PM) id QAA0000016326; Fri, 19 Feb 1999 16:14:18 -0500 (EST) From: Jim Bound Message-Id: <199902192114.QAA0000016326@wasted.zk3.dec.com> X-Authentication-Warning: wasted.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: droms@bucknell.edu cc: Charles.Perkins@Eng, narten@raleigh.ibm.com, burgan@home.net, bound@zk3.dec.com, dhcp-v6@bucknell.edu, ipng@sunroof.eng.sun.com Subject: (IPng 7210) DHCPv6 Update and Agenda at the IETF Date: Fri, 19 Feb 1999 16:14:18 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ralph, Charile and I will have an updated draft for DHCPv6 and the Extensions for DHCPv6 Documents submitted before the IETF Deadline of Feb 26th. This week we have completed our update of the draft and are working as co-authors to update the src of the specs. If all goes well we will have new drafts out by Feb 21st, but worst case by the IETF deadline. The change revision of both appendices will reflect the changes we made as a result of WG Last call. We will post these changes and what we did not change when the spec is released to the working group. At the IETF Minneapolis meeting we would like to request a full 2 hour slot for DHCPv6 with the following agenda: 1. Review the Last Call input received in bulletd form. 2. Review/Discuss the changes we made to the specs from that last call input. 3. Review/Discuss the changes we did not make and why. 4. Review/Discuss with the WG any other items needed to be addressed before IETF Last call of both specifications. We are hoping for attendance of IPv6 WG persons and review of the specs too. But because the DHCPv6 mailing list is set up so that only members can send to that mailing list, we will encourage them to send any mail to Charlie, yourself, and I; and we will have to forward their input to the DHCPv6 WG and cc them. We may not be able to get folks to get on the list right away who just want to be on for this review period. We also need to add how to join the dhcp-v6 mail list at http://www.ietf.org/html.charters/dhc-charter.html. For folks who want to join the dhcp-v6 mailing list: send mail to listserv@bucknell.edu in the body of your message subscribe dhcp-v6 your-email-address-goes-here 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 Fri Feb 19 13:34:32 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id NAA06320 for ipng-dist; Fri, 19 Feb 1999 13:24:26 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA06313 for ; Fri, 19 Feb 1999 13:23:31 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id NAA07496 for ; Fri, 19 Feb 1999 13:23:29 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id NAA11622 for ; Fri, 19 Feb 1999 13:23:30 -0800 (PST) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Fri, 19 Feb 1999 13:23:28 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D55@RED-MSG-50> From: Richard Draves To: "'Stephen Kent'" Cc: "'Dan McDonald'" , mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Subject: (IPng 7211) RE: Last Call: Mobility Support in IPv6 to Proposed Standard Date: Fri, 19 Feb 1999 13:23:26 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The IPsec architecture does not envision processing by > intermediate nodes > in the fashion you allude to. Only end systems and security gateways > perform IPsec processing, and they are arranged in pairs to > bracket SAs. I'm not suggesting anything that would change the pairwise nature of security associations. I'm suggesting that intermediate destination node that is processing a routing header be treated as a security gateway, so the sending node can have tunnel-mode security associations with the intermediate node and the sending node can have security associations with the final destination node. What alternative are you suggesting? Are you saying that an IPsec-enabled node should drop any packet with a routing header? Or are you saying that an IPsec-enabled node should process the routing header & forward the packet and bypass all IPsec processing? Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 19 17:33:52 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id RAA06558 for ipng-dist; Fri, 19 Feb 1999 17:30:01 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06551 for ; Fri, 19 Feb 1999 17:29:07 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id RAA01071 for ; Fri, 19 Feb 1999 17:29:03 -0800 (PST) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id RAA10725 for ; Fri, 19 Feb 1999 17:29:05 -0800 (PST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id RAA12908; Fri, 19 Feb 1999 17:29:04 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id RAA21982; Fri, 19 Feb 1999 17:29:04 -0800 (PST) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id RAA20799; Fri, 19 Feb 1999 17:29:03 -0800 (PST) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id RAA11332; Fri, 19 Feb 1999 17:29:09 -0800 (PST) Date: Fri, 19 Feb 1999 17:29:09 -0800 (PST) Message-Id: <199902200129.RAA11332@lookout.nsd.3com.com> To: Richard Draves Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Subject: (IPng 7212) RE: Last Call: Mobility Support in IPv6 to Proposed Standard In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D55@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8100AF81D55@RED-MSG-50> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, > > > I believe that an IPsec-enabled node that is processing a routing header > with non-zero Segments Left should do inbound IPsec processing (SPD lookup & > policy verification) when it gets to the routing header and outbound IPsec > processing before sending the updated packet. This should be just the same > as a security gateway that is forwarding a packet. The routing header should > not make it possible to bypass security policies. I would think that if the intermediate dest (defined per the routing hdr) gets an IP packet, it should not do inbound IPsec processing, as it is not the final dest for the packet, i.e it is not one of the endpoints of the IPSEC session. On the otherhand, if the packet was tunnelled to it then it would make sense to do inbound IPSEC processing. Security gateways only operate on tunnelled packets, destined to it. I agree that it is not the final destination, but is in the sense of the IPSEC session. Yes if the intermediate dest (one of the intermediate IP addresses in the routing header) is a security gateway, it should do the outbound IPSEC processing. > > Carrying forward the analogy with security gateways, the IPsec processing > associated with a routing header should only support tunnel-mode > associations. Otherwise it makes life too difficult for the node processing > the routing header, because it would have to be finding & removing & > inserting headers in strange places. Security gateways must only support > tunnel-mode associations. > > To make this concrete, suppose we have four nodes A, B, C, D. Node A sends a > packet with a routing header through nodes B and C to node D. Node A can > have tunnel and/or transport mode associations with node D, say for example > transport-mode AH. Node A can only have a tunnel mode association with node > B, say for example tunnel-mode ESP. > > The packets sent by node A will look like > IPv6 hdr - dst B, src A > ESP > IPv6 hdr - dst B, src A > Routing hdr, segments left = 2, addrs C, D > AH > Transport hdr > I would assume that each associations are related with some policies, which classify based on some fields in the packet. If node A has an association with D for this particular flow, then I am not sure if it needs to have another policy for the same flow which requires a tunnel mode security association with B and vice versa. A default policy which requires a tunnel mode association for any packets between A and B, should not be applicable either, as B is not the actual destination for this packet. > There might be further tunnel-mode associations between nodes B & C, nodes C > & D but node A won't know about that. > > Note that this means that outbound IPsec processing on node A has to happen > *twice*, first for the final destination node D, and then again for the > first intermediate destination node B. I don't understand why it should happen for the intermediate dest B, unless you have a policy which says that for all packets destined to intermediate destination B, use a tunnel mode association with B. Here your processing of the packet looks like as if it was originated twice, once as destined to D, and then destined to B. To me, it seems better to consider the packet as originated once, destined for D. I am not sure if routing header should be given the same semantic as a tunnelling header, in the IPSEC context. Sorry, if I am way offtrack in my understanding of this debate. Quaizar > > Does this sound reasonable? > > Applying this to the mobility case, there's only one intermediate > destination address and the final destination and the intermediate > destination address happen to both be assigned to the mobile node. > > Suppose the correspondent node has an active transport-mode AH association > for a TCP connection with the mobile node. Then the mobile node wanders off > and acquires a care-of address behind a security gateway. The correspondent > node needs to use tunnel-mode ESP to the security gateway to reach the > care-of address, and then transport-mode AH for the home address. > > This demonstrates the example above: when the correspondent node sends to > the mobile node, it needs to do outbound IPsec processing twice, first for > the home address, then for the care-of address. > > Thanks, > Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Feb 19 19:13:45 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA06609 for ipng-dist; Fri, 19 Feb 1999 19:07:50 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA06602 for ; Fri, 19 Feb 1999 19:07:41 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id TAA10657 for ; Fri, 19 Feb 1999 19:07:39 -0800 (PST) Received: from jazz-1.trumpet.com.au (jazz-1.trumpet.com.au [203.5.119.62]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA19123 for ; Fri, 19 Feb 1999 19:07:39 -0800 (PST) Received: from lana-2.trumpet.com.au (lana-2.trumpet.com.au [203.5.119.82]) by jazz-1.trumpet.com.au (8.8.7/8.8.7) with SMTP id OAA06876 for ; Sat, 20 Feb 1999 14:07:38 +1100 (EST) (envelope-from pete@trumpet.com.au) To: ipng@sunroof.eng.sun.com From: pete@trumpet.com.au (Peter R. Tattam) Subject: (IPng 7213) PF_INET6, AF_INET6 values. Date: Sat, 20 Feb 1999 14:07:34 +1100 Message-ID: <3en3qud$1mv@lana-2.trumpet.com.au> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Last time I looked at the API standard, the values for these were not explicitly set. While you may say it doesn't matter and that the source for the relevant machine platform should specify the value, what happens in the case where binaries are built with specific values for that machine implementation. With IPv4 this has not been an issue as the values of PF_INET & AF_INET appear to be the same from platform to platform (I have never noticed anything other than the value 2) but in the IPv6 development I have seen, because there are many other PF_ values after PF_INET, the value of PF_INET6 can be somewhat arbitrary. This is important for API that provide a binary level of compatibility such as Winsock 1.1, winsock 2.0, and also would be important for precompiled binaries that are distributed for a given platform. I myself have discovered that the values I used for my stack based on the FreeBSD settings turn out to be different to the ones used in the Winsock 2 spec. Winsock 1.1 is undefined as it is a frozen protocol (although everyone is using it). same issue also applies to sockaddr structure for IPv6. What's the correct way to deal with the issue? Peter -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 19 20:10:40 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA06645 for ipng-dist; Fri, 19 Feb 1999 20:07:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA06638 for ; Fri, 19 Feb 1999 20:07:10 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id UAA13856 for ; Fri, 19 Feb 1999 20:07:10 -0800 (PST) Received: from inner.net (avarice.inner.net [199.33.248.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA08895 for ; Fri, 19 Feb 1999 20:07:06 -0800 (PST) Received: from inner.net (cmetz.cstone.net [205.197.102.217]) by inner.net (8.9.1/8.9.1) with ESMTP id DAA06826; Sat, 20 Feb 1999 03:32:32 GMT Message-Id: <199902200332.DAA06826@inner.net> To: pete@trumpet.com.au (Peter R. Tattam) cc: ipng@sunroof.eng.sun.com Subject: (IPng 7214) Re: PF_INET6, AF_INET6 values. In-reply-to: Your message of "Sat, 20 Feb 1999 14:07:34 +1100." <3en3qud$1mv@lana-2.trumpet.com.au> X-Copyright: Copyright 1999, Craig Metz, All Rights Reserved. X-Reposting: With explicit permission only Date: Fri, 19 Feb 1999 22:52:39 -0500 From: Craig Metz Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message <3en3qud$1mv@lana-2.trumpet.com.au>, you write: >With IPv4 this has not been an issue as the values of PF_INET & AF_INET appear >to be the same from platform to platform (I have never noticed anything other >than the value 2) Linux. -Craig -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 20 00:13:15 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id AAA06837 for ipng-dist; Sat, 20 Feb 1999 00:09:01 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.85.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06830 for ; Sat, 20 Feb 1999 00:08:52 -0800 (PST) Received: from lucknow.eng.sun.com (lucknow [129.146.86.77]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28186; Sat, 20 Feb 1999 00:08:54 -0800 (PST) Received: (from mukesh@localhost) by lucknow.eng.sun.com (8.9.1b+Sun/8.9.1) id AAA00706; Sat, 20 Feb 1999 00:05:47 -0800 (PST) Date: Sat, 20 Feb 1999 00:05:47 -0800 (PST) From: Mukesh Kacker Message-Id: <199902200805.AAA00706@lucknow.eng.sun.com> To: pete@trumpet.com.au Subject: (IPng 7215) Re: PF_INET6, AF_INET6 values. Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Last time I looked at the API standard, the values for these were not > explicitly set. .... > > What's the correct way to deal with the issue? > You have just discovered the need for what some in the industry call the "ABI" or (Application Binary Interface). It involves a lot more than values of defined constants to have the ability to share "precompiled binaries that are distributed for a given platform" though those values are certainly a part of it. There is no "central registry" for those "values space" (ala IANA for all the numbers used in protocols). Product teams at comapanies or cooredinated development groups (e.g FreeBSD, Linux etc) enforce a registry that typically tries to keep the compatible with their previous releases but that is about it. The advise would be to pick one platform to track which you want to stay compatible with and and learn how to figure out its "binary interface" (which is lot more than values of constants) and try to design your "my stack" in a manner so you can share binaries with it. Current reality only allows people to keep struggling to have "source level" compatibility and that is the goal API efforts discussed here have been limited to that. [ Apologies if you know all this already this has been superfluous :-) ] - Mukesh Kacker Internet Engineering Solaris Software Sun Microsystems Inc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 20 03:04:07 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id CAA06944 for ipng-dist; Sat, 20 Feb 1999 02:49:28 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA06937 for ; Sat, 20 Feb 1999 02:49:18 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id CAA18467; Sat, 20 Feb 1999 02:49:16 -0800 (PST) Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id CAA25942; Sat, 20 Feb 1999 02:49:11 -0800 (PST) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by concorde.inria.fr (8.8.7/8.8.7) with ESMTP id LAA07992; Sat, 20 Feb 1999 11:49:09 +0100 (MET) Received: from givry.inria.fr (givry.inria.fr [128.93.8.18]) by givry.inria.fr (8.7.6/8.7.3) with ESMTP id LAA28452; Sat, 20 Feb 1999 11:49:08 +0100 (MET) Message-Id: <199902201049.LAA28452@givry.inria.fr> From: Francis Dupont To: Jim Bound cc: droms@bucknell.edu, Charles.Perkins@Eng, narten@raleigh.ibm.com, burgan@home.net, bound@zk3.dec.com, dhcp-v6@bucknell.edu, ipng@sunroof.eng.sun.com Subject: (IPng 7216) Re: DHCPv6 Update and Agenda at the IETF In-reply-to: Your message of Fri, 19 Feb 1999 16:14:18 EST. <199902192114.QAA0000016326@wasted.zk3.dec.com> Date: Sat, 20 Feb 1999 11:49:06 +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: At the IETF Minneapolis meeting we would like to request a full 2 hour slot for DHCPv6 with the following agenda: => DHCPv6 is very *important* for many reasons and is stalled (I'd like to remain polite then I add no comments). We need it as a proposal standard with implementations, not as a cancelled item in IETF meeting agendas! Thanks Francis.Dupont@inria.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Feb 20 20:08:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA07481 for ipng-dist; Sat, 20 Feb 1999 20:06:19 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07474 for ; Sat, 20 Feb 1999 20:06:10 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id UAA18323; Sat, 20 Feb 1999 20:06:08 -0800 (PST) Received: from csrlink.net (schroeder.csrlink.net [209.173.80.1]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA04236; Sat, 20 Feb 1999 20:06:08 -0800 (PST) Received: from [209.173.86.15] (pm3mi1-14.uplink.net [209.173.86.15]) by csrlink.net (8.8.8/8.8.5) with ESMTP id WAA10627; Sat, 20 Feb 1999 22:57:12 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: droms@mail.bucknell.edu (Unverified) Message-Id: In-Reply-To: <199902201049.LAA28452@givry.inria.fr> References: Your message of Fri, 19 Feb 1999 16:14:18 EST. <199902192114.QAA0000016326@wasted.zk3.dec.com> Date: Sat, 20 Feb 1999 22:54:28 -0500 To: Francis Dupont , Jim Bound From: Ralph Droms Subject: (IPng 7218) Re: DHCPv6 Update and Agenda at the IETF Cc: Charles.Perkins@Eng, narten@raleigh.ibm.com, burgan@home.net, bound@zk3.dec.com, dhcp-v6@bucknell.edu, ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 11:49 AM +0100 2/20/99, Francis Dupont wrote: > In your previous mail you wrote: > > At the IETF Minneapolis meeting we would like to request a full 2 hour > slot for DHCPv6 with the following agenda: > >=> DHCPv6 is very *important* for many reasons and is stalled >(I'd like to remain polite then I add no comments). We need it >as a proposal standard with implementations, not as a cancelled >item in IETF meeting agendas! I agree that DHCPv6 is very important. As to DHCPv6 being stalled, there has been little or no discussion on the DHC WG mailing list for DHCPv6 (dhcp-v6@bucknell.edu) following up on the issues raised about the current spec during the WG last call. If DHCPv6 is to become "unstalled", those who agree that DHCPv6 is important need to join the discussion about the last call issues and the DHCPv6 spec. We need to have clear, thorough technical review by the DHC WG and/or the IPv6 community and/or ??? before the spec goes to the IESG. - Ralph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 22 08:31:16 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA08622 for ipng-dist; Mon, 22 Feb 1999 08:23:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08615 for ; Mon, 22 Feb 1999 08:23:30 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id IAA21230 for ; Mon, 22 Feb 1999 08:23:28 -0800 (PST) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA27200 for ; Mon, 22 Feb 1999 08:23:28 -0800 (PST) Received: from bogey by east.isi.edu (8.8.5/5.61+local-24) id ; Mon, 22 Feb 1999 16:23:23 GMT Message-ID: <00b701be5e80$863f9010$634cf526@east.isi.edu> From: "Aaron Griggs" To: Cc: , Subject: (IPng 7221) Re: Last Call: Mobility Support in IPv6 to Proposed Standard Date: Mon, 22 Feb 1999 11:29:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0810.800 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think there is some confusion to what we are asking in regards to IPSec and routing headers, Rich correct me if I am wrong. Sorry this is so long, I want to make the example clear. A mobile node is in its home network when it first establishes a security policy with some correspondent node. The security policy in the correspondent node uses the "home address" of the mobile node when communicating. At a later time, the mobile node moves to another location. The correspondent node still communicates with the mobile node using the "home address" until the correspondent node discovers that there is a "care of address." The "care of address" is discovered when the correspondent node receives a packet from the mobile node with the source address set to the "care of address" and the packet contains a "Home Address" destination option. The correspondent node caches the binding. The IPSec headers for this packet could come before or after the destination option. If the IPSec is before the destination option, then there must be an association between the "care of address" and the correspondent node. If the IPSec is after the destination header, the "home address" is used in the policy and no association between the "care of address" and the mobile node exists. The latter case is probably the most likely. Lets take the example of the IPSec headers being after the destination option. When the mobile node sends a packet to the correspondent node, there is probably a security gateway protecting outbound traffic. The security gateway communicates with the correspondent node. Here is a diagram: MobileNode("care of address")---->SG---->Internet---->CorrespondentNode The traffic reaches the correspondent node which parses the packet and creates the "care of address" binding. Then, the end-end IPSec between the mobile node and the correspondent node is handled. Remember, the "home address" is the destination address. It was swapped when doing the binding. Now, the correspondent node sends traffic back to the mobile node. At the transport layer, the "home address" is used for the policy lookup. However if this is a TCP connection, the security association is probably cached in the TCP control block so a lookup is not needed. Before the traffic is actually protected by AH (AH because it covers the entire datagram), a check of the binding is done to see if there is a "care of address." Yes, a "care of address" does exist so the destination IP address is changed to the "care of address" and a routing header created containing the "home address." Of course, the routing header and the destination IP address are mutable but predictable. The actual authentication is done on the predicted value. This is one reason AH is so "fun" to implement and will cost in performance. Before the traffic is sent, a policy lookup is performed to see if the traffic is protected by IPSec. If a second policy lookup is not performed, the traffic is dropped when it reaches the security gateway. So in this case, it is necessary for the correspondent node to do a second lookup. Unless of course, the security gateway looks at the routing header and allows the packet to be forwarded to the mobile node. But this means the traffic bypasses security at the security gateway. I doubt this is an option. Aaron Original Message ----- From: Quaizar Vohra To: Richard Draves Cc: ; ; Sent: Friday, February 19, 1999 8:29 PM Subject: (IPng 7212) RE: Last Call: Mobility Support in IPv6 to Proposed Standard > > >Rich, > > >> >> >> I believe that an IPsec-enabled node that is processing a routing header >> with non-zero Segments Left should do inbound IPsec processing (SPD lookup & >> policy verification) when it gets to the routing header and outbound IPsec >> processing before sending the updated packet. This should be just the same >> as a security gateway that is forwarding a packet. The routing header should >> not make it possible to bypass security policies. > >I would think that if the intermediate dest (defined per the routing >hdr) gets an IP packet, it should not do inbound IPsec processing, as >it is not the final dest for the packet, i.e it is not one of the >endpoints of the IPSEC session. On the otherhand, if the packet was >tunnelled to it then it would make sense to do inbound IPSEC >processing. > >Security gateways only operate on tunnelled packets, destined to it. >I agree that it is not the final destination, but is in the sense >of the IPSEC session. > >Yes if the intermediate dest (one of the intermediate IP addresses in >the routing header) is a security gateway, it should do the outbound >IPSEC processing. > >> >> Carrying forward the analogy with security gateways, the IPsec processing >> associated with a routing header should only support tunnel-mode >> associations. Otherwise it makes life too difficult for the node processing >> the routing header, because it would have to be finding & removing & >> inserting headers in strange places. Security gateways must only support >> tunnel-mode associations. >> >> To make this concrete, suppose we have four nodes A, B, C, D. Node A sends a >> packet with a routing header through nodes B and C to node D. Node A can >> have tunnel and/or transport mode associations with node D, say for example >> transport-mode AH. Node A can only have a tunnel mode association with node >> B, say for example tunnel-mode ESP. >> >> The packets sent by node A will look like >> IPv6 hdr - dst B, src A >> ESP >> IPv6 hdr - dst B, src A >> Routing hdr, segments left = 2, addrs C, D >> AH >> Transport hdr >> > >I would assume that each associations are related with some policies, >which classify based on some fields in the packet. > >If node A has an association with D for this particular flow, then I >am not sure if it needs to have another policy for the same flow >which requires a tunnel mode security association with B and vice versa. > >A default policy which requires a tunnel mode association for any >packets between A and B, should not be applicable either, as B is not >the actual destination for this packet. > > >> There might be further tunnel-mode associations between nodes B & C, nodes C >> & D but node A won't know about that. >> >> Note that this means that outbound IPsec processing on node A has to happen >> *twice*, first for the final destination node D, and then again for the >> first intermediate destination node B. > >I don't understand why it should happen for the intermediate dest B, unless >you have a policy which says that for all packets destined to intermediate >destination B, use a tunnel mode association with B. > >Here your processing of the packet looks like as if it was originated >twice, once as destined to D, and then destined to B. To me, it seems >better to consider the packet as originated once, destined for D. > >I am not sure if routing header should be given the same semantic as >a tunnelling header, in the IPSEC context. > >Sorry, if I am way offtrack in my understanding of this debate. > >Quaizar > >> >> Does this sound reasonable? >> >> Applying this to the mobility case, there's only one intermediate >> destination address and the final destination and the intermediate >> destination address happen to both be assigned to the mobile node. >> >> Suppose the correspondent node has an active transport-mode AH association >> for a TCP connection with the mobile node. Then the mobile node wanders off >> and acquires a care-of address behind a security gateway. The correspondent >> node needs to use tunnel-mode ESP to the security gateway to reach the >> care-of address, and then transport-mode AH for the home address. >> >> This demonstrates the example above: when the correspondent node sends to >> the mobile node, it needs to do outbound IPsec processing twice, first for >> the home address, then for the care-of address. >> >> Thanks, >> Rich >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 22 09:03:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA08705 for ipng-dist; Mon, 22 Feb 1999 08:59:44 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08698 for ; Mon, 22 Feb 1999 08:59:35 -0800 (PST) From: agriggs@EAST.ISI.EDU Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id IAA22065 for ; Mon, 22 Feb 1999 08:59:33 -0800 (PST) Received: from neodymium.btinternet.com (neodymium.btinternet.com [194.73.73.83]) by earth.sun.com (8.9.1/8.9.1) with SMTP id IAA21936 for ; Mon, 22 Feb 1999 08:59:32 -0800 (PST) Received: from thss-barney.THSS-BARNEY [195.99.51.222] by neodymium.btinternet.com with esmtp (Exim 1.70 #1) id 10Eyhj-0004Vr-00; Mon, 22 Feb 1999 16:59:36 +0000 Received: from THSS-BARNEY by thss-barney.THSS-BARNEY with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id F3AG9LRQ; Mon, 22 Feb 1999 17:00:14 -0000 Message-Id: Date: Mon, 22 Feb 1999 16:59:36 +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From owner-ipng@sunroof.Eng.Sun.COM Mon Feb 22 16:49:02 1999 Received: from mailhub.btwebworld.com [193.113.211.246] by praseodumium.btinternet.com with smtp (Exim 1.70 #1) id 10EyXV-000301-00; Mon, 22 Feb 1999 16:49:01 +0000 Received: from mail.btwebworld.com by mailhub.btwebworld.com (SMI-8.6/SMI-SVR4) id QAA12074; Mon, 22 Feb 1999 16:50:03 GMT Received: by mail.btwebworld.com (SMI-8.6/SMI-SVR4) id QAA13151; Mon, 22 Feb 1999 16:49:25 GMT Received: from mercury.Sun.COM by mail.btwebworld.com with SMTP (XT-PP); Mon, 22 Feb 1999 16:49:22 +0000 Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id IAA01714; Mon, 22 Feb 1999 08:39:56 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id IAA23311; Mon, 22 Feb 1999 08:39:42 -0800 (PST) Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id IAA08622 for ipng-dist; Mon, 22 Feb 1999 08:23:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08615 for ; Mon, 22 Feb 1999 08:23:30 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id IAA21230 for ; Mon, 22 Feb 1999 08:23:28 -0800 (PST) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id IAA27200 for ; Mon, 22 Feb 1999 08:23:28 -0800 (PST) Received: from bogey by east.isi.edu (8.8.5/5.61+local-24) id ; Mon, 22 Feb 1999 16:23:23 GMT Message-ID: <00b701be5e80$863f9010$634cf526@east.isi.edu> From: "Aaron Griggs" To: Cc: , Subject: (IPng 7221) Re: Last Call: Mobility Support in IPv6 to Proposed Standard Date: Mon, 22 Feb 1999 11:29:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0810.800 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk I think there is some confusion to what we are asking in regards to IPSec and routing headers, Rich correct me if I am wrong. Sorry this is so long, I want to make the example clear. A mobile node is in its home network when it first establishes a security policy with some correspondent node. The security policy in the correspondent node uses the "home address" of the mobile node when communicating. At a later time, the mobile node moves to another location. The correspondent node still communicates with the mobile node using the "home address" until the correspondent node discovers that there is a "care of address." The "care of address" is discovered when the correspondent node receives a packet from the mobile node with the source address set to the "care of address" and the packet contains a "Home Address" destination option. The correspondent node caches the binding. The IPSec headers for this packet could come before or after the destination option. If the IPSec is before the destination option, then there must be an association between the "care of address" and the correspondent node. If the IPSec is after the destination header, the "home address" is used in the policy and no association between the "care of address" and the mobile node exists. The latter case is probably the most likely. Lets take the example of the IPSec headers being after the destination option. When the mobile node sends a packet to the correspondent node, there is probably a security gateway protecting outbound traffic. The security gateway communicates with the correspondent node. Here is a diagram: MobileNode("care of address")---->SG---->Internet---->CorrespondentNode The traffic reaches the correspondent node which parses the packet and creates the "care of address" binding. Then, the end-end IPSec between the mobile node and the correspondent node is handled. Remember, the "home address" is the destination address. It was swapped when doing the binding. Now, the correspondent node sends traffic back to the mobile node. At the transport layer, the "home address" is used for the policy lookup. However if this is a TCP connection, the security association is probably cached in the TCP control block so a lookup is not needed. Before the traffic is actually protected by AH (AH because it covers the entire datagram), a check of the binding is done to see if there is a "care of address." Yes, a "care of address" does exist so the destination IP address is changed to the "care of address" and a routing header created containing the "home address." Of course, the routing header and the destination IP address are mutable but predictable. The actual authentication is done on the predicted value. This is one reason AH is so "fun" to implement and will cost in performance. Before the traffic is sent, a policy lookup is performed to see if the traffic is protected by IPSec. If a second policy lookup is not performed, the traffic is dropped when it reaches the security gateway. So in this case, it is necessary for the correspondent node to do a second lookup. Unless of course, the security gateway looks at the routing header and allows the packet to be forwarded to the mobile node. But this means the traffic bypasses security at the security gateway. I doubt this is an option. Aaron Original Message ----- From: Quaizar Vohra To: Richard Draves Cc: ; ; Sent: Friday, February 19, 1999 8:29 PM Subject: (IPng 7212) RE: Last Call: Mobility Support in IPv6 to Proposed Standard > > >Rich, > > >> >> >> I believe that an IPsec-enabled node that is processing a routing header >> with non-zero Segments Left should do inbound IPsec processing (SPD lookup & >> policy verification) when it gets to the routing header and outbound IPsec >> processing before sending the updated packet. This should be just the same >> as a security gateway that is forwarding a packet. The routing header should >> not make it possible to bypass security policies. > >I would think that if the intermediate dest (defined per the routing >hdr) gets an IP packet, it should not do inbound IPsec processing, as >it is not the final dest for the packet, i.e it is not one of the >endpoints of the IPSEC session. On the otherhand, if the packet was >tunnelled to it then it would make sense to do inbound IPSEC >processing. > >Security gateways only operate on tunnelled packets, destined to it. >I agree that it is not the final destination, but is in the sense >of the IPSEC session. > >Yes if the intermediate dest (one of the intermediate IP addresses in >the routing header) is a security gateway, it should do the outbound >IPSEC processing. > >> >> Carrying forward the analogy with security gateways, the IPsec processing >> associated with a routing header should only support tunnel-mode >> associations. Otherwise it makes life too difficult for the node processing >> the routing header, because it would have to be finding & removing & >> inserting headers in strange places. Security gateways must only support >> tunnel-mode associations. >> >> To make this concrete, suppose we have four nodes A, B, C, D. Node A sends a >> packet with a routing header through nodes B and C to node D. Node A can >> have tunnel and/or transport mode associations with node D, say for example >> transport-mode AH. Node A can only have a tunnel mode association with node >> B, say for example tunnel-mode ESP. >> >> The packets sent by node A will look like >> IPv6 hdr - dst B, src A >> ESP >> IPv6 hdr - dst B, src A >> Routing hdr, segments left = 2, addrs C, D >> AH >> Transport hdr >> > >I would assume that each associations are related with some policies, >which classify based on some fields in the packet. > >If node A has an association with D for this particular flow, then I >am not sure if it needs to have another policy for the same flow >which requires a tunnel mode security association with B and vice versa. > >A default policy which requires a tunnel mode association for any >packets between A and B, should not be applicable either, as B is not >the actual destination for this packet. > > >> There might be further tunnel-mode associations between nodes B & C, nodes C >> & D but node A won't know about that. >> >> Note that this means that outbound IPsec processing on node A has to happen >> *twice*, first for the final destination node D, and then again for the >> first intermediate destination node B. > >I don't understand why it should happen for the intermediate dest B, unless >you have a policy which says that for all packets destined to intermediate >destination B, use a tunnel mode association with B. > >Here your processing of the packet looks like as if it was originated >twice, once as destined to D, and then destined to B. To me, it seems >better to consider the packet as originated once, destined for D. > >I am not sure if routing header should be given the same semantic as >a tunnelling header, in the IPSEC context. > >Sorry, if I am way offtrack in my understanding of this debate. > >Quaizar > >> >> Does this sound reasonable? >> >> Applying this to the mobility case, there's only one intermediate >> destination address and the final destination and the intermediate >> destination address happen to both be assigned to the mobile node. >> >> Suppose the correspondent node has an active transport-mode AH association >> for a TCP connection with the mobile node. Then the mobile node wanders off >> and acquires a care-of address behind a security gateway. The correspondent >> node needs to use tunnel-mode ESP to the security gateway to reach the >> care-of address, and then transport-mode AH for the home address. >> >> This demonstrates the example above: when the correspondent node sends to >> the mobile node, it needs to do outbound IPsec processing twice, first for >> the home address, then for the care-of address. >> >> Thanks, >> Rich >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 22 18:29:18 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA09541 for ipng-dist; Mon, 22 Feb 1999 18:14:51 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09534 for ; Mon, 22 Feb 1999 18:14:41 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id SAA15432 for ; Mon, 22 Feb 1999 18:14:40 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id SAA21439 for ; Mon, 22 Feb 1999 18:14:41 -0800 (PST) Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id ; Mon, 22 Feb 1999 18:14:41 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D8C@RED-MSG-50> From: Richard Draves To: "'Quaizar Vohra'" Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Subject: (IPng 7222) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Mon, 22 Feb 1999 18:14:36 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I would think that if the intermediate dest (defined per the routing > hdr) gets an IP packet, it should not do inbound IPsec processing, as > it is not the final dest for the packet, i.e it is not one of the > endpoints of the IPSEC session. On the otherhand, if the packet was > tunnelled to it then it would make sense to do inbound IPSEC > processing. See example below arguing that inbound IPsec processing should be required for intermediate destinations. > Security gateways only operate on tunnelled packets, destined to it. > I agree that it is not the final destination, but is in the sense > of the IPSEC session. > > Yes if the intermediate dest (one of the intermediate IP addresses in > the routing header) is a security gateway, it should do the outbound > IPSEC processing. There are two approaches to my questions about the interaction of routing headers and IPsec - the first is to think generically about routing headers, and the second is to think specifically about mobility scenarios. The mobility scenarios are good because they are very concrete, but they use the routing header in a very stylized way. In a later message I'll examine some more mobility scenarios. To get back to this particular thread, which is about more generic routing header scenarios: I don't understand how it can be legitimate for an IPsec-enabled node that is receiving a packet with a routing header to bypass inbound IPsec processing. A very concrete, simple example: consider a node SG. SG has two interfaces, an interface to the public network and an interface on a private network. Node A is on the public network and node B is on the private network. The SPD on SG requires all traffic through it to & from the public network to be protected with tunnel-mode ESP. This is a classic security gateway scenario. So in the normal case when node A sends a packet to node B, it will look like IPv6 hdr - src A, dst SG ESP IPv6 hdr - src A, dst B Transport hdr This packet will arrive at SG. The outer IPv6 header will be processed. The ESP header will be processed. The inner IPv6 header will be processed and SG will realize it needs to forward the packet. It will do an inbound SPD lookup and verify that the packet was protected with the appopriate tunnel-mode ESP security association, which it was. Then it will do outbound SPD processing, which will find a policy allowing the packet to be sent without further protection, and it will send the packet as IPv6 hdr - src A, dst B Transport hdr That's all well and good and I hope we are in agreement so far. Now suppose SG receives a packet that looks like IPv6 hdr - src A, dst SG Routing hdr - segs left = 1, B Transport hdr Now you are saying that SG should not perform any inbound IPsec processing?!? This would mean that SG will send the packet on to B without having verified that it was properly protected, bypassing the intended security policy. 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 Mon Feb 22 18:43:41 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA09573 for ipng-dist; Mon, 22 Feb 1999 18:33:46 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.81.144] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09566 for ; Mon, 22 Feb 1999 18:33:35 -0800 (PST) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA25547; Mon, 22 Feb 1999 18:33:35 -0800 (PST) Date: Mon, 22 Feb 1999 18:33:35 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 7223) Re: Last Call: Mobility Support in IPv6 to Proposed Standard To: Aaron Griggs Cc: ipng@sunroof.eng.sun.com, mobile-ip@smallworks.com, ipsec@tis.com In-Reply-To: "Your message with ID" <00b701be5e80$863f9010$634cf526@east.isi.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A small clarification: > The "care of address" is discovered when the correspondent node receives a > packet from the mobile node with the source address set to the "care of > address" and the packet contains a "Home Address" destination option. The > correspondent node caches the binding. The binding is only cached when the packet contains both a "binding update" destination option and a "home address" destination option. And the packet must include "either an AH or ESP header providing sender authentication, data integrity protection, and replay protection." 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 Feb 22 18:44:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id SAA09594 for ipng-dist; Mon, 22 Feb 1999 18:41:58 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.83.130] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA09587 for ; Mon, 22 Feb 1999 18:41:46 -0800 (PST) Received: from bobo (bobo [129.146.86.130]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA26181; Mon, 22 Feb 1999 18:41:45 -0800 (PST) Date: Mon, 22 Feb 1999 18:41:45 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 7224) Re: (mobile-ip) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard To: Richard Draves Cc: "'Quaizar Vohra'" , mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8100AF81D8C@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > That's all well and good and I hope we are in agreement so far. > Now suppose SG receives a packet that looks like > IPv6 hdr - src A, dst SG > Routing hdr - segs left = 1, B > Transport hdr > > Now you are saying that SG should not perform any inbound IPsec > processing?!? This would mean that SG will send the packet on to B without > having verified that it was properly protected, bypassing the intended > security policy. Presumably SG will do the same checks as when it receives a packet without a routing header: IPv6 hdr - src A, dst B Transport hdr If the SPD says that packets arriving on that interface must be protected with tunnel-mode ESP the SG would drop both the routed and source routed packets. Thus as far as I understand there isn't anything specific to source routing here other than an implementation having to perform the checks both in the normal forwarding path and when processing a routing header (which might be the same code on some implementations). 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 Feb 22 19:12:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA09714 for ipng-dist; Mon, 22 Feb 1999 19:07:35 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09707 for ; Mon, 22 Feb 1999 19:07:20 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id TAA21066; Mon, 22 Feb 1999 19:07:19 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA13607; Mon, 22 Feb 1999 19:07:20 -0800 (PST) Received: from quarry.zk3.dec.com (brrquarry.zk3.dec.com [16.141.56.3]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id WAA23133; Mon, 22 Feb 1999 22:07:19 -0500 (EST) Received: from localhost by quarry.zk3.dec.com (8.8.8/1.1.8.2/16Jan95-0946AM) id WAA0000019800; Mon, 22 Feb 1999 22:07:17 -0500 (EST) From: Jim Bound Message-Id: <199902230307.WAA0000019800@quarry.zk3.dec.com> To: Francis Dupont cc: Jim Bound , droms@bucknell.edu, Charles.Perkins@Eng, narten@raleigh.ibm.com, burgan@home.net, bound@zk3.dec.com, dhcp-v6@bucknell.edu, ipng@sunroof.eng.sun.com Subject: (IPng 7225) Re: DHCPv6 Update and Agenda at the IETF In-reply-to: Your message of "Sat, 20 Feb 1999 11:49:06 +0100." <199902201049.LAA28452@givry.inria.fr> Date: Mon, 22 Feb 1999 22:07:17 -0500 X-Mts: smtp Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thanks Francis... will be good to get INRIA's last call comments on the spec we will send out soon and the changes and other stuff Ralph asked for. /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 Feb 22 19:48:50 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id TAA09800 for ipng-dist; Mon, 22 Feb 1999 19:45:46 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA09793 for ; Mon, 22 Feb 1999 19:45:37 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id TAA15770 for ; Mon, 22 Feb 1999 19:45:37 -0800 (PST) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id TAA28391 for ; Mon, 22 Feb 1999 19:45:38 -0800 (PST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id TAA02829; Mon, 22 Feb 1999 19:45:36 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id TAA04964; Mon, 22 Feb 1999 19:45:35 -0800 (PST) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id TAA10300; Mon, 22 Feb 1999 19:45:35 -0800 (PST) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id TAA00668; Mon, 22 Feb 1999 19:45:33 -0800 (PST) Date: Mon, 22 Feb 1999 19:45:33 -0800 (PST) Message-Id: <199902230345.TAA00668@lookout.nsd.3com.com> To: Richard Draves Cc: "'Quaizar Vohra'" , mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Subject: (IPng 7226) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D8C@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8100AF81D8C@RED-MSG-50> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard Draves writes: > > I would think that if the intermediate dest (defined per the routing > > hdr) gets an IP packet, it should not do inbound IPsec processing, as > > it is not the final dest for the packet, i.e it is not one of the > > endpoints of the IPSEC session. On the otherhand, if the packet was > > tunnelled to it then it would make sense to do inbound IPSEC > > processing. > > See example below arguing that inbound IPsec processing should be required > for intermediate destinations. > > > Security gateways only operate on tunnelled packets, destined to it. > > I agree that it is not the final destination, but is in the sense > > of the IPSEC session. > > > > Yes if the intermediate dest (one of the intermediate IP addresses in > > the routing header) is a security gateway, it should do the outbound > > IPSEC processing. > > There are two approaches to my questions about the interaction of routing > headers and IPsec - the first is to think generically about routing headers, > and the second is to think specifically about mobility scenarios. The > mobility scenarios are good because they are very concrete, but they use the > routing header in a very stylized way. > > In a later message I'll examine some more mobility scenarios. To get back to > this particular thread, which is about more generic routing header > scenarios: > > I don't understand how it can be legitimate for an IPsec-enabled node that > is receiving a packet with a routing header to bypass inbound IPsec > processing. > > A very concrete, simple example: consider a node SG. SG has two interfaces, > an interface to the public network and an interface on a private network. > Node A is on the public network and node B is on the private network. The > SPD on SG requires all traffic through it to & from the public network to be > protected with tunnel-mode ESP. This is a classic security gateway scenario. > So in the normal case when node A sends a packet to node B, it will look > like > IPv6 hdr - src A, dst SG > ESP > IPv6 hdr - src A, dst B > Transport hdr > > This packet will arrive at SG. The outer IPv6 header will be processed. The > ESP header will be processed. The inner IPv6 header will be processed and SG > will realize it needs to forward the packet. It will do an inbound SPD > lookup and verify that the packet was protected with the appopriate > tunnel-mode ESP security association, which it was. Then it will do outbound > SPD processing, which will find a policy allowing the packet to be sent > without further protection, and it will send the packet as > IPv6 hdr - src A, dst B > Transport hdr > > That's all well and good and I hope we are in agreement so far. > Now suppose SG receives a packet that looks like > IPv6 hdr - src A, dst SG > Routing hdr - segs left = 1, B > Transport hdr > > Now you are saying that SG should not perform any inbound IPsec > processing?!? This would mean that SG will send the packet on to B without > having verified that it was properly protected, bypassing the intended > security policy. > I am sorry I was unclear in my last mail. When I said that SG will not do inbound IPSEC processing, I did not mean that it will not check its policies to see if the packet should have come encrypted to it If it has such a policy, it should drop the packet. Eric already clarified this. The intention of my previous mail was to say that the presence of source routing header in a packet should not change the IPSEC behavior either at the inbound or outbound. While a routing header might be considered as part of policy lookup, if an implementation allowed defining IPsec policies filtering on intermediate destination. Quaizar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 22 20:09:49 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA09842 for ipng-dist; Mon, 22 Feb 1999 20:06:51 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA09835 for ; Mon, 22 Feb 1999 20:06:42 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id UAA27126 for ; Mon, 22 Feb 1999 20:06:41 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA06248 for ; Mon, 22 Feb 1999 20:06:42 -0800 (PST) Received: by INET-IMC-05 with Internet Mail Service (5.5.2524.0) id ; Mon, 22 Feb 1999 20:06:43 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D91@RED-MSG-50> From: Richard Draves To: "'Quaizar Vohra'" Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Subject: (IPng 7227) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Mon, 22 Feb 1999 20:06:41 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I am sorry I was unclear in my last mail. When I said that SG will not > do inbound IPSEC processing, I did not mean that it will not check its > policies to see if the packet should have come encrypted to it > If it has such a policy, it should drop the packet. > > Eric already clarified this. > > The intention of my previous mail was to say that the presence > of source routing header in a packet should not change the IPSEC > behavior either at the inbound or outbound. While a routing > header might be considered as part of policy lookup, if an > implementation allowed defining IPsec policies filtering on > intermediate destination. I'm trying to keep things "simple" and not even consider policies that filter on routing headers. So are we in agreement that an IPsec-enabled node that is processing a routing header should do inbound & outbound IPsec processing, much like a security gateway that is forwarding a packet? Then I don't understand the point you are trying to make. One thought that occurs to me: to revisit the example of a node SG that receives a packet IPv6 hdr - src A, dst SG Routing hdr - segs left = 1, B Transport hdr When node SG is doing its inbound SPD lookup, what selectors should it use? Should the destination address selector be SG or B? In my first email on this subject I argued for SG, but now I'm thinking perhaps the destination address selector in inbound processing should be B (the destination address after routing header processing). Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 22 20:39:36 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA09920 for ipng-dist; Mon, 22 Feb 1999 20:36:01 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA09913 for ; Mon, 22 Feb 1999 20:35:51 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id UAA29443 for ; Mon, 22 Feb 1999 20:35:50 -0800 (PST) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA18367 for ; Mon, 22 Feb 1999 20:35:52 -0800 (PST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id UAA09171; Mon, 22 Feb 1999 20:35:50 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id UAA11554; Mon, 22 Feb 1999 20:35:49 -0800 (PST) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id UAA10896; Mon, 22 Feb 1999 20:35:48 -0800 (PST) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id UAA00683; Mon, 22 Feb 1999 20:35:47 -0800 (PST) Date: Mon, 22 Feb 1999 20:35:47 -0800 (PST) Message-Id: <199902230435.UAA00683@lookout.nsd.3com.com> To: Richard Draves Cc: "'Quaizar Vohra'" , mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Subject: (IPng 7228) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D91@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8100AF81D91@RED-MSG-50> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I am sorry I was unclear in my last mail. When I said that SG will not > > do inbound IPSEC processing, I did not mean that it will not check its > > policies to see if the packet should have come encrypted to it > > If it has such a policy, it should drop the packet. > > > > Eric already clarified this. > > > > The intention of my previous mail was to say that the presence > > of source routing header in a packet should not change the IPSEC > > behavior either at the inbound or outbound. While a routing > > header might be considered as part of policy lookup, if an > > implementation allowed defining IPsec policies filtering on > > intermediate destination. > > I'm trying to keep things "simple" and not even consider policies that > filter on routing headers. > > So are we in agreement that an IPsec-enabled node that is processing a > routing header should do inbound & outbound IPsec processing, much like a > security gateway that is forwarding a packet? Then I don't understand the > point you are trying to make. Yes I agree, but only that it should not consider SG as part of the selector, but the final destination, unless policies have capabilties to include intermediate destinations as part of the selector list. I guess this is implementation dependent. The point I was trying to make in my first mail, was that if A is communicating with D via B and C, the resulting packet looks like IPv6 hdr - src A, dst B Routing hdr - segs left = 1, C, D Transport hdr Then it does IPSEC processing. Depending on the policy (irrespective of how detailed the selector list) lookup, chooses a policy, which directs it to either do tunnel mode IPsec with an SG or transport mode IPSEC with D. In the 1st case, the packet will look like : IPv6 hdr - src A, dst SG ESP Tunnel mode with SG IPv6 hdr - src A, dst B Routing hdr - segs left = 1, C, D Transport hdr In the later case, it will be IPv6 hdr - src A, dst B ESP transport mode with D Routing hdr - segs left = 1, C, D Transport hdr The secure gateway processes the 1st case by doing inbound IPSEC, processing the ESP header. Next it processes the routing header and forwards the packet to C. In the 2nd case, if SG had an IPSEC policy that expected anything received on the interface this packet is received as ESP tunnelled, then it would drop the packet. All I was trying to say is that a routing header should not mean that IPSEC outbound processing be done twice, one with selector D, and next with selector B. IPsec processing should be done once, with both B and D as part of selectors. Or only D, if selectors containing intermediate dests are not supported. So when a mobile node moves beyond a SG, how does a correspondent know that and hence configures a policy to do IPSEC tunnel mode with SG ? Rather, I would assume that such SGs who expect mobile nodes to enter their domain, would have policies which would allow traffic which is IPSECed (by the presence of IPSEC headers) but not destined for them. Quaizar > > One thought that occurs to me: to revisit the example of a node SG that > receives a packet > IPv6 hdr - src A, dst SG > Routing hdr - segs left = 1, B > Transport hdr > > When node SG is doing its inbound SPD lookup, what selectors should it use? > Should the destination address selector be SG or B? In my first email on > this subject I argued for SG, but now I'm thinking perhaps the destination > address selector in inbound processing should be B (the destination address > after routing header processing). > > Thanks, > Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 22 21:00:54 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id UAA09971 for ipng-dist; Mon, 22 Feb 1999 20:57:51 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA09964 for ; Mon, 22 Feb 1999 20:57:42 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id UAA00832 for ; Mon, 22 Feb 1999 20:57:40 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id UAA26378 for ; Mon, 22 Feb 1999 20:57:41 -0800 (PST) Received: by mail1.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Mon, 22 Feb 1999 20:57:41 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D94@RED-MSG-50> From: Richard Draves To: "'Quaizar Vohra'" Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Subject: (IPng 7229) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Mon, 22 Feb 1999 20:57:39 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The point I was trying to make in my first mail, was that if A > is communicating with D via B and C, the resulting packet > looks like > > IPv6 hdr - src A, dst B > Routing hdr - segs left = 1, C, D > Transport hdr [I think you mean segs left = 2 in this example.] > Then it does IPSEC processing. Depending on the policy (irrespective > of how detailed the selector list) lookup, chooses a policy, which > directs it to either do tunnel mode IPsec with an SG or transport > mode IPSEC with D. > > In the 1st case, the packet will look like : > > IPv6 hdr - src A, dst SG > ESP Tunnel mode with SG > IPv6 hdr - src A, dst B > Routing hdr - segs left = 1, C, D > Transport hdr > > In the later case, it will be > > IPv6 hdr - src A, dst B > ESP transport mode with D > Routing hdr - segs left = 1, C, D > Transport hdr Surely you mean IPv6 hdr - src A, dst B Routing hdr - segs left = 2, C, D ESP transport mode with D Transport hdr ? > The secure gateway processes the 1st case by doing inbound IPSEC, > processing the ESP header. Next it processes the routing header > and forwards the packet to C. > > In the 2nd case, if SG had an IPSEC policy that expected anything > received on the interface this packet is received as ESP tunnelled, > then it would drop the packet. > > All I was trying to say is that a routing header should not mean that > IPSEC outbound processing be done twice, one with selector D, and next > with selector B. IPsec processing should be done once, with both B and > D as part of selectors. Or only D, if selectors containing > intermediate > dests are not supported. Consider the following scenario. Nodes A and C are on a public network. Their security policies let them communicate without a security association. Node B is on a private network, connected to the public network by a security gateway SG. The security policies on SG mandate that any traffic between the two networks must be protected with tunnel-mode ESP on the public side. Now for some reason, node A wants to send a packet to C with a routing header that will take the packet from A to B to C. The packet will need to look like: IPv6 hdr - src A, dst SG ESP tunnel mode, association A -> SG IPv6 hdr - src A, dst B Routing hdr - segs left = 1, C Transport hdr When this packet arrives at B, it will look like IPv6 hdr - src A, dst B Routing hdr - segs left = 1, C Transport hdr Node B will process the routing header and send this packet: IPv6 hdr - src A, dst C Routing hdr - segs left = 0, B Transport hdr The packet will get to SG again because SG is the router between B and C. SG will send the following packet: IPv6 hdr - src SG, dst C ESP tunnel mode, association SG -> C IPv6 hdr - src A, dst C Routing hdr - segs left = 0, B Transport hdr How does all that sound? Now go back to the packet sent by A. How will it know to do the tunnel-mode ESP to SG? It will need to do outbound IPsec processing with a destination address selector of B, and pick out the security association with SG. > So when a mobile node moves beyond a SG, how does a correspondent know > that and hence configures a policy to do IPSEC tunnel mode with SG ? > Rather, I would assume that such SGs who expect mobile nodes to enter > their domain, would have policies which would allow traffic which is > IPSECed (by the presence of IPSEC headers) but not destined for them. If a mobile node moves beyond a SG, then a correspondent can know that because the correspondent will learn a care-of address for the mobile and the correspondent can have a security policy that tells it how to send to the care-of address. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Feb 22 22:30:33 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id VAA10141 for ipng-dist; Mon, 22 Feb 1999 21:55:34 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA10130 for ; Mon, 22 Feb 1999 21:55:19 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id VAA05519 for ; Mon, 22 Feb 1999 21:55:18 -0800 (PST) Received: from seattle.3com.com (seattle.3com.com [129.213.128.97]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id VAA17529 for ; Mon, 22 Feb 1999 21:55:19 -0800 (PST) Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id VAA19177; Mon, 22 Feb 1999 21:55:06 -0800 (PST) Received: from chicago.nsd.3com.com (chicago.nsd.3com.com [129.213.157.11]) by new-york.3com.com (8.8.8/8.8.8) with ESMTP id VAA24695; Mon, 22 Feb 1999 21:55:06 -0800 (PST) Received: from lookout.nsd.3com.com (lookout.nsd.3com.com [129.213.48.28]) by chicago.nsd.3com.com (8.8.8/8.8.8) with ESMTP id VAA11822; Mon, 22 Feb 1999 21:55:06 -0800 (PST) From: Quaizar Vohra Received: (from qv@localhost) by lookout.nsd.3com.com (8.8.2/8.8.2) id VAA00754; Mon, 22 Feb 1999 21:55:05 -0800 (PST) Date: Mon, 22 Feb 1999 21:55:05 -0800 (PST) Message-Id: <199902230555.VAA00754@lookout.nsd.3com.com> To: Richard Draves Cc: "'Quaizar Vohra'" , mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Subject: (IPng 7230) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D94@RED-MSG-50> References: <4D0A23B3F74DD111ACCD00805F31D8100AF81D94@RED-MSG-50> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The point I was trying to make in my first mail, was that if A > > is communicating with D via B and C, the resulting packet > > looks like > > > > IPv6 hdr - src A, dst B > > Routing hdr - segs left = 1, C, D > > Transport hdr > > [I think you mean segs left = 2 in this example.] You are right. > > > Then it does IPSEC processing. Depending on the policy (irrespective > > of how detailed the selector list) lookup, chooses a policy, which > > directs it to either do tunnel mode IPsec with an SG or transport > > mode IPSEC with D. > > > > In the 1st case, the packet will look like : > > > > IPv6 hdr - src A, dst SG > > ESP Tunnel mode with SG > > IPv6 hdr - src A, dst B > > Routing hdr - segs left = 1, C, D > > Transport hdr > > > > In the later case, it will be > > > > IPv6 hdr - src A, dst B > > ESP transport mode with D > > Routing hdr - segs left = 1, C, D > > Transport hdr > > Surely you mean > IPv6 hdr - src A, dst B > Routing hdr - segs left = 2, C, D > ESP transport mode with D > Transport hdr > ? You are right. > > > The secure gateway processes the 1st case by doing inbound IPSEC, > > processing the ESP header. Next it processes the routing header > > and forwards the packet to C. > > > > In the 2nd case, if SG had an IPSEC policy that expected anything > > received on the interface this packet is received as ESP tunnelled, > > then it would drop the packet. > > > > All I was trying to say is that a routing header should not mean that > > IPSEC outbound processing be done twice, one with selector D, and next > > with selector B. IPsec processing should be done once, with both B and > > D as part of selectors. Or only D, if selectors containing > > intermediate > > dests are not supported. > > Consider the following scenario. Nodes A and C are on a public network. > Their security policies let them communicate without a security association. > Node B is on a private network, connected to the public network by a > security gateway SG. The security policies on SG mandate that any traffic > between the two networks must be protected with tunnel-mode ESP on the > public side. > > Now for some reason, node A wants to send a packet to C with a routing > header that will take the packet from A to B to C. The packet will need to > look like: > IPv6 hdr - src A, dst SG > ESP tunnel mode, association A -> SG > IPv6 hdr - src A, dst B > Routing hdr - segs left = 1, C > Transport hdr > > When this packet arrives at B, it will look like > IPv6 hdr - src A, dst B > Routing hdr - segs left = 1, C > Transport hdr > > Node B will process the routing header and send this packet: > IPv6 hdr - src A, dst C > Routing hdr - segs left = 0, B > Transport hdr > > The packet will get to SG again because SG is the router between B and C. SG > will send the following packet: > IPv6 hdr - src SG, dst C > ESP tunnel mode, association SG -> C > IPv6 hdr - src A, dst C > Routing hdr - segs left = 0, B > Transport hdr > > How does all that sound? Now go back to the packet sent by A. How will it > know to do the tunnel-mode ESP to SG? It will need to do outbound IPsec > processing with a destination address selector of B, and pick out the > security association with SG. > > > So when a mobile node moves beyond a SG, how does a correspondent know > > that and hence configures a policy to do IPSEC tunnel mode with SG ? > > Rather, I would assume that such SGs who expect mobile nodes to enter > > their domain, would have policies which would allow traffic which is > > IPSECed (by the presence of IPSEC headers) but not destined for them. > > If a mobile node moves beyond a SG, then a correspondent can know that > because the correspondent will learn a care-of address for the mobile and > the correspondent can have a security policy that tells it how to send to > the care-of address. > I see your point. So it might be useful to do outbound IPSEC processing again after appending the routing header. It would be interesting to understand the applications of such a model. Thanks, Quaizar -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 23 05:45:34 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id FAA10437 for ipng-dist; Tue, 23 Feb 1999 05:34:33 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA10430 for ; Tue, 23 Feb 1999 05:34:24 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id FAA04789; Tue, 23 Feb 1999 05:34:14 -0800 (PST) Received: from east.isi.edu (east.isi.edu [38.245.76.2]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id FAA08778; Tue, 23 Feb 1999 05:34:15 -0800 (PST) Received: from bogey by east.isi.edu (8.8.5/5.61+local-24) id ; Tue, 23 Feb 1999 13:34:14 GMT Message-ID: <029701be5f32$07bf8cb0$634cf526@east.isi.edu> From: "Aaron Griggs" To: "Erik Nordmark" , "Aaron Griggs" Cc: , , Subject: (IPng 7231) Re: Last Call: Mobility Support in IPv6 to Proposed Standard Date: Tue, 23 Feb 1999 08:40:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.0810.800 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.0810.800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >A small clarification: > >> The "care of address" is discovered when the correspondent node receives a >> packet from the mobile node with the source address set to the "care of >> address" and the packet contains a "Home Address" destination option. The >> correspondent node caches the binding. > >The binding is only cached when the packet contains both a "binding update" >destination option and a "home address" destination option. >And the packet must include > "either an AH or ESP header providing sender authentication, data integrity > protection, and replay protection." > Right, thanks for the clarrification. My main point was to describe why a node would want to do a second policy lookup when a routing header is inserted for mobility. It appeared there was some confusion about this. Althought this is an implementation detail, the handling of routing headers by both hosts and security gateways with respect to IPSec processing should be addressed in the relavent documents (mobility, security architecture). Rich began the thread with this point. Thanks, Aaron -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 23 06:42:42 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA10514 for ipng-dist; Tue, 23 Feb 1999 06:34:02 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10507 for ; Tue, 23 Feb 1999 06:33:53 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id GAA18395 for ; Tue, 23 Feb 1999 06:33:50 -0800 (PST) Received: from popcorn.cisco.com (popcorn.cisco.com [171.69.198.195]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA03393 for ; Tue, 23 Feb 1999 06:33:51 -0800 (PST) Received: from [171.68.180.69] (sj-dial-3-207.cisco.com [171.68.180.208]) by popcorn.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.6.5) with ESMTP id GAA08037; Tue, 23 Feb 1999 06:33:11 -0800 (PST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: deering@postoffice Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D91@RED-MSG-50> Date: Tue, 23 Feb 1999 06:35:42 -0800 To: Richard Draves From: Steve Deering Subject: (IPng 7232) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:06 PM -0800 2/22/99, Richard Draves wrote: > So are we in agreement that an IPsec-enabled node that is processing a > routing header should do inbound & outbound IPsec processing, ... Rich, I've only had a chance to skim these messages, but it occurs to me that some might be confused by your phrase "do IPsec processing", thinking that it means "process the IPsec header(s)", when what you really mean is "perform security policy enforcement", e.g., verify that the packet under consideration arrived via a secure tunnel, or encapsulate the packet in a secure tunnel for the next leg of its route, depending on arrival/departure interface. An IPsec header itself should never be "processed" by anyone other than its original source and its final destination. 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 Feb 23 09:40:44 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA10891 for ipng-dist; Tue, 23 Feb 1999 09:30:53 -0800 (PST) Received: from Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10875 for ; Tue, 23 Feb 1999 09:30:34 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id JAA24127 for ; Tue, 23 Feb 1999 09:30:31 -0800 (PST) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA19691 for ; Tue, 23 Feb 1999 09:30:31 -0800 (PST) Received: from mrohub2.mro.dec.com (mrohub2.mro.dec.com [16.34.192.32]) by mail13.digital.com (8.9.1a/8.9.1/WV2.0d) with ESMTP id MAA02245; Tue, 23 Feb 1999 12:30:25 -0500 (EST) Received: by mrohub2.mro.dec.com with Internet Mail Service (5.5.2232.9) id <1JX39HD9>; Tue, 23 Feb 1999 12:30:23 -0500 Message-ID: From: Ken Powell To: "'Richard Draves'" Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Subject: (IPng 7233) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Tue, 23 Feb 1999 12:30:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rich, >> A very concrete, simple example: consider a node SG. SG has two >> interfaces, an interface to the public network and an interface on >> a private network. Node A is on the public network and node B is >> on the private network. The SPD on SG requires all traffic through >> it to & from the public network to be protected with tunnel-mode >> ESP. This is a classic security gateway scenario. So in the normal >> case when node A sends a packet to node B, it will look >> like >> IPv6 hdr - src A, dst SG >> ESP >> IPv6 hdr - src A, dst B >> Transport hdr I thought that a tunnel interface would have a separate address from the public interface on node A. Therefore the message above would become: IPv6 hdr - src A, dst SG ESP with SG IPv6 hdr - src Atunnel, dst B Transport hdr As A moves around the public internet, it has to tell SG it's new location, not B. Its tunnel interface address never changes. If node B moves, it tells "Atunnel" what routing header to use. The resulting message from A would look like: IPv6 hdr - src A, dst SG ESP with SG IPv6 hdr - src Atunnel, dst B's care-of-addr Routing hdr - segs left = 1, B Transport hdr I don't see the problem when node's A and B move. I haven't thought the details of what happens when a node moves across the internet/intranet boundary, or when SG renumbers on either interface. You do run into problems when the "Atunnel" address is derived from "A". In such a case, "Atunnel" would have to change at the same time "A" changes, forcing two routing headers, one before the ESP and one after. 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 Tue Feb 23 10:00:59 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id JAA10925 for ipng-dist; Tue, 23 Feb 1999 09:47:39 -0800 (PST) Received: from Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10918 for ; Tue, 23 Feb 1999 09:47:22 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id JAA10399 for ; Tue, 23 Feb 1999 09:47:20 -0800 (PST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id JAA01066 for ; Tue, 23 Feb 1999 09:47:20 -0800 (PST) Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id MAA22090; Tue, 23 Feb 1999 12:47:12 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D8C@RED-MSG-50> Date: Tue, 23 Feb 1999 12:48:35 -0500 To: Richard Draves From: Stephen Kent Subject: (IPng 7234) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Cc: "'Quaizar Vohra'" , mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, > >I don't understand how it can be legitimate for an IPsec-enabled node that >is receiving a packet with a routing header to bypass inbound IPsec >processing. There is no contradiction here if the node is not a party to an SA associated with the IPsec headers in the packet in question. A security policy at an intermediate node could allow traffic to transit without Ipsec processing, if it "appeared" that such processing had been applied already. I'm not suggesting that this is good or bad, just making an observation about what it means to implement IPsec at an SG vs. what it implies for processing of transit traffic. I don'ty necessarily think we're in disagreement here, but I didn't agree with your characterization of the situation, in the cited paragraph. 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 Feb 23 11:56:30 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA11179 for ipng-dist; Tue, 23 Feb 1999 11:49:52 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11172 for ; Tue, 23 Feb 1999 11:49:43 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id LAA11281 for ; Tue, 23 Feb 1999 11:49:35 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA03279 for ; Tue, 23 Feb 1999 11:49:36 -0800 (PST) Received: by mail1.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Tue, 23 Feb 1999 11:49:32 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D9D@RED-MSG-50> From: Richard Draves To: "'Ken Powell'" Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Subject: (IPng 7235) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Tue, 23 Feb 1999 11:49:25 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >> A very concrete, simple example: consider a node SG. SG has two > >> interfaces, an interface to the public network and an interface on > >> a private network. Node A is on the public network and node B is > >> on the private network. The SPD on SG requires all traffic through > >> it to & from the public network to be protected with tunnel-mode > >> ESP. This is a classic security gateway scenario. So in the normal > >> case when node A sends a packet to node B, it will look > >> like > >> IPv6 hdr - src A, dst SG > >> ESP > >> IPv6 hdr - src A, dst B > >> Transport hdr > > I thought that a tunnel interface would have a separate > address from the public interface on node A. Therefore the > message above would become: > > IPv6 hdr - src A, dst SG > ESP with SG > IPv6 hdr - src Atunnel, dst B > Transport hdr Ken, this is a generic IPsec security gateway example with no routing header or mobility involved at this point. So I hope we can agree :-). I don't see why node A needs two addresses? Although node A has a tunnel-mode security association with SG, this does not imply that A has some kind of tunnel interface with a separate address assigned to the tunnel interface. Maybe some implementations will work that way, but it's certainly not required or usual, I believe. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Feb 23 11:57:43 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id LAA11189 for ipng-dist; Tue, 23 Feb 1999 11:55:48 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11182 for ; Tue, 23 Feb 1999 11:55:39 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id LAA14242 for ; Tue, 23 Feb 1999 11:55:33 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id LAA07802 for ; Tue, 23 Feb 1999 11:55:32 -0800 (PST) Received: by mail4.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Tue, 23 Feb 1999 11:55:33 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81D9E@RED-MSG-50> From: Richard Draves To: "'Stephen Kent'" Cc: "'Quaizar Vohra'" , mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Subject: (IPng 7236) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Tue, 23 Feb 1999 11:55:24 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >I don't understand how it can be legitimate for an > IPsec-enabled node that > >is receiving a packet with a routing header to bypass inbound IPsec > >processing. > > There is no contradiction here if the node is not a party to an SA > associated with the IPsec headers in the packet in question. > A security > policy at an intermediate node could allow traffic to transit > without Ipsec > processing, if it "appeared" that such processing had been > applied already. > I'm not suggesting that this is good or bad, just making an > observation > about what it means to implement IPsec at an SG vs. what it > implies for > processing of transit traffic. I don'ty necessarily think we're in > disagreement here, but I didn't agree with your > characterization of the > situation, in the cited paragraph. Steve, perhaps Steve Deering is correct and my use of "IPsec processing" is confusing. Would you agree with this statement: "An IPsec-enabled node that is processing a routing header must perform inbound and outbound security policy checks, analogous to the checks performed by security gateways." If we are in agreement on this, then I'd like to move on to considering the IPsec processing performed by a node generating a packet with a routing header, with the case of a correspondent node sending a packet to a mobile node being one example. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Feb 24 07:01:00 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id GAA12268 for ipng-dist; Wed, 24 Feb 1999 06:50:39 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12260 for ; Wed, 24 Feb 1999 06:50:24 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id GAA15196 for ; Wed, 24 Feb 1999 06:50:22 -0800 (PST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id GAA20967 for ; Wed, 24 Feb 1999 06:50:23 -0800 (PST) Received: from [128.89.0.110] (COSMEC.BBN.COM [128.89.0.110]) by po1.bbn.com (8.8.6/8.8.6) with ESMTP id JAA23468; Wed, 24 Feb 1999 09:49:50 -0500 (EST) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <4D0A23B3F74DD111ACCD00805F31D8100AF81D9E@RED-MSG-50> Date: Wed, 24 Feb 1999 09:49:03 -0500 To: Richard Draves From: Stephen Kent Subject: (IPng 7237) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Cc: mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, > >Would you agree with this statement: > >"An IPsec-enabled node that is processing a routing header must perform >inbound and outbound security policy checks, analogous to the checks >performed by security gateways." > >If we are in agreement on this, then I'd like to move on to considering the >IPsec processing performed by a node generating a packet with a routing >header, with the case of a correspondent node sending a packet to a mobile >node being one example. The critical issue is whether the node is a party to an SA for the packet and IPsec header in question. The fact that this is not mentioned in your concise statement makes me feel that we may still not be on the same wavelength. 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 Feb 24 14:52:53 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id OAA12660 for ipng-dist; Wed, 24 Feb 1999 14:44:49 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic [129.146.84.31] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12653 for ; Wed, 24 Feb 1999 14:44:37 -0800 (PST) Received: from awe174-18 (awe174-18.AWE.Sun.COM [192.29.174.18]) by jurassic.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA12349; Wed, 24 Feb 1999 14:44:31 -0800 (PST) Date: Wed, 24 Feb 1999 14:43:06 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: (IPng 7239) Re: (mobile-ip) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard To: Richard Draves Cc: "'Stephen Kent'" , "'Quaizar Vohra'" , mobile-ip@smallworks.com, ipng@sunroof.eng.sun.com, ipsec@tis.com In-Reply-To: "Your message with ID" <4D0A23B3F74DD111ACCD00805F31D8100AF81D9E@RED-MSG-50> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Would you agree with this statement: > > "An IPsec-enabled node that is processing a routing header must perform > inbound and outbound security policy checks, analogous to the checks > performed by security gateways." In interpret your statement that routing headers are somehow different than regular forwarding. Is this what you intend? Or do you intend? "An router forwarding packets (whether using routing headers or not) might implement security policy checks." I still don't see why routing headers need to be any different. 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 Feb 25 07:30:34 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA13431 for ipng-dist; Thu, 25 Feb 1999 07:24:21 -0800 (PST) Received: from hsmpka.eng.sun.com (hsmpka [129.146.121.47] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA13424 for ; Thu, 25 Feb 1999 07:24:11 -0800 (PST) Received: from finesse by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA01625; Thu, 25 Feb 1999 07:24:09 -0800 Message-Id: <199902251524.HAA01625@hsmpka.eng.sun.com> Date: Thu, 25 Feb 1999 07:19:16 -0800 (PST) From: Charles Perkins Reply-To: Charles Perkins Subject: (IPng 7240) Re: IPv6 mobility support To: ipng@sunroof.eng.sun.com, mobile-ip@smallworks.com Cc: "Alex A.M.R. Slingerland" MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8MNBi4PPr1Amg6CIIjrFnA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk With Alex's permission, I forward the following: ------------- Begin Forwarded Message ------------- Date: Wed, 24 Feb 1999 09:28:22 -0800 (PST) From: Charles Perkins Subject: Re: IPv6 mobility support To: "Alex A.M.R. Slingerland" ......... > 1. Section 10.5 of draft-ietf-mobileip-ipv6-0{67}.txt _suggests_ that a > MN, after changing primary care of address, _must_ send the first/next > BindingUpdate to its Home Agent (HA). Does the first paragraph of > Section 10.5 just say that the MN must inform the HA of the care of > address change, or that the MN must do so before informing any other > nodes? Would it reduce packet loss if the MN could first tell the old > Default Router of the new care of address (i.e. allow the MN to have > it's own policy)? This is a good point. I would agree that the MN could send a binding update to its old default router before sending the binding update to the Home Agent. This has never come up in the discussion before, and so as far as I know no one thought about it. > 2. (Section 10.10) Is MAX_UPDATE_RATE intended to limit the total rate > of Binding_Updates that leave a MN, or does it apply to the rate of > Binding_Updates to individual nodes/IP-addresses? > - If the former is the case (limit total rate), after sending the > BindingUpdate to the HA, the MN has to wait Max_Update_Rate (=1) seconds > before it can send another BindingUpdate, to any other node (e.g. its > old Default Router)? > - If the latter is the case (limit rate to individual nodes), the more > CN's a MN is communicating with, the higher the (aggregate) rate of > Binding_Updates after a care-of-address-update, correct? Would this > cause load spikes, even if the Binding_Updates are put in packets that > are destined for the CN anyway (perhaps the common case, if the MN's > communicating with a CN)? A good solution would be to define two update rates. The MAX_UPDATE_RATE for a correspondent node could be 1 second. I don't think it was ever the intention to restrict the total update rate to one per second. Indeed, I would even go further to say that the MAX_UPDATE_RATE should only apply to _empty_ packets. The update rate for Binding Update options that are inserted into normal data traffic might well be unrestricted, or perhaps instead restricted to a small percentage of the overall data volume. Regards, Charlie P. ......... > > Thanks for you time, > Alex. > -- > ___o___ > ___ | | | Alex Slingerland > / \ | | | University of Twente Tel. +31 53 489 4099 > | | | | Centre for Telematics and Information Technology > \___/ | | | P.O. Box 217 NL-7500 AE Enschede The Netherlands ------------- End Forwarded 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 Thu Feb 25 08:07:25 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA13463 for ipng-dist; Thu, 25 Feb 1999 07:59:51 -0800 (PST) Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13456 for ; Thu, 25 Feb 1999 07:59:41 -0800 (PST) From: Charles.Perkins@Eng Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id HAA15961 for ; Thu, 25 Feb 1999 07:59:40 -0800 (PST) Received: from neodymium.btinternet.com (neodymium.btinternet.com [194.73.73.83]) by earth.sun.com (8.9.1/8.9.1) with SMTP id HAA08616 for ; Thu, 25 Feb 1999 07:59:39 -0800 (PST) Received: from thss-barney.THSS-BARNEY [195.99.53.142] by neodymium.btinternet.com with esmtp (Exim 1.70 #1) id 10G3CT-0004hB-00; Thu, 25 Feb 1999 15:59:45 +0000 Received: from THSS-BARNEY by thss-barney.THSS-BARNEY with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id F3AG9MD4; Thu, 25 Feb 1999 16:00:13 -0000 Message-Id: Date: Thu, 25 Feb 1999 15:59:45 +0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From owner-ipng@sunroof.Eng.Sun.COM Thu Feb 25 15:41:27 1999 Received: from mailhub.btwebworld.com [193.113.211.246] by tantalum.btinternet.com with smtp (Exim 1.70 #1) id 10G2uk-000147-00; Thu, 25 Feb 1999 15:41:27 +0000 Received: from mail.btwebworld.com by mailhub.btwebworld.com (SMI-8.6/SMI-SVR4) id PAA03090; Thu, 25 Feb 1999 15:41:24 GMT Received: by mail.btwebworld.com (SMI-8.6/SMI-SVR4) id PAA01220; Thu, 25 Feb 1999 15:40:44 GMT Received: from mercury.Sun.COM by mail.btwebworld.com with SMTP (XT-PP); Thu, 25 Feb 1999 15:40:41 +0000 Received: from Eng.Sun.COM (engmail4 [129.144.134.6]) by mercury.Sun.COM (SMI-8.6/mail.byaddr) with SMTP id HAA21795; Thu, 25 Feb 1999 07:34:02 -0800 Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id HAA12348; Thu, 25 Feb 1999 07:33:57 -0800 (PST) Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id HAA13431 for ipng-dist; Thu, 25 Feb 1999 07:24:21 -0800 (PST) Received: from hsmpka.eng.sun.com (hsmpka [129.146.121.47] (may be forged)) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA13424 for ; Thu, 25 Feb 1999 07:24:11 -0800 (PST) Received: from finesse by hsmpka.eng.sun.com (SMI-8.6/SMI-SVR4) id HAA01625; Thu, 25 Feb 1999 07:24:09 -0800 Message-Id: <199902251524.HAA01625@hsmpka.eng.sun.com> Date: Thu, 25 Feb 1999 07:19:16 -0800 (PST) From: Charles Perkins Reply-To: Charles Perkins Subject: (IPng 7240) Re: IPv6 mobility support To: ipng@sunroof.Eng.Sun.COM, mobile-ip@smallworks.com Cc: "Alex A.M.R. Slingerland" MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8MNBi4PPr1Amg6CIIjrFnA== X-Mailer: dtmail 1.2.0 CDE Version 1.2 SunOS 5.6 sun4u sparc Sender: owner-ipng@sunroof.Eng.Sun.COM Precedence: bulk With Alex's permission, I forward the following: ------------- Begin Forwarded Message ------------- Date: Wed, 24 Feb 1999 09:28:22 -0800 (PST) From: Charles Perkins Subject: Re: IPv6 mobility support To: "Alex A.M.R. Slingerland" ......... > 1. Section 10.5 of draft-ietf-mobileip-ipv6-0{67}.txt _suggests_ that a > MN, after changing primary care of address, _must_ send the first/next > BindingUpdate to its Home Agent (HA). Does the first paragraph of > Section 10.5 just say that the MN must inform the HA of the care of > address change, or that the MN must do so before informing any other > nodes? Would it reduce packet loss if the MN could first tell the old > Default Router of the new care of address (i.e. allow the MN to have > it's own policy)? This is a good point. I would agree that the MN could send a binding update to its old default router before sending the binding update to the Home Agent. This has never come up in the discussion before, and so as far as I know no one thought about it. > 2. (Section 10.10) Is MAX_UPDATE_RATE intended to limit the total rate > of Binding_Updates that leave a MN, or does it apply to the rate of > Binding_Updates to individual nodes/IP-addresses? > - If the former is the case (limit total rate), after sending the > BindingUpdate to the HA, the MN has to wait Max_Update_Rate (=1) seconds > before it can send another BindingUpdate, to any other node (e.g. its > old Default Router)? > - If the latter is the case (limit rate to individual nodes), the more > CN's a MN is communicating with, the higher the (aggregate) rate of > Binding_Updates after a care-of-address-update, correct? Would this > cause load spikes, even if the Binding_Updates are put in packets that > are destined for the CN anyway (perhaps the common case, if the MN's > communicating with a CN)? A good solution would be to define two update rates. The MAX_UPDATE_RATE for a correspondent node could be 1 second. I don't think it was ever the intention to restrict the total update rate to one per second. Indeed, I would even go further to say that the MAX_UPDATE_RATE should only apply to _empty_ packets. The update rate for Binding Update options that are inserted into normal data traffic might well be unrestricted, or perhaps instead restricted to a small percentage of the overall data volume. Regards, Charlie P. ......... > > Thanks for you time, > Alex. > -- > ___o___ > ___ | | | Alex Slingerland > / \ | | | University of Twente Tel. +31 53 489 4099 > | | | | Centre for Telematics and Information Technology > \___/ | | | P.O. Box 217 NL-7500 AE Enschede The Netherlands ------------- End Forwarded 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Feb 25 12:47:21 1999 Received: by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) id MAA13870 for ipng-dist; Thu, 25 Feb 1999 12:28:51 -0800 (PST) Received: from Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13863 for ; Thu, 25 Feb 1999 12:28:42 -0800 (PST) Received: from earth.sun.com (earth.EBay.Sun.COM [129.150.69.3]) by Eng.Sun.COM (8.8.8+Sun/SMI-5.3) with ESMTP id MAA12838 for ; Thu, 25 Feb 1999 12:28:38 -0800 (PST) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by earth.sun.com (8.9.1/8.9.1) with ESMTP id MAA23260 for ; Thu, 25 Feb 1999 12:28:40 -0800 (PST) Received: by mail2.microsoft.com with Internet Mail Service (5.5.2524.0) id ; Thu, 25 Feb 1999 12:28:36 -0800 Message-ID: <4D0A23B3F74DD111ACCD00805F31D8100AF81DE2@RED-MSG-50> From: Richard Draves To: "'Mobile IP'" , "'IPsec'" , "'IPng List'" Cc: "'Stephen Kent'" Subject: (IPng 7241) Re: Last Call: Mobility Support in IPv6 to Propos ed Standard Date: Thu, 25 Feb 1999 12:28:29 -0800 X-Mailer: Internet Mail Service (5.5.2524.0) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Kent and I have talked this over off-line and come to agreement. (Actually, I think we were already in agreement, we just weren't communicating effectively via email.) We agree on the following two points: 1. A node will only process an ESP or AH header if it is participating in the relevant security association. In particular, a node processing a routing header will not "snoop" into ESP & AH headers that are not associated with the node. For example, node A receives a packet IPv6 hdr - src X, dst A ESP tunnel-mode assoc X -> A IPv6 hdr - src X, dst A Routing hdr - segs left = 1, B Transport hdr In this case node A WILL process the ESP header. IPv6 hdr - src X, dst A Routing hdr - segs left = 1, B ESP transport-mode assoc X -> B Transport hdr In this case node A will NOT process the ESP header. 2. In any case, an IPsec-enabled node that is processing a routing header (with segs left != 0) and hence forwarding a packet must perform inbound and outbound security policy checks. The IPsec processing in this situation is the same as the IPsec processing performed by a security gateway that is forwarding a packet not destined for itself. Thanks, Rich -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------