From owner-ipng@sunroof.eng.sun.com Fri Mar 1 00:43:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g218hPKL015854 for ; Fri, 1 Mar 2002 00:43:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g218hPmM015853 for ipng-dist; Fri, 1 Mar 2002 00:43:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g218hMKL015846 for ; Fri, 1 Mar 2002 00:43:22 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA26642 for ; Fri, 1 Mar 2002 00:43:21 -0800 (PST) From: juha.wiljakka@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA05161 for ; Fri, 1 Mar 2002 01:43:20 -0700 (MST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g218gk307424 for ; Fri, 1 Mar 2002 10:42:46 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 10:43:19 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Mar 2002 10:43:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Date: Fri, 1 Mar 2002 10:43:18 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F78568D@esebe005.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Thread-Index: AcHAZ4S29NY5c7xpTAaQvKrmko0CKQAlNk/w To: Cc: X-OriginalArrivalTime: 01 Mar 2002 08:43:18.0918 (UTC) FILETIME=[22FA6A60:01C1C0FD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g218hMKL015847 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Margaret! Informational RFC is fine for us (this was discussed in SLC meeting). We are happy that our document can be used as an input for a "general IPv6 node requirements" document that will be written in the (near) future. Cheers, -Juha W.- -----Original Message----- From: ext Margaret Wasserman [mailto:mrw@windriver.com] Sent: 28 February, 2002 16:53 What type of last call are you proposing? Do you think that this document should become an informational RFC? Or do you think it should be on the standards track? It was my impression that we (the WG) were hoping to move towards a more general "node requirements" document, using this document as (one of) the input(s). Margaret At 07:28 AM 2/28/02 , juha.wiljakka@nokia.com wrote: > Hi! > >We "cellular host IPv6" draft authors believe that our draft > >http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellular-host-00.txt > >would be ready for wg last call. > >Bob and Steve, if there are no objections from the WG, >could you please consider announcing last call for this draft? > >Thank You. > >On behalf of all the authors, > Juha Wiljakka >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Fri Mar 1 04:03:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g21C3eKL016537 for ; Fri, 1 Mar 2002 04:03:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21C3egN016536 for ipng-dist; Fri, 1 Mar 2002 04:03:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g21C3aKL016529 for ; Fri, 1 Mar 2002 04:03:36 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01416 for ; Fri, 1 Mar 2002 04:03:36 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03712 for ; Fri, 1 Mar 2002 05:03:35 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13201; Fri, 1 Mar 2002 07:03:32 -0500 (EST) Message-Id: <200203011203.HAA13201@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-06.txt Date: Fri, 01 Mar 2002 07:03:31 -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 IP Version 6 Working Group Working Group of the IETF. Title : Advanced Sockets API for IPv6 Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei Filename : draft-ietf-ipngwg-rfc2292bis-06.txt Pages : 80 Date : 28-Feb-02 A separate specification [RFC-2553] contain changes to the sockets API to support IP version 6. Those changes are for TCP and UDP-based applications. This document defines some of the 'advanced' features of the sockets API that are required for applications to take advantage of additional features of IPv6. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-rfc2292bis-06.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-rfc2292bis-06.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: <20020228134558.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2292bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020228134558.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 Fri Mar 1 04:15:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g21CFvKL016585 for ; Fri, 1 Mar 2002 04:15:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21CFva8016584 for ipng-dist; Fri, 1 Mar 2002 04:15:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g21CFsKL016577 for ; Fri, 1 Mar 2002 04:15:54 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA16476 for ; Fri, 1 Mar 2002 04:15:49 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18507 for ; Fri, 1 Mar 2002 05:15:48 -0700 (MST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g21CFvZ25060 for ; Fri, 1 Mar 2002 14:15:57 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 1 Mar 2002 14:15:47 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 1 Mar 2002 14:15:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Date: Fri, 1 Mar 2002 14:15:46 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AB6@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Thread-Index: AcHAZ4S29NY5c7xpTAaQvKrmko0CKQAlNk/wAAeUNWA= To: , Cc: X-OriginalArrivalTime: 01 Mar 2002 12:15:47.0098 (UTC) FILETIME=[D17C4FA0:01C1C11A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g21CFsKL016578 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > Informational RFC is fine for us (this was discussed in SLC meeting). > > We are happy that our document can be used as an input for a > "general IPv6 node requirements" document that will be > written in the (near) future. I think we discussed that possibility with the WG chairs, and that seemed to be an acceptable way forward. I think that most of the authors (I for one) would be happy to contribute to the general node requirements. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 1 04:47:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g21ClOKL016705 for ; Fri, 1 Mar 2002 04:47:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21ClO4w016704 for ipng-dist; Fri, 1 Mar 2002 04:47:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g21ClLKL016697 for ; Fri, 1 Mar 2002 04:47:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA06183 for ; Fri, 1 Mar 2002 04:47:21 -0800 (PST) From: francis.arts@alcatel.be Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA05619 for ; Fri, 1 Mar 2002 05:47:20 -0700 (MST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g21Cl9r20941; Fri, 1 Mar 2002 13:47:09 +0100 (MET) To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 3056 MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Fri, 1 Mar 2002 13:47:06 +0100 X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/01/2002 13:47:09, Serialize complete at 03/01/2002 13:47:09 Content-Type: multipart/alternative; boundary="=_alternative 00463ADEC1256B6F_=" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 00463ADEC1256B6F_= Content-Type: text/plain; charset="us-ascii" Hi Pekka, > Well, if no such thing is created, I think that's an implementation issue. > Anyway, RFC3056 is more of a ngtrans than ipng. I don't see why you > couldn't create an entry for automatic tunnels, the only thing to watch > out for is that tunnelConfigRemoteAddress is zero. This seems a nice trick. So basically what you are suggesting, is to create **1** entry in the tunnelConfigTable that serves **all** tunnels (to all 6to4 relay routers and/or 6to4 routers)? Francis. ================= Pekka Savola 01/03/2002 08:17 To: Francis ARTS/BE/ALCATEL@ALCATEL cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 3056 On Fri, 1 Mar 2002 francis.arts@alcatel.be wrote: > Thanks for your replies. I do have 1 question with respect to the > pseudo-interfaces. For **configured** tunnels the ifIndex for the > corresponding pseudo interface is created as a by-product of row > creation in the tunnelConfigTable (RFC 2667). However, for automatic > tunnels no row is created in the tunnelConfigTable. But what is then the > trigger to create an ifIndex for a pseudo interface for an **automatic** > tunnel? > > Thanks for any clarifications you can provide. Well, if no such thing is created, I think that's an implementation issue. Anyway, RFC3056 is more of a ngtrans than ipng. I don't see why you couldn't create an entry for automatic tunnels, the only thing to watch out for is that tunnelConfigRemoteAddress is zero. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- --=_alternative 00463ADEC1256B6F_= Content-Type: text/html; charset="us-ascii"
Hi Pekka,

> Well, if no such thing is created, I think that's an implementation issue.  
> Anyway, RFC3056 is more of a ngtrans than ipng.  I don't see why you
> couldn't create an entry for automatic tunnels, the only thing to watch
> out for is that tunnelConfigRemoteAddress is zero.
This seems a nice trick. So basically what you are suggesting, is to create **1** entry in the tunnelConfigTable that serves **all** tunnels (to all 6to4 relay routers and/or 6to4 routers)?

        Francis.

=================



Pekka Savola <pekkas@netcore.fi>

01/03/2002 08:17

       
        To:        Francis ARTS/BE/ALCATEL@ALCATEL
        cc:        ipng@sunroof.eng.sun.com
        Subject:        Re: RFC 3056  



On Fri, 1 Mar 2002 francis.arts@alcatel.be wrote:
> Thanks for your replies. I do have 1 question with respect to the
> pseudo-interfaces. For **configured** tunnels the ifIndex for the
> corresponding pseudo interface is created as a by-product of row
> creation in the tunnelConfigTable (RFC 2667). However, for automatic
> tunnels no row is created in the tunnelConfigTable. But what is then the
> trigger to create an ifIndex for a pseudo interface for an **automatic**
> tunnel?
>
> Thanks for any clarifications you can provide.

Well, if no such thing is created, I think that's an implementation issue.  
Anyway, RFC3056 is more of a ngtrans than ipng.  I don't see why you
couldn't create an entry for automatic tunnels, the only thing to watch
out for is that tunnelConfigRemoteAddress is zero.

--
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

--=_alternative 00463ADEC1256B6F_=-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 1 06:31:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g21EVOKL016799 for ; Fri, 1 Mar 2002 06:31:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g21EVN1D016798 for ipng-dist; Fri, 1 Mar 2002 06:31:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g21EVKKL016791 for ; Fri, 1 Mar 2002 06:31:20 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA10408 for ; Fri, 1 Mar 2002 06:31:22 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02928 for ; Fri, 1 Mar 2002 06:31:20 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g21EVCI11859; Fri, 1 Mar 2002 16:31:12 +0200 Date: Fri, 1 Mar 2002 16:31:11 +0200 (EET) From: Pekka Savola To: francis.arts@alcatel.be cc: ipng@sunroof.eng.sun.com Subject: Re: RFC 3056 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Mar 2002 francis.arts@alcatel.be wrote: > > Well, if no such thing is created, I think that's an implementation > issue. > > Anyway, RFC3056 is more of a ngtrans than ipng. I don't see why you > > couldn't create an entry for automatic tunnels, the only thing to watch > > out for is that tunnelConfigRemoteAddress is zero. > > This seems a nice trick. So basically what you are suggesting, is to > create **1** entry in the tunnelConfigTable that serves **all** tunnels > (to all 6to4 relay routers and/or 6to4 routers)? Yes, because that's what the link is: it never any explicit destinatination; anything within 2002::/16 will do. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 2 02:44:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g22AifKL018190 for ; Sat, 2 Mar 2002 02:44:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g22AieEK018189 for ipng-dist; Sat, 2 Mar 2002 02:44:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g22AibKL018182 for ; Sat, 2 Mar 2002 02:44:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13164 for ; Sat, 2 Mar 2002 02:44:37 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA22703 for ; Sat, 2 Mar 2002 03:44:36 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g22AiGq26255; Sat, 2 Mar 2002 12:44:17 +0200 Date: Sat, 2 Mar 2002 12:44:16 +0200 (EET) From: Pekka Savola To: tiny@tahi.org cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt In-Reply-To: <200203011204.HAA13764@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 1 Mar 2002 Internet-Drafts@ietf.org wrote: > Title : Minimum Requirement of IPv6 for Low Cost Network > Appliance > Author(s) : N. OKABE et al. > Filename : draft-okabe-ipv6-lcna-minreq-01.txt > Pages : 20 > Date : 28-Feb-02 A few comments in addition to ones I sent for -00.. Table 1. Resource restrictions of LCNA ===============+===============+==================+======= Memory CPU Performance OS ===============+===============+==================+======= PC >64MB Pentium/64bits Windows ---------------+---------------+------------------+------- PDA 2-8MB RISC/32bits(50MHz) WinCE VxWorks PalmOS ==> I think it'd be policitally correct to _at least_ change 'Windows' there to 'Any', and possibly add 'Others' to PDA section (e.g. I like Linux and NetBSD on PDA's :-). 2.7 Security In Section 4 "Security for LCNA", we will regulate a baseline for guaranteeing that a minimum host can communicate securely. However, Denial of Service (DoS) and intrusion are out of scope. So, we have to consider defending from DoS and/or intrusion in another place. Also, the authentication of users is out of scope, because some minimum hosts can omit a mechanism of user accounts. ==> intrusion out of scope? What do you mean by that? Auth? 2.8 Mobility support In this draft, we do not assume that LCNA itself moves on the network, but the processing from other nodes that operate as Mobile Nodes of Mobile IPv6 is mandatory. ==> I don't see why you force mobility but neglect security. - When it can recognize the extension header but does not support the options in it, it MUST perform error processing according to the option number. ==> you mean s/extension header/destination options header/? There is no processing defined by option number for extension headers. [Receiving] A minimum host SHOULD recognize it as a Hop-by-Hop Options Header, and perform the processing according to the option and option number in it. Because this option is used for signaling and router alert, in order to control routers on the path, all nodes on the transmission path have to interpret this header but do not need to interpret all options in it. ==> I don't understand your reasoning for router alert; LCNA's aren't routers by definition :-) 3.1.2 Routing Header [Sending] Following 3.1, minimum hosts do not send packets with this extension header. [Receiving] RFC regulates that if the Segment Left field has non-zero value in this header, the node has to forward the packet to the next intermediate node, even when the node is a host. But in the case of a minimum host, this forwarding MAY be omitted and be treated as an unsupported extension header, because only intermediate nodes (such as routers) and the destination node have to interpret this header. ==> please see draft-savola-ipv6-rh-hosts-00.txt One exception is when the minimum host supports the mobile node function of Mobile IPv6. As Mobile IPv6 uses a Routing header for receiving packets destined to Mobile Node, this header MUST be processed correctly. Another exception for sending this header is when using route optimization for communicating with Mobile IPv6 mobility agents. If route optimization is performed using binding update, the node MUST send packets with these extension headers. ==> mobile-ip wg chairs just decided that the consensus was to define a new routing header type for MIPv6, so LCNA's might only need to process type 2 RH's. 3.1.3 Fragment Header If a minimum host satisfies the following conditions, the host MAY not send this extension header, and MAY treat one as an unsupported header when receiving it. ==> I'm not sure what the robustness principle would say about hosts that cannot defragment. 3.1.4 Destination Options Header A minimum host SHOULD recognize this header as Destination Options Header and perform processing according to the options and option numbers in it. One exception is the handling of Home address destination option for Mobile IPv6. As mentioned in section 2.8, even if LCNA itself does not move, it has to process the packets sent from other mobile nodes. Therefore, the processing of Home address option becomes mandatory. However, since final specification of Mobile IPv6 is not regulated yet, we omit the concrete regulation for LCNA now. ==> one does not need to interpret HAO if one wants to communicate with mobile node: then all the traffic would just have to go through the Home Agent. In LCNA case, Home Agent would probably most often be in the home network, so nothing would be lost.. 3.3 Neighbor Discovery for IP Version 6 (IPv6) (RFC2461) [22] In this draft, we assume that an LCNA has only one network Interface, but it does not inhibit multiple interfaces. When an LCNA is assumed to have multiple interfaces, the following considerations are necessary, which requires more resources. - Source address selection ==> even with one interface, the LCNA has multiple addresses, so it obviously still needs source address selection (consider e.g. the case with link-local, site-local, 6to4 address, and native address). It may not necessarily need to be as complex though. 3.5 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (RFC2463) [24] On minimum hosts, ICMP used only by a router MAY be omitted (Table 2). ICMPs for Echo Request/Reply and minimum error reporting MUST be supported. ==> this MUST includes rate-limiting of error replies, I hope? Table 2. Mandatory ICMP messages for LCNA ===============+===============================+========== Type Code Necessary? ===============+===============================+========== 1: 0: No route to destination No Destination 1: Administratively Prohibited No Unreachable 3: Address unreachable No Message 4: port unreachable Yes ==> depending on how MIPv6 goes, some of these (e.g. admin prohibit) might become necessary too. 3.7 DNS Extensions to support IP version 6 (RFC1886) [26] and IPv6 Stateless DNS Discovery (draft-ietf-ipngwg-dns-discovery-02.txt) [27] The only function that is not supported in the current IPv6 autoconfiguration is automatic discovery of DNS server. On this topic discussions are ongoing in IETF IPNG WG. If a standard is fixed, it might become a mandatory item for minimum hosts. AAAA record is defined for transform from IPv6 name to IPv6 address. So, AAAA is currently mandatory for minimum host name resolution. Also, A6 record is currently proposed and discussed in IETF for an alternative of AAAA record. We need to check the progress. ==> What about reverse lookups? nibble-style, probably? ip6.int or ip6.arpa, or both? 4.2 Security mechanism for LCNA For example, IPsec realizes security on the IP layer, which is transparent from the transport and/or application layer, so it can be a generic solution. On the other hand, IPsec does not work well with IP layer translation technology (such as NAT and IPv4/IPv6 translator), which might be a restriction for the promotion of LCNAs. ==> I disagree with the latter: IMO it's ok to assume that people who want to connect remotely (when security is a MUST) to LCNA would use native IPv6. 4.3 Minimum security specification for LCNA ==> basically you seem to be saying it's okay to omit security (meaning encryption) if LCNA is so underpowered it can't handle it. I disagree. Put a better chip on it or say something to the effect 'If proper[??] encryption and security is not implemented, the node MUST NOT have a global address'. 6.2 Management facilities for LCNAs ==> personally I think being able to remotely monitor the status of the system is a rather necessary feature. 7. Security Consideration As mentioned in 2.7, DOS and intrusion are out of the scope of this draft. ==> you cannot specify requirements while leaving these features out of scope. 10 Appendix: Example of IPSEC minimum requirements specification [...] We believe that IPsec is an effective technology in order to guarantee security of communication. That is the reason why we regulate the minimum IPsec specification in this draft. ==> this needs editing as the last sentence is obviously false. * Even though we regulate minimum IPsec as mandatory, no one uses it because there are no prospects to deploy it in the real world. Therefore, it is WRONG to regulate the IPsec minimum specification as mandatory. ==> FUD. IPsec works fine in closed environment (which is what LCNA would be used in): it's trivial to perform manual keying for all of your systems (e.g. two computers and a few LCNA's), or use something like IKE in a restricted domain. Strangers accessing LCNA using IPsec is the problem you're referring to, but they shouldn't access it anyway. :-) (I didn't read the rest of the ipsec appendix). HTH, -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 3 02:16:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g23AGPKL019350 for ; Sun, 3 Mar 2002 02:16:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g23AGPKW019349 for ipng-dist; Sun, 3 Mar 2002 02:16:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g23AGMKL019342 for ; Sun, 3 Mar 2002 02:16:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04418 for ; Sun, 3 Mar 2002 02:16:23 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15285 for ; Sun, 3 Mar 2002 02:16:17 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g23AGCZc025793 for ; Sun, 3 Mar 2002 11:16:12 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sun Mar 03 11:16:12 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Sun, 3 Mar 2002 11:16:11 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA4F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Margaret Wasserman'" , juha.wiljakka@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Date: Sun, 3 Mar 2002 11:16:09 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, I don't know if someone already answered this, but I believe the agreement in SLC was to progress the cellular host draft independantly, mainly because of the very close 3GPP deadline. Cheers, Hesham > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Thursday, February 28, 2002 3:53 PM > To: juha.wiljakka@nokia.com > Cc: ipng@sunroof.eng.sun.com > Subject: Re: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? > > > > Hi Juha, > > What type of last call are you proposing? Do you think that this > document should become an informational RFC? Or do you think it > should be on the standards track? > > It was my impression that we (the WG) were hoping to move > towards a more general "node requirements" document, using this > document as (one of) the input(s). > > Margaret > > > At 07:28 AM 2/28/02 , juha.wiljakka@nokia.com wrote: > > > Hi! > > > >We "cellular host IPv6" draft authors believe that our draft > > > >http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellula r-host-00.txt > >would be ready for wg last call. > >Bob and Steve, if there are no objections from the WG, >could you please consider announcing last call for this draft? > >Thank You. > >On behalf of all the authors, > Juha Wiljakka >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Sun Mar 3 08:10:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g23GAGKL019880 for ; Sun, 3 Mar 2002 08:10:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g23GAGvP019879 for ipng-dist; Sun, 3 Mar 2002 08:10:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g23GACKL019872 for ; Sun, 3 Mar 2002 08:10:12 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02884 for ; Sun, 3 Mar 2002 08:10:12 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14977 for ; Sun, 3 Mar 2002 09:10:12 -0700 (MST) Received: from kenawang ([192.168.1.62]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA20579; Sun, 3 Mar 2002 08:09:36 -0800 (PST) Message-Id: <4.2.2.20020303105000.020a1a70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 03 Mar 2002 11:10:41 -0500 To: "Hesham Soliman (ERA)" From: Margaret Wasserman Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Cc: juha.wiljakka@nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AA4F@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I do think that this document includes interesting and useful information about the perspective of cellular handset vendors, and the technical requirements and issues for cellular handsets. Within the IETF, therefore, it might be useful to publish this document as an Informational RFC. However, I am concerned about how outside groups (specifically the 3GPP) will interpret publishing this document, even as an Informational RFC. Hesham's comment illustrates my concern... >I don't know if someone already answered this, >but I believe the agreement in SLC was to progress >the cellular host draft independantly, mainly because >of the very close 3GPP deadline. How are we expecting the 3GPP to use this document? Why is it needed for a 3GPP deadline? Will outside groups believe that this document represents a consensus of the IPv6 WG regarding what the minimal requirements actually are for an IPv6 cellular host? If so, I don't think that we should publish this document without a more significant discussion within the WG. It is not my impression that the WG has reached consensus on some of the issues raised in this document, specifically: - Forbidding the use of DAD on some links - Situation where IP Security should be optional/disabled (and the who distinction between "Core IP" and "IP Security") - Making ND optional on point-to-point links - Making IPv6 autoconfiguration optional on hosts (rather than mandatory on hosts and turned on/off for the link in router advertisements) Also, some of the comments in this document might best be handled as "applicability" portions of other documents (i.e. use of 6to4 over a cellular link), rather than as specific requirements for a class of hosts. I do think that the WG will need to do some work on defining the official contents of IPv6, including the minimal requirements for IPv6 nodes (or hosts and routers), but this will probably require a considerable effort, and a good deal of negotiation within the WG and with the IESG. I am concerned that we may bypass this effort, to our later detriment, by publishing a document now that is mistakenly interpretted as a standards-track host requirements document by outside groups. Does anyone else share this concern? What are our options to ensure that this doesn't happen? Margaret At 05:16 AM 3/3/02 , Hesham Soliman (ERA) wrote: >Margaret, > >I don't know if someone already answered this, >but I believe the agreement in SLC was to progress >the cellular host draft independantly, mainly because >of the very close 3GPP deadline. > >Cheers, >Hesham > > > > -----Original Message----- > > From: Margaret Wasserman [mailto:mrw@windriver.com] > > Sent: Thursday, February 28, 2002 3:53 PM > > To: juha.wiljakka@nokia.com > > Cc: ipng@sunroof.eng.sun.com > > Subject: Re: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? > > > > > > > > Hi Juha, > > > > What type of last call are you proposing? Do you think that this > > document should become an informational RFC? Or do you think it > > should be on the standards track? > > > > It was my impression that we (the WG) were hoping to move > > towards a more general "node requirements" document, using this > > document as (one of) the input(s). > > > > Margaret > > > > > > At 07:28 AM 2/28/02 , juha.wiljakka@nokia.com wrote: > > > > > Hi! > > > > > >We "cellular host IPv6" draft authors believe that our draft > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellula >r-host-00.txt > > > >would be ready for wg last call. > > > >Bob and Steve, if there are no objections from the WG, > >could you please consider announcing last call for this draft? > > > >Thank You. > > > >On behalf of all the authors, > > Juha Wiljakka > >-------------------------------------------------------------------- > >IETF IPng Working Group Mailing List > >IPng Home 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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 3 20:01:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2441RKL020849 for ; Sun, 3 Mar 2002 20:01:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2441RnU020848 for ipng-dist; Sun, 3 Mar 2002 20:01:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2441OKL020841 for ; Sun, 3 Mar 2002 20:01:24 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA14800 for ; Sun, 3 Mar 2002 20:01:25 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA00991 for ; Sun, 3 Mar 2002 21:01:24 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2441NB08918 for ; Mon, 4 Mar 2002 05:01:23 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Mar 04 05:01:20 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 04:51:35 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA59@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Margaret Wasserman'" Cc: juha.wiljakka@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Date: Mon, 4 Mar 2002 04:57:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, Thanks for the comments, I've been a bit concerned about the lack of interest/comments so far. I didn't think that we did a perfect job :) My comments below. BTW, these are comments/questions for all, hopefully we can get more feedback. > I do think that this document includes interesting and useful > information about the perspective of cellular handset vendors, > and the technical requirements and issues for cellular handsets. > Within the IETF, therefore, it might be useful to publish this > document as an Informational RFC. => OK. > >I don't know if someone already answered this, > >but I believe the agreement in SLC was to progress > >the cellular host draft independantly, mainly because > >of the very close 3GPP deadline. > > How are we expecting the 3GPP to use this document? Why is > it needed for a 3GPP deadline? => Because they would use it as a reference for UMTS handsets implementors. > > Will outside groups believe that this document represents a > consensus of the IPv6 WG regarding what the minimal requirements > actually are for an IPv6 cellular host? => Yes. If so, I don't think that > we should publish this document without a more significant > discussion > within the WG. => Then let's begin the discussions. The only reason for standardising the draft in the IPv6 WG was to make sure that we're doing the right thing. Otherwise an informational RFC wouldn't have to go through the IPv6 WG or could have been replaced by a 3GPP spec. But since the competence is here, it is crucial that we get feedback. > It is not my impression that the WG has reached consensus on some > of the issues raised in this document, specifically: > > - Forbidding the use of DAD on some links => DAD is not needed if address duplication is not possible. Since each terminal gets a unique /64 (as per the advice draft), and since all terminals are on p2p links, DAD would be a waste of BW. But please have a closer look and let us know if something was missed. > - Situation where IP Security should be optional/disabled > (and the who distinction between "Core IP" and > "IP Security") => The distinction between IP security and core IP is merely an editorial distinciton. For example you can see that in 'core IP' we list all the IPv6 WG RFCs. As to whether IP security (I assume you mean IPsec) should be mandated or not, we can discuss that. But some questions that we would need to answer: - By 'mandated' do we mean implementation or use? - What should be mandated? - Why should it be mandated? > - Making ND optional on point-to-point links => RFC 2461 MUST be implemented, the exceptions are things like the Link layer suboption which is not relevant for these links. Did we miss something else? > - Making IPv6 autoconfiguration optional on hosts (rather > than mandatory on hosts and turned on/off for the > link in router advertisements) => You mean 2462 shoud be a SHOULD/MUST? That's possible for the generic cellular case, but for 3GPP, since there is a separate 'autoconfig' mechanism, this RFC is not needed. Would a SHOULD/MUST for the general case, and a 'not needed' for 3GPP be staisfactory? > Also, some of the comments in this document might best be handled > as "applicability" portions of other documents (i.e. use of 6to4 > over a cellular link), rather than as specific requirements for > a class of hosts. > > I do think that the WG will need to do some work on defining the > official contents of IPv6, including the minimal requirements for > IPv6 nodes (or hosts and routers), but this will probably require > a considerable effort, and a good deal of negotiation within the > WG and with the IESG. > > I am concerned that we may bypass this effort, to our later > detriment, > by publishing a document now that is mistakenly interpretted as a > standards-track host requirements document by outside groups. > > Does anyone else share this concern? What are our options to > ensure that this doesn't happen? > => I think you're making valid points and, as I said, our intention (since the London meeting) was to try to get as much feedback as possible. Very few comments were made, I assumed due to lack of interest/time. But, since the draft has been out for a long time now, it would be good to get these comments ASAP. Rushing the draft to become RFC is not good, but delaying it for too long can be just as detrimental to deployment. I hope more WG members would comment on this. Cheers, Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 3 23:09:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24795KL021108 for ; Sun, 3 Mar 2002 23:09:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24795fA021107 for ipng-dist; Sun, 3 Mar 2002 23:09:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24792KL021100 for ; Sun, 3 Mar 2002 23:09:02 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04870 for ; Sun, 3 Mar 2002 23:09:03 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA05172 for ; Sun, 3 Mar 2002 23:08:57 -0800 (PST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g24795Z15457 for ; Mon, 4 Mar 2002 09:09:05 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Mar 2002 09:08:55 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Mar 2002 09:08:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Date: Mon, 4 Mar 2002 09:08:55 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D4D@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Thread-Index: AcHCzi/zcr6SYqEFSFmVrobbyvExkQAe40Tg To: , Cc: , X-OriginalArrivalTime: 04 Mar 2002 07:08:56.0037 (UTC) FILETIME=[72E09950:01C1C34B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g24792KL021101 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > I do think that this document includes interesting and useful > information about the perspective of cellular handset vendors, > and the technical requirements and issues for cellular handsets. > Within the IETF, therefore, it might be useful to publish this > document as an Informational RFC. Agreed. > However, I am concerned about how outside groups (specifically > the 3GPP) will interpret publishing this document, even as an > Informational RFC. I think that we can discuss if we need to add any clarifying text here. It could be as simple as this document is informational and should not override any standards documents. Please note that many of the authors of the document are also involved in the 3GPP standardization process. > How are we expecting the 3GPP to use this document? Why is > it needed for a 3GPP deadline? Release 5, as you know, is using IPv6 for the IMN subsystem. The Mobile Node, therefore, needs to have IPv6 in order to access content from IMN. 3GPP specifications have a March deadline. Our document is meant to enable interoperability between networks and cellular hosts. > Will outside groups believe that this document represents a > consensus of the IPv6 WG regarding what the minimal requirements > actually are for an IPv6 cellular host? If so, I don't think that > we should publish this document without a more significant discussion > within the WG. Discussion is always welcome. We have been asking for comment from the working group since London - and we have gotten some. In order to progress the work, the authors felt that the document is ready for last call. > It is not my impression that the WG has reached consensus on some > of the issues raised in this document, specifically: > > - Forbidding the use of DAD on some links > - Situation where IP Security should be optional/disabled > (and the who distinction between "Core IP" and > "IP Security") > - Making ND optional on point-to-point links > - Making IPv6 autoconfiguration optional on hosts (rather > than mandatory on hosts and turned on/off for the > link in router advertisements) > > Also, some of the comments in this document might best be handled > as "applicability" portions of other documents (i.e. use of 6to4 > over a cellular link), rather than as specific requirements for > a class of hosts. Put that way, I can see that the document does a bit more than just give requirements - it also discusses the applicability of some features of IPv6, that is true. > I do think that the WG will need to do some work on defining the > official contents of IPv6, including the minimal requirements for > IPv6 nodes (or hosts and routers), but this will probably require > a considerable effort, and a good deal of negotiation within the > WG and with the IESG. Agreed, we've been talking about this since London, and all of the authors have volunteered to help on this effort. I think a IPv6 Host Requirement document would be a very good thing. > I am concerned that we may bypass this effort, to our later detriment, > by publishing a document now that is mistakenly interpretted as a > standards-track host requirements document by outside groups. I don't share your doubts. I believe that we need this kind of document, as there will be IPv6 enabled phones being produced, probably this year. The networks are already being deployed. Should we not, then try to specify & give guidence on IPv6 - or should we do nothing? One of the prime goals of the document is to ensure that IPv6 works in these cellular networks & that the cellular hosts are good citizens on the net. I do agree that an IPv6 Host Requirements document is needed, and was probably needed last year. However, that should not prevent us from continuing work on this document. In summary, we welcome technical comments & discussion on the draft - we hoped that asking for a WG last call would stir up some comments. Additionally, we believe that a IPv6 Host Requirements document is needed & we are interested in participating. Finally, if some text is needed, in order to clarify that this document should not be taken as a basis for a general IPv6 host requirements document, we'd be happy to consider such a statement. best regards, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 3 23:41:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g247fDKL021148 for ; Sun, 3 Mar 2002 23:41:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g247fDO8021147 for ipng-dist; Sun, 3 Mar 2002 23:41:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g247f9KL021140 for ; Sun, 3 Mar 2002 23:41:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA22863 for ; Sun, 3 Mar 2002 23:41:09 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23525 for ; Mon, 4 Mar 2002 00:41:09 -0700 (MST) Received: from kenawang ([192.168.1.52]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id XAA23516; Sun, 3 Mar 2002 23:40:43 -0800 (PST) Message-Id: <4.2.2.20020304022057.020af950@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 04 Mar 2002 02:33:34 -0500 To: john.loughney@nokia.com From: Margaret Wasserman Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Cc: In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D4D@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John, > > However, I am concerned about how outside groups (specifically > > the 3GPP) will interpret publishing this document, even as an > > Informational RFC. > >I think that we can discuss if we need to add any clarifying text >here. It could be as simple as this document is informational >and should not override any standards documents. Please note >that many of the authors of the document are also involved in >the 3GPP standardization process. It is possible that some sort of clarifying text could alleviate some of my concerns. However, this document does seem (at least to me) to contradict some standards-based IPv6 documents. For instance, this document indicates that some features are optional that are listed as mandatory in other documents (IP Security, DAD, some types of ND processing, etc.). > > I do think that the WG will need to do some work on defining the > > official contents of IPv6, including the minimal requirements for > > IPv6 nodes (or hosts and routers), but this will probably require > > a considerable effort, and a good deal of negotiation within the > > WG and with the IESG. > >Agreed, we've been talking about this since London, and all of the >authors have volunteered to help on this effort. I think a IPv6 >Host Requirement document would be a very good thing. I mostly agree. I do have some concerns about defining the host requirements too early, before we have enough deployment experience with complete IPv6 implementations to make wise choices. This may be a chicken and egg issue, though -- how will we get "complete" IPv6 implementations before we define what that means? >I don't share your doubts. I believe that we need this kind of >document, as there will be IPv6 enabled phones being produced, >probably this year. The networks are already being deployed. >Should we not, then try to specify & give guidence on IPv6 - or >should we do nothing? I think that we should give guidance, and we have tried to do so in other documents. However, I think that we need to be careful not to give inconsistent or conflicting guidance. Specifically: - We should not publish guidance for cellular vendors that conflicts with our published standards. If the standards are wrong (or fail to take into account all of the cases), we should correct them. - The IPv6 WG may not be the correct group to provide guidance regarding transition mechanisms. I believe that the v6trans (or is it still ngtrans?) WG should be responsible for publish advice on the applicability of their mechanisms in different environments. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 3 23:49:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g247nlKL021170 for ; Sun, 3 Mar 2002 23:49:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g247nkmg021169 for ipng-dist; Sun, 3 Mar 2002 23:49:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g247niKL021162 for ; Sun, 3 Mar 2002 23:49:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA22334 for ; Sun, 3 Mar 2002 23:49:44 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA12770 for ; Mon, 4 Mar 2002 00:49:42 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g247noZ17555 for ; Mon, 4 Mar 2002 09:49:50 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Mar 2002 09:49:41 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Mar 2002 09:49:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Date: Mon, 4 Mar 2002 09:49:40 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AC6@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Thread-Index: AcHDT/MTOzPorvANQyWZLi36NLrwPAAACfrA To: Cc: X-OriginalArrivalTime: 04 Mar 2002 07:49:41.0068 (UTC) FILETIME=[243AB8C0:01C1C351] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g247niKL021163 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > >I think that we can discuss if we need to add any clarifying text > >here. It could be as simple as this document is informational > >and should not override any standards documents. Please note > >that many of the authors of the document are also involved in > >the 3GPP standardization process. > > It is possible that some sort of clarifying text could alleviate > some of my concerns. That's good - our intention has never been to put anything on general IPv6 hosts, but how to ensure they would work & work effectively when connecting to cellular networks. > However, this document does seem (at least to me) to contradict > some standards-based IPv6 documents. For instance, this document > indicates that some features are optional that are listed as > mandatory in other documents (IP Security, DAD, some types of ND > processing, etc.). Let's discuss them. The authors intended to help give clues to implementors about when these functions are useful & were not. Originally, the 3GPP addressing architecture was a bit different than what was in the specs, so we were trying to bring that information out - fortunately, that specific issue has changed. > I mostly agree. I do have some concerns about defining the host > requirements too early, before we have enough deployment experience > with complete IPv6 implementations to make wise choices. This may > be a chicken and egg issue, though -- how will we get "complete" IPv6 > implementations before we define what that means? Well, this is a chicken & egg scenario. There are IPv6 implementations, of course. Most are not complete according to all of the IPv6 standards. Without creating some sort of reference document, we run the risk of creating defacto standards which are contrary to the RFCs. > I think that we should give guidance, and we have tried to do so > in other documents. However, I think that we need to be careful > not to give inconsistent or conflicting guidance. Specifically: > > - We should not publish guidance for cellular vendors > that conflicts with our published standards. > If the standards are wrong (or fail to take > into account all of the cases), we should > correct them. Agreed. > - The IPv6 WG may not be the correct group to provide > guidance regarding transition mechanisms. I > believe that the v6trans (or is it still ngtrans?) > WG should be responsible for publish advice on > the applicability of their mechanisms in > different environments. Well, NGTRANS is discussing transition (from IPv4) to IPv6. In many cases, our document is specific to v6, with no coment on v4. PILC has been doing some related work, but that WG is getting ready to close down, and has been focusing their work higher up in the stack. What I think the authors want from folks in the IPv6 wg is a reality check that what we are saying is more-or-less OK & should not cause interop problems. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 00:01:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2481LKL021272 for ; Mon, 4 Mar 2002 00:01:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2481L69021271 for ipng-dist; Mon, 4 Mar 2002 00:01:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2481HKL021264 for ; Mon, 4 Mar 2002 00:01:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA23693 for ; Mon, 4 Mar 2002 00:01:16 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19482 for ; Mon, 4 Mar 2002 00:01:16 -0800 (PST) Received: from kenawang ([192.168.1.52]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id AAA29311; Mon, 4 Mar 2002 00:00:43 -0800 (PST) Message-Id: <4.2.2.20020304023354.020acc20@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 04 Mar 2002 02:57:47 -0500 To: "Hesham Soliman (ERA)" From: Margaret Wasserman Subject: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AA59@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Hesham, Thanks for the quick response. >=> Then let's begin the discussions. The only reason >for standardising the draft in the IPv6 WG was to make >sure that we're doing the right thing. Otherwise an >informational RFC wouldn't have to go through the >IPv6 WG or could have been replaced by a 3GPP spec. >But since the competence is here, it is crucial >that we get feedback. That sounds good. Let's begin the discussions... I'll send separate threads for each issue. > > It is not my impression that the WG has reached consensus on some > > of the issues raised in this document, specifically: > > > > - Forbidding the use of DAD on some links > >=> DAD is not needed if address duplication is not >possible. Since each terminal gets a unique >/64 (as per the advice draft), and since all terminals >are on p2p links, DAD would be a waste of BW. >But please have a closer look and let us know >if something was missed. Address duplication is possible on point-to-point links, because one end may choose an address that is already in use by the other end. I don't think that this is very likely, but it is possible. However, making DAD optional (and advising against the use of DAD) on point-to-point links, is in direct conflict with RFC 2462, which says: "Duplicate Address Detection MUST take place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration..." I don't think that we should publish an informational document that advises some implementors to do something that specifically disagrees with a MUST requirement in a standards-track document. If the standards-track document is broken, we need to fix it instead. [Please note that I actually think that we should be able to disable DAD for some link types. I made a proposal to that effect several years ago, but my arguments didn't win the day.] Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 00:16:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g248GhKL021385 for ; Mon, 4 Mar 2002 00:16:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g248GgxU021384 for ipng-dist; Mon, 4 Mar 2002 00:16:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g248GcKL021377 for ; Mon, 4 Mar 2002 00:16:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA11108 for ; Mon, 4 Mar 2002 00:16:38 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA04900 for ; Mon, 4 Mar 2002 01:16:38 -0700 (MST) Received: from kenawang ([192.168.1.52]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id AAA04761; Mon, 4 Mar 2002 00:16:14 -0800 (PST) Message-Id: <4.2.2.20020304025751.02121180@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 04 Mar 2002 03:17:04 -0500 To: "Hesham Soliman (ERA)" From: Margaret Wasserman Subject: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AA59@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk And the next issue, IP Security... > > - Situation where IP Security should be optional/disabled > > (and the whole distinction between "Core IP" and > > "IP Security") > >=> The distinction between IP security and core IP >is merely an editorial distinction. For example >you can see that in 'core IP' we list all the >IPv6 WG RFCs. Publishing a document that makes this distinction, however, will give the impression that IP Security (AKA IPSec) is not a _core_ part of IPv6. Some people may take that to mean that they can produce a complete IPv6 implementation that does not include IP Security. >As to whether IP security (I assume you mean IPsec) >should be mandated or not, we can discuss that. >But some questions that we would need to answer: > >- By 'mandated' do we mean implementation or use? >- What should be mandated? >- Why should it be mandated? RFC 2460 says: "A full implementation of IPv6 includes implementation of the following extension headers: Hop-by-Hop Options Routing (Type 0) Fragment Destination Options Authentication Encapsulating Security Payload The first four are specified in this document; the last two are specified in [RFC-2402] and [RFC-2406], respectively." So, a "full" implementation of IPv6 must include an implementation of the Authentication and ESP headers from RFCs 2402 and 2406. Obviously, it is possible for a host to implement RFCs 2402 and 2406, but to be configured such that no traffic is ever authenticated and/or encrypted. The draft-ietf-ipv6-cellular-host-00.txt document, however, seems to assume that there may be hosts that do not implement these headers. It says: " - AH and ESP headers: In the case of the Core IP functionality only, AH and ESP headers are treated as if the Security Association had not existed, i.e. - packets with these headers are dropped. When the IP Security functionality is in use, they are processed as specified in RFCs 2401, 2402, and 2406." I am not sure about the wording here, but this paragraph implies to me that cellular hosts that only implement the "Core IP" functionality may not actually implement AH or ESP processing. This conflicts directly with RFC 2460. Now, I don't actually live under a rock, so I do understand that most of today's IPv6 nodes don't actually implement IP Security. In the past, however, the IESG had mandated that IP Security would be a mandatory part of IPv6, and I don't believe that they've changed that statement. So, where do we go from here? No document can be published as an RFC without IESG approval, and I don't think that we'll get IESG approval for a document that says (or even strongly implies) that IP Security is optional in IPv6. Maybe our ADs could comment on this? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 00:27:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g248RnKL021451 for ; Mon, 4 Mar 2002 00:27:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g248RnLk021450 for ipng-dist; Mon, 4 Mar 2002 00:27:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g248RjKL021443 for ; Mon, 4 Mar 2002 00:27:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA28430 for ; Mon, 4 Mar 2002 00:27:45 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26406 for ; Mon, 4 Mar 2002 00:27:45 -0800 (PST) Received: from kenawang ([192.168.1.52]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id AAA07502; Mon, 4 Mar 2002 00:27:02 -0800 (PST) Message-Id: <4.2.2.20020304032347.020ac100@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 04 Mar 2002 03:28:06 -0500 To: "Hesham Soliman (ERA)" From: Margaret Wasserman Subject: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Cc: juha.wiljakka@nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AA59@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk And the last issue that I raised in my message: > > - Making IPv6 autoconfiguration optional on hosts (rather > > than mandatory on hosts and turned on/off for the > > link in router advertisements) > >=> You mean 2462 shoud be a SHOULD/MUST? >That's possible for the generic cellular case, but for 3GPP, >since there is a separate 'autoconfig' mechanism, >this RFC is not needed. Would a SHOULD/MUST for the >general case, and a 'not needed' for 3GPP >be satisfactory? My understanding is that the 3GPP group is actually migrating towards a more standard IPv6 configuration mechanism, using router advertisements and allowing hosts to generate their own interface IDs. Currently the cellular hosts draft says: "IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be supported." However, I think that RFC 2462 should be a MUST for all IPv6 nodes. There are probably other technical issues in the current draft that should be discussed, I've just listed what I consider to be the most pressing issues. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 00:27:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g248RXKL021441 for ; Mon, 4 Mar 2002 00:27:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g248RXL9021440 for ipng-dist; Mon, 4 Mar 2002 00:27:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g248RTKL021433 for ; Mon, 4 Mar 2002 00:27:29 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA28382 for ; Mon, 4 Mar 2002 00:27:26 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28174 for ; Mon, 4 Mar 2002 00:27:25 -0800 (PST) Received: from kenawang ([192.168.1.52]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id AAA07481; Mon, 4 Mar 2002 00:26:57 -0800 (PST) Message-Id: <4.2.2.20020304031935.02128260@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 04 Mar 2002 03:23:35 -0500 To: "Hesham Soliman (ERA)" From: Margaret Wasserman Subject: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AA59@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk And another issue: > > - Making ND optional on point-to-point links > >=> RFC 2461 MUST be implemented, the exceptions are >things like the Link layer suboption which is not >relevant for these links. Did we miss something else? The cellular hosts document says: "Therefore, Neighbor Solicitation and Advertisement messages MAY be implemented for the cellular interface." However, these messages are mandatory in RFCs 2461 and 2462, both for DAD and for the basic neighbor discovery mechanism, which needs to be used to establish two-way connectivity before other messages are exchanged. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 00:47:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g248lvKL021490 for ; Mon, 4 Mar 2002 00:47:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g248lvo9021489 for ipng-dist; Mon, 4 Mar 2002 00:47:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g248lsKL021482 for ; Mon, 4 Mar 2002 00:47:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA28377 for ; Mon, 4 Mar 2002 00:47:54 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA17490 for ; Mon, 4 Mar 2002 01:47:52 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g248jlE19029; Mon, 4 Mar 2002 10:45:47 +0200 Date: Mon, 4 Mar 2002 10:45:46 +0200 (EET) From: Pekka Savola To: Margaret Wasserman cc: "Hesham Soliman (ERA)" , Subject: Re: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] In-Reply-To: <4.2.2.20020304023354.020acc20@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 4 Mar 2002, Margaret Wasserman wrote: > However, making DAD optional (and advising against the use of DAD) > on point-to-point links, is in direct conflict with RFC 2462, > which says: > > "Duplicate Address Detection MUST take place on all unicast > addresses, regardless of whether they are obtained through > stateful, stateless or manual configuration..." > > I don't think that we should publish an informational document that > advises some implementors to do something that specifically > disagrees with a MUST requirement in a standards-track document. > If the standards-track document is broken, we need to fix it > instead. > > [Please note that I actually think that we should be able to > disable DAD for some link types. I made a proposal to that effect > several years ago, but my arguments didn't win the day.] I think DAD should be disableable for default for: - addresses generated randomly - addresses that are generated from e.g. EUI64 (this might be more prone to errors, e.g. manufacturing or "stupid" multi-port NIC's where every port has the same MAC address) Most definitely not: - manually configured addresses Because DAD is not a perfect (or even nearly so) solution anyway. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 01:32:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g249WcKL021723 for ; Mon, 4 Mar 2002 01:32:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g249Wc8J021722 for ipng-dist; Mon, 4 Mar 2002 01:32:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g249WZKL021715 for ; Mon, 4 Mar 2002 01:32:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02065 for ; Mon, 4 Mar 2002 01:32:31 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA02619 for ; Mon, 4 Mar 2002 02:32:24 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g249S8k14568; Mon, 4 Mar 2002 10:28:08 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA02907; Mon, 4 Mar 2002 10:28:07 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g249S6g03642; Mon, 4 Mar 2002 10:28:07 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203040928.g249S6g03642@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Margaret Wasserman cc: "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] In-reply-to: Your message of Mon, 04 Mar 2002 02:57:47 EST. <4.2.2.20020304023354.020acc20@mail.windriver.com> Date: Mon, 04 Mar 2002 10:28:06 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > > It is not my impression that the WG has reached consensus on some > > of the issues raised in this document, specifically: > > > > - Forbidding the use of DAD on some links > >=> DAD is not needed if address duplication is not >possible. Since each terminal gets a unique >/64 (as per the advice draft), and since all terminals >are on p2p links, DAD would be a waste of BW. >But please have a closer look and let us know >if something was missed. Address duplication is possible on point-to-point links, because one end may choose an address that is already in use by the other end. I don't think that this is very likely, but it is possible. => I disagree for addresses using the explicitely negociated interface IDs with in the first position the link-local addresses. However, making DAD optional (and advising against the use of DAD) on point-to-point links, is in direct conflict with RFC 2462, which says: "Duplicate Address Detection MUST take place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration..." => the point-to-point link is one case DAD is overkilling. But as too many persons want to make DAD optional I agree we have to be carefull. For instance we should ask that all DAD stuff must get rough consensus in the IPv6 WG. Another point is who makes the choice to avoid the DAD check: my opinion is this must be the "link manager" (i.e. the manager of the network where is the link). I don't think that we should publish an informational document that advises some implementors to do something that specifically disagrees with a MUST requirement in a standards-track document. If the standards-track document is broken, we need to fix it instead. => I agree we have a procedural case at least. [Please note that I actually think that we should be able to disable DAD for some link types. I made a proposal to that effect several years ago, but my arguments didn't win the day.] => so basically we agree! Thanks Francis.Dupont@enst-bretagne.fr PS: DAD is not a toy, at least one time I saw it saved us from a disaster. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 01:43:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g249hBKL021872 for ; Mon, 4 Mar 2002 01:43:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g249hBNa021871 for ipng-dist; Mon, 4 Mar 2002 01:43:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g249h8KL021864 for ; Mon, 4 Mar 2002 01:43:08 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA11307 for ; Mon, 4 Mar 2002 01:43:09 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA08375 for ; Mon, 4 Mar 2002 02:43:08 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g249dpk16311; Mon, 4 Mar 2002 10:39:52 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA03205; Mon, 4 Mar 2002 10:39:51 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g249dpg03701; Mon, 4 Mar 2002 10:39:51 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203040939.g249dpg03701@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Margaret Wasserman cc: "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] In-reply-to: Your message of Mon, 04 Mar 2002 03:17:04 EST. <4.2.2.20020304025751.02121180@mail.windriver.com> Date: Mon, 04 Mar 2002 10:39:51 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with you and Hesham: IPsec is required for any compliant IPv6 implementations and we should not accept an exemption for a device which can get a global address in the Internet. BTW the complexity argument is not very sound because IPsec with IKE is already available on PalmPilot and PSions (cf ipsec wg mailing list). Security should not be a compromise! Thanks Francis.Dupont@enst-bretagne.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 Mon Mar 4 01:45:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g249jFKL021889 for ; Mon, 4 Mar 2002 01:45:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g249jFLZ021888 for ipng-dist; Mon, 4 Mar 2002 01:45:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g249jCKL021881 for ; Mon, 4 Mar 2002 01:45:12 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA03493 for ; Mon, 4 Mar 2002 01:45:13 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28364 for ; Mon, 4 Mar 2002 01:45:10 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g249j9Zc027512 for ; Mon, 4 Mar 2002 10:45:09 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Mar 04 10:45:04 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 10:35:18 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFB8@esealnt117> From: "Karim El-Malki (ERA)" To: "'Margaret Wasserman'" , "Hesham Soliman (ERA)" Cc: juha.wiljakka@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] Date: Mon, 4 Mar 2002 10:44:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret > My understanding is that the 3GPP group is actually migrating towards > a more standard IPv6 configuration mechanism, using router > advertisements > and allowing hosts to generate their own interface IDs. Yes, we all agree that was the right decision. > > Currently the cellular hosts draft says: > > "IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be > supported." > > However, I think that RFC 2462 should be a MUST for all IPv6 nodes. I think this is related to 3GPP hosts in particular and it is the use of DADs here that may be excluded. In the 3gpp-advice draft we basically assign a /64 to the cellular host. That is, the upstream router (GGSN) only advertises the /64 to one connection/host. A major reason to do that was to forego a large number of (unreliable) DADs over lossy and expensive wireless point-to-point links. Specifically, if we use unreliable DADs as a way for the upstream router to know which addresses are in use there could be problems. In the 3GPP case, even without DADs no duplication occurs on the point-to-point link since the upstream router doesn't configure addresses on the advertised /64 prefix. Regards /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 01:46:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g249kPKL021906 for ; Mon, 4 Mar 2002 01:46:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g249kPOB021905 for ipng-dist; Mon, 4 Mar 2002 01:46:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g249kLKL021898 for ; Mon, 4 Mar 2002 01:46:21 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA19484 for ; Mon, 4 Mar 2002 01:46:22 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28741 for ; Mon, 4 Mar 2002 01:46:21 -0800 (PST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g249kIZc028575; Mon, 4 Mar 2002 10:46:18 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g249kIof014371; Mon, 4 Mar 2002 11:46:18 +0200 (EET) Message-ID: <3C83426A.EA7E70E6@lmf.ericsson.se> Date: Mon, 04 Mar 2002 11:46:18 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman CC: "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? [Was RE:draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] References: <4.2.2.20020304025751.02121180@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thanks Margaret for opening up discussions on each of the specific points you raised. I think we do need the discussion. > Now, I don't actually live under a rock, so I do understand that most > of today's IPv6 nodes don't actually implement IP Security. In the > past, however, the IESG had mandated that IP Security would be a > mandatory part of IPv6, and I don't believe that they've changed that > statement. First I'd just like to note that the main approach to security is outlined in the beginning of section 3. Section 2.4 text is just a consequence of that. Now, I actually believe there's today a better understanding of what security is required when, and what are the true capabilities of various security mechanisms than back when some of the base IPv6 RFCs were created. What we describe in section 3 tries to reflect some of that new understanding. In particular, we realize that there are a few different security mechanisms, and often IETF application protocol RFCs specify a particular security mechanism to be used. This isn't always IPsec. In other cases a single mechanism is simply the most appropriate one. As an example of this, consider the use of TLS vs. IPsec for web access; I think the appropriate security mechanism is quite clear in this case. Secondly, we now have a better understanding of what IPsec can do in the area of protecting IPv6 control signaling -- it can do things, but not perhaps quite as much as was originally believed [1, 2, 3]. IPsec is however, obviously the used in e.g. corporate intranet access and VPN solutions. Therefore we feel that on size- and power-constrained devices one should select the implemented security mechanisms based on the requirements of the applications rather than a general rule. The general rules aren't very good if in the end the application RFC you were running would demand something else than the general rule, or if the deployment at the other end was something else. This conclusion seems to be supported by other approaches to host requirements [4]. In any case, I'd be very happy to get feedback on exactly what we should write as the host requirements for security. I'm reasonably happy with what we have written -- in particular I believe this is roughly where the world seems to be heading -- but if you have other ideas or improvement suggestions, please present them! Jari ---- [1] http://search.ietf.org/internet-drafts/draft-kempf-ipng-netaccess-threats-00.txt [2] http://www.arkko.com/publications/draft-arkko-manual-icmpv6-sas-00.txt [3] http://www.ietf.org/internet-drafts/draft-arkko-mipv6-bu-security-01.txt [4] http://search.ietf.org/internet-drafts/draft-okabe-ipv6-lcna-minreq-01.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 Mon Mar 4 01:50:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g249ofKL021929 for ; Mon, 4 Mar 2002 01:50:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g249of7o021928 for ipng-dist; Mon, 4 Mar 2002 01:50:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g249ocKL021921 for ; Mon, 4 Mar 2002 01:50:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA12716 for ; Mon, 4 Mar 2002 01:50:39 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11918 for ; Mon, 4 Mar 2002 02:50:38 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g249lFk17830; Mon, 4 Mar 2002 10:47:15 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA03450; Mon, 4 Mar 2002 10:47:15 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g249lFg03791; Mon, 4 Mar 2002 10:47:15 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203040947.g249lFg03791@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Margaret Wasserman cc: "Hesham Soliman (ERA)" , juha.wiljakka@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] In-reply-to: Your message of Mon, 04 Mar 2002 03:28:06 EST. <4.2.2.20020304032347.020ac100@mail.windriver.com> Date: Mon, 04 Mar 2002 10:47:15 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Currently the cellular hosts draft says: "IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be supported." However, I think that RFC 2462 should be a MUST for all IPv6 nodes. => I agree but in order to avoid misunderstanding please make clear that the MUST is for the support, not the use. Thanks Francis.Dupont@enst-bretagne.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 Mon Mar 4 01:51:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g249p6KL021946 for ; Mon, 4 Mar 2002 01:51:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g249p6YP021945 for ipng-dist; Mon, 4 Mar 2002 01:51:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g249p1KL021931 for ; Mon, 4 Mar 2002 01:51:02 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA12820 for ; Mon, 4 Mar 2002 01:51:03 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA11955 for ; Mon, 4 Mar 2002 02:51:02 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA17242; Mon, 4 Mar 2002 11:50:58 +0200 Date: Mon, 4 Mar 2002 11:50:58 +0200 Message-Id: <200203040950.LAA17242@burp.tkv.asdf.org> From: Markku Savela To: mrw@windriver.com CC: hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com In-reply-to: <4.2.2.20020304023354.020acc20@mail.windriver.com> (message from Margaret Wasserman on Mon, 04 Mar 2002 02:57:47 -0500) Subject: Re: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] References: <4.2.2.20020304023354.020acc20@mail.windriver.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > [Please note that I actually think that we should be able to > disable DAD for some link types. I made a proposal to that effect > several years ago, but my arguments didn't win the day.] Yes. RFC-2462, "5.1. Node Configuration Variables": DupAddrDetectTransmits = 0 => DAD is disabled on link So, no DAD is "conformant" too. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 01:56:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g249umKL021974 for ; Mon, 4 Mar 2002 01:56:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g249umiM021973 for ipng-dist; Mon, 4 Mar 2002 01:56:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g249ujKL021966 for ; Mon, 4 Mar 2002 01:56:45 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20389 for ; Mon, 4 Mar 2002 01:56:46 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA14267 for ; Mon, 4 Mar 2002 02:56:45 -0700 (MST) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA25343; Mon, 4 Mar 2002 09:56:44 GMT Received: from login.ecs.soton.ac.uk (IDENT:tjc@login.ecs.soton.ac.uk [152.78.68.149]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA04349; Mon, 4 Mar 2002 09:56:44 GMT Date: Mon, 4 Mar 2002 09:56:43 +0000 (GMT) From: Tim Chown To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] In-Reply-To: <4.2.2.20020304025751.02121180@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, Another important reference is in RFC2401, "Security Architecture for the Internet Protocol" 10. Conformance Requirements All IPv4 systems that claim to implement IPsec MUST comply with all requirements of the Security Architecture document. All IPv6 systems MUST comply with all requirements of the Security Architecture document. There was a thread along these lines a few months back, the conclusion of which was that full implementations of IPv6 must implement IPsec, but that use of IPsec was not mandatory. So the cellular hosts document may choose to distinguish between implementation and use also. Tim On Mon, 4 Mar 2002, Margaret Wasserman wrote: > > And the next issue, IP Security... > > > > - Situation where IP Security should be optional/disabled > > > (and the whole distinction between "Core IP" and > > > "IP Security") > > > >=> The distinction between IP security and core IP > >is merely an editorial distinction. For example > >you can see that in 'core IP' we list all the > >IPv6 WG RFCs. > > Publishing a document that makes this distinction, however, will give > the impression that IP Security (AKA IPSec) is not a _core_ part of > IPv6. Some people may take that to mean that they can produce a > complete IPv6 implementation that does not include IP Security. > > >As to whether IP security (I assume you mean IPsec) > >should be mandated or not, we can discuss that. > >But some questions that we would need to answer: > > > >- By 'mandated' do we mean implementation or use? > >- What should be mandated? > >- Why should it be mandated? > > RFC 2460 says: > > "A full implementation of IPv6 includes implementation of the > following extension headers: > > Hop-by-Hop Options > Routing (Type 0) > Fragment > Destination Options > Authentication > Encapsulating Security Payload > > The first four are specified in this document; the last two are > specified in [RFC-2402] and [RFC-2406], respectively." > > So, a "full" implementation of IPv6 must include an implementation > of the Authentication and ESP headers from RFCs 2402 and 2406. > > Obviously, it is possible for a host to implement RFCs 2402 and 2406, > but to be configured such that no traffic is ever authenticated and/or > encrypted. > > The draft-ietf-ipv6-cellular-host-00.txt document, however, seems to > assume that there may be hosts that do not implement these headers. > It says: > > " - AH and ESP headers: In the case of the Core IP functionality > only, AH and ESP headers are treated as if the Security > Association had not existed, i.e. - packets with these headers > are dropped. When the IP Security functionality is in use, they > are processed as specified in RFCs 2401, 2402, and 2406." > > I am not sure about the wording here, but this paragraph implies to > me that cellular hosts that only implement the "Core IP" functionality > may not actually implement AH or ESP processing. This conflicts > directly with RFC 2460. > > Now, I don't actually live under a rock, so I do understand that most > of today's IPv6 nodes don't actually implement IP Security. In the > past, however, the IESG had mandated that IP Security would be a > mandatory part of IPv6, and I don't believe that they've changed that > statement. > > So, where do we go from here? > > No document can be published as an RFC without IESG approval, and I don't > think that we'll get IESG approval for a document that says (or even > strongly implies) that IP Security is optional in IPv6. Maybe our > ADs could comment on this? > > Margaret > > > > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 4 02:00:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24A0mKL022003 for ; Mon, 4 Mar 2002 02:00:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24A0mCD022002 for ipng-dist; Mon, 4 Mar 2002 02:00:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24A0jKL021995 for ; Mon, 4 Mar 2002 02:00:45 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA15175 for ; Mon, 4 Mar 2002 02:00:46 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA01144 for ; Mon, 4 Mar 2002 03:00:45 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g24A0Rk20551; Mon, 4 Mar 2002 11:00:27 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA03845; Mon, 4 Mar 2002 11:00:27 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g24A0Rg03901; Mon, 4 Mar 2002 11:00:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203041000.g24A0Rg03901@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: Margaret Wasserman , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] In-reply-to: Your message of Mon, 04 Mar 2002 10:45:46 +0200. Date: Mon, 04 Mar 2002 11:00:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I think DAD should be disableable for default for: - addresses generated randomly => I *strongly* disagree: even if the probability is small it is not zero. - addresses that are generated from e.g. EUI64 (this might be more prone to errors, e.g. manufacturing or "stupid" multi-port NIC's where every port has the same MAC address) => I agree: if two boxes have the same hardware number the address collision is no more than a detail. Most definitely not: - manually configured addresses => agree Because DAD is not a perfect (or even nearly so) solution anyway. => DAD is not perfect but only the network manager should take the decision to forget DAD in such or such situations. Of course this implies the "DAD avoidance" is negociated by the link-layer before (so PPP again is a good candidate for optional DAD). Regards Francis.Dupont@enst-bretagne.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 Mon Mar 4 02:21:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24ALgKL022198 for ; Mon, 4 Mar 2002 02:21:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24ALgt9022197 for ipng-dist; Mon, 4 Mar 2002 02:21:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24ALdKL022190 for ; Mon, 4 Mar 2002 02:21:39 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22822 for ; Mon, 4 Mar 2002 02:21:40 -0800 (PST) From: matthew.ford@bt.com Received: from gollum.axion.bt.co.uk (gollum.axion.bt.co.uk [132.146.17.41]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA23773 for ; Mon, 4 Mar 2002 03:21:40 -0700 (MST) Received: from cbtlipnt01.btlabs.bt.co.uk by gollum (local) with ESMTP; Mon, 4 Mar 2002 10:21:09 +0000 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2654.89) id ; Mon, 4 Mar 2002 10:20:46 -0000 Message-ID: To: Jari.Arkko@lmf.ericsson.se, mrw@windriver.com Cc: hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: RE: Should IP Security be Optional? [Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] Date: Mon, 4 Mar 2002 10:20:33 -0000 X-Mailer: Internet Mail Service (5.5.2654.89) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Therefore we feel that on size- and power-constrained > devices one should select the implemented security > mechanisms based on the requirements of the applications > rather than a general rule. The general rules aren't > very good if in the end the application RFC you were running > would demand something else than the general rule, or if > the deployment at the other end was something else. This seems to presume that you can predict in advance all of the applications that a user will wish to execute on a particular node. Can you do that? Also, please note well that the 'deployment at the other end' won't be 'something else' if we get IPsec in every IPv6 node. I thought that was the whole point.... Regards, Mat. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 02:27:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24ARiKL022242 for ; Mon, 4 Mar 2002 02:27:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24ARimL022241 for ipng-dist; Mon, 4 Mar 2002 02:27:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24ARfKL022234 for ; Mon, 4 Mar 2002 02:27:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07744 for ; Mon, 4 Mar 2002 02:27:42 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA25192 for ; Mon, 4 Mar 2002 03:27:41 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g24AO1k24300; Mon, 4 Mar 2002 11:24:01 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA04576; Mon, 4 Mar 2002 11:24:01 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g24AO1g04042; Mon, 4 Mar 2002 11:24:01 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203041024.g24AO1g04042@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Karim El-Malki (ERA)" cc: "'Margaret Wasserman'" , "Hesham Soliman (ERA)" , juha.wiljakka@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] In-reply-to: Your message of Mon, 04 Mar 2002 10:44:01 +0100. <795A014AF92DD21182AF0008C7A404320DFBEFB8@esealnt117> Date: Mon, 04 Mar 2002 11:24:01 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A way to solve your DAD/autoconf issue is to "delegate" the /64 prefix and to keep only link-local addresses using link-layer negociated interface IDs (negociation is very simple and just checks the interface IDs of the both ends are different). The link has to be point-to-point but this is the only constraint (you can even use PPP if you'd like). Regards Francis.Dupont@enst-bretagne.fr PS: prefix delegation should be one topic of the next IPv6 WG meeting. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 02:31:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24AVoKL022265 for ; Mon, 4 Mar 2002 02:31:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24AVotD022264 for ipng-dist; Mon, 4 Mar 2002 02:31:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24AViKL022257 for ; Mon, 4 Mar 2002 02:31:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA20545 for ; Mon, 4 Mar 2002 02:31:45 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA12096 for ; Mon, 4 Mar 2002 03:31:45 -0700 (MST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g24AVeZc003544; Mon, 4 Mar 2002 11:31:41 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g24AVeof017336; Mon, 4 Mar 2002 12:31:40 +0200 (EET) Message-ID: <3C834D0C.9B57EF12@lmf.ericsson.se> Date: Mon, 04 Mar 2002 12:31:40 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: matthew.ford@bt.com CC: mrw@windriver.com, hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk matthew.ford@bt.com wrote: > This seems to presume that you can predict in advance all of the > applications that a user will wish to execute on a particular node. Can you > do that? On a workstation you can't. On a tiny cellular device you often can. > Also, please note well that the 'deployment at the other end' won't be > 'something else' if we get IPsec in every IPv6 node. I thought that was the > whole point.... Well, the other end could still require TLS if the RFC-for-app-X required that. Regardless of what other RFC states something about security at IP layer... Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 02:36:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24Aa2KL022288 for ; Mon, 4 Mar 2002 02:36:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24Aa2Xd022287 for ipng-dist; Mon, 4 Mar 2002 02:36:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24AZxKL022280 for ; Mon, 4 Mar 2002 02:35:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA21306 for ; Mon, 4 Mar 2002 02:36:00 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA13443 for ; Mon, 4 Mar 2002 03:35:59 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g24AZwB25778 for ; Mon, 4 Mar 2002 11:35:58 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Mar 04 11:35:15 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 11:35:15 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFB9@esealnt117> From: "Karim El-Malki (ERA)" To: "'Francis Dupont'" Cc: "'Margaret Wasserman'" , "Hesham Soliman (ERA)" , juha.wiljakka@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] Date: Mon, 4 Mar 2002 11:34:15 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A way to solve your DAD/autoconf issue is to "delegate" the > /64 prefix > and to keep only link-local addresses using link-layer negociated > interface IDs (negociation is very simple and just checks > the interface > IDs of the both ends are different). The link has to be > point-to-point > but this is the only constraint (you can even use PPP if you'd like). That's exactly what we've pointed to in the 3gpp-advice draft and this is what 3GPP is following. Currently PPP is used. So I think we agree that 3gpp hosts need not do DAD, which explains the cellular hosts requirement. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 02:46:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24AkvKL022443 for ; Mon, 4 Mar 2002 02:46:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24Akvni022442 for ipng-dist; Mon, 4 Mar 2002 02:46:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24AksKL022435 for ; Mon, 4 Mar 2002 02:46:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA09408 for ; Mon, 4 Mar 2002 02:46:55 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA01075 for ; Mon, 4 Mar 2002 03:46:49 -0700 (MST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g24AksZ19363 for ; Mon, 4 Mar 2002 12:46:54 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Mar 2002 12:46:44 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Mar 2002 12:46:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Mon, 4 Mar 2002 12:46:44 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AD3@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDVUv/4/6kSjBJQH2Sa+80ZFq3vQAE+ANg To: , Cc: X-OriginalArrivalTime: 04 Mar 2002 10:46:44.0499 (UTC) FILETIME=[E049A630:01C1C369] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g24AksKL022436 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > Publishing a document that makes this distinction, however, will give > the impression that IP Security (AKA IPSec) is not a _core_ part of > IPv6. Some people may take that to mean that they can produce a > complete IPv6 implementation that does not include IP Security. Perhaps 'core' is not correct - would 'basic' be a better term, or will that cause confusion? The section on Security attempts to inject some reality into the security discussion. For the last several years, the Security Area ADs have said that IPsec is not a magic bullet (i.e. - having a standard that just says - All security can be provided by IPsec) is not sufficient. MIPv6 had tried to use IPsec to protect BUs, that has been found to be insufficient. There are concerns about IKE scalability, lack of PKI, etc. Of course, we should have a discussion on what is applicable, what is useful, and what is manditory. I think we should avoid stating that because RFC xyz says so, it is so. I think that Jari has addressed this issue better than I, though ... John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 02:50:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24AosKL022475 for ; Mon, 4 Mar 2002 02:50:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24Aos6h022474 for ipng-dist; Mon, 4 Mar 2002 02:50:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24AopKL022467 for ; Mon, 4 Mar 2002 02:50:51 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA23688 for ; Mon, 4 Mar 2002 02:50:53 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA04738 for ; Mon, 4 Mar 2002 03:50:52 -0700 (MST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g24AonB06512; Mon, 4 Mar 2002 11:50:49 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g24Aonof018824; Mon, 4 Mar 2002 12:50:49 +0200 (EET) Message-ID: <3C835189.EF375D4C@lmf.ericsson.se> Date: Mon, 04 Mar 2002 12:50:49 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Margaret Wasserman , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] References: <200203040939.g249dpg03701@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > I agree with you and Hesham: IPsec is required for any compliant > IPv6 implementations and we should not accept an exemption for > a device which can get a global address in the Internet. > BTW the complexity argument is not very sound because IPsec > with IKE is already available on PalmPilot and PSions (cf ipsec > wg mailing list). True, and I've personally done even smaller implementations of IPsec... however this isn't really the point. The point is the use of appropriate mechanisms for the task at hand. Even the other mechanisms may be complex and troublesome to implement. But we should avoid adding other mechanisms that we do not need. > Security should not be a compromise! I agree. However, I disagree with the thinking that e.g. my web-browsing-phone has somehow compromised on security when it implemented TLS instead of IPsec. Please note that I do NOT want to say that we shouldn't use IPsec. Rather, you could say that I'd like to get a more appropriate applicability statement for it than we currently have. For instance, the recommendations we have in some base IPv6 RFCs on the use of IPsec for ICMP protection are at least misleading -- and this is from personal experience on actually trying to do that. Have you tried it? Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 03:01:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24B1nKL022499 for ; Mon, 4 Mar 2002 03:01:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24B1n3P022498 for ipng-dist; Mon, 4 Mar 2002 03:01:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24B1kKL022491 for ; Mon, 4 Mar 2002 03:01:46 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25136 for ; Mon, 4 Mar 2002 03:01:45 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07625 for ; Mon, 4 Mar 2002 04:01:44 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g24AwFk29388; Mon, 4 Mar 2002 11:58:15 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id LAA05708; Mon, 4 Mar 2002 11:58:15 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g24AwDg04300; Mon, 4 Mar 2002 11:58:13 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203041058.g24AwDg04300@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Karim El-Malki (ERA)" cc: "'Margaret Wasserman'" , "Hesham Soliman (ERA)" , juha.wiljakka@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] In-reply-to: Your message of Mon, 04 Mar 2002 11:34:15 +0100. <795A014AF92DD21182AF0008C7A404320DFBEFB9@esealnt117> Date: Mon, 04 Mar 2002 11:58:13 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > A way to solve your DAD/autoconf issue is to "delegate" the > /64 prefix > and to keep only link-local addresses using link-layer negociated > interface IDs (negociation is very simple and just checks > the interface > IDs of the both ends are different). The link has to be > point-to-point > but this is the only constraint (you can even use PPP if you'd like). That's exactly what we've pointed to in the 3gpp-advice draft and this is what 3GPP is following. Currently PPP is used. So I think we agree that 3gpp hosts need not do DAD, which explains the cellular hosts requirement. => so we agree. The only problem is we have to find a way to explain that in a standard track document and to get rough consensus not only for the idea but also for the way to specify it. I don't know if the agenda is already closed (it should not): does someone ask for a short slot in the next meeting agenda? Regards Francis.Dupont@enst-bretagne.fr PS: I'd like to get this (DAD considerations) for PPP in general. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 03:17:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24BHcKL022603 for ; Mon, 4 Mar 2002 03:17:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24BHcXF022602 for ipng-dist; Mon, 4 Mar 2002 03:17:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24BHZKL022595 for ; Mon, 4 Mar 2002 03:17:35 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28670 for ; Mon, 4 Mar 2002 03:17:34 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13173 for ; Mon, 4 Mar 2002 04:17:33 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g24BEIk31341; Mon, 4 Mar 2002 12:14:18 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id MAA06200; Mon, 4 Mar 2002 12:14:18 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g24BEIg04387; Mon, 4 Mar 2002 12:14:18 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203041114.g24BEIg04387@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Margaret Wasserman , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] In-reply-to: Your message of Mon, 04 Mar 2002 12:50:49 +0200. <3C835189.EF375D4C@lmf.ericsson.se> Date: Mon, 04 Mar 2002 12:14:18 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: But we should avoid adding other mechanisms that we do not need. => we need IPsec and we need even other mechanisms because IPsec is not all the security. For instance for mails between humans we need PGP or S/MIME too. > Security should not be a compromise! Please note that I do NOT want to say that we shouldn't use IPsec. Rather, you could say that I'd like to get a more appropriate applicability statement for it than we currently have. => there is an IAB statement about security. IPsec support was made mandatory according to this statement and IMHO this was a big step forward. There are other security mechanisms, including some at the transport layer (SSL/TLS, IMHO IPsec is better but real world considerations have to be considered :-) and some at the application layer, with in some cases a very different usage (PGP). I have in favor of to make all core security mechanisms mandatory (MUST or strong SHOULD), cf RFC 2316 section 10. IPsec is only the first in the list. For instance, the recommendations we have in some base IPv6 RFCs on the use of IPsec for ICMP protection are at least misleading -- and this is from personal experience on actually trying to do that. Have you tried it? => yes, ICMP is hard to protect and to use it for small services does not make things simpler... Regards Francis.Dupont@enst-bretagne.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 Mon Mar 4 03:26:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24BQXKL022648 for ; Mon, 4 Mar 2002 03:26:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24BQWJQ022647 for ipng-dist; Mon, 4 Mar 2002 03:26:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24BQTKL022640 for ; Mon, 4 Mar 2002 03:26:29 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA28904 for ; Mon, 4 Mar 2002 03:26:29 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA16533 for ; Mon, 4 Mar 2002 04:26:28 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g24BQRZc007046 for ; Mon, 4 Mar 2002 12:26:27 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Mar 04 12:26:22 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 12:26:22 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFBB@esealnt117> From: "Karim El-Malki (ERA)" To: "'Francis Dupont'" Cc: "'Margaret Wasserman'" , "Hesham Soliman (ERA)" , juha.wiljakka@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] Date: Mon, 4 Mar 2002 12:25:16 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > PS: I'd like to get this (DAD considerations) for PPP in general. Agreed. I'd also be in favour of allowing PPP links on which there's some form of prefix delegation (doesn't have to be a prefix del. protocol) to disable DAD. Some more work is needed on RFC2472, which was also one of the outputs of the ipv6-3gpp design team. Can the chairs allow for a short discussion on this? /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 05:03:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24D3HKL022949 for ; Mon, 4 Mar 2002 05:03:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24D3HAn022948 for ipng-dist; Mon, 4 Mar 2002 05:03:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24D3EKL022941 for ; Mon, 4 Mar 2002 05:03:14 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22670 for ; Mon, 4 Mar 2002 05:03:14 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA07209 for ; Mon, 4 Mar 2002 06:03:13 -0700 (MST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g24D32Zc000476; Mon, 4 Mar 2002 14:03:09 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g24D30of029215; Mon, 4 Mar 2002 15:03:00 +0200 (EET) Message-ID: <3C837084.323A5407@lmf.ericsson.se> Date: Mon, 04 Mar 2002 15:03:00 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Francis Dupont CC: Margaret Wasserman , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] References: <200203041114.g24BEIg04387@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > => yes, ICMP is hard to protect and to use it for small services > does not make things simpler... So, we agree on this at least... > => there is an IAB statement about security. IPsec support was > made mandatory according to this statement and IMHO this was > a big step forward. There are other security mechanisms, > including some at the transport layer (SSL/TLS, IMHO IPsec > is better but real world considerations have to be considered :-) > and some at the application layer, with in some cases a very > different usage (PGP). > I have in favor of to make all core security mechanisms mandatory > (MUST or strong SHOULD), cf RFC 2316 section 10. IPsec is only > the first in the list. I'm partially in favor of this approach, but not entirely. I'd be much more comfortable with trying to make a detailed recommendation on where different mechanisms are applicable and mandated, than try to mandate them all everywhere (likely with less than 100% success among implementors). I think the general approach should be that security is mandatory, but not necessarily same type of security under all circumstances. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 05:36:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24DaKKL023021 for ; Mon, 4 Mar 2002 05:36:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24DaKlW023020 for ipng-dist; Mon, 4 Mar 2002 05:36:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24DaHKL023013 for ; Mon, 4 Mar 2002 05:36:17 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA25776 for ; Mon, 4 Mar 2002 05:36:18 -0800 (PST) Received: from tkd.att.ne.jp (tkd.att.ne.jp [165.76.16.8]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA02051 for ; Mon, 4 Mar 2002 05:36:16 -0800 (PST) Received: (qmail 20427 invoked from network); 4 Mar 2002 13:36:14 -0000 Received: from unknown (HELO localhost) (203.178.222.245) by tkd.att.ne.jp with SMTP; 4 Mar 2002 13:36:14 -0000 Date: Mon, 04 Mar 2002 22:35:53 +0900 (JST) Message-Id: <20020304.223553.39154929.nov@tahi.org> To: Jari.Arkko@lmf.ericsson.se Cc: Francis.Dupont@enst-bretagne.fr, mrw@windriver.com, hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? From: OKABE Nobuo In-Reply-To: <3C837084.323A5407@lmf.ericsson.se> References: <200203041114.g24BEIg04387@givry.rennes.enst-bretagne.fr> <3C837084.323A5407@lmf.ericsson.se> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thank you for your many feedbacks. From: Jari Arkko Subject: Re: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Mon, 04 Mar 2002 15:03:00 +0200 > Francis Dupont wrote: > > > => yes, ICMP is hard to protect and to use it for small services > > does not make things simpler... > > So, we agree on this at least... > > > => there is an IAB statement about security. IPsec support was > > made mandatory according to this statement and IMHO this was > > a big step forward. There are other security mechanisms, > > including some at the transport layer (SSL/TLS, IMHO IPsec > > is better but real world considerations have to be considered :-) > > and some at the application layer, with in some cases a very > > different usage (PGP). > > I have in favor of to make all core security mechanisms mandatory > > (MUST or strong SHOULD), cf RFC 2316 section 10. IPsec is only > > the first in the list. > > I'm partially in favor of this approach, but not entirely. > I'd be much more comfortable with trying to make a detailed > recommendation on where different mechanisms are applicable > and mandated, than try to mandate them all everywhere (likely > with less than 100% success among implementors). > > I think the general approach should be that security > is mandatory, but not necessarily same type of security > under all circumstances. I agree. If a very small host has single application (ex. web), the implementer will want to implement an appropriate security mechanism only (ex, TLS) because of fitting its cost. It should be our further work to make detailed guideline for LCNA part. ---- nobuo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 06:40:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24EenKL023245 for ; Mon, 4 Mar 2002 06:40:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24Eenwo023244 for ipng-dist; Mon, 4 Mar 2002 06:40:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24EejKL023237 for ; Mon, 4 Mar 2002 06:40:45 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04193 for ; Mon, 4 Mar 2002 06:40:44 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01667 for ; Mon, 4 Mar 2002 07:40:43 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g24Ec2F00684; Mon, 4 Mar 2002 09:38:02 -0500 (EST) Message-Id: <200203041438.g24Ec2F00684@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jari Arkko cc: matthew.ford@bt.com, mrw@windriver.com, hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] In-reply-to: (Your message of "Mon, 04 Mar 2002 12:31:40 +0200.") <3C834D0C.9B57EF12@lmf.ericsson.se> Date: Mon, 04 Mar 2002 09:38:02 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > This seems to presume that you can predict in advance all of the > > applications that a user will wish to execute on a particular node. Can you > > do that? > > On a workstation you can't. On a tiny cellular device you > often can. only if the device doesn't have a data port. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 07:09:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24F95KL023298 for ; Mon, 4 Mar 2002 07:09:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24F95wF023297 for ipng-dist; Mon, 4 Mar 2002 07:09:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24F92KL023290 for ; Mon, 4 Mar 2002 07:09:02 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14207 for ; Mon, 4 Mar 2002 07:08:47 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15996 for ; Mon, 4 Mar 2002 08:08:46 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g24F8Ib22159; Mon, 4 Mar 2002 17:08:19 +0200 Date: Mon, 4 Mar 2002 17:08:18 +0200 (EET) From: Pekka Savola To: Atsushi Inoue cc: tiny@tahi.org, Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt In-Reply-To: <200203041416.XAA07265@toshiba.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 4 Mar 2002, Atsushi Inoue wrote: > >A few comments in addition to ones I sent for -00.. > > > > Table 1. Resource restrictions of LCNA > > > > ===============+===============+==================+======= > > Memory CPU Performance OS > > ===============+===============+==================+======= > > PC >64MB Pentium/64bits Windows > > ---------------+---------------+------------------+------- > > PDA 2-8MB RISC/32bits(50MHz) WinCE > > VxWorks > > PalmOS > > > >==> I think it'd be policitally correct to _at least_ change 'Windows' > >there to 'Any', and possibly add 'Others' to PDA section (e.g. I like > >Linux and NetBSD on PDA's :-). > > The footprint of WinCE is 1MB as announced, but the CPU performance > of pocket PC becomes higher and higher. So, as you suggested we > should replace winCE with embedded Linux or others if we keep on > this device class. No, I'm proposing something like: --8<-- ===============+===============+==================+======= Memory CPU Performance OS ===============+===============+==================+======= PC >64MB Pentium/64bits Any ---------------+---------------+------------------+------- PDA 2-8MB RISC/32bits(50MHz) WinCE VxWorks PalmOS Others --8<-- Or even, remove WinCE from there completely. > >2.7 Security > > In Section 4 "Security for LCNA", we will regulate a baseline for > > guaranteeing that a minimum host can communicate securely. However, > > Denial of Service (DoS) and intrusion are out of scope. So, we have > > to consider defending from DoS and/or intrusion in another place. > > Also, the authentication of users is out of scope, because some > > minimum hosts can omit a mechanism of user accounts. > > > >==> intrusion out of scope? What do you mean by that? > >Auth? > > Here, we mention about intrusion as a typical case that LCNA and > other device (such as firewall) work togather in order to provide > specific security solution. "Intrusion out of scope" simply means > that our spec only treats the end node itself and the security > functionality provided by node and other network devices is not > considered yet. Did you perhaps mean 'Interaction with Intrusion Detection Systems'? If so, I definitely agree. By intrusion I understand a remote break-in into the device, which is _definitely_ in the scope.. (you really don't want your oven being heated up when you're away, do you :-) > > - When it can recognize the extension header but does not support > > the options in it, it MUST perform error processing according to > > the option number. > > > >==> you mean s/extension header/destination options header/? There is no > >processing defined by option number for extension headers. > > This is our typo. The correct description is as follows: > > When it can recognize the extension options headers but does not > support the options in it, it MUST perform error processing according > to the option type. (as secified in section 4.2 of RFC2460) Not all extension headers necessarily have TLV-encoded options which contain the option type coded like that. E.g. routing header has RH type coded differently. This is a bit of academic discussion though, as LCNA's don't intend to support RH; but there might be some headers in the future that behave the same way: you might not always find TLV-encoded options coded like that inside. So, the wording might be a bit more careful. > > [Receiving] > > A minimum host SHOULD recognize it as a Hop-by-Hop Options Header, > > and perform the processing according to the option and option > > number in it. Because this option is used for signaling and router > > alert, in order to control routers on the path, all nodes on the > > transmission path have to interpret this header but do not need to > > interpret all options in it. > > > >==> I don't understand your reasoning for router alert; LCNA's aren't > >routers by definition :-) > > RFC2460 says, > "The Hop-by-Hop Options header is used to carry optional > information that must be examined by every node along a packet's > delivery path." > so we regulated that the examination of Hop-by-Hop option have to be > performed even on LCNA. Is it too redundant ? Yes, I think the latter part of that paragraph is being overly verbose (discussing non-LCNA issues and motivations) -- one _might_ add something there about the applicability of HBH for e.g. signalling, but I'm not sure if it's necessary. > >3.1.3 Fragment Header > > > > If a minimum host satisfies the following conditions, the host MAY > > not send this extension header, and MAY treat one as an unsupported > > header when receiving it. > > > >==> I'm not sure what the robustness principle would say about hosts that > >cannot defragment. > > What do you mean for "the robustness principle" ? RFC791, RFC1122, "Be liberal in what you accept, and conservative in what you send" That is, if you can't be absolutely positive no one is going to send you packets which are fragmented, there should be *really* good reason if you don't want to accept them -- the sending node is complying to the specifications, receiver wouldn't! > >3.5 Internet Control Message Protocol (ICMPv6) for the Internet Protocol > > Version 6 (IPv6) Specification (RFC2463) [24] > > > > On minimum hosts, ICMP used only by a router MAY be omitted (Table > > 2). ICMPs for Echo Request/Reply and minimum error reporting MUST be > > supported. > > > >==> this MUST includes rate-limiting of error replies, I hope? > > Agree. But we cannot describe LCNA-specific example of > rate-limitation. I agree; I was just curious whether it's included in the interpretation of minimum ICMP error reporting or not (one could argue all DestUnreach messages belong to that category). > >3.7 DNS Extensions to support IP version 6 (RFC1886) [26] and IPv6 > > Stateless DNS Discovery (draft-ietf-ipngwg-dns-discovery-02.txt) > > [27] > > > > The only function that is not supported in the current IPv6 > > autoconfiguration is automatic discovery of DNS server. On this > > topic discussions are ongoing in IETF IPNG WG. If a standard is > > fixed, it might become a mandatory item for minimum hosts. > > AAAA record is defined for transform from IPv6 name to IPv6 > > address. So, AAAA is currently mandatory for minimum host name > > resolution. Also, A6 record is currently proposed and discussed in > > IETF for an alternative of AAAA record. We need to check the > > progress. > > > >==> What about reverse lookups? nibble-style, probably? ip6.int or > >ip6.arpa, or both? > > On which case the reverse lookup is necessary in LCNA usage? > We complete neglect that. If you don't even implement IPSEC, at least reverse lookups could be done so you could (possibly) configure access-lists to the box. I'm not sure how big an issue this is but reverse should be mentioned at least. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 08:44:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24GibKL023403 for ; Mon, 4 Mar 2002 08:44:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24Gibgt023402 for ipng-dist; Mon, 4 Mar 2002 08:44:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24GiWKL023395 for ; Mon, 4 Mar 2002 08:44:32 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g24GiQx04138; Mon, 4 Mar 2002 17:44:26 +0100 (MET) Date: Mon, 4 Mar 2002 17:39:28 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] To: Pekka Savola Cc: Margaret Wasserman , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think DAD should be disableable for default for: Did you mean disabled? > - addresses generated randomly > - addresses that are generated from e.g. EUI64 (this might be more prone > to errors, e.g. manufacturing or "stupid" multi-port NIC's where every > port has the same MAC address) An interesting historic note is that the reason we embark on DAD (back at the Stockholm IETF in the addrconf BoF/WG?) was becase even with manufacturing derived NICs there had been cases where a bunch of NICs had been shipped with the same MAC address in them. The reasoning was that doing DAD once while configuring the address seemed like a cheap approach to deal with a failure case that is otherwise extremely difficult to trouble shoot. Perhaps mobile IP and its need to configure a care-of-address in short time has changed the notion that DAD is "cheap". But I don't think the difficulty of trouble-shooting duplicate IP addresses as changed. Erik > Most definitely not: > - manually configured addresses > > Because DAD is not a perfect (or even nearly so) solution anyway. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 4 08:45:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24GjCKL023413 for ; Mon, 4 Mar 2002 08:45:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24GjBnu023412 for ipng-dist; Mon, 4 Mar 2002 08:45:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24Gj7KL023405 for ; Mon, 4 Mar 2002 08:45:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03460 for ; Mon, 4 Mar 2002 08:45:09 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06300 for ; Mon, 4 Mar 2002 08:45:08 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g24Gj7Zc011418 for ; Mon, 4 Mar 2002 17:45:07 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Mar 04 17:45:06 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 17:35:20 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA64@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Margaret Wasserman'" , "Hesham Soliman (ERA)" Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Mon, 4 Mar 2002 17:30:31 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The different threads is a good idea. There is one unanswered issue below. > > > > - Making ND optional on point-to-point links > > > >=> RFC 2461 MUST be implemented, the exceptions are > >things like the Link layer suboption which is not > >relevant for these links. Did we miss something else? > > The cellular hosts document says: > > "Therefore, Neighbor Solicitation and Advertisement messages MAY > be implemented for the cellular interface." > > However, these messages are mandatory in RFCs 2461 and 2462, both > for DAD and for the basic neighbor discovery mechanism, which needs > to be used to establish two-way connectivity before other messages > are exchanged. => Right, but would you agree that on a p2p link you don't actually *need* NS and NA? It's not a shared link, the prefix is implicitly delegated to the UE only. So I don't see why (apart from NUD) you would need NSs and NAs. Hence the MAY. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 09:06:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24H6uKL023699 for ; Mon, 4 Mar 2002 09:06:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24H6uht023698 for ipng-dist; Mon, 4 Mar 2002 09:06:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24H6qKL023691 for ; Mon, 4 Mar 2002 09:06:52 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17244 for ; Mon, 4 Mar 2002 09:06:53 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10785 for ; Mon, 4 Mar 2002 09:06:49 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 04 Mar 2002 09:06:47 -0800 From: "Tony Hain" To: Subject: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 09:06:47 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 1 (Highest) X-MSMail-Priority: High X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: High X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margret has raised several valuable questions about draft-ietf-ipv6-cellular-host-00.txt, which show it is clearly is not ready for last call. While I am willing to believe that there are valid reasons to make adjustments based on characteristics of the link, this document is fundamentally flawed because it is based around the pretense that small footprint devices are somehow special. We MUST NOT allow ourselves to modify well thought out architectural fundamentals based on point-in-time engineering constraints that are dubious at best. If a device wants to participate as an Internet node, there are basic requirements. Of course, participating in the Internet is optional, so if a device would prefer to avoid the requirements, it may choose to create its own universe. The argument that small devices have limited processors or memory overlooks the fact that the processor and memory of many hand-held devices today is significantly greater than the workstations that were available when IPv4 was defined. Interesting point; there was no problem getting the stack and an array of applications to fit then. Another interesting point; there are frequently rumors that laptops will include cellular interfaces, so where does the processing and memory constraint fit in that case? On the subject of applications, the absolute BS about limiting the application set to avoid an IPsec requirement is something that belongs in a product development discussion, NOT a standards discussion. The one point that should be clear is that over time the number of applications used via wireless (cellular or otherwise) will grow, and that we can't predict what they are, much less what they will need from the stack. To that point, we MUST reiterate that ***ALL IPv6 IMPLEMENTATIONS MUST INCLUDE SUPPORT FOR IPSEC***. If we relax that requirement, applications will never be able to expect support, therefore will have to keep inventing their own mechanisms. The only way to prevent new applications from appearing on computing devices is to put the executable code in non-rewritable, non-replaceable, rom. If a document on cellular requirements makes any sense, it has to be based on differences in fundamental characteristics of the air link, not the device on either end. Avoiding DAD simply due to expense is not a valid justification, but if the loss characteristics of the link make it more problematic than valuable, there may be an argument. Keep in mind that doing so precludes the use of RFC3041 addresses, so the applications where anonymity is most valuable (as one moves around and doesn't movement traced) are precluded. A non-zero probability of collision requires a mechanism to resolve duplicates, and DAD is the currently defined one. If another one exists that makes more sense over a lossy air-link, we should consider replacing DAD because it will probably be more reliable in the general case as well. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 4 09:08:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24H8IKL023722 for ; Mon, 4 Mar 2002 09:08:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24H8Iet023721 for ipng-dist; Mon, 4 Mar 2002 09:08:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24H8EKL023714 for ; Mon, 4 Mar 2002 09:08:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17585 for ; Mon, 4 Mar 2002 09:08:11 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17233 for ; Mon, 4 Mar 2002 09:08:11 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g24H84d15393; Mon, 4 Mar 2002 09:08:04 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAZ70125; Mon, 4 Mar 2002 09:07:37 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA03874; Mon, 4 Mar 2002 09:08:02 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15491.43506.762579.306254@thomasm-u1.cisco.com> Date: Mon, 4 Mar 2002 09:08:02 -0800 (PST) To: OKABE Nobuo Cc: Jari.Arkko@lmf.ericsson.se, Francis.Dupont@enst-bretagne.fr, mrw@windriver.com, hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? In-Reply-To: <20020304.223553.39154929.nov@tahi.org> References: <200203041114.g24BEIg04387@givry.rennes.enst-bretagne.fr> <3C837084.323A5407@lmf.ericsson.se> <20020304.223553.39154929.nov@tahi.org> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So, talking about making exceptions to the MUST IMPLEMENT aspect of ipsec on v6 strikes me as a really poor idea. First of all, a minimum implementation of IPsec to fulfill the mandatory requirements is quite small -- we're not talking about IKE here. Far more problematic, however, is the lack of a common security substrate on the net. We know what that means in practice: no security at all in the vast majority of cases. Requiring IPsec at least gets us to the point where two nodes can have a secure conversation with any mix of traffic instead of the current mishmash of incomplete and often insecure other mechanisms (read: nothing in many important cases). I think I also disagree with Jari's characterization of fixed-purpose devices. The net is not the PSTN with exactly one application. Once you've enabled IP, you have instant access to zillions of applications, and a zillion more to come. While small boxen certainly will only implement a small fraction of those applications, we have not one clue *which* ones they'll be! Some may very well be UDP based, and thus TLS won't be of any use. So we'll be back to the same state of trying to shoe-horn protocols to meet security requirements via unnatural acts with TLS, often ill-conceived application layer security, or just plain ignoring the problem and hoping for the best. *Please* let's not go there. For the scant amount of flash and ram that IPsec requires we get a common baseline. This is desparately needed so that we at least have something to proceed from rather than the current chaos. IPsec is the security analog to TCP's reliable transport. Without TCP, protocol and application development would have been severely hampered. TCP's utility amongst other things was to simplify networking so that people other than net weenies could write applications. The same, I'm afraid, is true of crypto -- maybe even worse, because a cursory understanding of transport wasn't all that hard to come by even 20 years ago, whereas there's not a surer way of getting people's eyes to glaze over faster than talking about crypto in my experience. We really, really need some commonality. Let's not backtrack. Mike OKABE Nobuo writes: > Thank you for your many feedbacks. > > From: Jari Arkko > Subject: Re: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > Date: Mon, 04 Mar 2002 15:03:00 +0200 > > > Francis Dupont wrote: > > > > > => yes, ICMP is hard to protect and to use it for small services > > > does not make things simpler... > > > > So, we agree on this at least... > > > > > => there is an IAB statement about security. IPsec support was > > > made mandatory according to this statement and IMHO this was > > > a big step forward. There are other security mechanisms, > > > including some at the transport layer (SSL/TLS, IMHO IPsec > > > is better but real world considerations have to be considered :-) > > > and some at the application layer, with in some cases a very > > > different usage (PGP). > > > I have in favor of to make all core security mechanisms mandatory > > > (MUST or strong SHOULD), cf RFC 2316 section 10. IPsec is only > > > the first in the list. > > > > I'm partially in favor of this approach, but not entirely. > > I'd be much more comfortable with trying to make a detailed > > recommendation on where different mechanisms are applicable > > and mandated, than try to mandate them all everywhere (likely > > with less than 100% success among implementors). > > > > I think the general approach should be that security > > is mandatory, but not necessarily same type of security > > under all circumstances. > > I agree. > > If a very small host has single application (ex. web), > the implementer will want to implement an appropriate > security mechanism only (ex, TLS) because of fitting > its cost. > > It should be our further work to make detailed > guideline for LCNA part. > > ---- nobuo > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 4 09:33:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24HXJKL023801 for ; Mon, 4 Mar 2002 09:33:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24HXJk2023800 for ipng-dist; Mon, 4 Mar 2002 09:33:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24HXGKL023793 for ; Mon, 4 Mar 2002 09:33:16 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25167 for ; Mon, 4 Mar 2002 09:33:17 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20410 for ; Mon, 4 Mar 2002 10:33:16 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g24HXFB15641 for ; Mon, 4 Mar 2002 18:33:15 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Mar 04 18:33:15 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 18:33:24 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA6C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Michael Thomas'" , OKABE Nobuo Cc: "Jari Arkko (LMF)" , Francis.Dupont@enst-bretagne.fr, mrw@windriver.com, "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: RE: Should IP Security be Optional? Date: Mon, 4 Mar 2002 18:33:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike, Good points. So are you saying we should mandate ESP and AH but it's ok not to mandate IKE? and perhaps use something else for key distribution? I'm just trying to understand how to address these comments in the draft. Hesham > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, March 04, 2002 6:08 PM > To: OKABE Nobuo > Cc: Jari.Arkko@lmf.ericsson.se; Francis.Dupont@enst-bretagne.fr; > mrw@windriver.com; hesham.soliman@era.ericsson.se; > ipng@sunroof.eng.sun.com > Subject: Re: Should IP Security be Optional? > > > > So, talking about making exceptions to the MUST > IMPLEMENT aspect of ipsec on v6 strikes me as a > really poor idea. First of all, a minimum > implementation of IPsec to fulfill the mandatory > requirements is quite small -- we're not talking > about IKE here. Far more problematic, however, is > the lack of a common security substrate on the > net. We know what that means in practice: no > security at all in the vast majority of cases. > Requiring IPsec at least gets us to the point > where two nodes can have a secure conversation > with any mix of traffic instead of the current > mishmash of incomplete and often insecure other > mechanisms (read: nothing in many important > cases). > > I think I also disagree with Jari's > characterization of fixed-purpose devices. The net > is not the PSTN with exactly one application. > Once you've enabled IP, you have instant access to > zillions of applications, and a zillion more to > come. While small boxen certainly will only > implement a small fraction of those applications, > we have not one clue *which* ones they'll be! Some > may very well be UDP based, and thus TLS won't be > of any use. So we'll be back to the same state of > trying to shoe-horn protocols to meet security > requirements via unnatural acts with TLS, often > ill-conceived application layer security, or just > plain ignoring the problem and hoping for the > best. > > *Please* let's not go there. For the scant amount > of flash and ram that IPsec requires we get a > common baseline. This is desparately needed so > that we at least have something to proceed from > rather than the current chaos. IPsec is the > security analog to TCP's reliable transport. > Without TCP, protocol and application development > would have been severely hampered. TCP's utility > amongst other things was to simplify networking so > that people other than net weenies could write > applications. The same, I'm afraid, is true of > crypto -- maybe even worse, because a cursory > understanding of transport wasn't all that hard to > come by even 20 years ago, whereas there's not a > surer way of getting people's eyes to glaze over > faster than talking about crypto in my experience. > > We really, really need some commonality. Let's > not backtrack. > > Mike > > > OKABE Nobuo writes: > > Thank you for your many feedbacks. > > > > From: Jari Arkko > > Subject: Re: Should IP Security be Optional? [Was RE: > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > Date: Mon, 04 Mar 2002 15:03:00 +0200 > > > > > Francis Dupont wrote: > > > > > > > => yes, ICMP is hard to protect and to use it for > small services > > > > does not make things simpler... > > > > > > So, we agree on this at least... > > > > > > > => there is an IAB statement about security. IPsec > support was > > > > made mandatory according to this statement and IMHO this was > > > > a big step forward. There are other security mechanisms, > > > > including some at the transport layer (SSL/TLS, IMHO IPsec > > > > is better but real world considerations have to be > considered :-) > > > > and some at the application layer, with in some cases a very > > > > different usage (PGP). > > > > I have in favor of to make all core security > mechanisms mandatory > > > > (MUST or strong SHOULD), cf RFC 2316 section 10. > IPsec is only > > > > the first in the list. > > > > > > I'm partially in favor of this approach, but not entirely. > > > I'd be much more comfortable with trying to make a detailed > > > recommendation on where different mechanisms are applicable > > > and mandated, than try to mandate them all everywhere (likely > > > with less than 100% success among implementors). > > > > > > I think the general approach should be that security > > > is mandatory, but not necessarily same type of security > > > under all circumstances. > > > > I agree. > > > > If a very small host has single application (ex. web), > > the implementer will want to implement an appropriate > > security mechanism only (ex, TLS) because of fitting > > its cost. > > > > It should be our further work to make detailed > > guideline for LCNA part. > > > > ---- nobuo > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Mar 4 09:36:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24HaEKL023831 for ; Mon, 4 Mar 2002 09:36:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24HaEsm023830 for ipng-dist; Mon, 4 Mar 2002 09:36:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24HaBKL023822 for ; Mon, 4 Mar 2002 09:36:11 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24195 for ; Mon, 4 Mar 2002 09:36:12 -0800 (PST) Received: from server.pasta.cs.uit.no (server.pasta.cs.UiT.No [129.242.16.119]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26162 for ; Mon, 4 Mar 2002 09:36:10 -0800 (PST) Received: from dillema.net (drifter.dillema.net [3ffe:2a00:100:3002:240:96ff:fe48:bed2]) by server.pasta.cs.uit.no (8.11.6/8.11.3) with ESMTP id g24Ha9E04473 for ; Mon, 4 Mar 2002 18:36:09 +0100 (CET) Received: (from dillema@localhost) by dillema.net (8.11.6/8.11.6) id g24HXQg23278 for ipng@sunroof.eng.sun.com; Mon, 4 Mar 2002 18:33:26 +0100 (CET) X-Authentication-Warning: drifter.dillema.net: dillema set sender to feico@pasta.cs.uit.no using -f Date: Mon, 4 Mar 2002 18:33:26 +0100 From: Feico Dillema To: ipng@sunroof.eng.sun.com Subject: Re: Should connecting to the Internet be Optional? Message-ID: <20020304173326.GS10496@pasta.cs.uit.no> Mail-Followup-To: ipng@sunroof.eng.sun.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i X-Operating-System: NetBSD drifter.dillema.net 1.5ZA NetBSD 1.5ZA (DRIFTER) X-URL: http://www.dillema.net/ Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, Mar 04, 2002 at 09:06:47AM -0800, Tony Hain wrote: > On the subject of applications, the absolute BS about limiting the > application set to avoid an IPsec requirement is something that belongs > in a product development discussion, NOT a standards discussion. The one > point that should be clear is that over time the number of applications > used via wireless (cellular or otherwise) will grow, and that we can't > predict what they are, much less what they will need from the stack. To > that point, we MUST reiterate that ***ALL IPv6 IMPLEMENTATIONS MUST > INCLUDE SUPPORT FOR IPSEC***. If we relax that requirement, applications > will never be able to expect support, therefore will have to keep > inventing their own mechanisms. The only way to prevent new applications > from appearing on computing devices is to put the executable code in > non-rewritable, non-replaceable, rom. And require these devices to be tamper-proof ;-}. Feico. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 09:40:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24HefKL023855 for ; Mon, 4 Mar 2002 09:40:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24HeeqF023854 for ipng-dist; Mon, 4 Mar 2002 09:40:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24HebKL023847 for ; Mon, 4 Mar 2002 09:40:37 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25183 for ; Mon, 4 Mar 2002 09:40:39 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28325 for ; Mon, 4 Mar 2002 09:40:37 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g24HeaZc029657 for ; Mon, 4 Mar 2002 18:40:36 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Mar 04 18:40:36 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 18:30:50 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA6A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Tony Hain'" , ipng@sunroof.eng.sun.com Subject: RE: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 18:28:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, First of all, I think that connecting to the Internet MUST be madated, not optional :) Having cleared that out, I have a couple of comments below. While I am willing to believe that > there are valid > reasons to make adjustments based on characteristics of the > link, this > document is fundamentally flawed because it is based around > the pretense > that small footprint devices are somehow special. We MUST NOT allow > ourselves to modify well thought out architectural > fundamentals based on > point-in-time engineering constraints that are dubious at best. => That's a bit inaccurate, there is a major difference that is due to the BW contraints of the air link. I see your points about size and memory, but it would be good if we identify the parts related to size and memory in which the draft deviates from IPv6 standards and distinguish them from the BW and l2-specific impacts. > The argument that small devices have limited processors or memory > overlooks the fact that the processor and memory of many hand-held > devices today is significantly greater than the > workstations that were > available when IPv4 was defined. Interesting point; there > was no problem > getting the stack and an array of applications to fit then. Another > interesting point; there are frequently rumors that laptops > will include > cellular interfaces, so where does the processing and > memory constraint > fit in that case? => It doesn't. But this is a classical argument which essentially says :'if you can't build it now, wait for a few years and you'll fit everything in'... well, as an engineer I don't have a major problem with that, but if I was someone who's trying to sell a wide range of products for different market segments, and some of those need to be limited in many ways to be sellable at all, then I would have a problem with this logic. Again, to be able to improve the quality of the draft, we need to point out *exactly* where the relevant problems are. Margaret did some of this already and it is being discussed. > > If a document on cellular requirements makes any sense, it has to be > based on differences in fundamental characteristics of the > air link, not > the device on either end. Avoiding DAD simply due to > expense is not a > valid justification, but if the loss characteristics of the > link make it > more problematic than valuable, there may be an argument. => The document does NOT avoid DAD. The document is aimed at a generic cellular host, and wherever applicable, makes an applicability statement on the 3GPP-specific cases. The reason DAD is not needed in 3GPP, is that the way an address is allocated leaves no room for on-link duplication. And still, the document does not say, you MUST NOT do DAD, it simply says that in *this* instance of a cellular network, DAD is not needed. So if you just want to implement it anyway, then go ahead. > Keep in mind > that doing so precludes the use of RFC3041 addresses, so the > applications where anonymity is most valuable (as one moves > around and > doesn't movement traced) are precluded. => This is not a problem and address privacy is already supported without the need for DAD. The 3gpp-advice draft, the cellular host draft and 3GPP TS 23.060 can provide the exact details. A non-zero probability of > collision requires a mechanism to resolve duplicates, and DAD is the > currently defined one. If another one exists that makes > more sense over > a lossy air-link, we should consider replacing DAD because it will > probably be more reliable in the general case as well. => It doesn't make sense if a host gets a /64 prefix that can not be used by anyone else on the cellular interface. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 09:46:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24HkZKL023881 for ; Mon, 4 Mar 2002 09:46:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24HkZvZ023880 for ipng-dist; Mon, 4 Mar 2002 09:46:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24HkWKL023873 for ; Mon, 4 Mar 2002 09:46:32 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23122 for ; Mon, 4 Mar 2002 09:46:33 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13746 for ; Mon, 4 Mar 2002 10:46:32 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g24HkWB19701 for ; Mon, 4 Mar 2002 18:46:32 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Mar 04 18:46:31 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 18:36:45 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFBE@esealnt117> From: "Karim El-Malki (ERA)" To: "'Tony Hain'" , ipng@sunroof.eng.sun.com Subject: RE: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 18:45:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A non-zero probability of > collision requires a mechanism to resolve duplicates, and DAD is the > currently defined one. If another one exists that makes more > sense over > a lossy air-link, we should consider replacing DAD because it will > probably be more reliable in the general case as well. No need to replace DAD but just allow it to be disabled on some links. The previous discussion with Francis seemed to point to the issue that PPP links where some form of prefix delegation occurs can do without DADs. As commented already, RFC3041 would work. Regards, /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 09:50:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24HoNKL023919 for ; Mon, 4 Mar 2002 09:50:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24HoNxl023918 for ipng-dist; Mon, 4 Mar 2002 09:50:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24HoJKL023911 for ; Mon, 4 Mar 2002 09:50:19 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28080 for ; Mon, 4 Mar 2002 09:50:21 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06040 for ; Mon, 4 Mar 2002 09:50:20 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g24HoJd22273; Mon, 4 Mar 2002 09:50:19 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAZ71190; Mon, 4 Mar 2002 09:49:51 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA03878; Mon, 4 Mar 2002 09:50:17 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15491.46041.481887.601707@thomasm-u1.cisco.com> Date: Mon, 4 Mar 2002 09:50:17 -0800 (PST) To: "Hesham Soliman (ERA)" Cc: "'Michael Thomas'" , OKABE Nobuo , "Jari Arkko (LMF)" , Francis.Dupont@enst-bretagne.fr, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: RE: Should IP Security be Optional? In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AA6C@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053802C6AA6C@Esealnt861.al.sw.ericsson.se> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham Soliman (ERA) writes: > Mike, > > Good points. So are you saying we should > mandate ESP and AH but it's ok not to mandate > IKE? and perhaps use something else for > key distribution? I think the v6 host requirements struck the right balance: require the IP packet layer transforms, and be silent on key distribution. Key distribution is clearly a huge problem, but IPsec doesn't mandate a single solution so I don't see why the cellular requirements draft should either. You can run IPsec with manually configured keys, after all, so at a base level you can get interoperability. This is foward progress IMO, even though we clearly need more going forward. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 09:56:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24HugKL023954 for ; Mon, 4 Mar 2002 09:56:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24Hugja023953 for ipng-dist; Mon, 4 Mar 2002 09:56:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24HuaKL023940 for ; Mon, 4 Mar 2002 09:56:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29665 for ; Mon, 4 Mar 2002 09:56:38 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08960 for ; Mon, 4 Mar 2002 09:56:38 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g24HuTe06148; Mon, 4 Mar 2002 09:56:29 -0800 (PST) Message-ID: <00c401c1c3a5$afea69c0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "Margaret Wasserman" Cc: References: <4.2.2.20020304023354.020acc20@mail.windriver.com> Subject: Re: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Mon, 4 Mar 2002 09:54:52 -0800 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.50.4522.1200 x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, > I don't think that we should publish an informational document that > advises some implementors to do something that specifically > disagrees with a MUST requirement in a standards-track document. > If the standards-track document is broken, we need to fix it > instead. > DAD has a substantial performance impact on handover if the Mobile IPv6 care of address is changed. If the address provision scheme is such that duplicate addresses are not possible, then I believe it should be possible to disable it. I agree that the change must be made in the standards-track document. Perhaps we could quickly get a short document that describes when DAD can be disabled, so that the issue can be resolved as quickly as possible. In the Mobile IPv6 specification, DAD is only a MAY. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 10:21:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24ILYKL024035 for ; Mon, 4 Mar 2002 10:21:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24ILYaM024034 for ipng-dist; Mon, 4 Mar 2002 10:21:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24ILUKL024027 for ; Mon, 4 Mar 2002 10:21:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05706 for ; Mon, 4 Mar 2002 10:21:30 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA05908 for ; Mon, 4 Mar 2002 11:21:29 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g24ILPF26319; Mon, 4 Mar 2002 13:21:27 -0500 (EST) Message-Id: <200203041821.g24ILPF26319@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Tony Hain" cc: ipng@sunroof.eng.sun.com Subject: Re: Should connecting to the Internet be Optional? In-reply-to: (Your message of "Mon, 04 Mar 2002 09:06:47 PST.") Date: Mon, 04 Mar 2002 13:21:25 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On the subject of applications, the absolute BS about limiting the > application set to avoid an IPsec requirement is something that belongs > in a product development discussion, NOT a standards discussion. The one > point that should be clear is that over time the number of applications > used via wireless (cellular or otherwise) will grow, and that we can't > predict what they are, much less what they will need from the stack. To > that point, we MUST reiterate that ***ALL IPv6 IMPLEMENTATIONS MUST > INCLUDE SUPPORT FOR IPSEC***. If we relax that requirement, applications > will never be able to expect support, therefore will have to keep > inventing their own mechanisms. The only way to prevent new applications > from appearing on computing devices is to put the executable code in > non-rewritable, non-replaceable, rom. actually, I disagree, slightly. I think we designed these rules for general-purpose hosts and it's not necessarily a good idea to make them apply to fixed-function devices. if none of the applications on a host can make use of IPsec, and the host is inherently not configurable to set policy based on IPsec then I don't see why the host should have to implement IPsec. OTOH as soon as you make the host programmable, or make it possible to set policy on the host then it's worth considering whether IPsec should be a requirement again. similarly, a host that is strictly an endpoint and has no way of routing messages to other hosts doesn't need to support routing protocols. but as soon as the host can route messages to other hosts (such as via the data port of a cell phone) then it needs to be able to act as a router. (I also think the requirement to impose IPsec on hosts is of dubious value unless IPsec is usable by applications, but that's a separate discussion.) I think the cell phone requirements document would do well to break down the different cases: - cell phone with fixed functions vs. - cell phone that can host applications - cell phone that is strictly an endpoint vs. - cell phone that can provide net connectivity to other devices and examine requirements separately for each case. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 10:47:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24IlhKL024115 for ; Mon, 4 Mar 2002 10:47:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24IlhiL024114 for ipng-dist; Mon, 4 Mar 2002 10:47:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24IldKL024107 for ; Mon, 4 Mar 2002 10:47:39 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21991 for ; Mon, 4 Mar 2002 10:47:38 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02335 for ; Mon, 4 Mar 2002 10:47:33 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 04 Mar 2002 10:47:31 -0800 From: "Tony Hain" To: "Hesham Soliman \(ERA\)" , Subject: RE: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 10:47:31 -0800 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AA6A@Esealnt861.al.sw.ericsson.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham Soliman wrote: > First of all, I think that connecting to the > Internet MUST be madated, not optional :) I am glad we agree. > ... > => That's a bit inaccurate, there is a major difference > that is due to the BW contraints of the air link. > I see your points about size and memory, but it would > be good if we identify the parts related to size > and memory in which the draft deviates from IPv6 > standards and distinguish them from the BW and > l2-specific impacts. Let's not go there. Those of us with lots of grey recall the days when half the 3G bandwidth cost in the 6 figure range a month, with loss and latencies were about the same as the 3G link. Yes it is a constrained environment relative to other options today, but there is nothing inherent in the BW, loss, latency, cost that limits the potential for use as a packet network. While we can't assume that everything is reasonable in the constrained environment, we also shouldn't be throwing out capabilities that history has proven useful simply because they are hard or cost a little more. > > => It doesn't. But this is a classical argument > which essentially says :'if you can't build it > now, wait for a few years and you'll fit everything > in'... well, as an engineer I don't have a major > problem with that, but if I was someone who's > trying to sell a wide range of products for > different market segments, and some of those > need to be limited in many ways to be sellable > at all, then I would have a problem with this > logic. Product decisions beyond what is technically possible don't belong in the discussion about standards. My son's 3-year old calculator has more low-power CPU & memory than the SGI workstation I had 10 years ago, and it would fit in a package small enough for a 3G handset (and has a longer battery life than my phone). I have to believe that there are better options out there now (at least 5 years after that device design was done), so the fact that a product team doesn't want to use those for a specific market is not a problem for the IETF. > > Again, to be able to improve the quality of the > draft, we need to point out *exactly* where > the relevant problems are. Margaret did some > of this already and it is being discussed. I only had time for a quick pass this morning, and don't expect to get much more this month. Not that my personal time should drive a WG schedule, but if Margret raised several questions, and my quick pass found fundamental issues, I would argue that this doc is not even close to ready for last call. > > => The document does NOT avoid DAD. The document > is aimed at a generic cellular host, and wherever > applicable, makes an applicability statement on the > 3GPP-specific cases. The reason DAD is not needed > in 3GPP, is that the way an address is allocated > leaves no room for on-link duplication. And still, > the document does not say, you MUST NOT do DAD, > it simply says that in *this* instance of a cellular > network, DAD is not needed. So if you just want > to implement it anyway, then go ahead. 'A cellular host SHOULD NOT perform Duplicate Address Detection...' While that is not a MUST NOT, it is a very strong instruction to avoid it. If it said something like 'A cellular host MAY choose NOT perform Duplicate Address Detection when it has other means to ensure uniqueness...' I would be less concerned. > > > Keep in mind > > that doing so precludes the use of RFC3041 addresses, so the > > applications where anonymity is most valuable (as one moves > > around and > > doesn't movement traced) are precluded. > > => This is not a problem and address privacy is already > supported without the need for DAD. > The 3gpp-advice draft, the cellular host draft > and 3GPP TS 23.060 can provide the exact details. If there is something specific that makes the statement true, it should be written here so people don't have to chase around to find it. The only thing that might make it true is that the router interface on the subnet will ALWAYS have the 'unique bit' set in an EUI-64 derived address, and will never use another format. This also presumes that the handset doesn't provide layer-2 bridging services to other locally connected devices. If it does that then there is no guarantee that some device on the allocated subnet will not collide. > > A non-zero probability of > > collision requires a mechanism to resolve duplicates, and > DAD is the > > currently defined one. If another one exists that makes > > more sense over > > a lossy air-link, we should consider replacing DAD because it will > > probably be more reliable in the general case as well. > > => It doesn't make sense if a host gets a /64 > prefix that can not be used by anyone else on > the cellular interface. See previous comment about L2 bridging by the handset/embedded device in a laptop ... Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 4 11:04:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24J4JKL024149 for ; Mon, 4 Mar 2002 11:04:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24J4Jm2024148 for ipng-dist; Mon, 4 Mar 2002 11:04:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24J4FKL024141 for ; Mon, 4 Mar 2002 11:04:15 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29434 for ; Mon, 4 Mar 2002 11:04:15 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11761 for ; Mon, 4 Mar 2002 11:04:13 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 04 Mar 2002 11:04:10 -0800 From: "Tony Hain" To: Cc: Subject: RE: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 11:04:10 -0800 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200203041821.g24ILPF26319@astro.cs.utk.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > I think the cell phone requirements document would do well to break > down the different cases: > > - cell phone with fixed functions vs. > - cell phone that can host applications > > - cell phone that is strictly an endpoint vs. > - cell phone that can provide net connectivity to other devices > > and examine requirements separately for each case. I agree with one comment: > > The only way to prevent new applications > > from appearing on computing devices is to put the executable code in > > non-rewritable, non-replaceable, rom. > And require these devices to be tamper-proof ;-}. > > Feico. Tony Actually another thought; what is the difference between a handset and a laptop that has an embedded 3G radio? Are they both cellular hosts? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 11:18:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24JIPKL024186 for ; Mon, 4 Mar 2002 11:18:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24JIPTv024185 for ipng-dist; Mon, 4 Mar 2002 11:18:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24JIMKL024178 for ; Mon, 4 Mar 2002 11:18:22 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11095 for ; Mon, 4 Mar 2002 11:18:22 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA09072 for ; Mon, 4 Mar 2002 12:18:21 -0700 (MST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Mar 2002 14:11:32 -0500 Message-ID: From: Phil Roberts To: "'juha.wiljakka@nokia.com'" , hinden@iprg.nokia.com, deering@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Date: Mon, 4 Mar 2002 14:11:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm a little bit concerned about the mobility sections of this doc. It recommends supporting two drafts that are far from complete in the MIP working group (HMIP and fast handovers) and where it's hard to say exactly how those drafts will dome out. I'm also not sure how fast handovers would be used in this context. Hopefully MIPv6 itself will be done soon.... > -----Original Message----- > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > Sent: Thursday, February 28, 2002 7:29 AM > To: hinden@iprg.nokia.com; deering@cisco.com > Cc: ipng@sunroof.eng.sun.com > Subject: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? > > > > Hi! > > We "cellular host IPv6" draft authors believe that our draft > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellular-host-00.txt would be ready for wg last call. Bob and Steve, if there are no objections from the WG, could you please consider announcing last call for this draft? Thank You. On behalf of all the authors, Juha Wiljakka -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Mar 4 11:27:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24JRLKL024211 for ; Mon, 4 Mar 2002 11:27:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24JRK6k024210 for ipng-dist; Mon, 4 Mar 2002 11:27:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24JRHKL024203 for ; Mon, 4 Mar 2002 11:27:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23435 for ; Mon, 4 Mar 2002 11:27:17 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12690 for ; Mon, 4 Mar 2002 12:27:16 -0700 (MST) Received: from jariws1 ([62.248.154.8]) by fep07-app.kolumbus.fi with SMTP id <20020304192626.EUFW13233.fep07-app.kolumbus.fi@jariws1>; Mon, 4 Mar 2002 21:26:26 +0200 Message-ID: <014601c1c3b2$a07c9a00$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Michael Thomas" , "Hesham Soliman \(ERA\)" Cc: "'Michael Thomas'" , "OKABE Nobuo" , "Jari Arkko \(LMF\)" , , , References: <4DA6EA82906FD511BE2F00508BCF053802C6AA6C@Esealnt861.al.sw.ericsson.se> <15491.46041.481887.601707@thomasm-u1.cisco.com> Subject: Re: Should IP Security be Optional? Date: Mon, 4 Mar 2002 21:27:30 +0200 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mike wrote: > > Good points. So are you saying we should > > mandate ESP and AH but it's ok not to mandate > > IKE? and perhaps use something else for > > key distribution? > > I think the v6 host requirements struck the right > balance: require the IP packet layer transforms, > and be silent on key distribution. Key > distribution is clearly a huge problem, but IPsec > doesn't mandate a single solution so I don't see > why the cellular requirements draft should either. > You can run IPsec with manually configured keys, > after all, so at a base level you can get > interoperability. This is foward progress IMO, > even though we clearly need more going forward. I do agree that the ESP and AH are really simple and easy compared to the rest. Unfortunately, this isn't going to be quite as easy as that. As we point out in section 3.8 the current cellular networks sometimes have dynamic IP address changes, and therefore manually keyed IPsec isn't going to work as such and key management is needed. While there might be multiple options here, interoperability is a concern and hence I feel that we must have a mandated key management scheme. In the cellular host requirements draft, we have chosen to say that IKE is a MUST in those cases where we mandate IPsec. Do you disagree? (In a way you could say that the cellular draft goes *beyond* what the current IETF MUSTs are, given that we mandate a full security solution in all cases, though at the same time we don't mandate the current requirement of AH and ESP in all cases.) Anyway, this is just *our* proposal on what we think would make sense. But the document is controlled by the WG; please state your proposed security MUSTs for IPv6 hosts, cellular or otherwise. Mike, what would you like to have there, for instance? Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 11:35:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24JZiKL024240 for ; Mon, 4 Mar 2002 11:35:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24JZhE8024239 for ipng-dist; Mon, 4 Mar 2002 11:35:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24JZeKL024232 for ; Mon, 4 Mar 2002 11:35:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA25883 for ; Mon, 4 Mar 2002 11:35:41 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19316 for ; Mon, 4 Mar 2002 12:35:40 -0700 (MST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Mar 2002 14:28:51 -0500 Message-ID: From: Phil Roberts To: "'Tony Hain'" , ipng@sunroof.eng.sun.com Subject: RE: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 14:28:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Having read through this thread now, might it be better to recast this document more along the lines of functions supported on the cellular interface rather than requirements for host? Some substantial number of devices for which this is targeted will be dual network interface capable and for the other interface some of these optimizations don't make sense. The Mobile IPv6 related specifications for the time being only make sense with such a dual network interface capable device, which means the optimizations recommended on the cell facing interface in many cases SHOULDN'T be recommended on the other interfaces. > -----Original Message----- > From: Tony Hain [mailto:tony@tndh.net] > Sent: Monday, March 04, 2002 12:07 PM > To: ipng@sunroof.eng.sun.com > Subject: Should connecting to the Internet be Optional? > Importance: High > > > Margret has raised several valuable questions about > draft-ietf-ipv6-cellular-host-00.txt, which show it is > clearly is not ready for last call. While I am willing to > believe that there are valid reasons to make adjustments > based on characteristics of the link, this document is > fundamentally flawed because it is based around the pretense > that small footprint devices are somehow special. We MUST NOT > allow ourselves to modify well thought out architectural > fundamentals based on point-in-time engineering constraints > that are dubious at best. If a device wants to participate as > an Internet node, there are basic requirements. Of course, > participating in the Internet is optional, so if a device > would prefer to avoid the requirements, it may choose to > create its own universe. > > The argument that small devices have limited processors or > memory overlooks the fact that the processor and memory of > many hand-held devices today is significantly greater than > the workstations that were available when IPv4 was defined. > Interesting point; there was no problem getting the stack and > an array of applications to fit then. Another interesting > point; there are frequently rumors that laptops will include > cellular interfaces, so where does the processing and memory > constraint fit in that case? > > On the subject of applications, the absolute BS about > limiting the application set to avoid an IPsec requirement is > something that belongs in a product development discussion, > NOT a standards discussion. The one point that should be > clear is that over time the number of applications used via > wireless (cellular or otherwise) will grow, and that we can't > predict what they are, much less what they will need from the > stack. To that point, we MUST reiterate that ***ALL IPv6 > IMPLEMENTATIONS MUST INCLUDE SUPPORT FOR IPSEC***. If we > relax that requirement, applications will never be able to > expect support, therefore will have to keep inventing their > own mechanisms. The only way to prevent new applications from > appearing on computing devices is to put the executable code > in non-rewritable, non-replaceable, rom. > > If a document on cellular requirements makes any sense, it > has to be based on differences in fundamental characteristics > of the air link, not the device on either end. Avoiding DAD > simply due to expense is not a valid justification, but if > the loss characteristics of the link make it more problematic > than valuable, there may be an argument. Keep in mind that > doing so precludes the use of RFC3041 addresses, so the > applications where anonymity is most valuable (as one moves > around and doesn't movement traced) are precluded. A non-zero > probability of collision requires a mechanism to resolve > duplicates, and DAD is the currently defined one. If another > one exists that makes more sense over a lossy air-link, we > should consider replacing DAD because it will probably be > more reliable in the general case as well. > > Tony > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 11:37:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24JbHKL024259 for ; Mon, 4 Mar 2002 11:37:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24JbH47024258 for ipng-dist; Mon, 4 Mar 2002 11:37:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24JbDKL024251 for ; Mon, 4 Mar 2002 11:37:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07324 for ; Mon, 4 Mar 2002 11:37:14 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA18923 for ; Mon, 4 Mar 2002 12:37:13 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g24JbBZc021043 for ; Mon, 4 Mar 2002 20:37:11 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Mar 04 20:37:11 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 20:37:20 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA74@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Tony Hain'" , ipng@sunroof.eng.sun.com Subject: RE: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 20:34:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => That's a bit inaccurate, there is a major difference > > that is due to the BW contraints of the air link. > > I see your points about size and memory, but it would > > be good if we identify the parts related to size > > and memory in which the draft deviates from IPv6 > > standards and distinguish them from the BW and > > l2-specific impacts. > > Let's not go there. Those of us with lots of grey recall > the days when > half the 3G bandwidth cost in the 6 figure range a month, > with loss and > latencies were about the same as the 3G link. Yes it is a > constrained > environment relative to other options today, but there is nothing > inherent in the BW, loss, latency, cost that limits the > potential for > use as a packet network. While we can't assume that everything is > reasonable in the constrained environment, we also > shouldn't be throwing > out capabilities that history has proven useful simply > because they are > hard or cost a little more. => OK, there is no point in arguing this particular point without pointing out the relevant parts of the draft. After all we want to get feedback that will improve the quality of the draft. > Product decisions beyond what is technically possible don't > belong in > the discussion about standards. My son's 3-year old > calculator has more > low-power CPU & memory than the SGI workstation I had 10 > years ago, and > it would fit in a package small enough for a 3G handset (and has a > longer battery life than my phone). I have to believe that there are > better options out there now (at least 5 years after that > device design > was done), so the fact that a product team doesn't want to > use those for > a specific market is not a problem for the IETF. => OK, same comment as above. > > Again, to be able to improve the quality of the > > draft, we need to point out *exactly* where > > the relevant problems are. Margaret did some > > of this already and it is being discussed. > > I only had time for a quick pass this morning, and don't > expect to get > much more this month. Not that my personal time should drive a WG > schedule, but if Margret raised several questions, and my quick pass > found fundamental issues, I would argue that this doc is > not even close > to ready for last call. => Maragret's comments are being discussed and we should definitely discuss your concerns as well. But my point is, if the draft is not ready we need some concrete reasons to be able to improve it. Experience also shows that ignoring other organisations' reasons or business models will not help in developing the Internet that we'd like to see. I'm not suggesting that you're ignoring it, but I want to highlight the importance of participating in the work. > > > > > => The document does NOT avoid DAD. The document > > is aimed at a generic cellular host, and wherever > > applicable, makes an applicability statement on the > > 3GPP-specific cases. The reason DAD is not needed > > in 3GPP, is that the way an address is allocated > > leaves no room for on-link duplication. And still, > > the document does not say, you MUST NOT do DAD, > > it simply says that in *this* instance of a cellular > > network, DAD is not needed. So if you just want > > to implement it anyway, then go ahead. > > 'A cellular host SHOULD NOT perform Duplicate Address Detection...' > While that is not a MUST NOT, it is a very strong > instruction to avoid > it. If it said something like 'A cellular host MAY choose > NOT perform > Duplicate Address Detection when it has other means to ensure > uniqueness...' I would be less concerned. => You're quoting a section written specifically for _3GPP_cellular_hosts. As I tried to explain in *this* particular cellular network DAD is not useful at all, it just wastes BW. But this statement was not made for *all* cellular hosts. > > > Keep in mind > > > that doing so precludes the use of RFC3041 addresses, so the > > > applications where anonymity is most valuable (as one moves > > > around and > > > doesn't movement traced) are precluded. > > > > => This is not a problem and address privacy is already > > supported without the need for DAD. > > The 3gpp-advice draft, the cellular host draft > > and 3GPP TS 23.060 can provide the exact details. > > If there is something specific that makes the statement > true, it should > be written here so people don't have to chase around to find it. => Appendix B of the draft explains this, and so does the advice draft. The > only thing that might make it true is that the router > interface on the > subnet will ALWAYS have the 'unique bit' set in an EUI-64 derived > address, and will never use another format. This also > presumes that the > handset doesn't provide layer-2 bridging services to other locally > connected devices. If it does that then there is no > guarantee that some > device on the allocated subnet will not collide. => Well, bridging is not the only/best way of connecting other devices to the cellular network. The mobile terminal can also be a router or an MLSN. Bridging will introduce a lot of other complexities in the current 3GPP architecture. If you're interested we can discuss it offline because it's very specific and will probably bore everyone else. > > A non-zero probability of > > > collision requires a mechanism to resolve duplicates, and > > DAD is the > > > currently defined one. If another one exists that makes > > > more sense over > > > a lossy air-link, we should consider replacing DAD > because it will > > > probably be more reliable in the general case as well. > > > > => It doesn't make sense if a host gets a /64 > > prefix that can not be used by anyone else on > > the cellular interface. > > See previous comment about L2 bridging by the > handset/embedded device in > a laptop ... => I don't know why you need it if you have the /64. But anyway if you want bridging it can work when simply running a PPP link between the phone and other devices behind it. Hesham > > Tony > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 4 11:38:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24JcWKL024279 for ; Mon, 4 Mar 2002 11:38:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24JcWQ4024278 for ipng-dist; Mon, 4 Mar 2002 11:38:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24JcTKL024271 for ; Mon, 4 Mar 2002 11:38:29 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26391 for ; Mon, 4 Mar 2002 11:38:29 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01703 for ; Mon, 4 Mar 2002 11:38:28 -0800 (PST) Received: from jariws1 ([62.248.154.8]) by fep07-app.kolumbus.fi with SMTP id <20020304193738.EVML13233.fep07-app.kolumbus.fi@jariws1>; Mon, 4 Mar 2002 21:37:38 +0200 Message-ID: <015e01c1c3b4$316644c0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Keith Moore" , "Tony Hain" Cc: References: <200203041821.g24ILPF26319@astro.cs.utk.edu> Subject: Re: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 21:38:43 +0200 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > - cell phone with fixed functions vs. > - cell phone that can host applications This is an interesting division and perhaps an important one. There's by the way different kinds of 'fixedness' -- complete burn-in fixed systems and upgrade-at-the-dealer systems. In the latter case typically all of the software gets changed at the same time, so for the purposes of requiring something from the IP stack it's pretty similar to completely fixed systems. Hosts that can run new apps per user request are a different class from these as you point out. > - cell phone that is strictly an endpoint vs. > - cell phone that can provide net connectivity to other devices On this one I think we have made the case very clear by talking about _host_ requirements document. The router case is important, but left as a future exercise. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 11:49:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24JnOKL024323 for ; Mon, 4 Mar 2002 11:49:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24JnOGs024322 for ipng-dist; Mon, 4 Mar 2002 11:49:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24JnLKL024315 for ; Mon, 4 Mar 2002 11:49:21 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA18507 for ; Mon, 4 Mar 2002 11:49:21 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29885 for ; Mon, 4 Mar 2002 11:49:21 -0800 (PST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g24JnIE08618; Mon, 4 Mar 2002 11:49:18 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAZ75287; Mon, 4 Mar 2002 11:48:52 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA03887; Mon, 4 Mar 2002 11:49:17 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15491.53181.845986.788655@thomasm-u1.cisco.com> Date: Mon, 4 Mar 2002 11:49:17 -0800 (PST) To: "Jari Arkko" Cc: "Michael Thomas" , "Hesham Soliman \(ERA\)" , "OKABE Nobuo" , "Jari Arkko \(LMF\)" , , , Subject: Re: Should IP Security be Optional? In-Reply-To: <014601c1c3b2$a07c9a00$8a1b6e0a@arenanet.fi> References: <4DA6EA82906FD511BE2F00508BCF053802C6AA6C@Esealnt861.al.sw.ericsson.se> <15491.46041.481887.601707@thomasm-u1.cisco.com> <014601c1c3b2$a07c9a00$8a1b6e0a@arenanet.fi> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari Arkko writes: > As we point out in section 3.8 the current > cellular networks sometimes have dynamic IP > address changes, and therefore manually keyed IPsec > isn't going to work as such and key management is > needed. While there might be multiple options > here, interoperability is a concern and hence > I feel that we must have a mandated key management > scheme. In the cellular host requirements draft, we > have chosen to say that IKE is a MUST in those > cases where we mandate IPsec. Do you disagree? I don't know; it depends on what you're trying to accomplish. Is there a reason that you must choose one? I agree that dynamic addresses makes manual keying problematic, but I'm not sure that it follows that you need to pick one keying scheme. Even with IKE, there's room for interoperability issues (some might say far too much room, but I digress). > (In a way you could say that the cellular draft goes > *beyond* what the current IETF MUSTs are, given > that we mandate a full security solution in all cases, > though at the same time we don't mandate the current > requirement of AH and ESP in all cases.) Well, at its base it's about what needs to be implemented, right? > Anyway, this is just *our* proposal on what we think > would make sense. But the document is controlled by the > WG; please state your proposed security MUSTs for > IPv6 hosts, cellular or otherwise. Mike, what would you > like to have there, for instance? My personal feeling is that the ng working group has the consensus about right. We need a base level set of mechanisms for protecting IP packets. Since this is normally kernel level work, having a strong statement here is useful. And while I think there's pretty good consensus that IPsec (eg, not IKE) is a a stable and mature, there's equally good consensus that IKE is not. Given KINK and JFK/IKEv2 -- not to mention how widespread transport mode keying really gets deployed -- I'm not sure that I'd want to choose any one at this point. I personally think that the Kerberos based keying is well suited to high fan out kinds of applications like telephony, but I wouldn't claim that it is the only way (or The Way) to approach the problem of keying. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 11:54:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24JsdKL024357 for ; Mon, 4 Mar 2002 11:54:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24JsdTs024356 for ipng-dist; Mon, 4 Mar 2002 11:54:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24JsaKL024349 for ; Mon, 4 Mar 2002 11:54:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12967 for ; Mon, 4 Mar 2002 11:54:33 -0800 (PST) From: juha.wiljakka@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01889 for ; Mon, 4 Mar 2002 11:54:32 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g24JseZ26193 for ; Mon, 4 Mar 2002 21:54:40 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Mar 2002 21:54:31 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Mon, 4 Mar 2002 21:54:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 21:54:30 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F7856A4@esebe005.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should connecting to the Internet be Optional? Thread-Index: AcHDr6uXaWPxCx7ASHOfWx4bck7RUwAAX0iQ To: , Cc: X-OriginalArrivalTime: 04 Mar 2002 19:54:31.0352 (UTC) FILETIME=[66756B80:01C1C3B6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g24JsaKL024350 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! Just commenting the possible differences between laptops and cellular terminals... There are different kinds of laptops and also different kinds of cellular hosts. Our intention is to write this specification as "minimum IPv6 functionality for a cellular host", i.e. not defining any kind of 'maximum set of functionality'. And this kind of minimum functionality should be possible to be implemented in even the smallest 2,5G / 3G cellular handsets. An example of dimensions for such a handset could be 11 x 5 x 2 centimeters (1 inch = 2,54 centimeters). Could you compare such a terminal to a laptop computer? Hardly. Of course, then there are communicator / PDA type of devices having bigger processor capacity and memory making it possible to install more demanding applications in them, but even those devices cannot (in my opinion) be directly compared to laptops. As a summary, a cellular host (often) has limited size, memory, processor capacity and battery capacity / power consumption. The users would like to see their terminals to be usable for quite a long time (typically for some days, at least stand-by time) without re-charging them. Cheers, -Juha W.- -----Original Message----- From: ext Tony Hain [mailto:tony@tndh.net] Sent: 04 March, 2002 21:04 To: moore@cs.utk.edu Cc: ipng@sunroof.eng.sun.com Subject: RE: Should connecting to the Internet be Optional? Keith Moore wrote: > I think the cell phone requirements document would do well to break > down the different cases: > > - cell phone with fixed functions vs. > - cell phone that can host applications > > - cell phone that is strictly an endpoint vs. > - cell phone that can provide net connectivity to other devices > > and examine requirements separately for each case. I agree with one comment: > > The only way to prevent new applications > > from appearing on computing devices is to put the executable code in > > non-rewritable, non-replaceable, rom. > And require these devices to be tamper-proof ;-}. > > Feico. Tony Actually another thought; what is the difference between a handset and a laptop that has an embedded 3G radio? Are they both cellular hosts? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Mar 4 12:01:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24K1oKL024424 for ; Mon, 4 Mar 2002 12:01:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24K1oNa024423 for ipng-dist; Mon, 4 Mar 2002 12:01:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24K1lKL024416 for ; Mon, 4 Mar 2002 12:01:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15313 for ; Mon, 4 Mar 2002 12:01:48 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA03755 for ; Mon, 4 Mar 2002 13:01:46 -0700 (MST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Mar 2002 14:54:57 -0500 Message-ID: From: Phil Roberts To: "'juha.wiljakka@nokia.com'" , tony@tndh.net, moore@cs.utk.edu Cc: ipng@sunroof.eng.sun.com Subject: RE: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 14:54:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, this needs to be spelled out in some detail then. I'm already mentally thinking of PocketPC kinds of devices whenever I here cellular hosts.... > -----Original Message----- > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > Sent: Monday, March 04, 2002 2:55 PM > To: tony@tndh.net; moore@cs.utk.edu > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Should connecting to the Internet be Optional? > > > > Hi! > > Just commenting the possible differences between laptops and > cellular terminals... > > There are different kinds of laptops and also different kinds > of cellular hosts. Our intention is to write this > specification as "minimum IPv6 functionality for a cellular > host", i.e. not defining any kind of 'maximum set of > functionality'. And this kind of minimum functionality should > be possible to be implemented in even the smallest 2,5G / 3G > cellular handsets. An example of dimensions for such a > handset could be 11 x 5 x 2 centimeters (1 inch = 2,54 > centimeters). Could you compare such a terminal to a laptop > computer? Hardly. > > Of course, then there are communicator / PDA type of devices > having bigger processor capacity and memory making it > possible to install more demanding applications in them, but > even those devices cannot (in my opinion) be directly > compared to laptops. > > As a summary, a cellular host (often) has limited size, > memory, processor capacity and battery capacity / power > consumption. The users would like to see their terminals to > be usable for quite a long time (typically for some days, at > least stand-by time) without re-charging them. > > Cheers, > -Juha W.- > > -----Original Message----- > From: ext Tony Hain [mailto:tony@tndh.net] > Sent: 04 March, 2002 21:04 > To: moore@cs.utk.edu > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Should connecting to the Internet be Optional? > > > Keith Moore wrote: > > I think the cell phone requirements document would do well to break > > down the different cases: > > > > - cell phone with fixed functions vs. > > - cell phone that can host applications > > > > - cell phone that is strictly an endpoint vs. > > - cell phone that can provide net connectivity to other devices > > > > and examine requirements separately for each case. > > I agree with one comment: > > > The only way to prevent new applications > > > from appearing on computing devices is to put the > executable code in > > > non-rewritable, non-replaceable, rom. > > And require these devices to be tamper-proof ;-}. > > > > Feico. > > Tony > > Actually another thought; what is the difference between a > handset and a laptop that has an embedded 3G radio? Are they > both cellular hosts? > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 4 12:09:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24K9XKL024475 for ; Mon, 4 Mar 2002 12:09:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24K9Xna024474 for ipng-dist; Mon, 4 Mar 2002 12:09:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24K9TKL024467 for ; Mon, 4 Mar 2002 12:09:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA25278 for ; Mon, 4 Mar 2002 12:09:30 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18578 for ; Mon, 4 Mar 2002 13:09:25 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g24K9HF27009; Mon, 4 Mar 2002 15:09:18 -0500 (EST) Message-Id: <200203042009.g24K9HF27009@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Jari Arkko" cc: "Keith Moore" , "Tony Hain" , ipng@sunroof.eng.sun.com Subject: Re: Should connecting to the Internet be Optional? In-reply-to: (Your message of "Mon, 04 Mar 2002 21:38:43 +0200.") <015e01c1c3b4$316644c0$8a1b6e0a@arenanet.fi> Date: Mon, 04 Mar 2002 15:09:17 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > - cell phone that is strictly an endpoint vs. > > - cell phone that can provide net connectivity to other devices > > On this one I think we have made the case very clear > by talking about _host_ requirements document. The > router case is important, but left as a future exercise. Given that *existing* cell phones already act as (two-port) IP routers, I don't think it's a good idea to defer that case to the future. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 12:10:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KASKL024492 for ; Mon, 4 Mar 2002 12:10:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24KASgu024491 for ipng-dist; Mon, 4 Mar 2002 12:10:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KAOKL024484 for ; Mon, 4 Mar 2002 12:10:24 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA04296 for ; Mon, 4 Mar 2002 12:10:25 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA08489 for ; Mon, 4 Mar 2002 12:10:24 -0800 (PST) Received: from jariws1 ([62.248.154.8]) by fep07-app.kolumbus.fi with SMTP id <20020304200934.EZGL13233.fep07-app.kolumbus.fi@jariws1>; Mon, 4 Mar 2002 22:09:34 +0200 Message-ID: <018f01c1c3b8$a78080e0$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Michael Thomas" Cc: "Michael Thomas" , "Hesham Soliman \(ERA\)" , "OKABE Nobuo" , "Jari Arkko \(LMF\)" , , , References: <4DA6EA82906FD511BE2F00508BCF053802C6AA6C@Esealnt861.al.sw.ericsson.se><15491.46041.481887.601707@thomasm-u1.cisco.com><014601c1c3b2$a07c9a00$8a1b6e0a@arenanet.fi> <15491.53181.845986.788655@thomasm-u1.cisco.com> Subject: Re: Should IP Security be Optional? Date: Mon, 4 Mar 2002 22:10:39 +0200 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I don't know; it depends on what you're trying > to accomplish. Is there a reason that you must > choose one? I agree that dynamic addresses makes > manual keying problematic, but I'm not sure that > it follows that you need to pick one keying > scheme. Even with IKE, there's room for > interoperability issues (some might say far > too much room, but I digress). I think we can agree on wanting to change IKE to IKEv2 as soon as that is possible. > My personal feeling is that the ng working > group has the consensus about right. We need > a base level set of mechanisms for protecting > IP packets. Since this is normally kernel > level work, having a strong statement here > is useful. And while I think there's pretty good > consensus that IPsec (eg, not IKE) is a > a stable and mature, there's equally good > consensus that IKE is not. Given KINK and > JFK/IKEv2 -- not to mention how widespread > transport mode keying really gets deployed -- > I'm not sure that I'd want to choose any one > at this point. I personally think that the > Kerberos based keying is well suited to > high fan out kinds of applications like > telephony, but I wouldn't claim that it is > the only way (or The Way) to approach the > problem of keying. Yes... this is not a bad approach. However, I still feel that it is sort of an underspecification. For instance, if we say that MUST ESP and leave key management in the air, then distribute 100,000,000 devices with no key management, 100,000,000 devices with IKE, 100,000,000 devices with IKEv2, 100,000,000 devices with KINK, and 100,000,000 devices with a weird app layer keying scheme that isn't documented anywhere, we aren't going to get interoperability! We couldn't make a server for all of these devices to connect to, and they certainly couldn't contact each other. I do understand your comments about kernels and so on, but I feel that I should perhaps explain more about the deployment aspects of handing out very large numbers of devices to grandmothers and truck drivers: they expect their device to work, and they aren't going to install isakmpd after finding out that their device doesn't work with their friend's device -- like you and I would. The device is a box that either works or doesn't work. Therefore, I'm not very happy with a half-way MUST particularly on a device where it may not make much sense to talk about kernels and application processes. (This is also in part why I'm worried about putting in extra features just in case, and why we wanted an all-or-nothing approach: either you really are using IPsec or TLS or you're not going to need to do some part of them.) Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 12:14:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KErKL024521 for ; Mon, 4 Mar 2002 12:14:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24KEqtx024520 for ipng-dist; Mon, 4 Mar 2002 12:14:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KEnKL024513 for ; Mon, 4 Mar 2002 12:14:49 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA05222 for ; Mon, 4 Mar 2002 12:14:50 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08660 for ; Mon, 4 Mar 2002 13:14:49 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g24KEmB16179 for ; Mon, 4 Mar 2002 21:14:48 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Mon Mar 04 21:14:48 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 21:05:02 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFC4@esealnt117> From: "Karim El-Malki (ERA)" To: "'Phil Roberts'" , "'Tony Hain'" , ipng@sunroof.eng.sun.com Subject: RE: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 21:13:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Having read through this thread now, might it be better to > recast this document more along the lines of functions > supported on the cellular interface rather than requirements > for host? Some substantial number of devices for which this > is targeted will be dual network interface capable and for the > other interface some of these optimizations don't make sense. > > The Mobile IPv6 related specifications for the time being > only make sense with such a dual network interface capable > device, which means the optimizations recommended on the cell > facing interface in many cases SHOULDN'T be recommended on > the other interfaces. The cellular host requirements draft is only aimed at minimum cellular host functionality. So if a host has a DSL interface this draft doesn't apply to it. I believe this is already an assumption of the current draft. If instead you have multiple wireless interfaces it would apply. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 12:23:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KNnKL024552 for ; Mon, 4 Mar 2002 12:23:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24KNnwH024551 for ipng-dist; Mon, 4 Mar 2002 12:23:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KNkKL024544 for ; Mon, 4 Mar 2002 12:23:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28426 for ; Mon, 4 Mar 2002 12:23:47 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25772 for ; Mon, 4 Mar 2002 13:23:46 -0700 (MST) Received: from jariws1 ([62.248.154.8]) by fep07-app.kolumbus.fi with SMTP id <20020304202255.FAVN13233.fep07-app.kolumbus.fi@jariws1>; Mon, 4 Mar 2002 22:22:55 +0200 Message-ID: <01d101c1c3ba$8538a560$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Keith Moore" Cc: "Keith Moore" , "Tony Hain" , References: <200203042009.g24K9HF27009@astro.cs.utk.edu> Subject: Re: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 22:24:00 +0200 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > On this one I think we have made the case very clear > > by talking about _host_ requirements document. The > > router case is important, but left as a future exercise. > > Given that *existing* cell phones already act as (two-port) IP routers, > I don't think it's a good idea to defer that case to the future. (Are you sure you don't refer to link-layer / bridging capability?) Anyway, we agree on the importance of the router case because at least I personally believe the interesting stuff gets here when we have Personal Area Networks and such. Could do that in a separate document, though, seems there's enough to discuss even if only hosts are mentioned ;-) Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 12:24:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KOZKL024569 for ; Mon, 4 Mar 2002 12:24:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24KOYmH024568 for ipng-dist; Mon, 4 Mar 2002 12:24:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KOVKL024561 for ; Mon, 4 Mar 2002 12:24:31 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA07836 for ; Mon, 4 Mar 2002 12:24:32 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13131 for ; Mon, 4 Mar 2002 13:24:32 -0700 (MST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Mar 2002 15:17:42 -0500 Message-ID: From: Phil Roberts To: "'Karim El-Malki (ERA)'" , Phil Roberts , "'Tony Hain'" , ipng@sunroof.eng.sun.com Subject: RE: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 15:17:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: Monday, March 04, 2002 3:14 PM > To: 'Phil Roberts'; 'Tony Hain'; ipng@sunroof.eng.sun.com > Subject: RE: Should connecting to the Internet be Optional? > > > > Having read through this thread now, might it be better to > > recast this document more along the lines of functions > > supported on the cellular interface rather than > requirements > for host? Some substantial number of devices > for which this > is targeted will be dual network interface > capable and for the > other interface some of these > optimizations don't make sense. > > > The Mobile IPv6 related specifications for the time being > > only make sense with such a dual network interface capable > > device, which means the optimizations recommended on the > cell > facing interface in many cases SHOULDN'T be > recommended on > the other interfaces. > > The cellular host requirements draft is only aimed at minimum > cellular host functionality. So if a host has a DSL interface > this draft doesn't apply to it. I believe this is already an > assumption of the current draft. If instead you have multiple > wireless interfaces it would apply. But if your multiple wireless interfaces include something like WLAN it needs to be spelled out which of these recommendations apply to which interfaces. No? > > /Karim > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 12:26:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KQJKL024589 for ; Mon, 4 Mar 2002 12:26:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24KQIw6024588 for ipng-dist; Mon, 4 Mar 2002 12:26:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KQEKL024581 for ; Mon, 4 Mar 2002 12:26:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29641 for ; Mon, 4 Mar 2002 12:26:15 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA15584 for ; Mon, 4 Mar 2002 13:26:13 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g24KQ8F27245; Mon, 4 Mar 2002 15:26:08 -0500 (EST) Message-Id: <200203042026.g24KQ8F27245@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Jari Arkko" cc: "Keith Moore" , "Tony Hain" , ipng@sunroof.eng.sun.com Subject: Re: Should connecting to the Internet be Optional? In-reply-to: (Your message of "Mon, 04 Mar 2002 22:24:00 +0200.") <01d101c1c3ba$8538a560$8a1b6e0a@arenanet.fi> Date: Mon, 04 Mar 2002 15:26:08 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Anyway, we agree on the importance of the router case because > at least I personally believe the interesting stuff gets here when > we have Personal Area Networks and such. > > Could do that in a separate document, though, seems there's > enough to discuss even if only hosts are mentioned ;-) a separate document is fine w/me; deferring work on such a document isn't. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 12:39:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KdAKL024643 for ; Mon, 4 Mar 2002 12:39:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24KdAwp024642 for ipng-dist; Mon, 4 Mar 2002 12:39:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24Kd7KL024635 for ; Mon, 4 Mar 2002 12:39:07 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA03583 for ; Mon, 4 Mar 2002 12:39:08 -0800 (PST) Received: from fep07-app.kolumbus.fi (fep07-0.kolumbus.fi [193.229.0.51]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00502 for ; Mon, 4 Mar 2002 12:39:07 -0800 (PST) Received: from jariws1 ([62.248.154.8]) by fep07-app.kolumbus.fi with SMTP id <20020304203816.FCSF13233.fep07-app.kolumbus.fi@jariws1>; Mon, 4 Mar 2002 22:38:16 +0200 Message-ID: <021701c1c3bc$aa4e2300$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: "Phil Roberts" , "'Karim El-Malki \(ERA\)'" , "'Tony Hain'" , References: Subject: Re: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 22:39:21 +0200 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > But if your multiple wireless interfaces include something like > WLAN it needs to be spelled out which of these recommendations > apply to which interfaces. No? True, and we probably need to clarify that. In general, most of the discussion in the draft relates to the cellular interface only. If a supercomputer has a cellular interface, it doesn't mean that it should suddenly start behaving like a cellular host in other interfaces ;-) (But I realize that you've been reading the mobility parts which do talk about the multi-interface cases in order to explain better how mobility should be used.) Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 12:44:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KinKL024666 for ; Mon, 4 Mar 2002 12:44:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24KinPL024665 for ipng-dist; Mon, 4 Mar 2002 12:44:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KijKL024658 for ; Mon, 4 Mar 2002 12:44:45 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA29336 for ; Mon, 4 Mar 2002 12:44:46 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25313 for ; Mon, 4 Mar 2002 13:44:45 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g24KiiB19728 for ; Mon, 4 Mar 2002 21:44:44 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Mar 04 21:44:43 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Mar 2002 21:34:57 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFC5@esealnt117> From: "Karim El-Malki (ERA)" To: "'Phil Roberts'" , "'Tony Hain'" , ipng@sunroof.eng.sun.com Subject: RE: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 21:43:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The cellular host requirements draft is only aimed at minimum > > cellular host functionality. So if a host has a DSL interface > > this draft doesn't apply to it. I believe this is already an > > assumption of the current draft. If instead you have multiple > > wireless interfaces it would apply. > > But if your multiple wireless interfaces include something like > WLAN it needs to be spelled out which of these recommendations > apply to which interfaces. No? If WLAN works differently from a cellular interface then it needs separate consideration (maybe another draft). So this draft wouldn't apply to interfaces for which cellular requirements are not meaningful. But I'm not sure that defining multiple technology hosts is the most urgent bit of the work. I'd be mostly interested in seeing a document which describes what needs to be implemented in the very short run i.e. basic 3gpp v6 hosts. So it makes sense to me that the document concentrate on these and then get updated later if/when new requirements appear. 3gpp has an urgent need and wants to deploy IPv6 so it's a good idea to provide guidance to implementors through the cellular hosts draft. Regarding Mobile IPv6, were you proposing that Mobile IP not be considered in the cellular hosts document if we are only describing requirements for basic cellular hosts and no multiple-technology devices? /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 12:50:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KoWKL024689 for ; Mon, 4 Mar 2002 12:50:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24KoWcO024688 for ipng-dist; Mon, 4 Mar 2002 12:50:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KoTKL024681 for ; Mon, 4 Mar 2002 12:50:29 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01397 for ; Mon, 4 Mar 2002 12:50:22 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05583 for ; Mon, 4 Mar 2002 12:50:22 -0800 (PST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Mar 2002 15:43:32 -0500 Message-ID: From: Phil Roberts To: "'Karim El-Malki (ERA)'" , Phil Roberts , "'Tony Hain'" , ipng@sunroof.eng.sun.com Subject: RE: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 15:43:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > If WLAN works differently from a cellular interface then it > needs separate consideration (maybe another draft). So this > draft wouldn't apply to interfaces for which cellular > requirements are not meaningful. But I'm not sure that > defining multiple technology hosts is the most urgent bit of > the work. I'd be mostly interested in seeing a document which > describes what needs to be implemented in the very short run > i.e. basic 3gpp v6 hosts. So it makes sense to me that the > document concentrate on these and then get updated later > if/when new requirements appear. 3gpp has an urgent need and > wants to deploy IPv6 so it's a good idea to provide guidance > to implementors through the cellular hosts draft. Maybe we should call it the cellular interfaces draft???? > > Regarding Mobile IPv6, were you proposing that Mobile IP not > be considered in the cellular hosts document if we are only > describing requirements for basic cellular hosts and no > multiple-technology devices? There are two issues - one is that it's not done, but hopefully soon, and two that it implies multiple interfaces at this point because at least in the 3gpp case it's not being considered for mobility management within the cellular network. But having the capability there seems important and I would be hesitant to take it out. It's probably wise to drop the references to HMIP and fast handover as those are still some distance from standardization. > > /Karim > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 12:52:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KqwKL024714 for ; Mon, 4 Mar 2002 12:52:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24Kqw8x024713 for ipng-dist; Mon, 4 Mar 2002 12:52:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24KqsKL024706 for ; Mon, 4 Mar 2002 12:52:54 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02341 for ; Mon, 4 Mar 2002 12:52:55 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06694 for ; Mon, 4 Mar 2002 12:52:54 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 04 Mar 2002 12:52:53 -0800 From: "Tony Hain" To: , Cc: Subject: RE: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 12:52:53 -0800 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <245DBCAEEC4F074CB77B3F984FF9834F7856A4@esebe005.NOE.Nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk juha.wiljakka@nokia.com wrote: > ... > Our intention is to write this specification as "minimum > IPv6 functionality for a cellular host", i.e. not defining > any kind of 'maximum set of functionality'. > ... > As a summary, a cellular host (often) has limited size, > memory, processor capacity and battery capacity / power > consumption. The users would like to see their terminals to > be usable for quite a long time (typically for some days, at > least stand-by time) without re-charging them. You are focused on the engineering constraints of a particular device (host) that is *only useful* in a cellular context as the definition. My point was that there are many other devices that could take advantage of the cellular link technology, and therefore MUST be considered 'cellular hosts'. Statements in the document like: 'A cellular host SHOULD NOT perform Duplicate Address Detection ...' or lack of support for IPsec that is justified as too hard for a small device to implement are focused on engineering issues for a particular product, not the architectural minimum. If there are characteristics of the cellular link that make the current standards inappropriate as written, we should address those. If you are looking for concessions simply for marketing reasons related to a particular target product, this document should die right here. The statement 'We can not list all possible services here, and in general we expect application protocol RFCs to have requirements on what security services they MUST employ.' is both an unrealistic expectation, and the fundamental reason that we are being so insistent about the requirement for IPsec. As a general rule, we don't expect (or have the means to require) that every application define security requirements; and even if they did evolving the security infrastructure to meet the needs of every new application would be insane. On the other hand by providing a secure channel for use by any application we can build an infrastructure that scales. The argument that a cellular host is exempt only ensures that the application developer can't count on that secure channel being available, so each one has to do something specific to address their needs. If you want to do as Keith suggested and split off fixed-function as a special case, I won't object too loudly. Even there you preclude something like a Java app, that comes in over the TLS channel, from opening a non-TLS secure channel to get additional content. Yes it is a fixed function web-browser, but do you really know how every web site is designed, and can you ensure that all bits in and out of the device can be protected by TLS? Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 4 13:05:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24L5lKL024793 for ; Mon, 4 Mar 2002 13:05:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24L5lMa024792 for ipng-dist; Mon, 4 Mar 2002 13:05:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24L5hKL024785 for ; Mon, 4 Mar 2002 13:05:43 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11710 for ; Mon, 4 Mar 2002 13:05:45 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12652 for ; Mon, 4 Mar 2002 13:05:43 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Mon, 04 Mar 2002 13:05:42 -0800 From: "Tony Hain" To: "Karim El-Malki \(ERA\)" , "'Phil Roberts'" , Subject: RE: Should connecting to the Internet be Optional? Date: Mon, 4 Mar 2002 13:05:42 -0800 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <795A014AF92DD21182AF0008C7A404320DFBEFC4@esealnt117> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Karim El-Malki wrote: > The cellular host requirements draft is only aimed at minimum > cellular host functionality. So if a host has a DSL interface this > draft doesn't apply to it. I believe this is already an assumption > of the current draft. If instead you have multiple wireless > interfaces it would apply. So this points out that 1) the document doesn't define 'cellular host', and 2) that 'assumptions' of the authors are not always obvious to the reader. A host must conform to specific requirements and mixing or adding different interface types doesn't change that. In this example, when a DSL interface got added to a 3G handset does it suddenly change from a 'cellular host' to something else? If so which rules apply? The document is fundamentally flawed because it is focused on a target product, the micro-3G handset. If it gets rewritten to focus on unique exceptions for the cellular air-link that are strictly about addressing the problems that arise from its characteristics, it MAY be worthy of a WG last call. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 4 13:25:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24LPWKL024876 for ; Mon, 4 Mar 2002 13:25:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24LPWQO024875 for ipng-dist; Mon, 4 Mar 2002 13:25:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24LPTKL024868 for ; Mon, 4 Mar 2002 13:25:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA12301 for ; Mon, 4 Mar 2002 13:25:30 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23787 for ; Mon, 4 Mar 2002 14:24:48 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 7717C6A901; Mon, 4 Mar 2002 23:24:06 +0200 (EET) Message-ID: <3C83E645.2080704@kolumbus.fi> Date: Mon, 04 Mar 2002 23:25:25 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Tony Hain Cc: juha.wiljakka@nokia.com, moore@cs.utk.edu, ipng@sunroof.eng.sun.com Subject: Re: Should connecting to the Internet be Optional? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > Statements in the document like: 'A cellular host SHOULD NOT > perform Duplicate Address Detection ...' or lack of support for IPsec > that is justified as too hard for a small device to implement are > focused on engineering issues for a particular product, not the > architectural minimum. I don't think this was exactly as we wanted to see the document. First, engineering issues are important, but if we would only follow them, why didn't the draft say MUST NOT implement RFCs of over 5 pages ;-) ? Secondly, there are two main classes of engineering issues: those internal to the device and not (so) relevant, and those related to the characteristics of the communications interfaces which typically do need to be addressed in some manner. In any case both examples you cite have NOT been done just in order to save space. Consider the small amount saved by DAD, or the recommendations to implement something equally complicated to IPsec in certain cases. Instead, what we tried to do was to evaluate the specific conditions in cellular networks and devices, and figure out if the function was technically necessary in that context. We may have done our analysis right, or wrong -- and that's the reason we are having this discussion. As an example, it isn't just necessary to show that DAD is expensive, you also have to show that on a particular class of links you don't need it. I seem to recall some discussion today on DAD not being necessary in PPP; I don't know what the conclusion of the discussion will be but that's the kind of result we are looking for - please work with us on the technical analysis. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 13:54:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24LswKL025012 for ; Mon, 4 Mar 2002 13:54:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24LswKR025011 for ipng-dist; Mon, 4 Mar 2002 13:54:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24LsrKL025004 for ; Mon, 4 Mar 2002 13:54:54 -0800 (PST) Received: from lillen (vpn-129-156-96-29.EMEA.Sun.COM [129.156.96.29]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g24Lsrx28323 for ; Mon, 4 Mar 2002 22:54:53 +0100 (MET) Date: Mon, 4 Mar 2002 22:49:54 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Applicability of draft-ietf-ipv6-cellular-host-00.txt To: ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think part of the questions are around the applicability of the document. The document doesn't seem to constrain this very much: For the purposes of this document, a cellular host is considered to be a terminal that uses an air interface to connect to a cellular access network (i.e. GPRS, UMTS, CDMA2000) in order to provide IPv6 connectivity to an IP network. So unless "terminal" is a well-defined term in the IETF context this seems to apply to e.g. a full-powered laptop with a PCMCIA radio card, a cellular phone with a Java JVM that allows it to run downloaded applications, and perhaps even a router with such an air interface. 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 Mar 4 14:20:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24MKFKL025130 for ; Mon, 4 Mar 2002 14:20:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g24MKFse025129 for ipng-dist; Mon, 4 Mar 2002 14:20:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g24MK9KL025122 for ; Mon, 4 Mar 2002 14:20:10 -0800 (PST) Received: from lillen (vpn-129-156-96-29.EMEA.Sun.COM [129.156.96.29]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g24MK8x00016 for ; Mon, 4 Mar 2002 23:20:08 +0100 (MET) Date: Mon, 4 Mar 2002 23:15:09 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Reserving bits in RFC 2473 Interface IDs? To: ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC 2373 defines two kinds of interface IDs: Those with the "u"-bit set to 1 (i.e, globally unique), and those set with the "u"-bit set to 0 (i.e., not globally unique). Prompted by some discussion in the Mobile IP working group I realized that RFC 2373 does not have any way to introduce or identify new types of interface IDs that can be identified syntactically by just looking at the interface ID. It might be useful in the future to be able to define a new type of interface id that has some new properties, similar in nature to the current ability to identify globally unique interface IDs, and making it possible to determine whether the interface ID has this property by merely inspecting the interface ID. Hence this note. This note is not about any particular use - it is merely an attempt at reserving some space in the interface ID to be prepared for potential future ideas. Any discussion about using a part of the reserved space, whether for Mobile IP or some other idea in the next 5 or 10 years, will need to be a separate standards track document that will need to be separately discussed. [Those wanting background information of potential future use of IID bits contemplated by the MIP WG can read http://playground.sun.com/mobile-ip/WG-archive/msg05351.html http://playground.sun.com/mobile-ip/WG-archive/msg05357.html Those proposals are not the subject of this note, but merely serve as an example of a possible use of reserved bits in the future.] The observation is that, at least on paper, we've given up all of the 64 bit IID space. Half of this space, with the universal bit set to 1, is given to IEEE EUI-64 identifiers. The other half (universal = 0) is used for IIDs that are not globally unique including - manually assigned, - assigned by DHCPv6 (but DHCPv6 can assign globally unique ones as well) - random IIDs that is used in RFC 3041 and RFC 2472 section 4.1. Those documents specifying random IIDs talk about generating a 64-bit random number and setting the universal bit to zero to form the IID. There are two possible ways to reserve some space for future use. Reserve one quarter of the IID space ------------------------------------ The first one does not have any implementation impact and is based on the observation that EUI-64 identifiers that are assigned to interfaces never have the 'group' bit set. (Such EUI-64 addresses are used for sending multicast packets.) Thus it is possible to reserve the IID that have universal = 1, group = 1 for future use. This would result in the IID space being divided as follows: universal = 0 Manual, DHCP, and random numbers. universal = 1, group = 0 EUI-64 universal = 1, group = 1 Reserved for future use This change has no impact on implementations. It can be captured in the specification by adding text to draft-ietf-addr-arch-v3 to point out that the group bit must be zero when the universal bit is set to one. Reserve half of the IID space ----------------------------- By modifying RFC 3041 and RFC 2472 to say that the random number generated must have both the universal *and* the group bit set to zero. This impacts implementations of those specifications; for RFC 2472 it only impacts the implementations that fall back to generating a random number as a last resort. If this option is selected it would result in the IID space being divided as follows: universal = 0, group = 0 Manual, DHCP, and random numbers. universal = 0, group = 1 Reserved for future use universal = 1, group = 0 EUI-64 universal = 1, group = 1 Reserved for future use draft-ietf-ipngwg-addr-arch-v3 needs to be updated if we take this path. Compared to the "quarter" proposal this would carve off a larger part of the IID space for future use but it comes with the disadvantage of needing to modify RFC 3041, RFC 2472, and implementations thereof. Note that an update to RFC 3041 with protocol clarifications is already in progress. Similar restrictions should be noted wherever we talk about manual configuration or DHCP assignment of addresses, which seems to just be in Appendix A in draft-ietf-ipngwg-addr-arch-v3. [As an aside the DHCPv6 specification should presumably mention what types of interface IDs should be used when a DHCP server allocates addresses.] Impact ------ Reserving these Interface IDs MUST NOT have any impact on implementations other than how addresses are auto-configured. In particular, implementations MUST NOT reject packets that have a source address from the reserved space and MUST NOT prevent sending packets to destination addresses from the reserved space. In effect the IID, just like the whole 128 bit addresses, should be treated as an opaque set of bits. Thus the effect of reserving this space is merely to say that IIDs must not be allocated in the reserved space. Any future *use* of these reserved portion(s) i.e. documents specifying semantics for bit the and/or suggesting that addresses be allocated with these reserved parts of the IID, require a standards track RFC i.e. any such use would require IETF wide rough consensus as normal for standards track documents. Thus the purpose of this is just to reserve the space should there be some utility of doing sub-allocations of IID space in the future. This seems consistent with the path that was taken when universal=1 was assigned to IIDs that are globally unique. 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 Mar 4 18:12:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g252CgKL025803 for ; Mon, 4 Mar 2002 18:12:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g252CgUs025802 for ipng-dist; Mon, 4 Mar 2002 18:12:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g252CcKL025795 for ; Mon, 4 Mar 2002 18:12:39 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26075 for ; Mon, 4 Mar 2002 18:12:39 -0800 (PST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA15929 for ; Mon, 4 Mar 2002 19:12:37 -0700 (MST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id LAA15541; Tue, 5 Mar 2002 11:12:31 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp (8.11.5/3.7W) id g252CV009084; Tue, 5 Mar 2002 11:12:31 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id MAA09081 ; Tue, 5 Mar 2002 11:12:31 +0900 Received: from mx.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id LAA03513; Tue, 5 Mar 2002 11:12:30 +0900 (JST) Received: from isl.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id LAA28320; Tue, 5 Mar 2002 11:12:30 +0900 (JST) Received: from localhost (inoue@flowerpark.isl.rdc.toshiba.co.jp [133.196.16.25]) by isl.rdc.toshiba.co.jp (8.11.6/8.11.6/1.4) with ESMTP id g252CTf24900; Tue, 5 Mar 2002 11:12:29 +0900 (JST) To: pekkas@netcore.fi, tiny@tahi.org Cc: ipng@sunroof.eng.sun.com Subject: Re: [tiny:1272] Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt In-Reply-To: Your message of "Mon, 04 Mar 2002 23:16:09 +0900" <200203041416.XAA07265@toshiba.co.jp> References: <200203041416.XAA07265@toshiba.co.jp> X-Mailer: Mew version 1.92 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: <20020305111229G.inoue@isl.rdc.toshiba.co.jp> Date: Tue, 05 Mar 2002 11:12:29 +0900 From: Atsushi Inoue X-Dispatcher: imput version 980905(IM100) Lines: 229 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk resending because my message did not submitted to ipng. -- inoue Pekka, Just a quick answers except for relating to MIPv6 and security issues. >On Fri, 1 Mar 2002 Internet-Drafts@ietf.org wrote: >> Title : Minimum Requirement of IPv6 for Low Cost Network >> Appliance >> Author(s) : N. OKABE et al. >> Filename : draft-okabe-ipv6-lcna-minreq-01.txt >> Pages : 20 >> Date : 28-Feb-02 > >A few comments in addition to ones I sent for -00.. > > Table 1. Resource restrictions of LCNA > > ===============+===============+==================+======= > Memory CPU Performance OS > ===============+===============+==================+======= > PC >64MB Pentium/64bits Windows > ---------------+---------------+------------------+------- > PDA 2-8MB RISC/32bits(50MHz) WinCE > VxWorks > PalmOS > >==> I think it'd be policitally correct to _at least_ change 'Windows' >there to 'Any', and possibly add 'Others' to PDA section (e.g. I like >Linux and NetBSD on PDA's :-). The footprint of WinCE is 1MB as announced, but the CPU performance of pocket PC becomes higher and higher. So, as you suggested we should replace winCE with embedded Linux or others if we keep on this device class. >2.7 Security > In Section 4 "Security for LCNA", we will regulate a baseline for > guaranteeing that a minimum host can communicate securely. However, > Denial of Service (DoS) and intrusion are out of scope. So, we have > to consider defending from DoS and/or intrusion in another place. > Also, the authentication of users is out of scope, because some > minimum hosts can omit a mechanism of user accounts. > >==> intrusion out of scope? What do you mean by that? >Auth? Here, we mention about intrusion as a typical case that LCNA and other device (such as firewall) work togather in order to provide specific security solution. "Intrusion out of scope" simply means that our spec only treats the end node itself and the security functionality provided by node and other network devices is not considered yet. > - When it can recognize the extension header but does not support > the options in it, it MUST perform error processing according to > the option number. > >==> you mean s/extension header/destination options header/? There is no >processing defined by option number for extension headers. This is our typo. The correct description is as follows: When it can recognize the extension options headers but does not support the options in it, it MUST perform error processing according to the option type. (as secified in section 4.2 of RFC2460) > [Receiving] > A minimum host SHOULD recognize it as a Hop-by-Hop Options Header, > and perform the processing according to the option and option > number in it. Because this option is used for signaling and router > alert, in order to control routers on the path, all nodes on the > transmission path have to interpret this header but do not need to > interpret all options in it. > >==> I don't understand your reasoning for router alert; LCNA's aren't >routers by definition :-) RFC2460 says, "The Hop-by-Hop Options header is used to carry optional information that must be examined by every node along a packet's delivery path." so we regulated that the examination of Hop-by-Hop option have to be performed even on LCNA. Is it too redundant ? > >3.1.2 Routing Header > [Sending] > Following 3.1, minimum hosts do not send packets with this extension > header. > > [Receiving] > RFC regulates that if the Segment Left field has non-zero value in > this header, the node has to forward the packet to the next > intermediate node, even when the node is a host. But in the case of > a minimum host, this forwarding MAY be omitted and be treated as an > unsupported extension header, because only intermediate nodes (such > as routers) and the destination node have to interpret this header. > >==> please see draft-savola-ipv6-rh-hosts-00.txt Basically agree with your draft, if there can implement an user interface (or other methods) to switch the behavior of routing header. >3.1.3 Fragment Header > > If a minimum host satisfies the following conditions, the host MAY > not send this extension header, and MAY treat one as an unsupported > header when receiving it. > >==> I'm not sure what the robustness principle would say about hosts that >cannot defragment. What do you mean for "the robustness principle" ? >3.3 Neighbor Discovery for IP Version 6 (IPv6) (RFC2461) [22] > In this draft, we assume that an LCNA has only one network > Interface, but it does not inhibit multiple interfaces. When > an LCNA is assumed to have multiple interfaces, the following > considerations are necessary, which requires more resources. > > - Source address selection > >==> even with one interface, the LCNA has multiple addresses, so it >obviously still needs source address selection (consider e.g. the case >with link-local, site-local, 6to4 address, and native address). It may >not necessarily need to be as complex though. Agree. We have made separate section of default address selection as 3.8, so we can cut of the descrition here now. > >3.5 Internet Control Message Protocol (ICMPv6) for the Internet Protocol > Version 6 (IPv6) Specification (RFC2463) [24] > > On minimum hosts, ICMP used only by a router MAY be omitted (Table > 2). ICMPs for Echo Request/Reply and minimum error reporting MUST be > supported. > >==> this MUST includes rate-limiting of error replies, I hope? Agree. But we cannot describe LCNA-specific example of rate-limitation. > > Table 2. Mandatory ICMP messages for LCNA > ===============+===============================+========== > Type Code Necessary? > ===============+===============================+========== > 1: 0: No route to destination No > Destination 1: Administratively Prohibited No > Unreachable 3: Address unreachable No > Message 4: port unreachable Yes > >==> depending on how MIPv6 goes, some of these (e.g. admin prohibit) >might become necessary too. Agree. >3.7 DNS Extensions to support IP version 6 (RFC1886) [26] and IPv6 > Stateless DNS Discovery (draft-ietf-ipngwg-dns-discovery-02.txt) > [27] > > The only function that is not supported in the current IPv6 > autoconfiguration is automatic discovery of DNS server. On this > topic discussions are ongoing in IETF IPNG WG. If a standard is > fixed, it might become a mandatory item for minimum hosts. > AAAA record is defined for transform from IPv6 name to IPv6 > address. So, AAAA is currently mandatory for minimum host name > resolution. Also, A6 record is currently proposed and discussed in > IETF for an alternative of AAAA record. We need to check the > progress. > >==> What about reverse lookups? nibble-style, probably? ip6.int or >ip6.arpa, or both? On which case the reverse lookup is necessary in LCNA usage? We complete neglect that. >6.2 Management facilities for LCNAs > >==> personally I think being able to remotely monitor the status of the >system is a rather necessary feature. We want to discuss about which functionality might be important for monitoring LCNA type of devices. > >7. Security Consideration > As mentioned in 2.7, DOS and intrusion are out of the scope of this > draft. > >==> you cannot specify requirements while leaving these features out of >scope. As mentioned above, this simply notes that our focus is only on LCNA node implementation, so the collaborative work with other network devices is omitted on this draft, which should be treated in other places. >10 Appendix: Example of IPSEC minimum requirements specification >[...] > We believe that IPsec is an effective technology in order to > guarantee security of communication. That is the reason why we > regulate the minimum IPsec specification in this draft. > >==> this needs editing as the last sentence is obviously false. Agree. We bring the original description of draft-00 but we should rewrite them because out treatment of IPsec has almost changed. We will send answers for rest of questions later. -- inoue -- Atsushi INOUE mailto:inoue@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 4 18:17:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g252HXKL025926 for ; Mon, 4 Mar 2002 18:17:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g252HW4D025925 for ipng-dist; Mon, 4 Mar 2002 18:17:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g252HSKL025918 for ; Mon, 4 Mar 2002 18:17:28 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA19597 for ; Mon, 4 Mar 2002 18:17:29 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13465 for ; Mon, 4 Mar 2002 18:17:28 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g252HNF01149; Mon, 4 Mar 2002 21:17:23 -0500 (EST) Message-Id: <200203050217.g252HNF01149@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jonne.Soininen@nokia.com cc: moore@cs.utk.edu, ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] In-reply-to: (Your message of "Mon, 04 Mar 2002 17:39:59 PST.") <4D7B558499107545BB45044C63822DDEB2D8AA@mvebe001.NOE.Nokia.com> Date: Mon, 04 Mar 2002 21:17:23 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > > This seems to presume that you can predict in advance all of the > > > > applications that a user will wish to execute on a particular node. Can you > > > > do that? > > > > > > On a workstation you can't. On a tiny cellular device you > > > often can. > > > only if the device doesn't have a data port. > > Actually then (especially in 3GPP devices) the IP stack will actually also > be behind that dataport, i.e. in the laptop. That is then a different story. true enough. but then you need the phone to act like an IPv6 router. (it might be sufficient to have the phone act like a network interface - if the network behind it provides a router and ND/RD etc. work normally) Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 21:49:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g255n8KL026409 for ; Mon, 4 Mar 2002 21:49:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g255n8BS026408 for ipng-dist; Mon, 4 Mar 2002 21:49:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g255n4KL026401 for ; Mon, 4 Mar 2002 21:49:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10468 for ; Mon, 4 Mar 2002 21:49:05 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA14249 for ; Mon, 4 Mar 2002 22:49:04 -0700 (MST) Received: from kenawang ([192.168.1.47]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id VAA10109; Mon, 4 Mar 2002 21:48:40 -0800 (PST) Message-Id: <4.2.2.20020305004548.00e3e760@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 05 Mar 2002 00:48:52 -0500 To: "Hesham Soliman (ERA)" From: Margaret Wasserman Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Cc: ipng@sunroof.eng.sun.com In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AA64@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > However, these messages are mandatory in RFCs 2461 and 2462, both > > for DAD and for the basic neighbor discovery mechanism, which needs > > to be used to establish two-way connectivity before other messages > > are exchanged. > >=> Right, but would you agree that on a p2p link you >don't actually *need* NS and NA? >It's not a shared link, the prefix is implicitly >delegated to the UE only. So I don't see why >(apart from NUD) you would need NSs and NAs. >Hence the MAY. I understand the argument for why you would not need to use DAD. However, you would need to use NS and NA messages to establish two-way reachability to the router, before sending other IP packets to (or through) that router. This is the basic neighbor discovery mechanism, and I don't believe that it is optional on point-to-point links. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 22:05:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2565oKL026434 for ; Mon, 4 Mar 2002 22:05:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2565oPP026433 for ipng-dist; Mon, 4 Mar 2002 22:05:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2565kKL026423 for ; Mon, 4 Mar 2002 22:05:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA03488 for ; Mon, 4 Mar 2002 22:05:47 -0800 (PST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA17557 for ; Mon, 4 Mar 2002 23:05:44 -0700 (MST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id PAA22682; Tue, 5 Mar 2002 15:05:40 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp (8.11.5/3.7W) id g2565dI15928; Tue, 5 Mar 2002 15:05:39 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id RAA15926 ; Tue, 5 Mar 2002 15:05:39 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id PAA25753; Tue, 5 Mar 2002 15:05:39 +0900 (JST) Received: from isl.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id PAA29793; Tue, 5 Mar 2002 15:05:38 +0900 (JST) Received: from miomio (JT01-093.mobile.toshiba.co.jp [133.120.196.93]) by isl.rdc.toshiba.co.jp (8.11.6/8.11.6/1.4) with SMTP id g2565Yf06672; Tue, 5 Mar 2002 15:05:34 +0900 (JST) Message-Id: <200203050605.g2565Yf06672@isl.rdc.toshiba.co.jp> Date: Tue, 05 Mar 2002 15:08:35 +0900 From: Atsushi INOUE Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt To: tiny@tahi.org, Pekka Savola Cc: ipng@sunroof.eng.sun.com Organization: Toshiba RDC In-Reply-To: <200203041407.XAA27215@toshiba.co.jp> References: <200203011204.HAA13764@ietf.org> <200203041407.XAA27215@toshiba.co.jp> X-Mailer: Datula version 1.51.08.01 for Windows Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Here are the answers for IPsec/MIPv6 related questions. >On Fri, 1 Mar 2002 Internet-Drafts@ietf.org wrote: >> Title : Minimum Requirement of IPv6 for Low Cost Network >> Appliance >> Author(s) : N. OKABE et al. >> Filename : draft-okabe-ipv6-lcna-minreq-01.txt >> Pages : 20 >> Date : 28-Feb-02 > >A few comments in addition to ones I sent for -00.. > >2.8 Mobility support > In this draft, we do not assume that LCNA itself moves on the > network, but the processing from other nodes that operate as Mobile > Nodes of Mobile IPv6 is mandatory. > >==> I don't see why you force mobility but neglect security. We don't force mobility to LCNA itself, but at least LCNA have to handle packets from other Mobile Nodes. > > One exception is when the minimum host supports the mobile node > function of Mobile IPv6. As Mobile IPv6 uses a Routing header for > receiving packets destined to Mobile Node, this header MUST be > processed correctly. Another exception for sending this header is > when using route optimization for communicating with Mobile IPv6 > mobility agents. If route optimization is performed using binding > update, the node MUST send packets with these extension headers. > >==> mobile-ip wg chairs just decided that the consensus was to define a >new routing header type for MIPv6, so LCNA's might only need to process >type 2 RH's. I have not followed up MIPv6 discussion yet, but I understand LCNA-specific PH type might answer to the requirement. >3.1.4 Destination Options Header > A minimum host SHOULD recognize this header as Destination Options > Header and perform processing according to the options and option > numbers in it. One exception is the handling of Home address > destination option for Mobile IPv6. As mentioned in section 2.8, > even if LCNA itself does not move, it has to process the packets > sent from other mobile nodes. Therefore, the processing of Home > address option becomes mandatory. However, since final specification > of Mobile IPv6 is not regulated yet, we omit the concrete regulation > for LCNA now. > >==> one does not need to interpret HAO if one wants to communicate with >mobile node: then all the traffic would just have to go through the Home >Agent. In LCNA case, Home Agent would probably most often be in the home >network, so nothing would be lost.. We have not made any specific assumption for the configuration of LCNA-involved network. The above discussion deeply depends on the distance between LCNA and its Home agent and the amount of traffic between them. In some case, your proposal might acceptable, but anyway, we have to propose network model for each solution. Basically what is lacking in our draft is this "LCNA network models", which makes the Mobility/Security discussion very difficult, I think. >4.2 Security mechanism for LCNA > For example, IPsec realizes security on the IP layer, which is > transparent from the transport and/or application layer, so it can > be a generic solution. On the other hand, IPsec does not work well > with IP layer translation technology (such as NAT and IPv4/IPv6 > translator), which might be a restriction for the promotion of > LCNAs. > >==> I disagree with the latter: IMO it's ok to assume that people who want >to connect remotely (when security is a MUST) to LCNA would use native >IPv6. If your proposal is to specify that "When security is a MUST, do not use IPv4/IPv6 translator", that might be reasonable and IPsec can work on that. But this kind of discussion is also to make a specific assumption to LCNA-involved network configuration. So, I would like to say, When discussing about security/mobility of LCNA, let's having a network configuration disucussion before saying about specific solutions. >4.3 Minimum security specification for LCNA > >==> basically you seem to be saying it's okay to omit security (meaning >encryption) if LCNA is so underpowered it can't handle it. I disagree. >Put a better chip on it or say something to the effect 'If proper[??] >encryption and security is not implemented, the node MUST NOT have a >global address'. What we are saying about security has two aspects,$B!!(B - > * Even though we regulate minimum IPsec as mandatory, no one uses > it because there are no prospects to deploy it in the real > world. Therefore, it is WRONG to regulate the IPsec minimum > specification as mandatory. > >==> FUD. IPsec works fine in closed environment (which is what LCNA would >be used in): it's trivial to perform manual keying for all of your systems >(e.g. two computers and a few LCNA's), or use something like IKE in a >restricted domain. Yeah, in some specific network configuration IPsec works! So, this is also falling into network configuration discussion. For IPsec discussion, the ML thread of cellular draft says IPsec implementation have to be mandated. I think the discussion depends on what is the purpose of these (cellular/LCNA) node requirement drafts. If these drafts regulates baseline implementation of thease nodes for rather long-term, IPsec should be mandated in order to realize better security infrastructure. But if these drafts only aims to work as a kind of implementation guideline, the node vendors might feel that mandating IPsec might be tough because of poor resource performance (for IPsec) and security requireent for the application is not so high currently. -- inoue -- Atsushi INOUE mailto:inoue@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 4 23:09:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2579OKL026574 for ; Mon, 4 Mar 2002 23:09:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2579ORv026573 for ipng-dist; Mon, 4 Mar 2002 23:09:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2579LKL026566 for ; Mon, 4 Mar 2002 23:09:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA02654 for ; Mon, 4 Mar 2002 23:09:22 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA03850 for ; Tue, 5 Mar 2002 00:09:17 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2579NZ17941 for ; Tue, 5 Mar 2002 09:09:23 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 09:09:12 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 09:09:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should connecting to the Internet be Optional? Date: Tue, 5 Mar 2002 09:09:09 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D4F@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should connecting to the Internet be Optional? Thread-Index: AcHDn1o/ArSoHkrTTS+1adEilgvyRwAc38ug To: , X-OriginalArrivalTime: 05 Mar 2002 07:09:12.0094 (UTC) FILETIME=[A6DC73E0:01C1C414] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2579LKL026567 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tony, First off, in reply to your subject, I think that connecting to the Internet is mandatory, or there would be no reason to be submitting this work to the IETF. > Margret has raised several valuable questions about > draft-ietf-ipv6-cellular-host-00.txt, which show it is clearly is not > ready for last call. Its good to see technical discussion on the draft. The authors really do appreciate feedback on the draft, what is a good idea and what is not. > While I am willing to believe that there are valid > reasons to make adjustments based on characteristics of the link, this > document is fundamentally flawed because it is based around > the pretense that small footprint devices are somehow special. We MUST > NOT allow ourselves to modify well thought out architectural > fundamentals based on point-in-time engineering constraints that are dubious > at best. If a device wants to participate as an Internet node, there are basic > requirements. Of course, participating in the Internet is optional, so > if a device would prefer to avoid the requirements, it may choose to > create its own universe. The IETF is an (mostly) an engineering body and engineering is the science of working with constraints. I do think that discussion on what is appropriate and what is not is a very good thing. The IETF has chartered working groups which do take considerations of devices, links, networks, so I don't see what we have been suggesting is out of place. > The argument that small devices have limited processors or memory > overlooks the fact that the processor and memory of many hand-held > devices today is significantly greater than the workstations that were > available when IPv4 was defined. Interesting point; there was > no problem getting the stack and an array of applications to fit then. Another > interesting point; there are frequently rumors that laptops > will include cellular interfaces, so where does the processing and memory > constraint fit in that case? In general, the authors approach has been to be conservative in what is sent and generous in what is accepted. Consider that many of the cellular hosts will have limited configurability, limited upgradability, limited power yet must be extremely robust - it isn't only about processing power or memory limitations. Additionally, most of the power savings on laptops & cell phones come from the careful usage of resources, not due to increases in battery technology - when considering signaling, I think it is a perfectly acceptable consideration to see what is necessary to send and what is not. This is what we have been attempting to do in our draft. > On the subject of applications, the absolute BS about limiting the > application set to avoid an IPsec requirement is something > that belongs in a product development discussion, NOT a standards > discussion. The one point that should be clear is that over time the number of > applications used via wireless (cellular or otherwise) will grow, and that we can't > predict what they are, much less what they will need from the > stack. To that point, we MUST reiterate that ***ALL IPv6 IMPLEMENTATIONS MUST > INCLUDE SUPPORT FOR IPSEC***. If we relax that requirement, > applications will never be able to expect support, therefore will have to keep > inventing their own mechanisms. The only way to prevent new > applications from appearing on computing devices is to put the executable code in > non-rewritable, non-replaceable, rom. Tony, we are not looking at removing requirements for IPsec. However, we all know that IPsec is not a magic bullet, which will solve security issues. Again, we have been trying to deal as realistically as we can with what security solutions fit into what scenarios. In several documents that I have been involved in, the IESG has commented on security sections - stating that better thought needs to be given when IPsec is used, dependancy in PKI, and what other methods are applicable. This is the considerations which we have tried to bring up in the document. If you feel that it is a MUST to implement IPsec on all devices that use IPv6 & connect to the Internet, wouldn't it have been easier to say just that? thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 23:09:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2579bKL026584 for ; Mon, 4 Mar 2002 23:09:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2579bVT026583 for ipng-dist; Mon, 4 Mar 2002 23:09:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2579XKL026576 for ; Mon, 4 Mar 2002 23:09:33 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA00115 for ; Mon, 4 Mar 2002 23:09:34 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00995 for ; Mon, 4 Mar 2002 23:09:32 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g257D3F02699; Tue, 5 Mar 2002 14:13:06 +0700 (ICT) From: Robert Elz To: Jari Arkko cc: Francis Dupont , Margaret Wasserman , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] In-Reply-To: <3C835189.EF375D4C@lmf.ericsson.se> References: <3C835189.EF375D4C@lmf.ericsson.se> <200203040939.g249dpg03701@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Mar 2002 14:13:03 +0700 Message-ID: <2697.1015312383@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 04 Mar 2002 12:50:49 +0200 From: Jari Arkko Message-ID: <3C835189.EF375D4C@lmf.ericsson.se> | The point | is the use of appropriate mechanisms for the task at hand. Yes, but you can't possibly know the mechanisms unless you know the requirements of the nets at both ends of the connection. You know only one of them. If you want your devices to ever be able to communicate with a net being installed in a new building currently being fitted out in Melb Uni, you will need to have IPsec implemented, nothing using clear IP will be connected (ie: packets will be dropped). If the application requires TLS, then it will use TLS, which will mean TLS over IPsec, which is just fine (might seem like overkill, but each is offering different functionality, so it isn't really). Requiring IPsec in *all* IPv6 is what makes this feasible - we know that everyone we're ever going to communicate with will be able to use IPsec. No exceptions. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 4 23:11:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257B0KL026608 for ; Mon, 4 Mar 2002 23:11:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g257B0S1026607 for ipng-dist; Mon, 4 Mar 2002 23:11:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257AvKL026600 for ; Mon, 4 Mar 2002 23:10:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA00751 for ; Mon, 4 Mar 2002 23:10:58 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA10370 for ; Tue, 5 Mar 2002 00:10:56 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g257B3Z18879 for ; Tue, 5 Mar 2002 09:11:03 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 09:10:51 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 09:10:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should IP Security be Optional? Date: Tue, 5 Mar 2002 09:10:51 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64ADF@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional? Thread-Index: AcHDpUv7V2Kx76SnS4S53gd9S9+e3wAb3JzA To: , Cc: , , , , X-OriginalArrivalTime: 05 Mar 2002 07:10:51.0535 (UTC) FILETIME=[E221F1F0:01C1C414] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g257AvKL026601 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mike, > I think the v6 host requirements struck the right > balance: require the IP packet layer transforms, > and be silent on key distribution. Key > distribution is clearly a huge problem, but IPsec > doesn't mandate a single solution so I don't see > why the cellular requirements draft should either. > You can run IPsec with manually configured keys, > after all, so at a base level you can get > interoperability. This is foward progress IMO, > even though we clearly need more going forward. Thanks for the clarification. I can see your point. The authors definately need to review how we address this in the document. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 23:18:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257IXKL026634 for ; Mon, 4 Mar 2002 23:18:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g257IXX7026633 for ipng-dist; Mon, 4 Mar 2002 23:18:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257IUKL026626 for ; Mon, 4 Mar 2002 23:18:30 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03691 for ; Mon, 4 Mar 2002 23:18:32 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06644 for ; Tue, 5 Mar 2002 00:18:26 -0700 (MST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g257IaZ23137 for ; Tue, 5 Mar 2002 09:18:36 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 09:18:22 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 09:18:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should connecting to the Internet be Optional? Date: Tue, 5 Mar 2002 09:18:22 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D50@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should connecting to the Internet be Optional? Thread-Index: AcHDrV2ashIpFybxSzy69P6fTzZrxgAZ5K/Q To: , , X-OriginalArrivalTime: 05 Mar 2002 07:18:22.0354 (UTC) FILETIME=[EED77720:01C1C415] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g257IUKL026627 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tony, > While we can't assume that everything is > reasonable in the constrained environment, we also shouldn't > be throwing out capabilities that history has proven useful simply > because they are hard or cost a little more. I think we'd appreciate more techincal comments on what you thik we got wrong. We've had the draft out for about 9 months, and most of the feedback has been from folks who have been considering how to optimize things. I'm sure we may have over-optimized, so specific recommendations on things are appreciated. Is it useful for us to also discuss the applicability of some of these features (like when & where to use them)? > > => It doesn't. But this is a classical argument > > which essentially says :'if you can't build it > > now, wait for a few years and you'll fit everything > > in'... well, as an engineer I don't have a major > > problem with that, but if I was someone who's > > trying to sell a wide range of products for > > different market segments, and some of those > > need to be limited in many ways to be sellable > > at all, then I would have a problem with this > > logic. > > Product decisions beyond what is technically possible don't belong in > the discussion about standards. My son's 3-year old > calculator has more low-power CPU & memory than the SGI workstation I had 10 > years ago, and it would fit in a package small enough for a 3G handset (and has a > longer battery life than my phone). I have to believe that there are > better options out there now (at least 5 years after that > device design was done), so the fact that a product team doesn't want to > use those for a specific market is not a problem for the IETF. Yeah, but my 4 year-old son's Mac (circa 1988) boots faster, doesn't freeze and the software fits on a floppy - which is much more than I can say about my laptop. Seriously, we are trying to consider IPv6 and ensure that it works, with a minimum amount of configuration, upgrading and a maximum of stability. If you think that specific recommendations we have in our draft are incorrect, please comment. > > => The document does NOT avoid DAD. The document > > is aimed at a generic cellular host, and wherever > > applicable, makes an applicability statement on the > > 3GPP-specific cases. The reason DAD is not needed > > in 3GPP, is that the way an address is allocated > > leaves no room for on-link duplication. And still, > > the document does not say, you MUST NOT do DAD, > > it simply says that in *this* instance of a cellular > > network, DAD is not needed. So if you just want > > to implement it anyway, then go ahead. > > 'A cellular host SHOULD NOT perform Duplicate Address Detection...' > While that is not a MUST NOT, it is a very strong instruction to avoid > it. If it said something like 'A cellular host MAY choose NOT perform > Duplicate Address Detection when it has other means to ensure > uniqueness...' I would be less concerned. That is a good point. > > => This is not a problem and address privacy is already > > supported without the need for DAD. > > The 3gpp-advice draft, the cellular host draft > > and 3GPP TS 23.060 can provide the exact details. > > If there is something specific that makes the statement true, it should > be written here so people don't have to chase around to find it. The > only thing that might make it true is that the router interface on the > subnet will ALWAYS have the 'unique bit' set in an EUI-64 derived > address, and will never use another format. This also presumes that the > handset doesn't provide layer-2 bridging services to other locally > connected devices. If it does that then there is no guarantee > that some device on the allocated subnet will not collide. OK, we'll check into adding text for this. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 23:25:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257PnKL026681 for ; Mon, 4 Mar 2002 23:25:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g257Png6026680 for ipng-dist; Mon, 4 Mar 2002 23:25:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257PkKL026673 for ; Mon, 4 Mar 2002 23:25:46 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA07517 for ; Mon, 4 Mar 2002 23:25:45 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA14943 for ; Tue, 5 Mar 2002 00:25:37 -0700 (MST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g257PiZ27144 for ; Tue, 5 Mar 2002 09:25:44 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 09:25:32 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 09:25:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should connecting to the Internet be Optional? Date: Tue, 5 Mar 2002 09:25:32 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AE2@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should connecting to the Internet be Optional? Thread-Index: AcHDr6vJK9Nkw79xTwmGjLQhrzGAhQAZuMYQ To: , Cc: X-OriginalArrivalTime: 05 Mar 2002 07:25:32.0893 (UTC) FILETIME=[EF7680D0:01C1C416] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g257PkKL026674 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tony, > Actually another thought; what is the difference between a > handset and a laptop that has an embedded 3G radio? Are they both cellular hosts? Yes they are. Our first attempt at the draft was very bias towards devices that would have the v6 stack burned in, so modification was near to impossible. Additionally, 3GPP had some quirks in their IPv6 usage, which would force implementations to do some different (non-standard) thinks in order to work. For the most part, those quirks have been fixed. So, we've tried more to discuss in what cases the requirements / functionalities are needed. For example, use of DAD on a cellular point-to-point link may not be needed. best regards, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 23:26:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257QdKL026698 for ; Mon, 4 Mar 2002 23:26:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g257Qd1C026697 for ipng-dist; Mon, 4 Mar 2002 23:26:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257QZKL026690 for ; Mon, 4 Mar 2002 23:26:35 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA03120 for ; Mon, 4 Mar 2002 23:26:37 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA17167 for ; Mon, 4 Mar 2002 23:26:36 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g257RBi24789 for ; Tue, 5 Mar 2002 09:27:11 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 09:26:34 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 09:26:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Date: Tue, 5 Mar 2002 09:26:34 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AE3@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Thread-Index: AcHDsZ9Q5rCNIOIYRmSlfngy55VXRQAZVT/g To: , , , Cc: X-OriginalArrivalTime: 05 Mar 2002 07:26:34.0710 (UTC) FILETIME=[144F0760:01C1C417] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g257QaKL026691 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Phil, > I'm a little bit concerned about the mobility sections of this > doc. It recommends supporting two drafts that are far from complete > in the MIP working group (HMIP and fast handovers) and where it's hard > to say exactly how those drafts will dome out. I'm also not > sure how fast handovers would be used in this context. Trust me, the authors have struggled with this issue mightily as well. We appreciate comments on what level of support we should include for mobility. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 23:30:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257UAKL026723 for ; Mon, 4 Mar 2002 23:30:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g257U90W026720 for ipng-dist; Mon, 4 Mar 2002 23:30:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257U6KL026713 for ; Mon, 4 Mar 2002 23:30:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05100 for ; Mon, 4 Mar 2002 23:30:05 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07412 for ; Mon, 4 Mar 2002 23:30:03 -0800 (PST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g257UAZ29849 for ; Tue, 5 Mar 2002 09:30:10 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 09:29:58 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 09:29:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should IP Security be Optional? Date: Tue, 5 Mar 2002 09:29:58 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AE4@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional? Thread-Index: AcHDsuGGUI9UsJhMRmOXRqKaLzjVXgAZEOUg To: , Cc: , , , , , X-OriginalArrivalTime: 05 Mar 2002 07:29:58.0733 (UTC) FILETIME=[8DEA77D0:01C1C417] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g257U7KL026714 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, > I do agree that the ESP and AH are really > simple and easy compared to the rest. Unfortunately, > this isn't going to be quite as easy as that. > > As we point out in section 3.8 the current > cellular networks sometimes have dynamic IP > address changes, and therefore manually keyed IPsec > isn't going to work as such and key management is > needed. While there might be multiple options > here, interoperability is a concern and hence > I feel that we must have a mandated key management > scheme. In the cellular host requirements draft, we > have chosen to say that IKE is a MUST in those > cases where we mandate IPsec. Do you disagree? > > (In a way you could say that the cellular draft goes > *beyond* what the current IETF MUSTs are, given > that we mandate a full security solution in all cases, > though at the same time we don't mandate the current > requirement of AH and ESP in all cases.) > > Anyway, this is just *our* proposal on what we think > would make sense. But the document is controlled by the > WG; please state your proposed security MUSTs for > IPv6 hosts, cellular or otherwise. Mike, what would you > like to have there, for instance? Just to add onto Jari - it would be a no-brainer to state that IPsec (AH & ESP) MUST be supported, IKE MAY/SHOULD be supported. However, does this give users anything? Will it increase security for these devices, or is it just something that will make folks happy? The authors prefer to have a reasonable discussion on security within the draft. Knowledge of the field of Internet Security has increased since some of the initial IPv6 documents were published ... thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 23:34:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257YRKL026843 for ; Mon, 4 Mar 2002 23:34:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g257YRL1026842 for ipng-dist; Mon, 4 Mar 2002 23:34:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257YOKL026833 for ; Mon, 4 Mar 2002 23:34:24 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA11047 for ; Mon, 4 Mar 2002 23:33:48 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11910 for ; Tue, 5 Mar 2002 00:33:42 -0700 (MST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g257XqZ02220 for ; Tue, 5 Mar 2002 09:33:52 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 09:33:40 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 09:33:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should connecting to the Internet be Optional? Date: Tue, 5 Mar 2002 09:33:40 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AE5@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should connecting to the Internet be Optional? Thread-Index: AcHDt7lUCyMIdNAyQaKOAJGDm1FkfQAYBu6w To: , , , Cc: X-OriginalArrivalTime: 05 Mar 2002 07:33:40.0906 (UTC) FILETIME=[125760A0:01C1C418] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g257YOKL026836 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Phil, > Well, this needs to be spelled out in some detail then. I'm already > mentally thinking of PocketPC kinds of devices whenever I here > cellular hosts.... Could you re-read the intro to the draft and tell us what parts are unclear - I'm probably a bit blind to the draft at the moment. Anyhow, we specified the term 'minimum' to imply the base set of features needed to ensure interoperability. Anything beyond that is seen as gravy. Again, if some of our recommendations are off-base, please let us know. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 23:35:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257ZtKL026860 for ; Mon, 4 Mar 2002 23:35:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g257ZtHb026859 for ipng-dist; Mon, 4 Mar 2002 23:35:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257ZqKL026852 for ; Mon, 4 Mar 2002 23:35:52 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA11905 for ; Mon, 4 Mar 2002 23:35:49 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA09198 for ; Mon, 4 Mar 2002 23:35:47 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g257dpF02769; Tue, 5 Mar 2002 14:39:51 +0700 (ICT) From: Robert Elz To: "Karim El-Malki (ERA)" cc: "'Margaret Wasserman'" , "Hesham Soliman (ERA)" , juha.wiljakka@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] In-Reply-To: <795A014AF92DD21182AF0008C7A404320DFBEFB8@esealnt117> References: <795A014AF92DD21182AF0008C7A404320DFBEFB8@esealnt117> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Mar 2002 14:39:51 +0700 Message-ID: <2767.1015313991@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 4 Mar 2002 10:44:01 +0100 From: "Karim El-Malki (ERA)" Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFB8@esealnt117> | I think this is related to 3GPP hosts in particular and it is the use of | DADs here that may be excluded. In the 3gpp-advice draft we basically | assign a /64 to the cellular host. That is, the upstream router (GGSN) | only advertises the /64 to one connection/host. A major reason to do that | was to forego a large number of (unreliable) DADs over lossy and expensive | wireless point-to-point links I have seen this argument a couple of times now, and there's, I believe, a degree of correctness about it. Like others, I can see links where address assignment policies don't require DAD to be used, and so where using it would just be a waste of time (and bandwidth, which may or may not matter). But notice just what this is about - it is a property of the link technology in use, and has absolutely nothing to do with the host that is connected at the end of it. That is, the proper place to make this kind of argument / statement, would be in a draft with a title something like "IPv6 over 3GPP network links", which would look very much like the "IPv6 over foobar" drafts/rfcs that now abound. It most certainly should not be in a "requirements for xxx hosts" regardless of the value of xxx - even though a side effect of the statement in a "IPv6 over 3GPP" draft might be that a host which only implements a 3GPP interface might not need to implement DAD at all. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 4 23:36:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257aLKL026873 for ; Mon, 4 Mar 2002 23:36:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g257aKZE026872 for ipng-dist; Mon, 4 Mar 2002 23:36:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257aHKL026865 for ; Mon, 4 Mar 2002 23:36:17 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05437 for ; Mon, 4 Mar 2002 23:36:15 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA20347 for ; Mon, 4 Mar 2002 23:36:01 -0800 (PST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g257ZL310802 for ; Tue, 5 Mar 2002 09:35:21 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 09:35:55 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 09:35:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should connecting to the Internet be Optional? Date: Tue, 5 Mar 2002 09:35:54 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AE6@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should connecting to the Internet be Optional? Thread-Index: AcHDuypu8N9/uJhoTH2VjFJVyMnfEwAXPR2A To: , Cc: , X-OriginalArrivalTime: 05 Mar 2002 07:35:55.0104 (UTC) FILETIME=[62545E00:01C1C418] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g257aHKL026866 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Keith, > > Anyway, we agree on the importance of the router case because > > at least I personally believe the interesting stuff gets here when > > we have Personal Area Networks and such. > > > > Could do that in a separate document, though, seems there's > > enough to discuss even if only hosts are mentioned ;-) > > a separate document is fine w/me; > deferring work on such a document isn't. Agreed. When this draft was first discussed (in London) there was guestions about routing of packets, etc. We tried to clarify that in this draft, we are looking at host functionality. I do think that router / personal router issues need to be addressed. I think that we would like to tackle the host issues first, but router issues need to be discussed (preferably in a seperate doc). thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 23:40:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257e1KL026932 for ; Mon, 4 Mar 2002 23:40:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g257e1I5026931 for ipng-dist; Mon, 4 Mar 2002 23:40:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257dwKL026924 for ; Mon, 4 Mar 2002 23:39:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA06141 for ; Mon, 4 Mar 2002 23:39:57 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA14261 for ; Mon, 4 Mar 2002 23:39:56 -0800 (PST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g257dK312803 for ; Tue, 5 Mar 2002 09:39:20 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 09:39:54 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 09:39:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should connecting to the Internet be Optional? Date: Tue, 5 Mar 2002 09:39:54 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AE7@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should connecting to the Internet be Optional? Thread-Index: AcHDutbO09xUa7A4RMOoz3OYMZCsTwAXaLPw To: , , , X-OriginalArrivalTime: 05 Mar 2002 07:39:54.0814 (UTC) FILETIME=[F13535E0:01C1C418] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g257dwKL026925 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Phil, > But if your multiple wireless interfaces include something like > WLAN it needs to be spelled out which of these recommendations > apply to which interfaces. No? I think that we don't need to even divide things up amongst wireless and non-wireless, as this might be an arbitrary division. We do try to cover cellular links in this draft, which have some special properties, and then discuss the what requirements are for normal interfaces. Most folks view WLAN quite much like regular LAN links, so that we did not think we need to be specific in that respect. Anyhow, for all we know, some devices (which could even be micro-devices) would have an ethernet port on them, in additional to a cellular radio. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 23:40:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257etKL026949 for ; Mon, 4 Mar 2002 23:40:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g257etpL026948 for ipng-dist; Mon, 4 Mar 2002 23:40:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257eqKL026941 for ; Mon, 4 Mar 2002 23:40:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA00267 for ; Mon, 4 Mar 2002 23:40:51 -0800 (PST) Received: from mailweb17.rediffmail.com ([203.199.83.141]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA19973 for ; Tue, 5 Mar 2002 00:40:50 -0700 (MST) Received: (qmail 6723 invoked by uid 510); 5 Mar 2002 07:37:59 -0000 Date: 5 Mar 2002 07:37:59 -0000 Message-ID: <20020305073759.6720.qmail@mailweb17.rediffmail.com> Received: from unknown (164.99.143.100) by rediffmail.com via HTTP; 05 Mar 2002 07:37:59 -0000 MIME-Version: 1.0 From: "Kunapareddy R B" Reply-To: "Kunapareddy R B" To: ipng@sunroof.eng.sun.com Subject: Neighbor Discovery Clarification Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I am new to this group. I might be asking simple questions. Can u clarify the following. *. Router Can be configured automatically as part of Autoconfiguration. *. How can One ensure the autoconfiguration address must be Global Address or Site Local Address or Link Local Address Regards Kunapareddy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 23:42:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257gtKL026975 for ; Mon, 4 Mar 2002 23:42:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g257gsMw026974 for ipng-dist; Mon, 4 Mar 2002 23:42:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257gpKL026967 for ; Mon, 4 Mar 2002 23:42:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA06474 for ; Mon, 4 Mar 2002 23:42:50 -0800 (PST) Received: from mailweb22.rediffmail.com ([203.199.83.146]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA20692 for ; Tue, 5 Mar 2002 00:42:47 -0700 (MST) Received: (qmail 1262 invoked by uid 510); 5 Mar 2002 07:41:35 -0000 Date: 5 Mar 2002 07:41:35 -0000 Message-ID: <20020305074135.1261.qmail@mailweb22.rediffmail.com> Received: from unknown (164.99.143.100) by rediffmail.com via HTTP; 05 Mar 2002 07:41:35 -0000 MIME-Version: 1.0 From: "Kunapareddy R B" Reply-To: "Kunapareddy R B" To: ipng@sunroof.eng.sun.com Subject: Neighbor Discovery Clarification Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I am new to this group. I might be asking simple questions. Can u clarify the following. *. Router Can be configured automatically as part of Autoconfiguration. *. How can One ensure the autoconfiguration address must be Global Address or Site Local Address or Link Local Address Regards Kunapareddy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 23:44:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257i5KL026998 for ; Mon, 4 Mar 2002 23:44:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g257i5QK026997 for ipng-dist; Mon, 4 Mar 2002 23:44:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257i1KL026990 for ; Mon, 4 Mar 2002 23:44:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA14410 for ; Mon, 4 Mar 2002 23:44:00 -0800 (PST) Received: from mailweb22.rediffmail.com ([203.199.83.146]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA27546 for ; Tue, 5 Mar 2002 00:42:33 -0700 (MST) Received: (qmail 919 invoked by uid 510); 5 Mar 2002 07:41:20 -0000 Date: 5 Mar 2002 07:41:20 -0000 Message-ID: <20020305074120.917.qmail@mailweb22.rediffmail.com> Received: from unknown (164.99.143.100) by rediffmail.com via HTTP; 05 Mar 2002 07:41:20 -0000 MIME-Version: 1.0 From: "Kunapareddy R B" Reply-To: "Kunapareddy R B" To: ipng@sunroof.eng.sun.com Subject: Neighbor Discovery Clarification Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I am new to this group. I might be asking simple questions. Can u clarify the following. *. Router Can be configured automatically as part of Autoconfiguration. *. How can One ensure the autoconfiguration address must be Global Address or Site Local Address or Link Local Address Regards Kunapareddy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 4 23:47:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257luKL027021 for ; Mon, 4 Mar 2002 23:47:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g257ltFv027020 for ipng-dist; Mon, 4 Mar 2002 23:47:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g257lqKL027013 for ; Mon, 4 Mar 2002 23:47:52 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA16287 for ; Mon, 4 Mar 2002 23:47:51 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA24359 for ; Mon, 4 Mar 2002 23:46:37 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g257khZ10178 for ; Tue, 5 Mar 2002 09:46:43 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 09:46:31 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 09:46:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] Date: Tue, 5 Mar 2002 09:46:31 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AE9@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] Thread-Index: AcHD7CRCQ39IlOiQSTG8NzwBKWu1zwALZN0A To: , Cc: X-OriginalArrivalTime: 05 Mar 2002 07:46:31.0824 (UTC) FILETIME=[DDD82100:01C1C419] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g257lrKL027014 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Keith, > true enough. but then you need the phone to act like an IPv6 router. But what about if PPP is used? > (it might be sufficient to have the phone act like a network > interface - if the network behind it provides a router and ND/RD etc. > work normally) Agreed. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 00:25:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g258PDKL027122 for ; Tue, 5 Mar 2002 00:25:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g258PCLt027121 for ipng-dist; Tue, 5 Mar 2002 00:25:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g258P9KL027111 for ; Tue, 5 Mar 2002 00:25:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA00982 for ; Tue, 5 Mar 2002 00:25:07 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA05189 for ; Tue, 5 Mar 2002 01:25:03 -0700 (MST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g258PDZ08390 for ; Tue, 5 Mar 2002 10:25:13 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 10:25:02 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 10:13:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Tue, 5 Mar 2002 10:13:02 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AF2@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Thread-Index: AcHECccuwg+363afReeR5KpU3y19MwAE0cKw To: , Cc: X-OriginalArrivalTime: 05 Mar 2002 08:13:02.0759 (UTC) FILETIME=[921D8B70:01C1C41D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g258P9KL027112 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > I understand the argument for why you would not need to > use DAD. > > However, you would need to use NS and NA messages to > establish two-way reachability to the router, before > sending other IP packets to (or through) that router. > This is the basic neighbor discovery mechanism, and > I don't believe that it is optional on point-to-point > links. I've clipped the discussion on Neighbor Discovery from the draft. Essentially, in the 3GPP environment, a layer 2 method is used to obtain connectivity to the default router. Do you feel that we should discuss this mechanism in more detail in order to fully explain why NS and NA messages are only MAY, or do you find fault with our reasoning? thanks, John 2.5 RFC2461 - Neighbor Discovery for IPv6 Neighbor Discovery is described in [RFC-2461] and, in general, MUST be supported. In cellular networks, some Neighbor Discovery messages can cause unnecessary traffic and consume valuable (limited) bandwidth. All current cellular links resemble a point-to-point link, hence, a mobile terminal's only neighbour on the cellular link is the default router which is already known through Router Discovery. This router most likely will not be a final destination for the hostÆs traffic. Additionally, due to special characteristics of the cellular link, lower layer connectivity information should make it unnecessary to track the reachability of the router. Therefore, Neighbor Solicitation and Advertisement messages MAY be implemented for the cellular interface. In addition, a cellular host SHOULD NOT send the link layer sub-option on its cellular interface, and SHOULD silently ignore it if received on the same interface. 2.5.1 Neighbor Discovery in 3GPP 3GPP terminals only need to support Router Solicitations and Router Advertisements for 3GPP IPv6 Address Autoconfiguration. Neighbor Solicitations and Advertisements MAY be used for Neighbor Unreachability Detection (NUD). They are not needed for 3GPP IPv6 Stateless Address Autoconfiguration, since Duplicate Address Detection is not needed in this address assignment mechanism (see section 2.6.1). 2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be supported. 2.6.1 Stateless Address Autoconfiguration in 3GPP A 3GPP cellular host MUST process a Router Advertisement as stated in chapter 5.5.3 of [RFC-2462]. A cellular host SHOULD NOT perform Duplicate Address Detection on its cellular interface, as each delegated prefix is unique within its scope when allocated using the 3GPP IPv6 Stateless Address Autoconfiguration. See appendix B for more details on 3GPP IPv6 Stateless Address Autoconfiguration. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 00:29:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g258T2KL027154 for ; Tue, 5 Mar 2002 00:29:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g258T212027153 for ipng-dist; Tue, 5 Mar 2002 00:29:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g258SxKL027146 for ; Tue, 5 Mar 2002 00:28:59 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA06153 for ; Tue, 5 Mar 2002 00:28:59 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA06714 for ; Tue, 5 Mar 2002 01:28:44 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g258SsZ11493 for ; Tue, 5 Mar 2002 10:28:54 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 10:28:39 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 10:28:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Applicability of draft-ietf-ipv6-cellular-host-00.txt Date: Tue, 5 Mar 2002 10:28:39 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D51@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Applicability of draft-ietf-ipv6-cellular-host-00.txt Thread-Index: AcHDx4VefkJ/p4+8TtmMWQd/3+RxwwAVy1nQ To: , X-OriginalArrivalTime: 05 Mar 2002 08:28:39.0888 (UTC) FILETIME=[C0B01500:01C1C41F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g258T0KL027147 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, > I think part of the questions are around the applicability of > the document. The document doesn't seem to constrain this very > much: > > For the purposes of this document, a cellular host is considered to > be a terminal that uses an air interface to connect to a cellular > access network (i.e. GPRS, UMTS, CDMA2000) in order to provide IPv6 > connectivity to an IP network. > > So unless "terminal" is a well-defined term in the IETF context this > seems to apply to e.g. a full-powered laptop with a PCMCIA radio card, > a cellular phone with a Java JVM that allows it to run downloaded > applications, and perhaps even a router with such an air interface. Parsing through your comment, are you suggesting that be better clarify some instances, such as 1) Closed 'phone' with no additional external interfaces, limited software & upgradability. 2) PDA / phone, small device, small configuration ability, some ability to run extra applications, additional interfaces possible. 3) PCMCIA radio card on a full-powered laptop, with a commercial IP stack If this is useful, then we could then clarify in more detail the difference between a 'host' and a 'router' - I do think that if we try to cover both cases in a single draft, we will run into trouble. Again, the authors do see that some devices will have personal area networks and may route packets, but we feel that this would be best to specify in another document, because there are a lot of different issues involved and this model (phone as personal router) has less applicability than a more generic 'phone' as an endpoint. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 00:31:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g258V2KL027171 for ; Tue, 5 Mar 2002 00:31:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g258V22I027170 for ipng-dist; Tue, 5 Mar 2002 00:31:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g258UxKL027163 for ; Tue, 5 Mar 2002 00:30:59 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA06513 for ; Tue, 5 Mar 2002 00:30:59 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07634 for ; Tue, 5 Mar 2002 01:30:57 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g258Uuq30567 for ; Tue, 5 Mar 2002 10:30:56 +0200 Date: Tue, 5 Mar 2002 10:30:55 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Re: Should connecting to the Internet be Optional? (Half-serious!) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 4 Mar 2002, Tony Hain wrote: (Half-) seriously.. I think connecting to the Internet MAY be optional. I discussed in lcna-minreq thread; I think that if a node like that can not implement IPSEC or security in general, it MUST NOT have a global address. Under some cornercases, link-local and/or site-local _might_ be remotely acceptable. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 00:36:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g258a9KL027194 for ; Tue, 5 Mar 2002 00:36:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g258a9F5027193 for ipng-dist; Tue, 5 Mar 2002 00:36:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g258a6KL027186 for ; Tue, 5 Mar 2002 00:36:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA18179 for ; Tue, 5 Mar 2002 00:35:53 -0800 (PST) From: juha.wiljakka@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA26396 for ; Tue, 5 Mar 2002 01:35:45 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g258ZsZ16166 for ; Tue, 5 Mar 2002 10:35:54 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 10:35:43 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 10:35:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Applicability of draft-ietf-ipv6-cellular-host-00.txt Date: Tue, 5 Mar 2002 10:35:42 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F7856A8@esebe005.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Applicability of draft-ietf-ipv6-cellular-host-00.txt Thread-Index: AcHDx4U+TUEQWAq7Sh6pgWzoENjuFwAVReYg To: , X-OriginalArrivalTime: 05 Mar 2002 08:35:43.0075 (UTC) FILETIME=[BCED4B30:01C1C420] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g258a6KL027187 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Erik and the others! Let me suggest the following - before we can draw good conclusions, we need to better define what we are actually talking about. At least these "cellular host categories" can be imagined: 1) "Closed system" basic 2.5G / 3G terminal typically with fixed applications and software. Examples of such devices could be Nokia 8310, Ericsson T65, Motorola Timeport 280, ... Usually these terminals have a very compact size and optimized functionality. 2) "Open system" 2.5G / 3G terminal. External developers can develop software and applications for such terminals. Examples of such devices could be Ericsson R380, Nokia Communicator 9210/9290, PDAs such as Compaq iPAQ Pocket PC (having e.g. GPRS functionality), ... 3) a "full laptop" with e.g. GPRS/WLAN (PCMCIA) card. These typically are very powerful devices compared to two first categories. An example of WLAN/GPRS card can be found here: http://www.nokia.com/phones/nokiad211/ And if we talk about "minimum IPv6", it should be implementable also for type 1) ... In my opinion, the main focus of our draft has been so far on the cases 1) and 2). Cheers, -Juha W.- -----Original Message----- From: ext Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] Sent: 04 March, 2002 23:50 To: ipng@sunroof.eng.sun.com Subject: Applicability of draft-ietf-ipv6-cellular-host-00.txt I think part of the questions are around the applicability of the document. The document doesn't seem to constrain this very much: For the purposes of this document, a cellular host is considered to be a terminal that uses an air interface to connect to a cellular access network (i.e. GPRS, UMTS, CDMA2000) in order to provide IPv6 connectivity to an IP network. So unless "terminal" is a well-defined term in the IETF context this seems to apply to e.g. a full-powered laptop with a PCMCIA radio card, a cellular phone with a Java JVM that allows it to run downloaded applications, and perhaps even a router with such an air interface. 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 01:04:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2594lKL027263 for ; Tue, 5 Mar 2002 01:04:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2594kxZ027262 for ipng-dist; Tue, 5 Mar 2002 01:04:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2594dKL027255 for ; Tue, 5 Mar 2002 01:04:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15410 for ; Tue, 5 Mar 2002 01:04:32 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19346 for ; Tue, 5 Mar 2002 02:04:31 -0700 (MST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2594fZ10383 for ; Tue, 5 Mar 2002 11:04:41 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 11:04:29 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 11:04:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Tue, 5 Mar 2002 11:04:29 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D53@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDVvSLPE/z9khJSN66svI9fxujrAAzRIXA To: , Cc: , X-OriginalArrivalTime: 05 Mar 2002 09:04:29.0859 (UTC) FILETIME=[C22B9F30:01C1C424] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2594eKL027256 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > However, I think that RFC 2462 should be a MUST for all IPv6 nodes. 2462 states in the introduction: IPv6 defines both a stateful and stateless address autoconfiguration mechanism. Stateless autoconfiguration requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. [some text clipped] The stateless approach is used when a site is not particularly concerned with the exact addresses hosts use, so long as they are unique and properly routable. The stateful approach is used when a site requires tighter control over exact address assignments. Both stateful and stateless address autoconfiguration may be used simultaneously. This leads me to think that IPv6 MUST support either stateless or stateful, but stateless is not mandatory. When we prepared the document, we realized that the 3GPP mechanism looks quite much like an automated stateful process, thus 2462 was probably optional. Are you suggesting: 1) Stateless address autoconfig is needed for 3GPP cellular link 2) Stateless address autoconfig is such a good think, it is needed even if it is not used. thanks! John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 01:15:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g259FmKL027300 for ; Tue, 5 Mar 2002 01:15:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g259FmB7027299 for ipng-dist; Tue, 5 Mar 2002 01:15:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g259FhKL027292 for ; Tue, 5 Mar 2002 01:15:44 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02711 for ; Tue, 5 Mar 2002 01:15:33 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28528 for ; Tue, 5 Mar 2002 01:15:32 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g259FgZ19646 for ; Tue, 5 Mar 2002 11:15:42 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 11:15:29 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 11:15:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should connecting to the Internet be Optional? Date: Tue, 5 Mar 2002 11:15:29 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AF5@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should connecting to the Internet be Optional? Thread-Index: AcHDvqVB9fUpjFt0SZimpN4ZrLVPOQAZyBJQ To: , , , X-OriginalArrivalTime: 05 Mar 2002 09:15:30.0053 (UTC) FILETIME=[4BAD3B50:01C1C426] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g259FjKL027293 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Phil, > Maybe we should call it the cellular interfaces draft???? I think that would not be sufficient. Currently, there is no IPv6 hosts document. If there were one, this discussion would be shorter. I would suggest that some sort of hosts document is needed - it will be a big problem if many companies make devices with IPv6 that function poorly or badly. I would hope that our draft goes someway in ensuring some basic compliance when companies start adding IPv6 to mobile phones. This is a very real thing, most likely the IPv6 stack will not be very upgradable / configurable. > > Regarding Mobile IPv6, were you proposing that Mobile IP not > > be considered in the cellular hosts document if we are only > > describing requirements for basic cellular hosts and no > > multiple-technology devices? > > There are two issues - one is that it's not done, but hopefully soon, > and two that it implies multiple interfaces at this point because > at least in the 3gpp case it's not being considered for mobility > management within the cellular network. But having the capability > there seems important and I would be hesitant to take it out. > It's probably wise to drop the references to HMIP and fast handover > as those are still some distance from standardization. I feel that support for MIPv6 is important in the draft - at least some discussion of it, where it might be applicable, etc. for HMIP & FMIP, I'll leave it to the mobility experts to discuss it. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 01:18:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g259IbKL027317 for ; Tue, 5 Mar 2002 01:18:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g259Iauc027316 for ipng-dist; Tue, 5 Mar 2002 01:18:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g259IXKL027309 for ; Tue, 5 Mar 2002 01:18:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14221 for ; Tue, 5 Mar 2002 01:18:33 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18980 for ; Tue, 5 Mar 2002 02:18:32 -0700 (MST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g259Iti17141 for ; Tue, 5 Mar 2002 11:18:55 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 11:18:14 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 11:18:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should connecting to the Internet be Optional? Date: Tue, 5 Mar 2002 11:18:13 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AF6@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should connecting to the Internet be Optional? Thread-Index: AcHDwMSnJiCIlgUWRVeUsZNwjkcOOgAZZNPA To: Cc: X-OriginalArrivalTime: 05 Mar 2002 09:18:13.0430 (UTC) FILETIME=[AD0E9560:01C1C426] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g259IYKL027310 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tony, > The document is fundamentally flawed because it is focused on a target > product, the micro-3G handset. If it gets rewritten to focus on unique > exceptions for the cellular air-link that are strictly about > addressing the problems that arise from its characteristics, it MAY be > worthy of a WG last call. As there are open issues with the document, I'm not worry about last call. My intent is to get the requirements / features / functions correct. I would hesitate to say the focus is on micro-3G handsets, but to get a starting point for devices that are going to made, which work in constrained environments. Hopefully some of my earier comments have clarified things a bit. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 01:21:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g259LrKL027345 for ; Tue, 5 Mar 2002 01:21:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g259LrhS027344 for ipng-dist; Tue, 5 Mar 2002 01:21:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g259LoKL027337 for ; Tue, 5 Mar 2002 01:21:50 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17349 for ; Tue, 5 Mar 2002 01:21:05 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00772 for ; Tue, 5 Mar 2002 01:20:59 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA19391; Tue, 5 Mar 2002 11:20:52 +0200 Date: Tue, 5 Mar 2002 11:20:52 +0200 Message-Id: <200203050920.LAA19391@burp.tkv.asdf.org> From: Markku Savela To: john.loughney@nokia.com CC: mrw@windriver.com, hesham.soliman@era.ericsson.se, juha.wiljakka@nokia.com, ipng@sunroof.eng.sun.com In-reply-to: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D53@esebe004.NOE.Nokia.com> (john.loughney@nokia.com) Subject: Re: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] References: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D53@esebe004.NOE.Nokia.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f > From: john.loughney@nokia.com > > This leads me to think that IPv6 MUST support either stateless or > stateful, but stateless is not mandatory. This seems quite warped, as stateless is much simpler than stateful (at least with PPP6, which can negotiate ID part). And probably every existing IPv6 stack has stateless supported, and stateful is an option that is supposed to be DHCP6, which nobody has... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 01:23:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g259N9KL027365 for ; Tue, 5 Mar 2002 01:23:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g259N9bm027364 for ipng-dist; Tue, 5 Mar 2002 01:23:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g259N6KL027357 for ; Tue, 5 Mar 2002 01:23:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA04682 for ; Tue, 5 Mar 2002 01:23:05 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA18607 for ; Tue, 5 Mar 2002 01:23:04 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g259NEZ25750 for ; Tue, 5 Mar 2002 11:23:14 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 11:23:02 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 11:23:02 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Tue, 5 Mar 2002 11:23:02 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AF8@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHEJxUe4RAiChWxTomij7RW4rCZVgAAAgcA To: Cc: , , , X-OriginalArrivalTime: 05 Mar 2002 09:23:02.0881 (UTC) FILETIME=[59954D10:01C1C427] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g259N6KL027358 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Markku, > > This leads me to think that IPv6 MUST support either stateless or > > stateful, but stateless is not mandatory. > > This seems quite warped, as stateless is much simpler than stateful > (at least with PPP6, which can negotiate ID part). And probably every > existing IPv6 stack has stateless supported, and stateful is an option > that is supposed to be DHCP6, which nobody has... OK, I'm just asking for clarification. Sorting out what is required and what is not required is actually rather difficult. Believe me, it took a lot of time to try to determine what are actually required RFCs, what are optional, what are good to use, etc. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 02:20:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25AKvKL027461 for ; Tue, 5 Mar 2002 02:20:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25AKudx027460 for ipng-dist; Tue, 5 Mar 2002 02:20:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25AKlKL027453 for ; Tue, 5 Mar 2002 02:20:47 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g25AKgx09045; Tue, 5 Mar 2002 11:20:43 +0100 (MET) Date: Tue, 5 Mar 2002 11:15:44 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Applicability of draft-ietf-ipv6-cellular-host-00.txt To: john.loughney@nokia.com Cc: Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <0C1353ABB1DEB74DB067ADFF749C4EEFD38D51@esebe004.NOE.Nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Parsing through your comment, are you suggesting that be better clarify > some instances, such as > > 1) Closed 'phone' with no additional external interfaces, > limited software & upgradability. > 2) PDA / phone, small device, small configuration ability, > some ability to run extra applications, additional > interfaces possible. > 3) PCMCIA radio card on a full-powered laptop, with > a commercial IP stack I think making the above distinctions would help focus the discussion. BTW: Does 1) include the ability to run e.g. Java applets or other downloadable code? > If this is useful, then we could then clarify in more detail the > difference between a 'host' and a 'router' - I do think that if > we try to cover both cases in a single draft, we will run into > trouble. The draft uses the term "terminal" which I think is defined in 3G. But does that definition explicitly say something about IP level stuff like host vs. router? Or will there soon be "mobile terminals" that have IP router functionality? I suspect it makes sense to very clearly restrict the document to only be about terminals that have no router functionality. Erik > Again, the authors do see that some devices will have personal > area networks and may route packets, but we feel that this would > be best to specify in another document, because there are a lot > of different issues involved and this model (phone as personal > router) has less applicability than a more generic 'phone' > as an endpoint. > > John > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 02:53:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25ArfKL027499 for ; Tue, 5 Mar 2002 02:53:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25Arfiq027498 for ipng-dist; Tue, 5 Mar 2002 02:53:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25ArbKL027491 for ; Tue, 5 Mar 2002 02:53:38 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA20814 for ; Tue, 5 Mar 2002 02:53:39 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA13019 for ; Tue, 5 Mar 2002 02:53:24 -0800 (PST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g25ArYZ02889 for ; Tue, 5 Mar 2002 12:53:34 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 12:53:23 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 12:53:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Applicability of draft-ietf-ipv6-cellular-host-00.txt Date: Tue, 5 Mar 2002 12:53:23 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D55@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Applicability of draft-ietf-ipv6-cellular-host-00.txt Thread-Index: AcHEL6phty8ghu4iTGuzDMySokWUYgAAA+Xw To: Cc: X-OriginalArrivalTime: 05 Mar 2002 10:53:23.0218 (UTC) FILETIME=[F85B1720:01C1C433] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g25ArcKL027492 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, > > 1) Closed 'phone' with no additional external interfaces, > > limited software & upgradability. > > 2) PDA / phone, small device, small configuration ability, > > some ability to run extra applications, additional > > interfaces possible. > > 3) PCMCIA radio card on a full-powered laptop, with > > a commercial IP stack > > I think making the above distinctions would help focus the discussion. Then we will do this. > BTW: Does 1) include the ability to run e.g. Java applets or > other downloadable code? I think we would clasify it as closed, no applets or downloadable code. > > If this is useful, then we could then clarify in more detail the > > difference between a 'host' and a 'router' - I do think that if > > we try to cover both cases in a single draft, we will run into > > trouble. > > The draft uses the term "terminal" which I think is defined in 3G. > But does that definition explicitly say something about IP level stuff > like host vs. router? We've tried to limit the term 'terminal' for that point, it is not an IETF term. We tried to eliminate the use of the word 'terminal' from the main body of the text, but a quick search seems to show we haven't done a good job. Perhaps we should define the term. > Or will there soon be "mobile terminals" that have IP router > functionality? > I suspect it makes sense to very clearly restrict the document to only > be about terminals that have no router functionality. Right now, in 3GPP specifications, there is not this possibility. The market might do something else at some point (my visibility isn't exactly clear on this point), but it has always been my intention that terminals with IP router functionality should have seperate requirements, something I think most of the authors are interested in specifying (in a seperate draft) after this draft is done. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 03:20:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25BKBKL027523 for ; Tue, 5 Mar 2002 03:20:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25BKBvx027522 for ipng-dist; Tue, 5 Mar 2002 03:20:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25BK8KL027515 for ; Tue, 5 Mar 2002 03:20:08 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25340 for ; Tue, 5 Mar 2002 03:20:07 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA11607 for ; Tue, 5 Mar 2002 03:20:06 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23428; Tue, 5 Mar 2002 06:20:02 -0500 (EST) Message-Id: <200203051120.GAA23428@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-router-selection-01.txt Date: Tue, 05 Mar 2002 06:20:02 -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 IP Version 6 Working Group Working Group of the IETF. Title : Default Router Preferences and More-Specific Routes Author(s) : R. Draves Filename : draft-ietf-ipv6-router-selection-01.txt Pages : 13 Date : 04-Mar-02 This document describes an optional extension to Neighbor Discovery Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-router-selection-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipv6-router-selection-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipv6-router-selection-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020304133440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-router-selection-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-router-selection-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304133440.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 03:21:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25BL9KL027550 for ; Tue, 5 Mar 2002 03:21:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25BL8Kg027549 for ipng-dist; Tue, 5 Mar 2002 03:21:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25BL3KL027542 for ; Tue, 5 Mar 2002 03:21:03 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA24945 for ; Tue, 5 Mar 2002 03:21:02 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA08015 for ; Tue, 5 Mar 2002 04:21:00 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23573; Tue, 5 Mar 2002 06:20:58 -0500 (EST) Message-Id: <200203051120.GAA23573@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-kitamura-ipv6-name-auto-reg-01.txt Date: Tue, 05 Mar 2002 06:20:58 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Domain Name Auto-Registration for Plugged-in IPv6 Nodes Author(s) : H. Kitamura Filename : draft-kitamura-ipv6-name-auto-reg-01.txt Pages : 19 Date : 04-Mar-02 This document describes a scheme of 'Domain Name Auto-Registration for Plugged-in IPv6 Nodes' mechanism that makes it possible to register both regular and inverse domain name information of plugged- in IPv6 nodes to DNS servers automatically. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kitamura-ipv6-name-auto-reg-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-kitamura-ipv6-name-auto-reg-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-kitamura-ipv6-name-auto-reg-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020304140931.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kitamura-ipv6-name-auto-reg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-kitamura-ipv6-name-auto-reg-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020304140931.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 05:50:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25Do8KL027969 for ; Tue, 5 Mar 2002 05:50:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25Do8K3027968 for ipng-dist; Tue, 5 Mar 2002 05:50:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25Do4KL027961 for ; Tue, 5 Mar 2002 05:50:04 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14368 for ; Tue, 5 Mar 2002 05:50:05 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02490 for ; Tue, 5 Mar 2002 06:50:04 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g25DnpF15805; Tue, 5 Mar 2002 08:49:51 -0500 (EST) Message-Id: <200203051349.g25DnpF15805@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: john.loughney@nokia.com cc: moore@cs.utk.edu, Jonne.Soininen@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] In-reply-to: (Your message of "Tue, 05 Mar 2002 09:46:31 +0200.") <0C1353ABB1DEB74DB067ADFF749C4EEFC64AE9@esebe004.NOE.Nokia.com> Date: Tue, 05 Mar 2002 08:49:51 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > true enough. but then you need the phone to act like an IPv6 router. > > But what about if PPP is used? I don't immediately see how the choice of link-level protocol changes this. Keith p.s. assuming this is a serial interface, PPP framing might be a reasonable choice. But PPP authentication, link negotiation, etc. (as I have experienced them, I admit I haven't followed the specs in recent years) don't seem like a good fit. for instance, would use of PPP restrict the user to at most one IP host attached to the phone? that would seem like an overly restrictive choice. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 06:06:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25E6CKL028057 for ; Tue, 5 Mar 2002 06:06:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25E6CWV028056 for ipng-dist; Tue, 5 Mar 2002 06:06:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25E68KL028049 for ; Tue, 5 Mar 2002 06:06:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17143 for ; Tue, 5 Mar 2002 06:06:09 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10130 for ; Tue, 5 Mar 2002 07:06:08 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g25E5sF18497; Tue, 5 Mar 2002 09:05:54 -0500 (EST) Message-Id: <200203051405.g25E5sF18497@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: juha.wiljakka@nokia.com cc: Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Applicability of draft-ietf-ipv6-cellular-host-00.txt In-reply-to: (Your message of "Tue, 05 Mar 2002 10:35:42 +0200.") <245DBCAEEC4F074CB77B3F984FF9834F7856A8@esebe005.NOE.Nokia.com> Date: Tue, 05 Mar 2002 09:05:54 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > At least these "cellular host categories" can be imagined: > > 1) "Closed system" basic 2.5G / 3G terminal typically with fixed > applications and software. Examples of such devices could be Nokia > 8310, Ericsson T65, Motorola Timeport 280, ... Usually these > terminals have a very compact size and optimized functionality. > 2) "Open system" 2.5G / 3G terminal. External developers can develop > software and applications for such terminals. Examples of such > devices could be Ericsson R380, Nokia Communicator 9210/9290, PDAs > such as Compaq iPAQ Pocket PC (having e.g. GPRS functionality), ... > 3) a "full laptop" with e.g. GPRS/WLAN (PCMCIA) card. These typically > are very powerful devices compared to two first categories. An > example of WLAN/GPRS card can be found here: > http://www.nokia.com/phones/nokiad211/ these sound like useful categories. however, for categories #1 and #2 there would need to be different requirements depending on whether or not the device had an external interface to which one or more other IPv6 hosts could be attached. as for category #3, I'd focus on defining the requirements of the network interface that is seen by the laptop, rather than the requirements of the laptop itself. presumably the laptop is a normal IPv6 host and doesn't have unusual requirements. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 06:18:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25EIbKL028079 for ; Tue, 5 Mar 2002 06:18:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25EIbMJ028078 for ipng-dist; Tue, 5 Mar 2002 06:18:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25EIYKL028071 for ; Tue, 5 Mar 2002 06:18:34 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17832 for ; Tue, 5 Mar 2002 06:18:35 -0800 (PST) From: juha.wiljakka@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16944 for ; Tue, 5 Mar 2002 06:18:34 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g25EJBi26883 for ; Tue, 5 Mar 2002 16:19:11 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 16:18:32 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 16:18:32 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Applicability of draft-ietf-ipv6-cellular-host-00.txt Date: Tue, 5 Mar 2002 16:18:32 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F7856B1@esebe005.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Applicability of draft-ietf-ipv6-cellular-host-00.txt Thread-Index: AcHETuVtFYV8RG2CTWCWxUPjkYGmgwAAIQ+g To: Cc: , X-OriginalArrivalTime: 05 Mar 2002 14:18:32.0573 (UTC) FILETIME=[A14D9AD0:01C1C450] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g25EIYKL028072 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! -----Original Message----- From: ext Keith Moore [mailto:moore@cs.utk.edu] Sent: 05 March, 2002 16:06 To: Wiljakka Juha (NMP/Tampere) Cc: Erik.Nordmark@eng.sun.com; ipng@sunroof.eng.sun.com Subject: Re: Applicability of draft-ietf-ipv6-cellular-host-00.txt > At least these "cellular host categories" can be imagined: > > 1) "Closed system" basic 2.5G / 3G terminal typically with fixed > applications and software. Examples of such devices could be Nokia > 8310, Ericsson T65, Motorola Timeport 280, ... Usually these > terminals have a very compact size and optimized functionality. > 2) "Open system" 2.5G / 3G terminal. External developers can develop > software and applications for such terminals. Examples of such > devices could be Ericsson R380, Nokia Communicator 9210/9290, PDAs > such as Compaq iPAQ Pocket PC (having e.g. GPRS functionality), ... > 3) a "full laptop" with e.g. GPRS/WLAN (PCMCIA) card. These typically > are very powerful devices compared to two first categories. An > example of WLAN/GPRS card can be found here: > http://www.nokia.com/phones/nokiad211/ these sound like useful categories. however, for categories #1 and #2 there would need to be different requirements depending on whether or not the device had an external interface to which one or more other IPv6 hosts could be attached. JWi: Thanks for your opinion! This is a relevant point to think about - however, a typical case in 3GPP architecture would be connecting a laptop computer to the mobile terminal using PPP(v6). as for category #3, I'd focus on defining the requirements of the network interface that is seen by the laptop, rather than the requirements of the laptop itself. presumably the laptop is a normal IPv6 host and doesn't have unusual requirements. JWi: Good point as well. Certainly, laptop is a "normal IPv6 host" and does not need special treatment. We could write some clarifying text about the laptop (network interface) and leave the laptop IPv6 functionality to be defined in a separate specification (a generic IPv6 host draft)? Cheers, -Juha W.- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 06:20:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25EK2KL028096 for ; Tue, 5 Mar 2002 06:20:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25EK2qf028095 for ipng-dist; Tue, 5 Mar 2002 06:20:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25EJwKL028088 for ; Tue, 5 Mar 2002 06:19:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA28811 for ; Tue, 5 Mar 2002 06:19:59 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16229 for ; Tue, 5 Mar 2002 07:19:58 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g25EJvZc020989 for ; Tue, 5 Mar 2002 15:19:58 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Tue Mar 05 15:19:10 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 15:09:13 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFD0@esealnt117> From: "Karim El-Malki (ERA)" To: "'Keith Moore'" , john.loughney@nokia.com Cc: Jonne.Soininen@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] Date: Tue, 5 Mar 2002 15:17:51 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > true enough. but then you need the phone to act like an > IPv6 router. > > > > But what about if PPP is used? > > I don't immediately see how the choice of link-level > protocol changes this. > > Keith > > p.s. assuming this is a serial interface, PPP framing might > be a reasonable > choice. But PPP authentication, link negotiation, etc. (as > I have experienced > them, I admit I haven't followed the specs in recent years) > don't seem like > a good fit. for instance, would use of PPP restrict the > user to at most one > IP host attached to the phone? that would seem like an > overly restrictive choice. No. The terminal (phone) doesn't need to act as a router to allow for multiple devices behind it to connect to the cellular interface. You could eventually have multiple serial connections to the terminal each having its own corresponding air interface connection. So it can act as a host (if you're running the IP stack + app on it) or as an L2 device (modem) for e.g. laptops behind it. That doesn't mean that there's no advantages in making it a router but it's not mandatory. Given that implementers need guidelines now, it's good if we only limit the scope to hosts for the moment and go onto routers once the first is complete. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 06:48:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25EmJKL028120 for ; Tue, 5 Mar 2002 06:48:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25EmJfh028119 for ipng-dist; Tue, 5 Mar 2002 06:48:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25EmFKL028112 for ; Tue, 5 Mar 2002 06:48:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23146; Tue, 5 Mar 2002 06:48:13 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25234; Tue, 5 Mar 2002 07:48:12 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g25ElUF24407; Tue, 5 Mar 2002 09:47:30 -0500 (EST) Message-Id: <200203051447.g25ElUF24407@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: juha.wiljakka@nokia.com cc: moore@cs.utk.edu, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Applicability of draft-ietf-ipv6-cellular-host-00.txt In-reply-to: (Your message of "Tue, 05 Mar 2002 16:18:32 +0200.") <245DBCAEEC4F074CB77B3F984FF9834F7856B1@esebe005.NOE.Nokia.com> Date: Tue, 05 Mar 2002 09:47:30 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > these sound like useful categories. however, for categories #1 and #2 > there would need to be different requirements depending on whether > or not the device had an external interface to which one or more other > IPv6 hosts could be attached. > > JWi: Thanks for your opinion! This is a relevant point to think about - > however, a typical case in 3GPP architecture would be connecting a > laptop computer to the mobile terminal using PPP(v6). The requirements should not assume what kind of device may be attached, and they certainly should not constrain the type of such devices. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 06:55:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25EtWKL028145 for ; Tue, 5 Mar 2002 06:55:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25EtWGi028144 for ipng-dist; Tue, 5 Mar 2002 06:55:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25EtSKL028137 for ; Tue, 5 Mar 2002 06:55:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA25480 for ; Tue, 5 Mar 2002 06:55:27 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29121 for ; Tue, 5 Mar 2002 07:55:26 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g25ErJF25142; Tue, 5 Mar 2002 09:53:19 -0500 (EST) Message-Id: <200203051453.g25ErJF25142@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Karim El-Malki (ERA)" cc: "'Keith Moore'" , john.loughney@nokia.com, Jonne.Soininen@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] In-reply-to: (Your message of "Tue, 05 Mar 2002 15:17:51 +0100.") <795A014AF92DD21182AF0008C7A404320DFBEFD0@esealnt117> Date: Tue, 05 Mar 2002 09:53:18 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > No. The terminal (phone) doesn't need to act as a router to allow > for multiple devices behind it to connect to the cellular interface. > You could eventually have multiple serial connections to the terminal > each having its own corresponding air interface connection. So it can > act as a host (if you're running the IP stack + app on it) or as > an L2 device (modem) for e.g. laptops behind it. That doesn't mean > that there's no advantages in making it a router but it's not > mandatory. The point, I think, is that the network that is seen by the devices atached to the terminal must support all features of an IPv6 network so that any IPv6 hosts can function when their connectivity is provided through such a terminal. (subject to the normal bandwidth, delay, packet loss etc. constraints) Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 07:26:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25FQaKL028172 for ; Tue, 5 Mar 2002 07:26:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25FQaOp028171 for ipng-dist; Tue, 5 Mar 2002 07:26:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25FQXKL028164 for ; Tue, 5 Mar 2002 07:26:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA00138 for ; Tue, 5 Mar 2002 07:26:32 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA11992 for ; Tue, 5 Mar 2002 08:26:31 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g25FQUB25932 for ; Tue, 5 Mar 2002 16:26:30 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Mar 05 16:26:16 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 16:26:05 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFD1@esealnt117> From: "Karim El-Malki (ERA)" To: "'Keith Moore'" Cc: john.loughney@nokia.com, Jonne.Soininen@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] Date: Tue, 5 Mar 2002 16:25:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > No. The terminal (phone) doesn't need to act as a router to allow > > for multiple devices behind it to connect to the cellular > interface. > > You could eventually have multiple serial connections to > the terminal > > each having its own corresponding air interface > connection. So it can > > act as a host (if you're running the IP stack + app on it) or as > > an L2 device (modem) for e.g. laptops behind it. That doesn't mean > > that there's no advantages in making it a router but it's not > > mandatory. > > The point, I think, is that the network that is seen by the devices > atached to the terminal must support all features of an IPv6 network > so that any IPv6 hosts can function when their connectivity is > provided through such a terminal. (subject to the normal bandwidth, > delay, packet loss etc. constraints) Agreed, being able to provide connectivity from the "terminal" to a generic v6 host behind it was always the aim. Overall I don't think that there is something preventing this in the cellular host draft if we reach agreement on the security sections. However if you're a basic standalone host with only a cellular interface that runs a specific set of apps then you should be free not to implement everything that a generic host has. That is also important to have in the draft and I believe that's what the cellular-interface-specific sections (e.g. 3gpp) are doing. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 07:37:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25Fb6KL028191 for ; Tue, 5 Mar 2002 07:37:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25Fb6xD028190 for ipng-dist; Tue, 5 Mar 2002 07:37:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25Fb3KL028183 for ; Tue, 5 Mar 2002 07:37:03 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20240 for ; Tue, 5 Mar 2002 07:37:02 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21276 for ; Tue, 5 Mar 2002 08:37:02 -0700 (MST) Subject: RE: I-D ACTION:draft-ietf-ipv6-router-selection-01.txt Date: Tue, 5 Mar 2002 07:36:57 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DEFD@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Thread-Index: AcHDMa6Nk3UYRh/zRD+yQG+eDO/mdwBKNcWw From: "Michel Py" To: Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g25Fb3KL028184 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Richard, Preliminary comments: If I read it correctly, all the RA extensions are based on destination IPv6 address. I can see several situations where it might be useful to have some RA extensions based on the source address as well, which would create some kind of a policy routing in the hosts (decide where to send traffic based on the source IP, not the destination one). Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 07:46:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25FkuKL028208 for ; Tue, 5 Mar 2002 07:46:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25FkuHe028207 for ipng-dist; Tue, 5 Mar 2002 07:46:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25FkqKL028200 for ; Tue, 5 Mar 2002 07:46:52 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02595 for ; Tue, 5 Mar 2002 07:46:52 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA23385 for ; Tue, 5 Mar 2002 08:46:51 -0700 (MST) Received: from kenawang ([192.168.1.60]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA19204 for ; Tue, 5 Mar 2002 07:46:31 -0800 (PST) Message-Id: <4.2.2.20020305103309.00e4c6c0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 05 Mar 2002 10:45:31 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: Updating draft-ietf-ipv6-cellular-host-00.txt? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Before folks go and do a lot of additional work to update draft-ietf-ipv6-cellular-host-00.txt based on our discussions, I think we have to answer a fundamental question: Should the WG publish an informational RFC detailing the IPv6 requirements for cellular hosts? If so, how can we prevent the two most likely bad outcomes: - 3GPP (or other) folks thinking that this document is an IETF standard? [May be handled by a strongly worded disclaimer in the document?] - Everyone with an agenda attempting to publish a similar document for their "special" category of IPv6 host? [Can we just say 'no'?] I also think that we should start work on two standards-track documents, both of which would use the current draft as input: - An "IPv6 over " document for 3GPP links. - A general "IPv6 Node Requirements" document. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 07:47:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25FlFKL028218 for ; Tue, 5 Mar 2002 07:47:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25FlFXX028217 for ipng-dist; Tue, 5 Mar 2002 07:47:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25Fl9KL028210 for ; Tue, 5 Mar 2002 07:47:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22938 for ; Tue, 5 Mar 2002 07:47:08 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26671 for ; Tue, 5 Mar 2002 08:47:08 -0700 (MST) Received: from kenawang ([192.168.1.60]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA19160; Tue, 5 Mar 2002 07:46:25 -0800 (PST) Message-Id: <4.2.2.20020305100050.00e4c840@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 05 Mar 2002 10:24:06 -0500 To: john.loughney@nokia.com From: Margaret Wasserman Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Cc: ipng@sunroof.eng.sun.com In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AF2@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John, > This router > most likely will not be a final destination for the host's traffic. > Additionally, due to special characteristics of the cellular link, > lower layer connectivity information should make it unnecessary to > track the reachability of the router. We have defined a mechanism to locate and maintain reachability information about neighbours in IPv6, called "Neighbor Discovery". This isn't an optional part of IPv6 that it would be appropriate to disable on a particular link type. However, it is expected for ND to receive "advice" from other layers regarding the "reachability" of another host -- so it would be great if the L2 mechanism gave ongoing advice to IPv6 regarding the reachability of the router, which would result in suppressing IPv6 NS messages. I don't believe that your conclusion is sound... >Therefore, Neighbor > Solicitation and Advertisement messages MAY be implemented for the > cellular interface. An implementor could read this and believe that it was acceptable to build a 3GPP cell phone (with only one cellular interface) that didn't even contain the _code_ necessary to generate IPv6 NS and NA messages. What happens when that host receives an NS message? Do you think that people may ever want to set-up redundant 3GPP networks, or make a choice between two possible 3GPP routers, based on their current reachability? If you don't use ND, how will this information be available for IPv6 routing decisions? There seems to be a mis-perception in the 3GPP community that ND will result in a lot of extra traffic. The idea of ND is to locate the other node _once_ and maintain reachability information about that node on an ongoing basis, using advice from other layers, _without_ sending additional ND messages unless absolutely necessary. Are there reasons why you think that this won't work on 3GPP hosts? >In addition, a cellular host SHOULD NOT send the > link layer sub-option on its cellular interface, and SHOULD silently > ignore it if received on the same interface. This is fine, and would be an excellent piece of information to put in a standards-track "IP over " document. >2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration > > IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be > supported. This should be a MUST. IPv6 hosts MUST support address autoconfiguration, although it is possible for the routers to be configured so that it isn't used (if desired). > A cellular host SHOULD NOT perform Duplicate Address Detection on > its cellular interface, as each delegated prefix is unique within > its scope when allocated using the 3GPP IPv6 Stateless Address > Autoconfiguration. Will the router end of the link allocate any addresses within the unique /64 assigned to the PDP context? If so, what mechanism will be used to ensure that the host doesn't allocate the same address? If it's actually true that a conflict can never occur, then we should indicate that DAD won't be used on these link types in an "IPv6 over " document, as previously discussed. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 07:47:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25FltKL028235 for ; Tue, 5 Mar 2002 07:47:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25Fltbh028234 for ipng-dist; Tue, 5 Mar 2002 07:47:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25FlnKL028227 for ; Tue, 5 Mar 2002 07:47:50 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23080 for ; Tue, 5 Mar 2002 07:47:49 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00510 for ; Tue, 5 Mar 2002 07:47:47 -0800 (PST) Received: from kenawang ([192.168.1.60]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA19099; Tue, 5 Mar 2002 07:46:13 -0800 (PST) Message-Id: <4.2.2.20020305094655.00e472d0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 05 Mar 2002 09:57:43 -0500 To: Robert Elz From: Margaret Wasserman Subject: Re: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] Cc: "Karim El-Malki (ERA)" , "Hesham Soliman (ERA)" , juha.wiljakka@nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: <2767.1015313991@brandenburg.cs.mu.OZ.AU> References: <795A014AF92DD21182AF0008C7A404320DFBEFB8@esealnt117> <795A014AF92DD21182AF0008C7A404320DFBEFB8@esealnt117> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with Robert on this... >That is, the proper place to make this kind of argument / statement, would >be in a draft with a title something like "IPv6 over 3GPP network links", >which would look very much like the "IPv6 over foobar" drafts/rfcs that >now abound. Many of the specific technical issues raised in this "requirements" document would be best handled in an "IPv6 over " document. This document could cover the specific behaviour of IPv6 over a cellular link. We should also update some of the base IPv6 specs to expect that certain portions of IPv6 behaviour (i.e. whether or not to use DAD) will be dependent on the link type, and defined in the "IPv6 over " documents for each link type. Of course, we then have to define this behaviour for each of the link types that we've already specified (ethernet, PPP, etc.). None of this is rocket science, but it will require some updates to existing standards currently at DS. Is this something that we want to do at this point? >It most certainly should not be in a "requirements for xxx hosts" >regardless of the value of xxx - even though a side effect of the >statement in a "IPv6 over 3GPP" draft might be that a host which only >implements a 3GPP interface might not need to implement DAD at all. In fact, I am pretty certain that we _don't_ want to head down the path of publishing an informational "Requirements for xxx Hosts" document for every specialized host type... Over time, it will be impossible to maintain these documents, and they will mislead people regarding what the actual standards-based requirements are for IPv6. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 08:17:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25GHSKL028304 for ; Tue, 5 Mar 2002 08:17:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25GHRJb028303 for ipng-dist; Tue, 5 Mar 2002 08:17:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25GHMKL028293 for ; Tue, 5 Mar 2002 08:17:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09747 for ; Tue, 5 Mar 2002 08:17:22 -0800 (PST) Received: from mail5.nc.rr.com ([24.93.67.52]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26412 for ; Tue, 5 Mar 2002 08:17:22 -0800 (PST) Received: from lorien.sc.innovationslab.net ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 5 Mar 2002 11:16:46 -0500 Message-ID: <3C84EF96.499F8FA3@lorien.sc.innovationslab.net> Date: Tue, 05 Mar 2002 11:17:26 -0500 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman CC: ipng@sunroof.eng.sun.com Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? References: <4.2.2.20020305103309.00e4c6c0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, Margaret Wasserman wrote: > > Before folks go and do a lot of additional work to update > draft-ietf-ipv6-cellular-host-00.txt based on our discussions, > I think we have to answer a fundamental question: > > Should the WG publish an informational RFC detailing the IPv6 > requirements for cellular hosts? I don't think we should. It just starts us down that slippery slope of creating new "foo hosts" requirements docs. Your following arguments are reason enough to avoid this path. > > If so, how can we prevent the two most likely bad outcomes: > > - 3GPP (or other) folks thinking that this document > is an IETF standard? [May be handled by > a strongly worded disclaimer in the document?] > - Everyone with an agenda attempting to publish a > similar document for their "special" > category of IPv6 host? [Can we just say 'no'?] > > I also think that we should start work on two standards-track > documents, both of which would use the current draft as > input: > > - An "IPv6 over " document for 3GPP links. > - A general "IPv6 Node Requirements" document. Definitely agree with this. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 08:17:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25GHRKL028301 for ; Tue, 5 Mar 2002 08:17:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25GHR0h028300 for ipng-dist; Tue, 5 Mar 2002 08:17:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25GHLKL028286 for ; Tue, 5 Mar 2002 08:17:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01760 for ; Tue, 5 Mar 2002 08:17:21 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18637 for ; Tue, 5 Mar 2002 09:17:20 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g25GHJZc012564 for ; Tue, 5 Mar 2002 17:17:19 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 05 17:15:59 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 17:07:32 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFD3@esealnt117> From: "Karim El-Malki (ERA)" To: "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Tue, 5 Mar 2002 17:16:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > However, it is expected for ND to receive "advice" from other layers > regarding the "reachability" of another host -- so it would be > great if the L2 mechanism gave ongoing advice to IPv6 regarding > the reachability of the router, which would result in suppressing > IPv6 NS messages. Yes, that's what a basic host with only a cellular interface would do. If there's nobody else on your cellular link (as is the case) then you won't receive NSs and don't need to send NAs. I think this is the reason for the MAY in relation to the special cellular host case. > > I don't believe that your conclusion is sound... > > >Therefore, Neighbor > > Solicitation and Advertisement messages MAY be > implemented for the > > cellular interface. > > An implementor could read this and believe that it was acceptable > to build a 3GPP cell phone (with only one cellular interface) that > didn't even contain the _code_ necessary to generate IPv6 NS and > NA messages. > > What happens when that host receives an NS message? It won't because a cellular host /e.g. 3gpp) is alone on its link. > > Do you think that people may ever want to set-up redundant > 3GPP networks, or make a choice between two possible 3GPP > routers, based on their current reachability? If you don't > use ND, how will this information be available for IPv6 > routing decisions? You can only have one so that's not a 3gpp requirement. > >2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration > > > > IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be > > supported. > > This should be a MUST. IPv6 hosts MUST support address > autoconfiguration, > although it is possible for the routers to be configured so > that it isn't > used (if desired). If you're a host with only a cellular interface you don't need to run DADs for example. The 3gpp host as per 3gpp-advice draft gets a prefix delegated on which to generate addresses. Link-local is handled using PPP. > > > A cellular host SHOULD NOT perform Duplicate Address > Detection on > > its cellular interface, as each delegated prefix is > unique within > > its scope when allocated using the 3GPP IPv6 Stateless Address > > Autoconfiguration. > > Will the router end of the link allocate any addresses within the > unique /64 assigned to the PDP context? If so, what mechanism will > be used to ensure that the host doesn't allocate the same address? No, the router doesn't allocate any addresses on the "delegated" prefix. That was the assumption behind our 3gpp-advice draft and has been followed by 3gpp. > > If it's actually true that a conflict can never occur, then we should > indicate that DAD won't be used on these link types in an > "IPv6 over " document, as previously discussed. OK. But a host which only has a cellular interface doesn't need to implement DADs so it should be in the cellular hosts draft right? /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 08:29:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25GTqKL028352 for ; Tue, 5 Mar 2002 08:29:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25GTqpi028351 for ipng-dist; Tue, 5 Mar 2002 08:29:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25GTnKL028344 for ; Tue, 5 Mar 2002 08:29:49 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA11274 for ; Tue, 5 Mar 2002 08:29:49 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02531 for ; Tue, 5 Mar 2002 08:29:48 -0800 (PST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Mar 2002 11:22:51 -0500 Message-ID: From: Phil Roberts To: "'Brian Haberman'" , Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Tue, 5 Mar 2002 11:22:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I don't think we should. It just starts us down that > slippery slope of creating new "foo hosts" requirements docs. > Your following arguments are reason enough to avoid this path. Agree we shouldn't. > > > > > If so, how can we prevent the two most likely bad outcomes: > > > > - 3GPP (or other) folks thinking that this document > > is an IETF standard? [May be handled by > > a strongly worded disclaimer in the document?] > > - Everyone with an agenda attempting to publish a > > similar document for their "special" > > category of IPv6 host? [Can we just say 'no'?] > > > > I also think that we should start work on two standards-track > > documents, both of which would use the current draft as > > input: > > > > - An "IPv6 over " document for 3GPP links. > > - A general "IPv6 Node Requirements" document. > > Definitely agree with this. I also agree. > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 08:55:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25Gt4KL028385 for ; Tue, 5 Mar 2002 08:55:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25Gt4Ib028384 for ipng-dist; Tue, 5 Mar 2002 08:55:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25Gt0KL028377 for ; Tue, 5 Mar 2002 08:55:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17207 for ; Tue, 5 Mar 2002 08:55:00 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06478 for ; Tue, 5 Mar 2002 09:55:00 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g25GscF14366; Tue, 5 Mar 2002 11:54:38 -0500 (EST) Message-Id: <200203051654.g25GscF14366@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Karim El-Malki (ERA)" cc: "'Margaret Wasserman'" , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] In-reply-to: (Your message of "Tue, 05 Mar 2002 17:16:17 +0100.") <795A014AF92DD21182AF0008C7A404320DFBEFD3@esealnt117> Date: Tue, 05 Mar 2002 11:54:38 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > What happens when that host receives an NS message? > > It won't because a cellular host /e.g. 3gpp) is alone on its link. I don't see why this should necessarily be the case, unless 3gpp is trying to treat IPv6 as a link layer. what if there are one or more hosts connected to the data interface on a terminal, that want to communicate directly with applications on the terminal? the terminal will need to support ND to alow this to happen. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 08:55:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25GtIKL028395 for ; Tue, 5 Mar 2002 08:55:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25GtIUD028394 for ipng-dist; Tue, 5 Mar 2002 08:55:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25GtEKL028387 for ; Tue, 5 Mar 2002 08:55:14 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14233 for ; Tue, 5 Mar 2002 08:55:14 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10843 for ; Tue, 5 Mar 2002 09:55:14 -0700 (MST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Mar 2002 11:48:22 -0500 Message-ID: From: Phil Roberts To: "'john.loughney@nokia.com'" , Phil Roberts , juha.wiljakka@nokia.com, tony@tndh.net, moore@cs.utk.edu Cc: ipng@sunroof.eng.sun.com Subject: RE: Should connecting to the Internet be Optional? Date: Tue, 5 Mar 2002 11:48:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sure. "For the purposes of this document, a cellular host is considered to be a terminal that uses an air interface to connect to a cellular access network (i.e. GPRS, UMTS, CDMA2000) in order to provide IPv6 connectivity to an IP network." As others have pointed out it's hard to be more ambiguous than this. What is a terminal? There is this in the abbreviations section: "TE Terminal Equipment. For example, a laptop attached through a 3GPP handset." And especially when you start talking about UMTS IMS capable devices, one does not necessarily think of small, limited bandwidth, not updateable with new software, kinds of devices. So the issue here is that it is anticipated there is about to be an explosion of v6 capable cellular devices for 3gpp standardized networks and that not providing guidance on host requirements may make it difficult for such devices to interoperate? A different approach might be to write a v6 host requirements doc akin to 1122 and realize that device implementors may have to make intelligent decisions about what not to include if it's not possible to include everything specified in that. Phil > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, March 05, 2002 2:34 AM > To: PRoberts@megisto.com; juha.wiljakka@nokia.com; > tony@tndh.net; moore@cs.utk.edu > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Should connecting to the Internet be Optional? > > > Hi Phil, > > > Well, this needs to be spelled out in some detail then. > I'm already > > mentally thinking of PocketPC kinds of devices whenever I here > > cellular hosts.... > > Could you re-read the intro to the draft and tell us what > parts are unclear - I'm probably a bit blind to the draft at > the moment. > > Anyhow, we specified the term 'minimum' to imply the base set > of features needed to ensure interoperability. Anything > beyond that is seen as gravy. Again, if some of our > recommendations are off-base, please let us know. > > thanks, > John > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 08:57:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25GvpKL028425 for ; Tue, 5 Mar 2002 08:57:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25Gvpah028424 for ipng-dist; Tue, 5 Mar 2002 08:57:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25GvmKL028417 for ; Tue, 5 Mar 2002 08:57:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15120 for ; Tue, 5 Mar 2002 08:57:48 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05336 for ; Tue, 5 Mar 2002 09:57:48 -0700 (MST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Mar 2002 11:50:56 -0500 Message-ID: From: Phil Roberts To: "'john.loughney@nokia.com'" , Phil Roberts , Karim.El-Malki@era.ericsson.se, tony@tndh.net, ipng@sunroof.eng.sun.com Subject: RE: Should connecting to the Internet be Optional? Date: Tue, 5 Mar 2002 11:50:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, March 05, 2002 4:15 AM > To: PRoberts@megisto.com; Karim.El-Malki@era.ericsson.se; > tony@tndh.net; ipng@sunroof.eng.sun.com > Subject: RE: Should connecting to the Internet be Optional? > > > Hi Phil, > > > Maybe we should call it the cellular interfaces draft???? > > I think that would not be sufficient. Currently, there is no > IPv6 hosts document. If there were one, this discussion > would be shorter. I would suggest that some sort of hosts > document is needed - it will be a big problem if many companies > make devices with IPv6 that function poorly or badly. I > would hope that our draft goes someway in ensuring some basic > compliance when companies start adding IPv6 to mobile phones. > This is a very real thing, most likely the IPv6 stack will > not be very upgradable / configurable. I simply disagree with this. On some devices this may be true, but certainly not on all, and perhaps not even on the majority of devices used for data operations. > > > > Regarding Mobile IPv6, were you proposing that Mobile IP not > > > be considered in the cellular hosts document if we are only > > > describing requirements for basic cellular hosts and no > > > multiple-technology devices? > > > > There are two issues - one is that it's not done, but > hopefully soon, > > and two that it implies multiple interfaces at this point > because at > > least in the 3gpp case it's not being considered for mobility > > management within the cellular network. But having the capability > > there seems important and I would be hesitant to take it out. It's > > probably wise to drop the references to HMIP and fast handover as > > those are still some distance from standardization. > > I feel that support for MIPv6 is important in the draft - at > least some discussion of it, where it might be applicable, > etc. for HMIP & FMIP, I'll leave it to the mobility experts > to discuss it. > > John > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 09:02:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25H2vKL028448 for ; Tue, 5 Mar 2002 09:02:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25H2v19028447 for ipng-dist; Tue, 5 Mar 2002 09:02:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25H2rKL028440 for ; Tue, 5 Mar 2002 09:02:53 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20361 for ; Tue, 5 Mar 2002 09:02:54 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA18113 for ; Tue, 5 Mar 2002 09:02:53 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g25H2qZc001536 for ; Tue, 5 Mar 2002 18:02:52 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Tue Mar 05 18:02:44 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 18:02:43 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFD6@esealnt117> From: "Karim El-Malki (ERA)" To: "'Keith Moore'" Cc: "'Margaret Wasserman'" , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Tue, 5 Mar 2002 18:01:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > What happens when that host receives an NS message? > > > > It won't because a cellular host /e.g. 3gpp) is alone on its link. > > I don't see why this should necessarily be the case, unless > 3gpp is trying to treat IPv6 as a link layer. No, it's just a normal point-to-point link as we discussed some mails ago with Francis. There's only the router and the cellular host. Router reachability can be handled using L2 information (possible in cellular links) or through NUD. That's why NS/NAs are not strictly needed. > > what if there are one or more hosts connected to the data interface > on a terminal, that want to communicate directly with applications > on the terminal? the terminal will need to support ND to > alow this to happen. Agreed. But in the email I was considering a host which only has a cellular interface. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 09:08:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25H8pKL028544 for ; Tue, 5 Mar 2002 09:08:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25H8plg028542 for ipng-dist; Tue, 5 Mar 2002 09:08:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25H8mKL028535 for ; Tue, 5 Mar 2002 09:08:48 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19193 for ; Tue, 5 Mar 2002 09:08:49 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA14351 for ; Tue, 5 Mar 2002 09:08:47 -0800 (PST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Mar 2002 12:01:55 -0500 Message-ID: From: Phil Roberts To: "'john.loughney@nokia.com'" , Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Applicability of draft-ietf-ipv6-cellular-host-00.txt Date: Tue, 5 Mar 2002 12:01:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > BTW: Does 1) include the ability to run e.g. Java applets or > > other downloadable code? > > I think we would clasify it as closed, no applets or > downloadable code. Hmmm. I think you've excluded a large number (the majority) of the kinds of devices that you'd like to be giving guidance on. > > Or will there soon be "mobile terminals" that have IP router > > functionality? > > I suspect it makes sense to very clearly restrict the > document to only > > be about terminals that have no router functionality. > > Right now, in 3GPP specifications, there is not this > possibility. The market might do something else at some point > (my visibility isn't exactly clear on this point), but it has > always been my intention that terminals with IP router > functionality should > have seperate requirements, something I think most of the > authors are interested in specifying (in a seperate draft) > after this draft is done. Hmmm (again). I guess I'm wondering what is to prevent the terminal from having a router in it. 3gpp has agreed to update the spec to assign a prefix, no? What's to keep someone from running routing protocols over the link? > > thanks, > John > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 09:22:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HMOKL028709 for ; Tue, 5 Mar 2002 09:22:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25HMOeS028708 for ipng-dist; Tue, 5 Mar 2002 09:22:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HMKKL028701 for ; Tue, 5 Mar 2002 09:22:20 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24871 for ; Tue, 5 Mar 2002 09:22:21 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21938 for ; Tue, 5 Mar 2002 09:22:20 -0800 (PST) Received: from kenawang (d_73nuj.wrs.com [147.11.46.202] (may be forged)) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id JAA17955; Tue, 5 Mar 2002 09:21:51 -0800 (PST) Message-Id: <4.2.2.20020305121521.020f8880@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 05 Mar 2002 12:22:10 -0500 To: "Karim El-Malki (ERA)" From: Margaret Wasserman Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: <795A014AF92DD21182AF0008C7A404320DFBEFD3@esealnt117> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >It won't because a cellular host /e.g. 3gpp) is alone on its link. On a point-to-point link, there must be at least two nodes... In this case, one node is the cellular host and the other is the 3GPP router (GGSN). The link is the PDP Context. If more than one host is attached via a cell phone (using the cell phone as a layer 2 "modem"), each attached host will establish a separate PDP context (and a separate IPv6 link), and receive a separate /64 delegation. So, I agree that there won't be more than 2 nodes on a 3GPP cellular link, the way things are currently specified. >If you're a host with only a cellular interface you don't need >to run DADs for example. The 3gpp host as per 3gpp-advice draft gets a >prefix delegated on which to generate addresses. Link-local >is handled using PPP. There will be (at least) two prefixes in use on the link: a global prefix (the delegated /64) and the link-local prefix. It is my understanding that the GGSN will use a link-local address on the link. And, it is important that the link-local address in use by the GGSN _not_ conflict with the link-local address(es) in use on the host. This could definitely be achieved by other means than running DAD on the link, though, which is fine with me. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 09:27:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HR9KL028749 for ; Tue, 5 Mar 2002 09:27:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25HR9PO028748 for ipng-dist; Tue, 5 Mar 2002 09:27:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HR6KL028741 for ; Tue, 5 Mar 2002 09:27:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA26601 for ; Tue, 5 Mar 2002 09:27:02 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28918 for ; Tue, 5 Mar 2002 09:27:01 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 05 Mar 2002 09:26:59 -0800 From: "Tony Hain" To: "Karim El-Malki \(ERA\)" , "'Margaret Wasserman'" , Cc: Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Tue, 5 Mar 2002 09:26:59 -0800 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <795A014AF92DD21182AF0008C7A404320DFBEFD3@esealnt117> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Karim El-Malki wrote: > No, the router doesn't allocate any addresses on the > "delegated" prefix. > That was the assumption behind our 3gpp-advice draft and has > been followed > by 3gpp. The router has to allocate at least 1 address in the prefix, even if it is just the all-routers address. It is also likely to create another one that is unique to itself, so there has to be a mechanism in that which will ensure that the remote end doesn't collide when it chooses a 3041 address. The only obvious choice is to make sure that bit 6 is set, which in turn means that the router is using an EUI-64 derived address. Since I don't have access to the 3G specs, is that all true? Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 09:29:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HTiKL028769 for ; Tue, 5 Mar 2002 09:29:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25HTiit028768 for ipng-dist; Tue, 5 Mar 2002 09:29:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HTfKL028761 for ; Tue, 5 Mar 2002 09:29:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28151 for ; Tue, 5 Mar 2002 09:29:42 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00161 for ; Tue, 5 Mar 2002 09:29:41 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 05 Mar 2002 09:29:40 -0800 From: "Tony Hain" To: "Margaret Wasserman" , Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Tue, 5 Mar 2002 09:29:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.2.2.20020305103309.00e4c6c0@mail.windriver.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > Before folks go and do a lot of additional work to update > draft-ietf-ipv6-cellular-host-00.txt based on our discussions, > I think we have to answer a fundamental question: > > Should the WG publish an informational RFC detailing the IPv6 > requirements for cellular hosts? > > If so, how can we prevent the two most likely bad outcomes: > > - 3GPP (or other) folks thinking that this document > is an IETF standard? [May be handled by > a strongly worded disclaimer in the document?] > - Everyone with an agenda attempting to publish a > similar document for their "special" > category of IPv6 host? [Can we just say 'no'?] > > I also think that we should start work on two standards-track > documents, both of which would use the current draft as > input: > > - An "IPv6 over " document for 3GPP links. > - A general "IPv6 Node Requirements" document. > Thank you Margaret. You have made the point much more concisely than I did, and translating this doc into IPv6 over foo is exactly what needs to happen. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 09:34:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HY7KL028792 for ; Tue, 5 Mar 2002 09:34:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25HY7hb028791 for ipng-dist; Tue, 5 Mar 2002 09:34:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HY4KL028784 for ; Tue, 5 Mar 2002 09:34:04 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00030 for ; Tue, 5 Mar 2002 09:34:04 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24357 for ; Tue, 5 Mar 2002 10:33:58 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g25HY7Z09608 for ; Tue, 5 Mar 2002 19:34:08 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 19:33:56 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 19:33:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Tue, 5 Mar 2002 19:33:56 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B14@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHEXTjYcMmoP21BSXSVxfI73uVEAQADYjNw To: , X-OriginalArrivalTime: 05 Mar 2002 17:33:56.0723 (UTC) FILETIME=[ED70EC30:01C1C46B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g25HY4KL028785 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > Before folks go and do a lot of additional work to update > draft-ietf-ipv6-cellular-host-00.txt based on our discussions, > I think we have to answer a fundamental question: I am having a hard time understanding what your objections to the document are. You have raised some good technical points & we are looking at how to address them & revise the document. However, you seem to be saying now that the technical issues are not important. > Should the WG publish an informational RFC detailing the IPv6 > requirements for cellular hosts? Is the issue the title of the document. If the draft were titled 'Applicability of IPv6 for Cellular Hosts' - would that make a difference? > If so, how can we prevent the two most likely bad outcomes: > > - 3GPP (or other) folks thinking that this document > is an IETF standard? [May be handled by > a strongly worded disclaimer in the document?] If the draft can go through the process of becoming an RFC, with work group consensus, etc. what is the problem? > - Everyone with an agenda attempting to publish a > similar document for their "special" > category of IPv6 host? [Can we just say 'no'?] Of course, I do think that you are being very unfair in this statement. Most of the authors are IETF participants, not 3GPP participants. We have no 'agenda' - or at least no more than your average IETF participant. This is not 3GPP trying to push anything in the IETF. Also, I really don't think that involving a more diverse set of participants in the IETF is a bad thing. I think we ought to encourage more direct participation in the IETF rather than less. Do you feel it is a problem if folks from the FOO SDO starting participating in the IETF, and functioning under IETF rules? I really could not find a problem with that. > I also think that we should start work on two standards-track > documents, both of which would use the current draft as > input: > > - An "IPv6 over " document for 3GPP links. > - A general "IPv6 Node Requirements" document. My suggestion would be that we work on these documents: - The current document - General IPv6 host Requirements - General IPv6 node requirements (mixture of routing + host functions). I think that we may want to consider making the current document more of an applicability statement or something along those lines. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 09:38:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HcHKL028814 for ; Tue, 5 Mar 2002 09:38:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25HcHZe028813 for ipng-dist; Tue, 5 Mar 2002 09:38:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HcEKL028806 for ; Tue, 5 Mar 2002 09:38:14 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01865 for ; Tue, 5 Mar 2002 09:38:15 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00248 for ; Tue, 5 Mar 2002 10:38:01 -0700 (MST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g25HcZi10890 for ; Tue, 5 Mar 2002 19:38:35 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 19:37:57 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 19:37:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should connecting to the Internet be Optional? Date: Tue, 5 Mar 2002 19:37:56 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B15@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should connecting to the Internet be Optional? Thread-Index: AcHEZo6NIOYGQvxpRkaWGO8cRgvLIgABcjyg To: Cc: X-OriginalArrivalTime: 05 Mar 2002 17:37:57.0029 (UTC) FILETIME=[7CACB550:01C1C46C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g25HcEKL028807 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Phil, > As others have pointed out it's hard to be more ambiguous than this. > What is a terminal? > > There is this in the abbreviations section: > > "TE Terminal Equipment. For example, a laptop attached > through a 3GPP handset." TE is actually something quite different than terminal. I think we should come up with a different term than terminal in the document. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 09:42:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HgPKL028837 for ; Tue, 5 Mar 2002 09:42:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25HgPob028836 for ipng-dist; Tue, 5 Mar 2002 09:42:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HgMKL028829 for ; Tue, 5 Mar 2002 09:42:22 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03268 for ; Tue, 5 Mar 2002 09:42:18 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02930 for ; Tue, 5 Mar 2002 09:42:16 -0800 (PST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g25HgNZ12087 for ; Tue, 5 Mar 2002 19:42:23 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 19:42:11 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 19:42:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Applicability of draft-ietf-ipv6-cellular-host-00.txt Date: Tue, 5 Mar 2002 19:42:11 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B16@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Applicability of draft-ietf-ipv6-cellular-host-00.txt Thread-Index: AcHEat8uFVDu2jOOSBOpDNzezD+pbgAAchoQ To: , Cc: X-OriginalArrivalTime: 05 Mar 2002 17:42:11.0823 (UTC) FILETIME=[148B2FF0:01C1C46D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g25HgMKL028830 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Phil, > > > BTW: Does 1) include the ability to run e.g. Java applets or > > > other downloadable code? > > > > I think we would clasify it as closed, no applets or > > downloadable code. > > Hmmm. I think you've excluded a large number (the majority) of the > kinds of devices that you'd like to be giving guidance on. There will be many different types of devices, some will support downloadable code, some will not. Currently, I don't know if the majority will be one sort or another. Some folks will want bells & wistles, some won't. I prefer to turn java off when I browse the net ... > > Right now, in 3GPP specifications, there is not this > > possibility. The market might do something else at some point > > (my visibility isn't exactly clear on this point), but it has > > always been my intention that terminals with IP router > > functionality should > > have seperate requirements, something I think most of the > > authors are interested in specifying (in a seperate draft) > > after this draft is done. > > Hmmm (again). I guess I'm wondering what is to prevent the > terminal from having a router in it. 3gpp has agreed to update > the spec to assign a prefix, no? What's to keep someone from > running routing protocols over the link? Again, we have never said that this won't happen, there are then quite a few additional issues to be tackled. We're seperating the two functionalities. For example, I don't think a general host requirement document should address routing either. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 09:47:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25Hl3KL028857 for ; Tue, 5 Mar 2002 09:47:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25Hl3K5028856 for ipng-dist; Tue, 5 Mar 2002 09:47:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25Hl0KL028849 for ; Tue, 5 Mar 2002 09:47:00 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04731 for ; Tue, 5 Mar 2002 09:47:01 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05630 for ; Tue, 5 Mar 2002 10:46:55 -0700 (MST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g25HkJ315049 for ; Tue, 5 Mar 2002 19:46:19 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 19:46:53 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 19:46:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Tue, 5 Mar 2002 19:46:53 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B18@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHEYY+CB8zIzHvITtW5elHHSYjMZAAC/Ekg To: , Cc: X-OriginalArrivalTime: 05 Mar 2002 17:46:53.0684 (UTC) FILETIME=[BC8BC340:01C1C46D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g25Hl0KL028850 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > I don't think we should. It just starts us down that slippery slope > of creating new "foo hosts" requirements docs. Your following > arguments are reason enough to avoid this path. Is your complaint that the document is Minimum IPv6 Requirements for a Cellular Hosts? Are there problems with the content? Do you agree or disagree with the intent of the document, which is to provide guidence on what to implement on a cellular host & what the applicability of those features are? John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 09:50:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HooKL028874 for ; Tue, 5 Mar 2002 09:50:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25Hoo8F028873 for ipng-dist; Tue, 5 Mar 2002 09:50:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HokKL028866 for ; Tue, 5 Mar 2002 09:50:47 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05143 for ; Tue, 5 Mar 2002 09:50:47 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08327 for ; Tue, 5 Mar 2002 10:50:46 -0700 (MST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g25HoA315997 for ; Tue, 5 Mar 2002 19:50:10 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 5 Mar 2002 19:50:44 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 5 Mar 2002 19:50:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Tue, 5 Mar 2002 19:50:43 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B1A@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHEY03/7AXltjVpT8ygqDW/XuJDYgACntgQ To: , , Cc: X-OriginalArrivalTime: 05 Mar 2002 17:50:44.0562 (UTC) FILETIME=[4628F320:01C1C46E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g25HolKL028867 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Phil, > > I don't think we should. It just starts us down that > > slippery slope of creating new "foo hosts" requirements docs. > > Your following arguments are reason enough to avoid this path. > > Agree we shouldn't. If the discussion is that creating hosts requirements for every kind of device is a bad idea, well, I think that you may have a point. What I think we have been trying to do in the draft is really discuss the applicability of various IPv6 standards & features for a cellualr host. In some cases, we go beyond what a general host requirements would say. So my question to the list, is what is contained in the draft fundamentally flawed or not. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 09:57:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HvJKL028902 for ; Tue, 5 Mar 2002 09:57:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25HvJ4a028901 for ipng-dist; Tue, 5 Mar 2002 09:57:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HvFKL028894 for ; Tue, 5 Mar 2002 09:57:15 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10627 for ; Tue, 5 Mar 2002 09:57:16 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15870 for ; Tue, 5 Mar 2002 10:57:15 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g25HuwF20219; Tue, 5 Mar 2002 12:56:58 -0500 (EST) Message-Id: <200203051756.g25HuwF20219@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Margaret Wasserman cc: "Karim El-Malki (ERA)" , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] In-reply-to: (Your message of "Tue, 05 Mar 2002 12:22:10 EST.") <4.2.2.20020305121521.020f8880@mail.windriver.com> Date: Tue, 05 Mar 2002 12:56:58 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >It won't because a cellular host /e.g. 3gpp) is alone on its link. > > On a point-to-point link, there must be at least two nodes... > In this case, one node is the cellular host and the other is > the 3GPP router (GGSN). > > The link is the PDP Context. If more than one host is attached > via a cell phone (using the cell phone as a layer 2 "modem"), each > attached host will establish a separate PDP context (and a separate > IPv6 link), and receive a separate /64 delegation. So, I agree > that there won't be more than 2 nodes on a 3GPP cellular link, the > way things are currently specified. that's bizarre. does that mean that apps on a host that's connected to a cell phone won't be able to communicate with apps on that cell phone unless the cell phone is talking to the network? and that communications between the host and the cell phone will have to go over the wireless network? Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 09:59:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HxRKL028922 for ; Tue, 5 Mar 2002 09:59:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25HxRTn028921 for ipng-dist; Tue, 5 Mar 2002 09:59:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25HxNKL028914 for ; Tue, 5 Mar 2002 09:59:23 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07446 for ; Tue, 5 Mar 2002 09:59:24 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13599 for ; Tue, 5 Mar 2002 10:59:23 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g25HxMZc015164 for ; Tue, 5 Mar 2002 18:59:22 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 05 18:58:02 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 5 Mar 2002 18:59:21 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFD7@esealnt117> From: "Karim El-Malki (ERA)" To: "'Tony Hain'" , "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Tue, 5 Mar 2002 18:58:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Karim El-Malki wrote: > > No, the router doesn't allocate any addresses on the > > "delegated" prefix. > > That was the assumption behind our 3gpp-advice draft and has > > been followed > > by 3gpp. > > The router has to allocate at least 1 address in the prefix, > even if it > is just the all-routers address. It is also likely to create > another one > that is unique to itself, This special router is called a GGSN and it knows it MUST NOT configure itself with a unicast address on that prefix. That means there's no conflict. Does that make sense? /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 10:01:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25I17KL028939 for ; Tue, 5 Mar 2002 10:01:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25I17lt028938 for ipng-dist; Tue, 5 Mar 2002 10:01:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25I14KL028931 for ; Tue, 5 Mar 2002 10:01:04 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07365 for ; Tue, 5 Mar 2002 10:01:05 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12134 for ; Tue, 5 Mar 2002 10:01:02 -0800 (PST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Mar 2002 12:54:09 -0500 Message-ID: From: Phil Roberts To: "'john.loughney@nokia.com'" , Phil Roberts , Erik.Nordmark@eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Applicability of draft-ietf-ipv6-cellular-host-00.txt Date: Tue, 5 Mar 2002 12:54:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, March 05, 2002 12:42 PM > To: PRoberts@megisto.com; Erik.Nordmark@eng.sun.com > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Applicability of draft-ietf-ipv6-cellular-host-00.txt > > > Hi Phil, > > There will be many different types of devices, some will > support downloadable code, some will not. Currently, I don't > know if the majority will be one sort or another. Some folks > will want bells & wistles, some won't. I prefer to turn java > off when I > browse the net ... I agree. But my uncle, who was the first person I knew to have a cellphone doesn't know what java is, much less how to turn it off. > > > > Hmmm (again). I guess I'm wondering what is to prevent the > terminal > > from having a router in it. 3gpp has agreed to update the spec to > > assign a prefix, no? What's to keep someone from running routing > > protocols over the link? > > Again, we have never said that this won't happen, there are > then quite a few additional issues to be tackled. We're > seperating the two functionalities. For example, I don't > think a general host requirement document should address > routing either. I agree with that. But I was just curious why you thought you couldn't attach a router on the mobile device end of a GTP pipe? > > John > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 10:03:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25I3sKL028964 for ; Tue, 5 Mar 2002 10:03:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25I3s92028963 for ipng-dist; Tue, 5 Mar 2002 10:03:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25I3oKL028956 for ; Tue, 5 Mar 2002 10:03:50 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13101 for ; Tue, 5 Mar 2002 10:03:47 -0800 (PST) Received: from fep06-app.kolumbus.fi (fep06-0.kolumbus.fi [193.229.0.57]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13789 for ; Tue, 5 Mar 2002 10:03:45 -0800 (PST) Received: from jariws1 ([62.248.148.147]) by fep06-app.kolumbus.fi with SMTP id <20020305180343.YUOH20539.fep06-app.kolumbus.fi@jariws1>; Tue, 5 Mar 2002 20:03:43 +0200 Message-ID: <012b01c1c470$207f9d20$8a1b6e0a@arenanet.fi> From: "Jari Arkko" To: , "Margaret Wasserman" References: <4.2.2.20020305103309.00e4c6c0@mail.windriver.com> Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Tue, 5 Mar 2002 20:04:00 +0200 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.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, You had the below proposal: > I also think that we should start work on two standards-track > documents, both of which would use the current draft as > input: > > - An "IPv6 over " document for 3GPP links. > - A general "IPv6 Node Requirements" document. I would very much like to have e.g. the general node requirements document, and your approach of splitting into two documents looks very clean. I have already in the past announced my interest on working on the general host document, so I would like to see it happen, as soon as possible. However, I do have a concern. Or at least some issues, but perhaps you can suggest how to deal with them. I think most of us agree that a host requirements document is something that we should have and is a necessary one. If we had a general document I'm pretty sure there'd be no need for any specific XXX host requirements documents. Now, my concern is this: how long do you think producing the general document to an RFC will take? What should we say in the meantime to folks who want to deploy IPv6 now? If there are decisions as to what to do with ND/DAD/whatever, should those be made by (a) IPv6 WG, (b) 3GPP, or (c) vendors? Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 10:25:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25IPBKL029163 for ; Tue, 5 Mar 2002 10:25:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25IPBeM029162 for ipng-dist; Tue, 5 Mar 2002 10:25:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25IP8KL029155 for ; Tue, 5 Mar 2002 10:25:08 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16646 for ; Tue, 5 Mar 2002 10:25:07 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA26549 for ; Tue, 5 Mar 2002 10:25:07 -0800 (PST) Received: from T23KEMPF ([172.21.96.179]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g25IOpe26029; Tue, 5 Mar 2002 10:24:51 -0800 (PST) Message-ID: <056701c1c472$d21a9d80$b36015ac@T23KEMPF> From: "James Kempf" To: "Phil Roberts" , , Cc: References: Subject: Re: Applicability of draft-ietf-ipv6-cellular-host-00.txt Date: Tue, 5 Mar 2002 10:23:14 -0800 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.50.4522.1200 x-mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, I think some 90% of the new cellphones, even low end, now have Java on them. Carriers like it. But the last spec I saw for the Java MidP (the Java profile that runs on a cell phone) did not have a way to open a socket. You could only go through a URL. That may have changed. So I think it is likely that most cellphones will have Java on them, but it is not clear whether they will be programmable to use IP at the level most people do on other IP capable devices. jak ----- Original Message ----- From: "Phil Roberts" To: ; "Phil Roberts" ; Cc: Sent: Tuesday, March 05, 2002 9:54 AM Subject: RE: Applicability of draft-ietf-ipv6-cellular-host-00.txt > > > > -----Original Message----- > > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > > Sent: Tuesday, March 05, 2002 12:42 PM > > To: PRoberts@megisto.com; Erik.Nordmark@eng.sun.com > > Cc: ipng@sunroof.eng.sun.com > > Subject: RE: Applicability of draft-ietf-ipv6-cellular-host-00.txt > > > > > > Hi Phil, > > > > There will be many different types of devices, some will > > support downloadable code, some will not. Currently, I don't > > know if the majority will be one sort or another. Some folks > > will want bells & wistles, some won't. I prefer to turn java > > off when I > > browse the net ... > > I agree. But my uncle, who was the first person I knew to have a cellphone > doesn't know what java is, much less how to turn it off. > > > > > > > > Hmmm (again). I guess I'm wondering what is to prevent the > > terminal > > > from having a router in it. 3gpp has agreed to update the spec to > > > assign a prefix, no? What's to keep someone from running routing > > > protocols over the link? > > > > Again, we have never said that this won't happen, there are > > then quite a few additional issues to be tackled. We're > > seperating the two functionalities. For example, I don't > > think a general host requirement document should address > > routing either. > > I agree with that. But I was just curious why you thought you couldn't > attach a router on the mobile device end of a GTP pipe? > > > > > John > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 10:30:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25IUHKL029245 for ; Tue, 5 Mar 2002 10:30:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25IUHZu029244 for ipng-dist; Tue, 5 Mar 2002 10:30:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25IUDKL029237 for ; Tue, 5 Mar 2002 10:30:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23460 for ; Tue, 5 Mar 2002 10:30:12 -0800 (PST) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25432 for ; Tue, 5 Mar 2002 11:30:07 -0700 (MST) Received: from lorien.sc.innovationslab.net ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 5 Mar 2002 12:46:12 -0500 Message-ID: <3C85048C.53C591F@lorien.sc.innovationslab.net> Date: Tue, 05 Mar 2002 12:46:53 -0500 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com CC: mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B14@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, Since I have already voiced an agreement with Margaret's suggestion, let me explain my rationale. Your document is a mix of: 1. Host requirements (granted they are limited functionality hosts) 2. IPv6 over cellular links requirements I believe that #2 is important as a standalone document. But #1 belongs in a general host requirements document. In Margaret's proposal, your doc would be the genesis of two new docs that solve bigger needs for the WG. The technical suggestions made can simply be included in the new drafts. Regards, Brian john.loughney@nokia.com wrote: > > Hi Margaret, > > > Before folks go and do a lot of additional work to update > > draft-ietf-ipv6-cellular-host-00.txt based on our discussions, > > I think we have to answer a fundamental question: > > I am having a hard time understanding what your objections > to the document are. You have raised some good technical > points & we are looking at how to address them & revise > the document. However, you seem to be saying now that the > technical issues are not important. > > > Should the WG publish an informational RFC detailing the IPv6 > > requirements for cellular hosts? > > Is the issue the title of the document. If the draft were > titled 'Applicability of IPv6 for Cellular Hosts' - > would that make a difference? > > > If so, how can we prevent the two most likely bad outcomes: > > > > - 3GPP (or other) folks thinking that this document > > is an IETF standard? [May be handled by > > a strongly worded disclaimer in the document?] > > If the draft can go through the process of becoming an > RFC, with work group consensus, etc. what is the problem? > > > - Everyone with an agenda attempting to publish a > > similar document for their "special" > > category of IPv6 host? [Can we just say 'no'?] > > Of course, I do think that you are being very unfair in > this statement. Most of the authors are IETF participants, > not 3GPP participants. We have no 'agenda' - or at > least no more than your average IETF participant. This > is not 3GPP trying to push anything in the IETF. Also, > I really don't think that involving a more diverse set > of participants in the IETF is a bad thing. I think > we ought to encourage more direct participation in the > IETF rather than less. Do you feel it is a problem if > folks from the FOO SDO starting participating in the IETF, > and functioning under IETF rules? I really could not > find a problem with that. > > > I also think that we should start work on two standards-track > > documents, both of which would use the current draft as > > input: > > > > - An "IPv6 over " document for 3GPP links. > > - A general "IPv6 Node Requirements" document. > > My suggestion would be that we work on these documents: > > - The current document > - General IPv6 host Requirements > - General IPv6 node requirements (mixture of routing + host functions). > > I think that we may want to consider making the current document more > of an applicability statement or something along those lines. > > John > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 10:33:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25IXXKL029354 for ; Tue, 5 Mar 2002 10:33:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25IXXQM029353 for ipng-dist; Tue, 5 Mar 2002 10:33:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25IXTKL029346 for ; Tue, 5 Mar 2002 10:33:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23300 for ; Tue, 5 Mar 2002 10:33:29 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07012 for ; Tue, 5 Mar 2002 11:33:28 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA04439; Tue, 5 Mar 2002 10:33:27 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g25IXQ208747; Tue, 5 Mar 2002 10:33:26 -0800 X-mProtect:  Tue, 5 Mar 2002 10:33:26 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdDDjmnb; Tue, 05 Mar 2002 10:33:24 PST Message-ID: <3C850F75.2D4D3910@iprg.nokia.com> Date: Tue, 05 Mar 2002 10:33:25 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: ipng@sunroof.eng.sun.com, Margaret Wasserman Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? References: <4.2.2.20020305103309.00e4c6c0@mail.windriver.com> <012b01c1c470$207f9d20$8a1b6e0a@arenanet.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari Arkko wrote: > how long do you think producing the general document > to an RFC will take? What should we say in the > meantime to folks who want to deploy IPv6 now? What if we make some revision to "draft-ietf-ipv6-cellular-host", and run that as Informational? Then we could have IPv6 Host Requirements later on the standards track. We could even have a later IPv6-over-3GPP standards track document which would obsolete the Informational document, if desirable. Or, would that be IPv6-over-3.75G? > If there are decisions as to what to do with ND/DAD/whatever, > should those be made by (a) IPv6 WG, (b) 3GPP, or (c) > vendors? Each of these groups will make decisions. However, I think that the IPv6 working group should have the responsibility to determine protocol behavior for a general IPv6 node. Clearly, in general, an IPv6 node has to be able to run these protocols. But there are times when the node should be allowed to attach to a link without using them. As an example, in the Mobile IPv6 working group, we have a document that enables a mobile node to attach to a new link without running DAD. This is done only after assurance is received, that no other node at the new point of attachment could possibly have a conflicting address with the mobile node. A more general statement could be something like: "An IPv6 node MUST run DAD unless it already has assurance that there is no possible address conflict." with some more wordsmithing. One way to satisfy this would be to have DAD run by some proxy agent -- again, the Mobile IPv6 home agent has this responsibility at times. Also, note that in this case the mobile node is still presumed to be able to run DAD, it just does not have always do DAD. If all this has been said before, please just chalk it up to my inability to keep up with enough mail lately. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 10:38:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25IcVKL029450 for ; Tue, 5 Mar 2002 10:38:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25IcVn9029449 for ipng-dist; Tue, 5 Mar 2002 10:38:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25IcRKL029439 for ; Tue, 5 Mar 2002 10:38:27 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29264 for ; Tue, 5 Mar 2002 10:38:26 -0800 (PST) Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02228 for ; Tue, 5 Mar 2002 10:38:24 -0800 (PST) Received: from lorien.sc.innovationslab.net ([24.162.252.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 5 Mar 2002 12:56:46 -0500 Message-ID: <3C8506EC.2CB7FFD5@lorien.sc.innovationslab.net> Date: Tue, 05 Mar 2002 12:57:00 -0500 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: john.loughney@nokia.com CC: mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B18@esebe004.NOE.Nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, I don't think there is problem with the content. I believe the content needs to be separated. One part to discuss IPv6 operation over cellular links and one part to discuss the minimal IPv6 functionality for hosts. The second part really belongs in a general host requirements document. Brian john.loughney@nokia.com wrote: > > Brian, > > > I don't think we should. It just starts us down that slippery slope > > of creating new "foo hosts" requirements docs. Your following > > arguments are reason enough to avoid this path. > > Is your complaint that the document is Minimum IPv6 Requirements for > a Cellular Hosts? Are there problems with the content? Do you > agree or disagree with the intent of the document, which is to > provide guidence on what to implement on a cellular host & > what the applicability of those features are? > > John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 10:42:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25IgZKL029491 for ; Tue, 5 Mar 2002 10:42:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25IgZEK029490 for ipng-dist; Tue, 5 Mar 2002 10:42:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25IgWKL029480 for ; Tue, 5 Mar 2002 10:42:32 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28250 for ; Tue, 5 Mar 2002 10:42:31 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04028 for ; Tue, 5 Mar 2002 10:42:30 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA05059; Tue, 5 Mar 2002 10:42:28 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g25IgRN05351; Tue, 5 Mar 2002 10:42:27 -0800 X-mProtect:  Tue, 5 Mar 2002 10:42:27 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdP5kpzB; Tue, 05 Mar 2002 10:42:25 PST Message-ID: <3C851192.E3CC57B4@iprg.nokia.com> Date: Tue, 05 Mar 2002 10:42:26 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman CC: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Making ND Optional [Was RE:draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] References: <4.2.2.20020305100050.00e4c840@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, Disclaimer: I am not fully caught up on this discussion. I hope that cellular hosts would be able to run DAD and ND whenever they need to. I would hope that the IETF would not approve a document that says "some" IPv6 hosts MUST NOT (or even SHOULD NOT!) implement DAD/ND. This would be a problem, if for instance some operators would then use it to DISALLOW IPv6 addressable devices from running those protocols. They could claim non-conformance to RFC nnnn! I reckon that it would be better to determine certain conditions under which an IPv6 node would experience better performance by not running those protocols, but still to expect the protocols to be part of the IPv6 node implementation. My own interest lies in having the ability for some 3G device to serve as a router for personal devices that I may carry with me. I'd also like for those devices to be autoconfigurable, and to find the 3G router by using standard techniques. All of this could be done so that my devices would share the same prefix as my 3G router device. Why not? Again, please excuse if this is all duplication of previous discussion. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 10:46:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25IkQKL029520 for ; Tue, 5 Mar 2002 10:46:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25IkQQH029519 for ipng-dist; Tue, 5 Mar 2002 10:46:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25IkNKL029512 for ; Tue, 5 Mar 2002 10:46:23 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00078 for ; Tue, 5 Mar 2002 10:46:22 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06511 for ; Tue, 5 Mar 2002 10:46:18 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 05 Mar 2002 10:46:17 -0800 From: "Tony Hain" To: , , Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Tue, 5 Mar 2002 10:46:17 -0800 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B14@esebe004.NOE.Nokia.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com wrote: > Hi Margaret, > > > Before folks go and do a lot of additional work to update > > draft-ietf-ipv6-cellular-host-00.txt based on our discussions, > > I think we have to answer a fundamental question: > > I am having a hard time understanding what your objections > to the document are. You have raised some good technical > points & we are looking at how to address them & revise > the document. However, you seem to be saying now that the > technical issues are not important. No, she is simply setting the stage for the following questions that will try to refocus those technical comments into documents where they make more sense in the framework of other IETF documents. > > > Should the WG publish an informational RFC detailing the IPv6 > > requirements for cellular hosts? > > Is the issue the title of the document. If the draft were > titled 'Applicability of IPv6 for Cellular Hosts' - > would that make a difference? Please don't take this as a personal attack, but you just don't get it. Approaching the definition of a set of protocol standards from the limitations of a device perspective is simply wrong. There is nothing about the device that makes it 'special'. Yes it may be less capable than other devices available today, but that is not the point. The document about cellular characteristics you write today will apply to devices built over the next 5 or 10 years, so the focus has to be on the specific characteristics of the air-link and why that is different from other link types. This will also avoid the host vs. router/bridge issues since the link characteristics don't change based on what the device decides to do with the packet. > > > If so, how can we prevent the two most likely bad outcomes: > > > > - 3GPP (or other) folks thinking that this document > > is an IETF standard? [May be handled by > > a strongly worded disclaimer in the document?] > > If the draft can go through the process of becoming an > RFC, with work group consensus, etc. what is the problem? > > > - Everyone with an agenda attempting to publish a > > similar document for their "special" > > category of IPv6 host? [Can we just say 'no'?] > > Of course, I do think that you are being very unfair in > this statement. Most of the authors are IETF participants, > not 3GPP participants. We have no 'agenda' - or at > least no more than your average IETF participant. This > is not 3GPP trying to push anything in the IETF. Also, > I really don't think that involving a more diverse set > of participants in the IETF is a bad thing. I think > we ought to encourage more direct participation in the > IETF rather than less. Do you feel it is a problem if > folks from the FOO SDO starting participating in the IETF, > and functioning under IETF rules? I really could not > find a problem with that. I seriously doubt Margaret was attacking anyone here, just asking the basic question about how we distinguish between valid reasons for special-cases. More below: > > > I also think that we should start work on two standards-track > > documents, both of which would use the current draft as > > input: > > > > - An "IPv6 over " document for 3GPP links. > > - A general "IPv6 Node Requirements" document. > > My suggestion would be that we work on these documents: > > - The current document > - General IPv6 host Requirements > - General IPv6 node requirements (mixture of routing + > host functions). > > I think that we may want to consider making the current document more > of an applicability statement or something along those lines. The basic problems with keeping the current document is that at its core it is fundamentally, and too narrowly, focused on the 3G micro handset, then looks for exceptions completely out of context from what other hosts will do. This disconnection appears to be making it difficult for the authors to see why people are so unhappy about their desire to leave out basic requirements which are expected of other nodes. Again this is not a personal attack, but even you are disconnected in your expectations when you answer me with: > what is the difference between a handset and a laptop that has > an embedded 3G radio? Are they both cellular hosts? Yes they are. then answer Erik with: > BTW: Does 1) include the ability to run e.g. Java applets or > other downloadable code? I think we would clasify it as closed, no applets or downloadable code. Think about it...how can we be defining 'Minimum IPv6 Functionality of a Cellular Host' when a laptop qualifies, but the definition includes a limitation that a cellular host may be closed? How does any given node figure out what capabilities the other end has? Don't we end up with everyone assuming lowest-common-denominator, and if so have we crippled or fatally wounded the IPv6 network? For those that *really* want to be working on a host requirements doc, that is fine, but it has to be a much more comprehensive document so the whole community (including the current document authors) can appreciate the context of the trade-offs. This is particularly true for the case where hosts have multiple types of links, and may be expected to act differently based on those link types. At the same time there are some characteristics of the air-link (like: not all nodes on the link can hear each other) that make it appropriate to have an IPv6-over-foo discussing those details. If we don't approach it that way we end up with a series of 'special case' documents which are more likely to prevent interoperation than to create it. Tony BTW: I am still not convinced that either a 3G or PPP link can avoid DAD, but I am willing to listen. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 11:07:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25J7gKL029621 for ; Tue, 5 Mar 2002 11:07:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25J7gYt029620 for ipng-dist; Tue, 5 Mar 2002 11:07:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25J7eKL029613 for ; Tue, 5 Mar 2002 11:07:40 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g25J6uuX014189 for ; Tue, 5 Mar 2002 11:06:56 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g25J6u8c014188 for ipng@sunroof.eng.sun.com; Tue, 5 Mar 2002 11:06:56 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g21IEUKL017231 for ; Fri, 1 Mar 2002 10:14:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA19397 for ; Fri, 1 Mar 2002 10:14:31 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA29791 for ; Fri, 1 Mar 2002 11:14:30 -0700 (MST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Mar 2002 18:57:57 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D8201EAEFCF@lat3721.rd.francetelecom.fr> From: BELOEIL Luc FTRD/DMI/CAE To: "'Nathan Lutchansky'" Cc: ipng@sunroof.eng.sun.com Subject: Prefix Delegation Option in RA - draft comments Date: Fri, 1 Mar 2002 18:57:58 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-87c1632e-2d1d-11d6-ac1f-00508b692753" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-87c1632e-2d1d-11d6-ac1f-00508b692753 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C14A.9F17C3C0" ------_=_NextPart_001_01C1C14A.9F17C3C0 Content-Type: text/plain Hi, I have just read your draft that proposes to add a new Prefix Delegation Option to Router Advertisement so as to enable configuration of a site router (I'm using you definition of a site router). Here's my comments : 3.1 Deployement scenario I found you figure unclear. First, I thought that your router had only 2 Site Links, then I understood. It would be clearer to precise "Site link #1 ... Site Link#n". 3.3 Site router operation Firstly, one should precise that the site router must route site packets towards a default route that is the PPP link. Secondly, you tell that the site router send a Router Solicitation. But I think that router solicitation should contain a Prefix Delegation Request Option (to be defined). Indeed, the site router could have already a global prefix, and in that case the provider router should not allocate any prefix but only route site packets. 3.3.1 Prefix Delegation option processing Has David Binet asked on mailing list, you give no proposal on the way to manage IPv6 prefix pool on the provider router. Do you have any idea ? Do we must use manual configuration . Do you think that is only an implementer and operator issue ? Your solution seems great because it is simple. But I am wondering if its applicability is to limited or not ? It is just for dialup link and the most unconfortable issue is that its impose only 1 router in the site. The solution is really not scalable on the site side. Luc ------_=_NextPart_001_01C1C14A.9F17C3C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Prefix Delegation Option in RA - draft comments

Hi,

I have just read your draft that proposes to add a = new Prefix Delegation Option to Router Advertisement so as to enable = configuration of a site router (I'm using you definition of a site = router).

Here's my comments :
3.1 Deployement scenario
I found you figure unclear. First, I thought that = your router had only 2 Site Links, then I understood. It would be = clearer to precise "Site link #1 ... Site Link#n".

3.3 Site router operation
Firstly, one should precise that the site router = must route site packets towards a default route that is the PPP = link.
Secondly, you tell that the site router send a = Router Solicitation. But I think that router solicitation should = contain a Prefix Delegation Request Option (to be defined). Indeed, the = site router could have already a global prefix, and in that case the = provider router should not allocate any prefix but only route site = packets.

3.3.1 Prefix Delegation option processing
Has David Binet asked on mailing list, you give no = proposal on the way to manage IPv6 prefix pool on the provider router. = Do you have any idea ? Do we must use manual configuration . Do you = think that is only an implementer and operator issue ?


Your solution seems great because it is simple. But I = am wondering if its applicability is to limited or not ? It is just for = dialup link and the most unconfortable issue is that its impose only 1 = router in the site. The solution is really not scalable on the site = side.

Luc

------_=_NextPart_001_01C1C14A.9F17C3C0-- ------=_NextPartTM-000-87c1632e-2d1d-11d6-ac1f-00508b692753-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 11:12:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25JCfKL029731 for ; Tue, 5 Mar 2002 11:12:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25JCfhf029730 for ipng-dist; Tue, 5 Mar 2002 11:12:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25JCcKL029723 for ; Tue, 5 Mar 2002 11:12:38 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA11671 for ; Tue, 5 Mar 2002 11:12:37 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19127 for ; Tue, 5 Mar 2002 12:12:36 -0700 (MST) Received: from mira-sjc5-7.cisco.com (mira-sjc5-7.cisco.com [171.71.163.27]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g25JCST12318; Tue, 5 Mar 2002 11:12:28 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-7.cisco.com (Mirapoint) with ESMTP id AAZ99024; Tue, 5 Mar 2002 11:12:00 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA04242; Tue, 5 Mar 2002 11:12:26 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15493.6298.348854.619921@thomasm-u1.cisco.com> Date: Tue, 5 Mar 2002 11:12:26 -0800 (PST) To: Cc: , , , , , , Subject: RE: Should IP Security be Optional? In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AE4@esebe004.NOE.Nokia.com> References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AE4@esebe004.NOE.Nokia.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com writes: > Just to add onto Jari - it would be a no-brainer to > state that IPsec (AH & ESP) MUST be supported, > IKE MAY/SHOULD be supported. However, does this > give users anything? Will it increase security for > these devices, or is it just something that will make > folks happy? The authors prefer to have a reasonable > discussion on security within the draft. Knowledge of > the field of Internet Security has increased since > some of the initial IPv6 documents were published ... It categorically depends on what you're trying to do. Frankly, this entire line of discourse seems a little bizarre to me. What is the point of a set of must implement protocols where on the one hand it's intended for fixed function device without easy upgradability, etc, and on the other hand wanting to insure some amount of future proofing. Future proofing for *what*? Maybe I have this all wrong, but it seems that what's going on here is an architecture that's not an architecture. It makes my head hurt. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 11:12:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25JCjKL029745 for ; Tue, 5 Mar 2002 11:12:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25JCj4p029743 for ipng-dist; Tue, 5 Mar 2002 11:12:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25JChKL029735 for ; Tue, 5 Mar 2002 11:12:43 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g25JBwuX014204 for ; Tue, 5 Mar 2002 11:11:58 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g25JBwA3014203 for ipng@sunroof.eng.sun.com; Tue, 5 Mar 2002 11:11:58 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1S9YdKL012865 for ; Thu, 28 Feb 2002 01:34:39 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA16048 for ; Thu, 28 Feb 2002 01:34:40 -0800 (PST) Received: from hotmail.com (oe53.law14.hotmail.com [64.4.20.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA19693 for ; Thu, 28 Feb 2002 02:34:40 -0700 (MST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 28 Feb 2002 01:34:39 -0800 X-Originating-IP: [203.200.20.226] From: "Vinayak Prabhu" To: Subject: Multiple link local addresses Date: Thu, 28 Feb 2002 15:03:34 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01C1C069.17C610C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 Disposition-Notification-To: "Vinayak Prabhu" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: X-OriginalArrivalTime: 28 Feb 2002 09:34:39.0571 (UTC) FILETIME=[24C70230:01C1C03B] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0031_01C1C069.17C610C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Can a node have multiple link local addresses? Regards, Vinu ------=_NextPart_000_0031_01C1C069.17C610C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
Can a node have multiple link local=20 addresses?
 
Regards,
Vinu
------=_NextPart_000_0031_01C1C069.17C610C0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 11:12:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25JCnKL029754 for ; Tue, 5 Mar 2002 11:12:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25JCnr4029753 for ipng-dist; Tue, 5 Mar 2002 11:12:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25JCjKL029744 for ; Tue, 5 Mar 2002 11:12:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29051 for ; Tue, 5 Mar 2002 11:12:44 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA18484 for ; Tue, 5 Mar 2002 11:12:44 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 05 Mar 2002 11:12:43 -0800 From: "Tony Hain" To: "Karim El-Malki \(ERA\)" , "'Margaret Wasserman'" , Cc: Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Tue, 5 Mar 2002 11:12:43 -0800 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <795A014AF92DD21182AF0008C7A404320DFBEFD7@esealnt117> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Karim El-Malki wrote: > This special router is called a GGSN and it knows it MUST NOT > configure > itself with a unicast address on that prefix. That means there's no > conflict. Does that make sense? I will grant you that I don't know (or want to know) the inner workings of a GGSN, but what is the point of a link with only one node? Where does an origin send data if there is no other device to receive it? If there is another device (assuming for a moment that the GGSN is the second device), how does the origin find it unless that device uses an address in the range the origin considers to be in this prefix? If that second device uses an on-link address, how do the nodes at either end know that there will never be a conflict (easy with out-of-band coordination)? If either end generates RFC-3041 addresses, how does that node ensure that the other end hasn't already used that bit pattern (easy if only one end generates, and the other only uses EUI-64s with bit 6 set)? If a GGSN really MUST NOT configure itself into a prefix that is allocated to a client device, what is the point of a GGSN? Does that make sense? Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 11:15:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25JFiKL029791 for ; Tue, 5 Mar 2002 11:15:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25JFi6D029790 for ipng-dist; Tue, 5 Mar 2002 11:15:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25JFgKL029783 for ; Tue, 5 Mar 2002 11:15:42 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g25JEvuX014221 for ; Tue, 5 Mar 2002 11:14:57 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g25JEvMI014220 for ipng@sunroof.eng.sun.com; Tue, 5 Mar 2002 11:14:57 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g251WaKL025672 for ; Mon, 4 Mar 2002 17:32:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09155 for ; Mon, 4 Mar 2002 17:32:38 -0800 (PST) From: Jonne.Soininen@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04538 for ; Mon, 4 Mar 2002 17:32:37 -0800 (PST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g251Yjx23764 for ; Mon, 4 Mar 2002 19:34:45 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Mar 2002 19:32:36 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 4 Mar 2002 19:31:20 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Mon, 4 Mar 2002 17:31:19 -0800 Message-ID: <4D7B558499107545BB45044C63822DDEB2D8A9@mvebe001.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHD5XNpMDfdYqToQXC6pGLqiMQ3Qg== To: Cc: X-OriginalArrivalTime: 05 Mar 2002 01:31:20.0391 (UTC) FILETIME=[73FC0D70:01C1C3E5] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g251WaKL025673 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> [Please note that I actually think that we should be able to >> disable DAD for some link types. I made a proposal to that effect >> several years ago, but my arguments didn't win the day.] >Yes. >RFC-2462, "5.1. Node Configuration Variables": > DupAddrDetectTransmits = 0 > => DAD is disabled on link >So, no DAD is "conformant" too. This is actually what PPPv6 (RFC2472)suggests: "As long as the Interface Identifier is negotiated in the IPV6CP phase of the PPP connection setup, it is redundant to perform duplicate address detection as a part of the IPv6 Stateless Autoconfiguration protocol [3]. Therefore it is recommended that for PPP links with the IPV6CP Interface-Identifier option enabled the default value of the DupAddrDetectTransmits autoconfiguration variable [3] be zero." Cheers, Jonne. -------- Jonne Soininen Nokia Tel. +1 650 864 6794 Cellular: +1 650 714 7733 Email: jonne.soininen@nokia.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 11:16:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25JG9KL029811 for ; Tue, 5 Mar 2002 11:16:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25JG9uL029810 for ipng-dist; Tue, 5 Mar 2002 11:16:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25JG7KL029803 for ; Tue, 5 Mar 2002 11:16:07 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g25JFNuX014229 for ; Tue, 5 Mar 2002 11:15:23 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g25JFM7s014228 for ipng@sunroof.eng.sun.com; Tue, 5 Mar 2002 11:15:22 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g251eCKL025685 for ; Mon, 4 Mar 2002 17:40:13 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA04402 for ; Mon, 4 Mar 2002 17:40:13 -0800 (PST) From: Jonne.Soininen@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28894 for ; Mon, 4 Mar 2002 17:40:12 -0800 (PST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g251gJx23982 for ; Mon, 4 Mar 2002 19:42:19 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 4 Mar 2002 19:40:11 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 4 Mar 2002 19:40:00 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Re: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] Date: Mon, 4 Mar 2002 17:39:59 -0800 Message-ID: <4D7B558499107545BB45044C63822DDEB2D8AA@mvebe001.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] Thread-Index: AcHD5ql1TC+ykYsiTgOx31ojIY58Yw== To: Cc: X-OriginalArrivalTime: 05 Mar 2002 01:40:00.0695 (UTC) FILETIME=[AA1C2470:01C1C3E6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g251eDKL025686 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > This seems to presume that you can predict in advance all of the > > > applications that a user will wish to execute on a particular node. Can you > > > do that? > > > > On a workstation you can't. On a tiny cellular device you > > often can. > only if the device doesn't have a data port. Actually then (especially in 3GPP devices) the IP stack will actually also be behind that dataport, i.e. in the laptop. That is then a different story. -Jonne. -------- Jonne Soininen Nokia Tel. +1 650 864 6794 Cellular: +1 650 714 7733 Email: jonne.soininen@nokia.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 11:36:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25JasKL000369 for ; Tue, 5 Mar 2002 11:36:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25JarNu000368 for ipng-dist; Tue, 5 Mar 2002 11:36:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25JaoKL000360 for ; Tue, 5 Mar 2002 11:36:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24586 for ; Tue, 5 Mar 2002 11:36:45 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00227 for ; Tue, 5 Mar 2002 11:36:44 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 29EB36A901; Tue, 5 Mar 2002 21:36:43 +0200 (EET) Message-ID: <3C851E9B.1060103@kolumbus.fi> Date: Tue, 05 Mar 2002 21:38:03 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Michael Thomas Cc: john.loughney@nokia.com, nov@tahi.org, Jari.Arkko@lmf.ericsson.se, Francis.Dupont@enst-bretagne.fr, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? References: <0C1353ABB1DEB74DB067ADFF749C4EEFC64AE4@esebe004.NOE.Nokia.com> <15493.6298.348854.619921@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michael Thomas wrote: > john.loughney@nokia.com writes: > > Just to add onto Jari - it would be a no-brainer to > > state that IPsec (AH & ESP) MUST be supported, > > IKE MAY/SHOULD be supported. However, does this > > give users anything? Will it increase security for > > these devices, or is it just something that will make > > folks happy? The authors prefer to have a reasonable > > discussion on security within the draft. Knowledge of > > the field of Internet Security has increased since > > some of the initial IPv6 documents were published ... > > It categorically depends on what you're trying to > do. Frankly, this entire line of discourse seems a > little bizarre to me. What is the point of a set of > must implement protocols where on the one hand it's > intended for fixed function device without easy > upgradability, etc, and on the other hand wanting > to insure some amount of future proofing. Future > proofing for *what*? Future proofing of the *environment*. Your grandmother's old and bulky IPv6 host still needs to work with your new and shiny IPv6 host, doesn't it? Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 11:56:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25JuAKL000468 for ; Tue, 5 Mar 2002 11:56:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25JuAZV000467 for ipng-dist; Tue, 5 Mar 2002 11:56:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25Ju6KL000460 for ; Tue, 5 Mar 2002 11:56:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14019 for ; Tue, 5 Mar 2002 11:56:06 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA08504 for ; Tue, 5 Mar 2002 11:56:05 -0800 (PST) Received: from kenawang (d_73nuj.wrs.com [147.11.46.202] (may be forged)) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id LAA08686; Tue, 5 Mar 2002 11:55:30 -0800 (PST) Message-Id: <4.2.2.20020305124933.020f9a70@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 05 Mar 2002 14:56:39 -0500 To: john.loughney@nokia.com From: Margaret Wasserman Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Cc: In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B14@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John, >I am having a hard time understanding what your objections >to the document are. You have raised some good technical >points & we are looking at how to address them & revise >the document. However, you seem to be saying now that the >technical issues are not important. I don't believe that the technical issues that you have raised are unimportant. I think that they are very important -- important enough that they should be addressed in standards-track documents. But, I don't think that this document is in quite the right form to move on to the standards track as written, and I don't think that it makes sense to publish it as an informational document. Your document and your arguments have convinced me that we should publish a standard definition of the minimal requirements for an IPv6 node, an "IPv6 Node Requirements" document (or perhaps two documents, one for hosts and one for routers?). This should be a standards-track document, not an informational one, and I think that your document would serve as an excellent starting point for this work. It is important that the minimal host requirements of IPv6 be applicable to low-end systems, such as cell phones, and that should be reflected in our general IPv6 node requirements effort. However, I don't think that we want to have a fragmented set of informational host requirements documents with different requirements for different IPv6 application spaces (cellular hosts vs network appliances vs. home gateways vs. car infotainment equipment, etc.). If I'm missing some reason why cellular hosts are special, that explains why they would need an informational requirements document (when other applications would not), please explain. Most of the things that make the hosts you've discussed unique are related to the fact that they run over a specific link type. In my opinion, these differences, and the behaviour that is required because of them, should be captured in a link-specific standards-track "IPv6 over " document, such as "IPv6 over 3GPP PDP Contexts". This document could be based on portions of your current document. Of course, I don't personally get to decide what the IPv6 WG publishes. I'm just voicing my opinion... > > If so, how can we prevent the two most likely bad outcomes: > > > > - 3GPP (or other) folks thinking that this document > > is an IETF standard? [May be handled by > > a strongly worded disclaimer in the document?] > >If the draft can go through the process of becoming an >RFC, with work group consensus, etc. what is the problem? Well, this is the process of trying to find that consensus. Consensus on publishing an RFC doesn't just mean that no one can find any technical problems with the contents. It also means getting the consensus of the WG and the IESG that a document is needed in this area, and that publishing that document would be useful. I have voiced technical issues with the document AND reasons why I thnk the WG may not want to publish this specific document as an Informational RFC, even if the technical issues were addressed. > > - Everyone with an agenda attempting to publish a > > similar document for their "special" > > category of IPv6 host? [Can we just say 'no'?] > >Of course, I do think that you are being very unfair in >this statement. Most of the authors are IETF participants, >not 3GPP participants. We have no 'agenda' - or at >least no more than your average IETF participant. I can see how you interpreted my comments this way, but this isn't what I meant... I don't think that the authors of this draft have an "agenda" (in the negative connotation sense) that runs contrary to the interests of the IETF, IPv6 or any related work. I meant "agenda" more in the sense of "focus" or "area of interest". There are a lot of people involved in the IETF (myself included) who have a strong interest in making sure that IPv6 is applicable for certain types of uses. This is a positive thing, because we often have a lot of technical knowledge about those environments, and we can add to the quality and wide applicability of IPv6 by reviewing documents and representing our differing perspectives. However, I don't think that the WG should publish a number of different informational RFCs, representing all of these different positions regarding what the minimal contents of IPv6 should be for each type of application. Instead, we should bring all of our knowledge and skills together to write a single standards- based "IPv6 Node Requirements" document that defines what the minimal requirements are for all IPv6 nodes. >This >is not 3GPP trying to push anything in the IETF. Also, >I really don't think that involving a more diverse set >of participants in the IETF is a bad thing. I think >we ought to encourage more direct participation in the >IETF rather than less. Do you feel it is a problem if >folks from the FOO SDO starting participating in the IETF, >and functioning under IETF rules? I really could not >find a problem with that. No, I have no problem with that at all! In fact, I'd like to see even more of it. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 12:21:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25KLqKL000602 for ; Tue, 5 Mar 2002 12:21:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25KLq8b000601 for ipng-dist; Tue, 5 Mar 2002 12:21:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25KLnKL000594 for ; Tue, 5 Mar 2002 12:21:49 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06620 for ; Tue, 5 Mar 2002 12:21:49 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20647 for ; Tue, 5 Mar 2002 12:21:49 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 05 Mar 2002 12:21:48 -0800 From: "Tony Hain" To: "Vinayak Prabhu" , Subject: RE: Multiple link local addresses Date: Tue, 5 Mar 2002 12:21:48 -0800 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vinayak Prabhu wrote: > Can a node have multiple link local addresses? There is nothing to prevent a node from having multiple link local addresses, but what would be the value? The only thing it would appear to do is consume resources on the node that has multiple addresses, and require all other nodes to decide which address to use when talking to it. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 12:26:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25KQ1KL000619 for ; Tue, 5 Mar 2002 12:26:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25KQ1Fi000618 for ipng-dist; Tue, 5 Mar 2002 12:26:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25KPwKL000611 for ; Tue, 5 Mar 2002 12:25:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA10257 for ; Tue, 5 Mar 2002 12:25:58 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA22159 for ; Tue, 5 Mar 2002 12:25:58 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 05 Mar 2002 12:25:57 -0800 From: "Tony Hain" To: "Kunapareddy R B" , Subject: RE: Neighbor Discovery Clarification Date: Tue, 5 Mar 2002 12:25:57 -0800 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20020305073759.6720.qmail@mailweb17.rediffmail.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kunapareddy R B wrote: > Hi all, > > I am new to this group. I might be asking simple questions. Can > u > clarify the following. > > *. Router Can be configured automatically as part of > Autoconfiguration. > > *. How can One ensure the autoconfiguration address must be > Global Address or > Site Local Address or > Link Local Address You are asking implementation specific questions, so the more appropriate forum might be with your vendors. In general, if a non-router is auto-configuring, it will create which ever address scope its configuration policy says to, but link-local must be part of the set. Routers may or may-not auto-configure, so you need to take that up with your vendor. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 13:34:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25LYfKL000856 for ; Tue, 5 Mar 2002 13:34:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25LYfen000855 for ipng-dist; Tue, 5 Mar 2002 13:34:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25LYbKL000848 for ; Tue, 5 Mar 2002 13:34:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA04857 for ; Tue, 5 Mar 2002 13:34:37 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA21034 for ; Tue, 5 Mar 2002 14:34:03 -0700 (MST) Received: from kenawang (d_73nuj.wrs.com [147.11.46.202] (may be forged)) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA15744; Tue, 5 Mar 2002 13:31:20 -0800 (PST) Message-Id: <4.2.2.20020305160820.0210a600@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 05 Mar 2002 16:31:46 -0500 To: "Jari Arkko" From: Margaret Wasserman Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? Cc: In-Reply-To: <012b01c1c470$207f9d20$8a1b6e0a@arenanet.fi> References: <4.2.2.20020305103309.00e4c6c0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jari, >I think most of >us agree that a host requirements document is >something that we should have and is a necessary >one. If we had a general document I'm pretty sure >there'd be no need for any specific XXX host >requirements documents. I hope that we do have agreement about this. Are there others who disagree? >Now, my concern is this: >how long do you think producing the general document >to an RFC will take? What should we say in the >meantime to folks who want to deploy IPv6 now? >If there are decisions as to what to do with ND/DAD/whatever, >should those be made by (a) IPv6 WG, (b) 3GPP, or (c) >vendors? This is a very good question... One answer is that I think that we could produce an "IPv6 over 3GPP PDP Contexts" document fairly quickly. This document could address several of the issues raised in your document. It _will_ take a while for the IPv6 WG to reach consensus on the minimal requirements for an IPv6 node. IMHO, reaching real consensus on these requirements will take a similar amount of time, whether we do it as part of a standards-based "node requirements" effort, or whether we do it for an informational "cellular host requirements" document. I don't believe that limiting the discussion to "cellular hosts" will substantially reduce the amount of effort, as cellular hosts span the spectrum from low-end cell phones to high-end laptops. I do not support publishing an informational document quickly that does not actually represent the consensus of the IPv6 WG regarding what the minimal requirements for an IPv6 host actually are... I think that such a document could do more harm than good. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 13:53:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25Lr4KL000892 for ; Tue, 5 Mar 2002 13:53:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25Lr4dg000891 for ipng-dist; Tue, 5 Mar 2002 13:53:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25LqxKL000884 for ; Tue, 5 Mar 2002 13:52:59 -0800 (PST) Received: from lillen (vpn-129-159-0-86.EMEA.Sun.COM [129.159.0.86]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g25Lqpx10722; Tue, 5 Mar 2002 22:52:51 +0100 (MET) Date: Tue, 5 Mar 2002 22:47:50 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] To: "Karim El-Malki (ERA)" Cc: "'Keith Moore'" , john.loughney@nokia.com, Jonne.Soininen@nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <795A014AF92DD21182AF0008C7A404320DFBEFD0@esealnt117> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > No. The terminal (phone) doesn't need to act as a router to allow > for multiple devices behind it to connect to the cellular interface. > You could eventually have multiple serial connections to the terminal > each having its own corresponding air interface connection. So it can > act as a host (if you're running the IP stack + app on it) or as > an L2 device (modem) for e.g. laptops behind it. That doesn't mean > that there's no advantages in making it a router but it's not > mandatory. Given that implementers need guidelines now, it's good if we > only limit the scope to hosts for the moment and go onto routers once > the first is complete. Karim, In the case of the terminal being an L2 device like a modem and the IP device being a laptop there might be some care. For instance, the laptop IPv6 stack might follow the specifications and use NUD over that PPP link. This requires that the 3G devices in the network actually support NUD over the PPP link. While the draft claims it scope is about the cellular hosts I wouldn't be surprised if some folks read the MAY and conclude that they don't need to implement it at the first hop IPv6 router. So I wonder if it makes sense to make this more clear in an IPv6-over-3G document which would say hosts MAY implement sending of NUD messages routers MAY implement sending of NUD messages routers MUST implement processing NUD messages (unicast NS messages) hosts ??? implement processing NUD messages Such careful statements would make sense that things would always interoperate. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 14:14:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25MEMKL000914 for ; Tue, 5 Mar 2002 14:14:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25MEMh2000913 for ipng-dist; Tue, 5 Mar 2002 14:14:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25MEGKL000906 for ; Tue, 5 Mar 2002 14:14:17 -0800 (PST) Received: from lillen (vpn-129-159-0-86.EMEA.Sun.COM [129.159.0.86]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g25ME2x11775; Tue, 5 Mar 2002 23:14:03 +0100 (MET) Date: Tue, 5 Mar 2002 23:09:02 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? To: Jari Arkko Cc: ipng@sunroof.eng.sun.com, Margaret Wasserman In-Reply-To: "Your message with ID" <012b01c1c470$207f9d20$8a1b6e0a@arenanet.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > If there are decisions as to what to do with ND/DAD/whatever, > should those be made by (a) IPv6 WG, (b) 3GPP, or (c) > vendors? Jari, I think the ND/DAD type issues can be dealt with by the IPv6 over foo document which should be a lot quicker to produce than the host requirements document. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 14:15:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25MFtKL000931 for ; Tue, 5 Mar 2002 14:15:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25MFsSg000930 for ipng-dist; Tue, 5 Mar 2002 14:15:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25MFnKL000923 for ; Tue, 5 Mar 2002 14:15:50 -0800 (PST) Received: from lillen (vpn-129-159-0-86.EMEA.Sun.COM [129.159.0.86]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g25MFix11862; Tue, 5 Mar 2002 23:15:44 +0100 (MET) Date: Tue, 5 Mar 2002 23:10:44 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] To: "Karim El-Malki (ERA)" Cc: "'Tony Hain'" , "'Margaret Wasserman'" , john.loughney@nokia.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <795A014AF92DD21182AF0008C7A404320DFBEFD7@esealnt117> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > This special router is called a GGSN and it knows it MUST NOT configure > itself with a unicast address on that prefix. That means there's no > conflict. Does that make sense? What about a link-local address? Those are required on all interfaces. And the RAs sent by the GGSN must have a link-local source. Is the assumption that the link-local address of the router will never conflict with the link-local address that the host picks e.g. by relying on PPP to negotiate the interface ID? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 14:17:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25MHlKL000951 for ; Tue, 5 Mar 2002 14:17:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25MHl0I000950 for ipng-dist; Tue, 5 Mar 2002 14:17:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25MHfKL000940 for ; Tue, 5 Mar 2002 14:17:42 -0800 (PST) Received: from lillen (vpn-129-159-0-86.EMEA.Sun.COM [129.159.0.86]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g25MHax11925; Tue, 5 Mar 2002 23:17:37 +0100 (MET) Date: Tue, 5 Mar 2002 23:12:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <4.2.2.20020305103309.00e4c6c0@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I also think that we should start work on two standards-track > documents, both of which would use the current draft as > input: > > - An "IPv6 over " document for 3GPP links. > - A general "IPv6 Node Requirements" document. I think the above two documents make a lot of sense. I wonder if there is utility in having a third document; an informational and non-prescriptive document (i.e. no MUST, SHOULD, MAY language) which is more like a document roadmap plus issues for hosts of category X (where X is a rather narrowly defined subset of the 3g/cellular host). For instance, listing the set of documents that implementors need to take into account seems quite useful. Also, discussing tradeoffs of what optional things to implement also sounds useful. And talking about how things fit together i.e. the relationship between IPsec/IKE vs. TLS also sounds like useful information to implementors. But "discussing issues" and not having any normative MUST, SHOULD, MAY language. Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 15:39:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25NdQKL001043 for ; Tue, 5 Mar 2002 15:39:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g25NdQJw001042 for ipng-dist; Tue, 5 Mar 2002 15:39:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g25NdMKL001035 for ; Tue, 5 Mar 2002 15:39:22 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18143 for ; Tue, 5 Mar 2002 15:39:22 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA29543 for ; Tue, 5 Mar 2002 16:39:21 -0700 (MST) Received: from kenawang (d_73nuj.wrs.com [147.11.46.202] (may be forged)) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA20648; Tue, 5 Mar 2002 15:38:58 -0800 (PST) Message-Id: <4.2.2.20020305183740.00c55f00@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 05 Mar 2002 18:39:35 -0500 To: "Jari Arkko" From: Margaret Wasserman Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? Cc: In-Reply-To: <012b01c1c470$207f9d20$8a1b6e0a@arenanet.fi> References: <4.2.2.20020305103309.00e4c6c0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Now, my concern is this: >how long do you think producing the general document >to an RFC will take? What should we say in the >meantime to folks who want to deploy IPv6 now? >If there are decisions as to what to do with ND/DAD/whatever, >should those be made by (a) IPv6 WG, (b) 3GPP, or (c) >vendors? This is a valid concern... Many of the issues that are raised in your document could be handled in an "IPv6 over 3GPP PDP Contexts" document. I think that we should be able to produce that document fairly quickly, probably quicker than we will reach consensus on any requirements document, even your informational one. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 16:04:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2603xKL001129 for ; Tue, 5 Mar 2002 16:03:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2603xpO001128 for ipng-dist; Tue, 5 Mar 2002 16:03:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2603uKL001121 for ; Tue, 5 Mar 2002 16:03:56 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26050 for ; Tue, 5 Mar 2002 16:03:56 -0800 (PST) Received: from msgbas1.sgp.agilent.com (msgbas1x.net.asiapac.agilent.com [192.25.42.26]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14218 for ; Tue, 5 Mar 2002 16:03:55 -0800 (PST) Received: from msgrel1.sgp.agilent.com (msgrel1.sgp.agilent.com [141.183.101.233]) by msgbas1.sgp.agilent.com (Postfix) with ESMTP id EE68722B; Wed, 6 Mar 2002 08:03:53 +0800 (SGP) Received: from apbrg2.jpn.agilent.com (apbrg2.jpn.agilent.com [146.208.102.163]) by msgrel1.sgp.agilent.com (Postfix) with SMTP id 99E2D58E; Wed, 6 Mar 2002 08:03:19 +0800 (SGP) Received: from 146.208.102.163 by apbrg2.jpn.agilent.com (InterScan E-Mail VirusWall NT); Wed, 06 Mar 2002 09:03:52 +0900 Received: by apbrg2.jpn.agilent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 09:03:52 +0900 Message-ID: <050F1F49D79BD3118F3B0090278CB91803A39D17@apmail7.aus.agilent.com> From: "FIELD,GEOFF (A-Australia,ex1)" To: "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 09:03:50 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't think I've popped up here before, but I've been following the conversations for a while. I'm currently working in the 3G field, so I'd just like to present my view on the matter. Just a gentle reminder or two first: Cellular phones - 3G or otherwise - tend to be *mobile*. People use them in moving vehicles, as well as while just walking. In the 3G infrastructure, there are a number of nodes between a given terminal (phone) and the network - the base station (aka Node B in 3G terminology) which is moderately "dumb" w.r.t network protocols, the Radio Network Controller (RNC), which is a massive rack of powerful processors, and the SGSN or MSC, which are the choices of interconnect to the Core Network. The RNC, SGSN and MSC exhibit router-like behaviour. What can really confuse the issue is the mobility of the terminal - at any given moment it may be talking to two or more Node Bs, each of which may be connected to a separate RNC. If a terminal is on a cell's edge and swapping between Node Bs, does it have to perform ND each time it swaps? There's a hell of a lot of other protocol stuff going on at the same time during handover, particularly if it's between different RNCs. What about the situation where a terminal is in a fast- moving vehicle (a car on a highway, a train, an aircraft)? Does each and every handover have to have ND added to it as well as all the other stuff that's going on? It's a thorny issue, particularly for a handheld phone where price of manufacture and battery life are already being squeezed hard. As for security, remember that 3G phones use CDMA variants that are inherently nearly impossible to crack. Further, encryption is available already on the higher layers. I'm not arguing that the code for handling ND and security should be omitted for these terminals. I *am* saying it could possibly be simplified to silently ignore some things. OTOH, if a terminal is to be used as a router, it *must* be able to act like a proper router, so everything required must be fully implemented. I can envisage a mobile router in a fast-moving vehicle (an in-train Internet connection system, perhaps) that would complicate issues. For this, I'm glad that I (probably) won't be involved in working out the nightmare of handover issues. Geoff - further replies in the body. > Hi John, > [snip] > We have defined a mechanism to locate and maintain reachability > information about neighbours in IPv6, called "Neighbor Discovery". > This isn't an optional part of IPv6 that it would be appropriate > to disable on a particular link type. > > However, it is expected for ND to receive "advice" from other layers > regarding the "reachability" of another host -- so it would be > great if the L2 mechanism gave ongoing advice to IPv6 regarding > the reachability of the router, which would result in suppressing > IPv6 NS messages. This may or may not happen. In the 3G stacks, IP runs over AAL-5, which is not a complex protocol. As far as I can see, it just treats the IP traffic as a set of bytes to be transmitted. > I don't believe that your conclusion is sound... > > >Therefore, Neighbor > > Solicitation and Advertisement messages MAY be > implemented for the > > cellular interface. > > An implementor could read this and believe that it was acceptable > to build a 3GPP cell phone (with only one cellular interface) that > didn't even contain the _code_ necessary to generate IPv6 NS and > NA messages. To *generate* them? Why would it want to? > What happens when that host receives an NS message? If the RNC chooses to generate one, it had better be certain that the phone can handle it. The terminal may just silently ignore the NS message. > Do you think that people may ever want to set-up redundant > 3GPP networks, or make a choice between two possible 3GPP > routers, based on their current reachability? If you don't > use ND, how will this information be available for IPv6 > routing decisions? In point of fact, the terminals will be handed over frequently. 3G specifies control-plane protocols to handle this separately to IP. I would suspect that the RNCs or other upstream hardware would have to maintain the IP reachability information. > There seems to be a mis-perception in the 3GPP community that > ND will result in a lot of extra traffic. The idea of ND is > to locate the other node _once_ and maintain reachability > information about that node on an ongoing basis, using advice > from other layers, _without_ sending additional ND messages > unless absolutely necessary. This is fine if the terminal is stationary and well within the cell's boundaries and the characteristics of the air interface aren't changed by interference, rain or a truck parking in the way. > Are there reasons why you think that this won't work on 3GPP > hosts? It probably would, but there are other mechanisms already in place. It strikes me as a duplication of effort. [snip] > >2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration > > > > IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be > > supported. > > This should be a MUST. IPv6 hosts MUST support address > autoconfiguration, > although it is possible for the routers to be configured so > that it isn't > used (if desired). And, in fact, mobile hosts should support auto-configuration anyway, by virtue of the fact that they're mobile. [snip] There's my simple, non-expert spin on this debate. Geoff -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 16:37:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g260b8KL001302 for ; Tue, 5 Mar 2002 16:37:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g260b7xj001301 for ipng-dist; Tue, 5 Mar 2002 16:37:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g260b4KL001294 for ; Tue, 5 Mar 2002 16:37:04 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA27695 for ; Tue, 5 Mar 2002 16:37:05 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18227 for ; Tue, 5 Mar 2002 17:37:01 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Tue, 05 Mar 2002 16:36:58 -0800 From: "Tony Hain" To: "FIELD,GEOFF \(A-Australia,ex1\)" , "'Margaret Wasserman'" , Cc: Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Tue, 5 Mar 2002 16:36:58 -0800 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <050F1F49D79BD3118F3B0090278CB91803A39D17@apmail7.aus.agilent.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FIELD,GEOFF wrote: > ... > What about the situation where a terminal is in a fast- > moving vehicle (a car on a highway, a train, an aircraft)? > Does each and every handover have to have ND added to > it as well as all the other stuff that's going on? It's > a thorny issue, particularly for a handheld phone where > price of manufacture and battery life are already being > squeezed hard. Depends on how the device (terminal) views those different connections to RNCs. If they appear as interfaces that are somewhat persistent, then NO you would not have to do a new ND unless your timer had expired. If on the other hand they appeared to be interfaces that were new/removed, then YES ND would be required because there is no local state about the L3/L2 mapping. This is a very specific implementation issue, but there is no inherent reason for a terminal to violate the architecture. > > As for security, remember that 3G phones use CDMA variants > that are inherently nearly impossible to crack. Further, > encryption is available already on the higher layers. This is a frequent point from the 3G community, and if the only node I wanted to talk to was the GGSN it would be fine. Problem is that security needs to be from the origin all the way across the Internet, so whatever magic encryption is happening on the air link is really irrelevant. > > I'm not arguing that the code for handling ND and security > should be omitted for these terminals. I *am* saying it > could possibly be simplified to silently ignore some things. > OTOH, if a terminal is to be used as a router, it *must* > be able to act like a proper router, so everything required > must be fully implemented. I can envisage a mobile router > in a fast-moving vehicle (an in-train Internet connection > system, perhaps) that would complicate issues. For this, > I'm glad that I (probably) won't be involved in working > out the nightmare of handover issues. The only way a mobile router works is if the GGSN expects all terminals to act like proper IPv6 nodes. If a GGSN takes shortcuts based on an expectation that the micro-handset will never do X, then no device connecting to it will be able to do X because the GGSN will simply ignore it. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 5 17:14:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g261EUKL001332 for ; Tue, 5 Mar 2002 17:14:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g261EUjb001331 for ipng-dist; Tue, 5 Mar 2002 17:14:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g261ERKL001324 for ; Tue, 5 Mar 2002 17:14:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18632 for ; Tue, 5 Mar 2002 17:14:28 -0800 (PST) Received: from tkd.att.ne.jp (tkd.att.ne.jp [165.76.16.8]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id RAA26766 for ; Tue, 5 Mar 2002 17:14:27 -0800 (PST) Received: (qmail 29999 invoked from network); 6 Mar 2002 01:14:24 -0000 Received: from unknown (HELO localhost) (203.178.245.243) by tkd.att.ne.jp with SMTP; 6 Mar 2002 01:14:24 -0000 Date: Wed, 06 Mar 2002 10:14:19 +0900 (JST) Message-Id: <20020306.101419.71080782.nov@tahi.org> cc: pekkas@netcore.fi to: ipng@sunroof.eng.sun.com Subject: changing security part of LCNA ID From: OKABE Nobuo In-Reply-To: References: X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk From: Pekka Savola Subject: Re: Should connecting to the Internet be Optional? (Half-serious!) Date: Tue, 5 Mar 2002 10:30:55 +0200 (EET) > On Mon, 4 Mar 2002, Tony Hain wrote: > > (Half-) seriously.. I think connecting to the Internet MAY be optional. > > I discussed in lcna-minreq thread; I think that if a node like that can > not implement IPSEC or security in general, it MUST NOT have a global > address. Under some cornercases, link-local and/or site-local _might_ be > remotely acceptable. The authors decided to change security related part of our LCNA draft. We can not show exact wording yet. But we hope that this can be comprehensive answer for the WG's security concern. 1) The ID must not permit null security LNCA. 2) The ID treats IPsec as a MUST requrirement. 3) When we introduce IPsec to LCNAs we will face practical issues. If so, we will feedback our issues to the WG as our current practice with somehow (ex. another draft or so). The heart of the decision is not to harm "well thought out architectural fundamentals" (as Tony Hain said), but to respect the one. At the same time, we also concern feasibility about LCNA security. Therefore, it seems better way to feedback our practices to the WG than to compromise the fundamentals. We hope our effort contribute the WG. thanks, ---- nobuo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 19:41:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g263fJKL001730 for ; Tue, 5 Mar 2002 19:41:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g263fJcV001729 for ipng-dist; Tue, 5 Mar 2002 19:41:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g263fGKL001722 for ; Tue, 5 Mar 2002 19:41:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA24462 for ; Tue, 5 Mar 2002 19:41:16 -0800 (PST) Received: from tkd.att.ne.jp (tkd.att.ne.jp [165.76.16.8]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id UAA22655 for ; Tue, 5 Mar 2002 20:41:15 -0700 (MST) Received: (qmail 23225 invoked from network); 6 Mar 2002 03:41:12 -0000 Received: from unknown (HELO localhost) (203.178.249.30) by tkd.att.ne.jp with SMTP; 6 Mar 2002 03:41:12 -0000 Date: Wed, 06 Mar 2002 12:41:07 +0900 (JST) Message-Id: <20020306.124107.112630528.nov@tahi.org> To: pekkas@netcore.fi Cc: tiny@tahi.org, ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt From: OKABE Nobuo In-Reply-To: References: <200203041416.XAA07265@toshiba.co.jp> X-Mailer: Mew version 2.0 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Sorry not respond quickly. I answer some part of your questions. Inoue-san will answer the rest of them. From: Pekka Savola Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt Date: Mon, 4 Mar 2002 17:08:18 +0200 (EET) > > >3.1.3 Fragment Header > > > > > > If a minimum host satisfies the following conditions, the host MAY > > > not send this extension header, and MAY treat one as an unsupported > > > header when receiving it. > > > > > >==> I'm not sure what the robustness principle would say about hosts that > > >cannot defragment. > > > > What do you mean for "the robustness principle" ? > > RFC791, RFC1122, > > "Be liberal in what you accept, and > conservative in what you send" > > That is, if you can't be absolutely positive no one is going to send you > packets which are fragmented, there should be *really* good reason if you > don't want to accept them -- the sending node is complying to the > specifications, receiver wouldn't! I'm trying to explain our ideas. [motivation #1] 1) It is obviously helpful for some LCNAs to omit re-assembling function because of their memory limitation. 2) In another word, such kind of LCNAs have limited applications that also do handle small enough data. So that fragmentation should not be happened. [motivation #2] There is no minimum guideline how meny fragmented packets should be held. Then, we can not estimate memory consumption if reassembling is enabled. If a LCNA has reassembling function but can hold too small number of fragmented packets, it will be disaster for the network. [idea] ID should show a guideline for omitting reassembling function safely. [issues & solutions] 1) TCP can control packet size by MSS. -> If LNCA's applications are TCP only and the system control the value of MSS less then IPv6 MIN MTU, the LCNA will be able to omit reassembling function safely. 2) However, other protocols (ex, UDP, ICMP) can not control their packet size. -> What kind application should exceed IPv6 Min MTU. -> Maybe NFS or product specific applications. -> A implementer can omit reassembling function if he/she designs the LCNA carefully for being sure packet size not to exceed IPv6 MIN MTU. > > >3.7 DNS Extensions to support IP version 6 (RFC1886) [26] and IPv6 > > > Stateless DNS Discovery (draft-ietf-ipngwg-dns-discovery-02.txt) > > > [27] > > > > > > The only function that is not supported in the current IPv6 > > > autoconfiguration is automatic discovery of DNS server. On this > > > topic discussions are ongoing in IETF IPNG WG. If a standard is > > > fixed, it might become a mandatory item for minimum hosts. > > > AAAA record is defined for transform from IPv6 name to IPv6 > > > address. So, AAAA is currently mandatory for minimum host name > > > resolution. Also, A6 record is currently proposed and discussed in > > > IETF for an alternative of AAAA record. We need to check the > > > progress. > > > > > >==> What about reverse lookups? nibble-style, probably? ip6.int or > > >ip6.arpa, or both? > > > > On which case the reverse lookup is necessary in LCNA usage? > > We complete neglect that. > > If you don't even implement IPSEC, at least reverse lookups could be done > so you could (possibly) configure access-lists to the box. > > I'm not sure how big an issue this is but reverse should be mentioned at > least. Let me go back to your original question. Do you think that our draft should describe about reverse lookups? If so, I think ID should refer RFC1886, then nibble-style, of cause. But I have a question. What domain should be the right stuff, ip6.int or ip6.arpa, or both? Please tell us WG consensus. ---- nobuo -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 21:28:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g265SJKL001875 for ; Tue, 5 Mar 2002 21:28:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g265SJ81001874 for ipng-dist; Tue, 5 Mar 2002 21:28:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g265SGKL001867 for ; Tue, 5 Mar 2002 21:28:16 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA14997 for ; Tue, 5 Mar 2002 21:28:11 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA08862 for ; Tue, 5 Mar 2002 22:28:07 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 456346A901; Wed, 6 Mar 2002 07:27:53 +0200 (EET) Message-ID: <3C85A469.2060407@kolumbus.fi> Date: Wed, 06 Mar 2002 07:08:57 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com, Margaret Wasserman Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: >>If there are decisions as to what to do with ND/DAD/whatever, >>should those be made by (a) IPv6 WG, (b) 3GPP, or (c) >>vendors? >> > > Jari, > > I think the ND/DAD type issues can be dealt with by the IPv6 over foo > document which should be a lot quicker to produce than the host requirements > document. True, but I guess I was more worried about the "whatever" part. Looking at typical IPv6 over Foo documents, I would say ND, DAD, PPP, and RFC 3041 issues fit those documents well. But what about the rest? Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 5 22:36:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g266aeKL001993 for ; Tue, 5 Mar 2002 22:36:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g266aeFb001992 for ipng-dist; Tue, 5 Mar 2002 22:36:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g266aaKL001984 for ; Tue, 5 Mar 2002 22:36:36 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA23276 for ; Tue, 5 Mar 2002 22:36:36 -0800 (PST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA17659 for ; Tue, 5 Mar 2002 23:36:35 -0700 (MST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id PAA13212; Wed, 6 Mar 2002 15:36:29 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp (8.11.5/3.7W) id g266aTA28638; Wed, 6 Mar 2002 15:36:29 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id RAA28635 ; Wed, 6 Mar 2002 15:36:29 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id PAA24905; Wed, 6 Mar 2002 15:36:29 +0900 (JST) Received: from isl.rdc.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id PAA02637; Wed, 6 Mar 2002 15:36:28 +0900 (JST) Received: from localhost (inoue@flowerpark.isl.rdc.toshiba.co.jp [133.196.16.25]) by isl.rdc.toshiba.co.jp (8.11.6/8.11.6/1.4) with ESMTP id g266aRf07360; Wed, 6 Mar 2002 15:36:27 +0900 (JST) To: tiny@tahi.org, pekkas@netcore.fi Cc: ipng@sunroof.eng.sun.com Subject: Re: [tiny:1276] Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt In-Reply-To: Your message of "Mon, 4 Mar 2002 17:08:18 +0200 (EET)" References: X-Mailer: Mew version 1.92 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: <20020306153626L.inoue@isl.rdc.toshiba.co.jp> Date: Wed, 06 Mar 2002 15:36:26 +0900 From: Atsushi Inoue X-Dispatcher: imput version 980905(IM100) Lines: 135 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, >On Mon, 4 Mar 2002, Atsushi Inoue wrote: >> >A few comments in addition to ones I sent for -00.. >> > >> > Table 1. Resource restrictions of LCNA >> > >> > ===============+===============+==================+======= >> > Memory CPU Performance OS >> > ===============+===============+==================+======= >> > PC >64MB Pentium/64bits Windows >> > ---------------+---------------+------------------+------- >> > PDA 2-8MB RISC/32bits(50MHz) WinCE >> > VxWorks >> > PalmOS >> > >> >==> I think it'd be policitally correct to _at least_ change 'Windows' >> >there to 'Any', and possibly add 'Others' to PDA section (e.g. I like >> >Linux and NetBSD on PDA's :-). >> >> The footprint of WinCE is 1MB as announced, but the CPU performance >> of pocket PC becomes higher and higher. So, as you suggested we >> should replace winCE with embedded Linux or others if we keep on >> this device class. > >No, I'm proposing something like: > >--8<-- > ===============+===============+==================+======= > Memory CPU Performance OS > ===============+===============+==================+======= > PC >64MB Pentium/64bits Any > ---------------+---------------+------------------+------- > PDA 2-8MB RISC/32bits(50MHz) WinCE > VxWorks > PalmOS > Others >--8<-- > >Or even, remove WinCE from there completely. This is just what I proposed on the last reply, so I will change as you suggested. >> >2.7 Security >> > In Section 4 "Security for LCNA", we will regulate a baseline for >> > guaranteeing that a minimum host can communicate securely. However, >> > Denial of Service (DoS) and intrusion are out of scope. So, we have >> > to consider defending from DoS and/or intrusion in another place. >> > Also, the authentication of users is out of scope, because some >> > minimum hosts can omit a mechanism of user accounts. >> > >> >==> intrusion out of scope? What do you mean by that? >> >Auth? >> >> Here, we mention about intrusion as a typical case that LCNA and >> other device (such as firewall) work togather in order to provide >> specific security solution. "Intrusion out of scope" simply means >> that our spec only treats the end node itself and the security >> functionality provided by node and other network devices is not >> considered yet. > >Did you perhaps mean 'Interaction with Intrusion Detection Systems'? If >so, I definitely agree. By intrusion I understand a remote break-in into >the device, which is _definitely_ in the scope.. (you really don't want >your oven being heated up when you're away, do you :-) Agree. But we have not decided whether we have a concept of valid users when using LCNAs. Of course, some mechanism for authentication and authorization is necessary, but how those discriminatgion of access is done is out of scope for our draft. So, the correct description is: Preventing DOS and/or intrusion by collabotration with other network devices is out of scope. Intrusion to node itself have to be handled by some security mechanisms, but the detail of that is not described yet (FFS). > >> > - When it can recognize the extension header but does not support >> > the options in it, it MUST perform error processing according to >> > the option number. >> > >> >==> you mean s/extension header/destination options header/? There is no >> >processing defined by option number for extension headers. >> >> This is our typo. The correct description is as follows: >> >> When it can recognize the extension options headers but does not >> support the options in it, it MUST perform error processing according >> to the option type. (as secified in section 4.2 of RFC2460) > >Not all extension headers necessarily have TLV-encoded options which >contain the option type coded like that. E.g. routing header has RH type >coded differently. > >This is a bit of academic discussion though, as LCNA's don't intend to >support RH; but there might be some headers in the future that behave the >same way: you might not always find TLV-encoded options coded like that >inside. So, the wording might be a bit more careful. Thanks for pointing out that. > >> > [Receiving] >> > A minimum host SHOULD recognize it as a Hop-by-Hop Options Header, >> > and perform the processing according to the option and option >> > number in it. Because this option is used for signaling and router >> > alert, in order to control routers on the path, all nodes on the >> > transmission path have to interpret this header but do not need to >> > interpret all options in it. >> > >> >==> I don't understand your reasoning for router alert; LCNA's aren't >> >routers by definition :-) >> >> RFC2460 says, >> "The Hop-by-Hop Options header is used to carry optional >> information that must be examined by every node along a packet's >> delivery path." >> so we regulated that the examination of Hop-by-Hop option have to be >> performed even on LCNA. Is it too redundant ? > >Yes, I think the latter part of that paragraph is being overly verbose >(discussing non-LCNA issues and motivations) -- one _might_ add something >there about the applicability of HBH for e.g. signalling, but I'm not sure >if it's necessary. We will revise the wording of this part on -02 draft. --inoue -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 00:29:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g268TpKL002288 for ; Wed, 6 Mar 2002 00:29:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g268TpbD002287 for ipng-dist; Wed, 6 Mar 2002 00:29:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g268TmKL002280 for ; Wed, 6 Mar 2002 00:29:48 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA06490 for ; Wed, 6 Mar 2002 00:29:46 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA26060 for ; Wed, 6 Mar 2002 00:29:45 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g268TXB23610; Wed, 6 Mar 2002 09:29:33 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id JAA29511; Wed, 6 Mar 2002 09:29:33 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g268TXg12457; Wed, 6 Mar 2002 09:29:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203060829.g268TXg12457@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: Reserving bits in RFC 2473 Interface IDs? In-reply-to: Your message of Mon, 04 Mar 2002 23:15:09 +0100. Date: Wed, 06 Mar 2002 09:29:33 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Have you read draft-dupont-ipv6-imei-00.txt? Regards Francis.Dupont@enst-bretagne.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 Wed Mar 6 00:43:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g268hmKL002331 for ; Wed, 6 Mar 2002 00:43:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g268hmIX002330 for ipng-dist; Wed, 6 Mar 2002 00:43:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g268hiKL002323 for ; Wed, 6 Mar 2002 00:43:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA22128 for ; Wed, 6 Mar 2002 00:43:42 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00788 for ; Wed, 6 Mar 2002 00:43:41 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g268hSu10240; Wed, 6 Mar 2002 10:43:29 +0200 Date: Wed, 6 Mar 2002 10:43:28 +0200 (EET) From: Pekka Savola To: OKABE Nobuo cc: tiny@tahi.org, Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt In-Reply-To: <20020306.124107.112630528.nov@tahi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think we agree or almost on most points discussed here. On Wed, 6 Mar 2002, OKABE Nobuo wrote: > > > On which case the reverse lookup is necessary in LCNA usage? > > > We complete neglect that. > > > > If you don't even implement IPSEC, at least reverse lookups could be done > > so you could (possibly) configure access-lists to the box. > > > > I'm not sure how big an issue this is but reverse should be mentioned at > > least. > > Let me go back to your original question. > Do you think that our draft should describe about reverse lookups? I believe it should. > If so, I think ID should refer RFC1886, then nibble-style, of cause. Agree. > But I have a question. > What domain should be the right stuff, > ip6.int or ip6.arpa, or both? > Please tell us WG consensus. ip6.arpa is the thing of the future (see RFC 3152), but it isn't used that widely yet. Still, I'd say ip6.arpa only, especially if these LCNA's don't intend to ship tomorrow. Pekka -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 01:35:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g269ZpKL002502 for ; Wed, 6 Mar 2002 01:35:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g269ZoH8002501 for ipng-dist; Wed, 6 Mar 2002 01:35:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g269ZkKL002494 for ; Wed, 6 Mar 2002 01:35:46 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02286 for ; Wed, 6 Mar 2002 01:35:42 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07163 for ; Wed, 6 Mar 2002 01:35:39 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g269ZcB08781 for ; Wed, 6 Mar 2002 10:35:38 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 06 10:34:37 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 10:24:49 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFDB@esealnt117> From: "Karim El-Malki (ERA)" To: "'Tony Hain'" , "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 10:33:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Karim El-Malki wrote: > > This special router is called a GGSN and it knows it MUST NOT > > configure > > itself with a unicast address on that prefix. That means there's no > > conflict. Does that make sense? > > I will grant you that I don't know (or want to know) the > inner workings > of a GGSN, but what is the point of a link with only one node? Where > does an origin send data if there is no other device to > receive it? If > there is another device (assuming for a moment that the GGSN is the > second device), how does the origin find it unless that > device uses an > address in the range the origin considers to be in this > prefix? If that > second device uses an on-link address, how do the nodes at either end > know that there will never be a conflict (easy with out-of-band > coordination)? If either end generates RFC-3041 addresses, > how does that > node ensure that the other end hasn't already used that bit pattern > (easy if only one end generates, and the other only uses EUI-64s with > bit 6 set)? If a GGSN really MUST NOT configure itself into a prefix > that is allocated to a client device, what is the point of a GGSN? > > Does that make sense? Sorry but what you're saying doesn't make sense to me. Let's just use a generic example. A host discovers a router using RAs. The router uses a link-local address for the RAs. A host and a router on a point-to-point link can use the link-local to communicate. They don't need to use a global for example. The link-local is not in conflict if you use PPP where you can negotiate the interface id and specifically not run DAD on it. If the host is "delegated" a global prefix, it can run RFC3041 and doesn't need to do DAD on the cellular link since there is nobody else using that prefix. Yes, there is someone else on that link of course, the router. But the router doesn't configure any address on this delegated prefix so no conflict. This applies to any point-to-point link. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 01:38:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g269cNKL002524 for ; Wed, 6 Mar 2002 01:38:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g269cN57002523 for ipng-dist; Wed, 6 Mar 2002 01:38:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g269cKKL002516 for ; Wed, 6 Mar 2002 01:38:20 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA02654 for ; Wed, 6 Mar 2002 01:38:19 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21971 for ; Wed, 6 Mar 2002 02:38:18 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g269cHZc026938 for ; Wed, 6 Mar 2002 10:38:17 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 06 10:38:16 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 10:28:29 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFDC@esealnt117> From: "Karim El-Malki (ERA)" To: "'Erik Nordmark'" Cc: "'Keith Moore'" , john.loughney@nokia.com, Jonne.Soininen@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 10:37:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > No. The terminal (phone) doesn't need to act as a router to allow > > for multiple devices behind it to connect to the cellular > interface. > > You could eventually have multiple serial connections to > the terminal > > each having its own corresponding air interface > connection. So it can > > act as a host (if you're running the IP stack + app on it) or as > > an L2 device (modem) for e.g. laptops behind it. That doesn't mean > > that there's no advantages in making it a router but it's not > > mandatory. Given that implementers need guidelines now, > it's good if we > > only limit the scope to hosts for the moment and go onto > routers once > > the first is complete. > > Karim, > > In the case of the terminal being an L2 device like a modem > and the IP device being a laptop there might be some care. > > For instance, the laptop IPv6 stack might follow the > specifications and > use NUD over that PPP link. > This requires that the 3G devices in the network actually support NUD > over the PPP link. Agreed and they will do. I wasn't saying that the network won't support NUDs but the host doesn't necessarily have to. This was just to give the reason for the MAY on NA/NSs in a basic cellular host having only a cellular interface. > > While the draft claims it scope is about the cellular hosts > I wouldn't be surprised if some folks read the MAY and conclude > that they don't need to implement it at the first hop IPv6 router. The first hop router (GGSN) specs belong to 3gpp because it is a special router. I was just using the name router for simplification since that is what it looks like from the host's IPv6 stack. The 3gpp specs support NUDs in this first hop router so no worry about that. > > So I wonder if it makes sense to make this more clear in an > IPv6-over-3G > document which would say > hosts MAY implement sending of NUD messages > routers MAY implement sending of NUD messages > routers MUST implement processing NUD messages (unicast > NS messages) > hosts ??? implement processing NUD messages > > Such careful statements would make sense that things would > always interoperate. Not sure if we should get into putting MUST/MAYs on the 3gpp network parts since the GGSN is not simply a cellular router and is specified in 3gpp specs. However I agree that clarification on the behaviour of the upstream "router" from the host's point of view would fit nicely into an IPv6 over 3G spec. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 01:53:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g269r5KL002596 for ; Wed, 6 Mar 2002 01:53:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g269r5BP002595 for ipng-dist; Wed, 6 Mar 2002 01:53:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g269r2KL002588 for ; Wed, 6 Mar 2002 01:53:02 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA05587 for ; Wed, 6 Mar 2002 01:53:02 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15130 for ; Wed, 6 Mar 2002 01:52:59 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g269qTB22755 for ; Wed, 6 Mar 2002 10:52:29 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 06 10:47:59 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 10:38:12 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFDD@esealnt117> From: "Karim El-Malki (ERA)" To: "'FIELD,GEOFF (A-Australia,ex1)'" , "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 10:46:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It would be good if we kept 3G radio network architecture discussions off this list. /Karim P.S. As a note the RNC, Node B, SGSN have nothing to do with what we're discussing and they're not involved in any of the IPv6 mechanisms discussed so far. > -----Original Message----- > From: FIELD,GEOFF (A-Australia,ex1) [mailto:geoff_field@agilent.com] > Sent: den 6 mars 2002 01:04 > To: 'Margaret Wasserman'; john.loughney@nokia.com > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Making ND Optional [Was RE: > draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] > > > I don't think I've popped up here before, but I've been > following the conversations for a while. > > I'm currently working in the 3G field, so I'd just like > to present my view on the matter. > > Just a gentle reminder or two first: > Cellular phones - 3G or otherwise - tend to be *mobile*. > People use them in moving vehicles, as well as while > just walking. > > In the 3G infrastructure, there are a number of nodes > between a given terminal (phone) and the network - > the base station (aka Node B in 3G terminology) which > is moderately "dumb" w.r.t network protocols, the > Radio Network Controller (RNC), which is a massive > rack of powerful processors, and the SGSN or MSC, which > are the choices of interconnect to the Core Network. > The RNC, SGSN and MSC exhibit router-like behaviour. > > What can really confuse the issue is the mobility of > the terminal - at any given moment it may be talking > to two or more Node Bs, each of which may be connected > to a separate RNC. If a terminal is on a cell's edge > and swapping between Node Bs, does it have to perform > ND each time it swaps? There's a hell of a lot of > other protocol stuff going on at the same time during > handover, particularly if it's between different RNCs. > > What about the situation where a terminal is in a fast- > moving vehicle (a car on a highway, a train, an aircraft)? > Does each and every handover have to have ND added to > it as well as all the other stuff that's going on? It's > a thorny issue, particularly for a handheld phone where > price of manufacture and battery life are already being > squeezed hard. > > As for security, remember that 3G phones use CDMA variants > that are inherently nearly impossible to crack. Further, > encryption is available already on the higher layers. > > I'm not arguing that the code for handling ND and security > should be omitted for these terminals. I *am* saying it > could possibly be simplified to silently ignore some things. > OTOH, if a terminal is to be used as a router, it *must* > be able to act like a proper router, so everything required > must be fully implemented. I can envisage a mobile router > in a fast-moving vehicle (an in-train Internet connection > system, perhaps) that would complicate issues. For this, > I'm glad that I (probably) won't be involved in working > out the nightmare of handover issues. > > Geoff - further replies in the body. > > > > Hi John, > > > [snip] > > We have defined a mechanism to locate and maintain reachability > > information about neighbours in IPv6, called "Neighbor > Discovery". > > This isn't an optional part of IPv6 that it would be appropriate > > to disable on a particular link type. > > > > However, it is expected for ND to receive "advice" from > other layers > > regarding the "reachability" of another host -- so it would be > > great if the L2 mechanism gave ongoing advice to IPv6 regarding > > the reachability of the router, which would result in suppressing > > IPv6 NS messages. > > This may or may not happen. In the 3G stacks, IP runs over > AAL-5, which is not a complex protocol. As far as I can see, > it just treats the IP traffic as a set of bytes to be transmitted. > > > I don't believe that your conclusion is sound... > > > > >Therefore, Neighbor > > > Solicitation and Advertisement messages MAY be > > implemented for the > > > cellular interface. > > > > An implementor could read this and believe that it was acceptable > > to build a 3GPP cell phone (with only one cellular interface) that > > didn't even contain the _code_ necessary to generate IPv6 NS and > > NA messages. > > To *generate* them? Why would it want to? > > > What happens when that host receives an NS message? > > If the RNC chooses to generate one, it had better be certain > that the phone can handle it. The terminal may just silently > ignore the NS message. > > > Do you think that people may ever want to set-up redundant > > 3GPP networks, or make a choice between two possible 3GPP > > routers, based on their current reachability? If you don't > > use ND, how will this information be available for IPv6 > > routing decisions? > > In point of fact, the terminals will be handed over frequently. > 3G specifies control-plane protocols to handle this separately > to IP. I would suspect that the RNCs or other upstream hardware > would have to maintain the IP reachability information. > > > There seems to be a mis-perception in the 3GPP community that > > ND will result in a lot of extra traffic. The idea of ND is > > to locate the other node _once_ and maintain reachability > > information about that node on an ongoing basis, using advice > > from other layers, _without_ sending additional ND messages > > unless absolutely necessary. > > This is fine if the terminal is stationary and well within the > cell's boundaries and the characteristics of the air interface > aren't changed by interference, rain or a truck parking in the > way. > > > Are there reasons why you think that this won't work on 3GPP > > hosts? > > It probably would, but there are other mechanisms already in > place. It strikes me as a duplication of effort. > > [snip] > > >2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration > > > > > > IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be > > > supported. > > > > This should be a MUST. IPv6 hosts MUST support address > > autoconfiguration, > > although it is possible for the routers to be configured so > > that it isn't > > used (if desired). > > And, in fact, mobile hosts should support auto-configuration > anyway, by virtue of the fact that they're mobile. > > [snip] > > There's my simple, non-expert spin on this debate. > > Geoff > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 02:02:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26A22KL002652 for ; Wed, 6 Mar 2002 02:02:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26A22p4002651 for ipng-dist; Wed, 6 Mar 2002 02:02:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26A1vKL002644 for ; Wed, 6 Mar 2002 02:01:58 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g26A1qx22855; Wed, 6 Mar 2002 11:01:53 +0100 (MET) Date: Wed, 6 Mar 2002 10:56:50 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Reserving bits in RFC 2473 Interface IDs? To: Francis Dupont Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200203060829.g268TXg12457@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Have you read draft-dupont-ipv6-imei-00.txt? Now I have. 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 Wed Mar 6 02:03:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26A3oKL002678 for ; Wed, 6 Mar 2002 02:03:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26A3o3A002677 for ipng-dist; Wed, 6 Mar 2002 02:03:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26A3kKL002667 for ; Wed, 6 Mar 2002 02:03:46 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04495 for ; Wed, 6 Mar 2002 02:03:46 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA00784 for ; Wed, 6 Mar 2002 02:03:45 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g26A3hZc014444 for ; Wed, 6 Mar 2002 11:03:44 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 06 10:56:30 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 10:56:41 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFDE@esealnt117> From: "Karim El-Malki (ERA)" To: "'Tony Hain'" , "FIELD,GEOFF (A-Australia,ex1)" , "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 10:55:28 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > FIELD,GEOFF wrote: > > ... > > What about the situation where a terminal is in a fast- > > moving vehicle (a car on a highway, a train, an aircraft)? > > Does each and every handover have to have ND added to > > it as well as all the other stuff that's going on? It's > > a thorny issue, particularly for a handheld phone where > > price of manufacture and battery life are already being > > squeezed hard. > > Depends on how the device (terminal) views those different > connections > to RNCs. If they appear as interfaces that are somewhat > persistent, then > NO you would not have to do a new ND unless your timer had > expired. If > on the other hand they appeared to be interfaces that were > new/removed, > then YES ND would be required because there is no local > state about the > L3/L2 mapping. This is a very specific implementation issue, > but there > is no inherent reason for a terminal to violate the architecture. This discussion started from an incorrect basis. Please let's keep away from discussions on the 3g architecture details which don't belong here. > The only way a mobile router works is if the GGSN expects > all terminals > to act like proper IPv6 nodes. If a GGSN takes shortcuts based on an > expectation that the micro-handset will never do X, then no device > connecting to it will be able to do X because the GGSN will simply > ignore it. No shortcuts, the 3G network will support a standard IPv6 host. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 02:12:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26ACBKL002726 for ; Wed, 6 Mar 2002 02:12:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26ACBkb002725 for ipng-dist; Wed, 6 Mar 2002 02:12:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26AC8KL002718 for ; Wed, 6 Mar 2002 02:12:08 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18730 for ; Wed, 6 Mar 2002 02:12:08 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA05696 for ; Wed, 6 Mar 2002 03:12:07 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id MAA21120; Wed, 6 Mar 2002 12:12:06 +0200 Date: Wed, 6 Mar 2002 12:12:06 +0200 Message-Id: <200203061012.MAA21120@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: DAD and unique ID on link? Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Last year, in Seattle, I asked that RFC-2462 should be changed so that at any specific point of time, the id-part of address should be unique for each host on the link. That is, it should not be legal for two hosts on same link to use same ID part of the IPv6-address, regardless of the prefix. The main reason for this request is that, if id alone is not required to be unique on link, then *EVERY HOST* on the link must do DAD on every assigned id on every new prefix it sees from RA. On a link with many nodes, this causes a flood of DAD's after RA! [a host may have multilple ID's due to privacy drafts, and due other reasons]. Apparently my request has been totally forgotten. It's really a minor issue, and should just be clarified. ********* Do I have to write a new modified draft of RFC-2462 to get this issue hanndled? Or, how to proceed on this? ********* I've coded our stack do what "aggressive ID defendign", which is basicly: when DAD arrives (NS with src=::), 1) if target is my valid address, reply with NA 2) if target my tentative address, declare it duplicate --- up to this point, this is the normal DAD processing. The following step is my "tweak" 3) if target is not may address (valid or tentative), but if the ID part of the target matches any of my valid addresses, I will reply with NA as if the tested address were mine (regardless of the prefix in target). So far, the only thing that seems to break, is TAHI tests in prefix lifetime checks, where it uses DAD NS to see if I actually deleted the prefix. (If it used normal NS to test this, everything would go ok). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 02:35:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26AZwKL002912 for ; Wed, 6 Mar 2002 02:35:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26AZvdF002911 for ipng-dist; Wed, 6 Mar 2002 02:35:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26AZsKL002904 for ; Wed, 6 Mar 2002 02:35:54 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA13011 for ; Wed, 6 Mar 2002 02:35:54 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA15092 for ; Wed, 6 Mar 2002 03:35:52 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26Aa2Z24614 for ; Wed, 6 Mar 2002 12:36:02 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 12:35:51 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 12:35:51 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Applicability of draft-ietf-ipv6-cellular-host-00.txt Date: Wed, 6 Mar 2002 12:35:51 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B25@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Applicability of draft-ietf-ipv6-cellular-host-00.txt Thread-Index: AcHEcxObkjxNe0+SQEyf7jTmnTrRjgAhzCCQ To: Cc: X-OriginalArrivalTime: 06 Mar 2002 10:35:51.0760 (UTC) FILETIME=[B00D1500:01C1C4FA] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26AZtKL002905 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi James, [note: this discussion isn't really related to the task at hand ...] > I think some 90% of the new cellphones, even low end, now have Java on > them. Were would this be? I do know that many companies are promoting this, but some have not committed to it; very few phones are actually in shops. > But the last spec I saw for the Java MidP (the Java profile > that runs on a cell phone) did not have > a way to open a socket. You could only go through a URL. For a while, that will be the way it is done. It is doubtful that users will be able to see sockets on most phones, even for a long time. Don't think that most members of my family would really care to open a socket either. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 03:09:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26B9LKL002987 for ; Wed, 6 Mar 2002 03:09:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26B9L6j002986 for ipng-dist; Wed, 6 Mar 2002 03:09:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26B9IKL002979 for ; Wed, 6 Mar 2002 03:09:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25684 for ; Wed, 6 Mar 2002 03:09:16 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA10110 for ; Wed, 6 Mar 2002 04:09:00 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26B94Z13699 for ; Wed, 6 Mar 2002 13:09:04 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 13:08:53 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 13:08:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 13:08:52 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D58@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHEf8QUXJxkFwD+SSi98f8z17dtkQAfjtgg To: Cc: X-OriginalArrivalTime: 06 Mar 2002 11:08:53.0804 (UTC) FILETIME=[4D70FEC0:01C1C4FF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26B9IKL002980 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > Your document and your arguments have convinced me that we > should publish a standard definition of the minimal requirements > for an IPv6 node, an "IPv6 Node Requirements" document (or perhaps > two documents, one for hosts and one for routers?). This should > be a standards-track document, not an informational one, and I > think that your document would serve as an excellent starting > point for this work. Point of clarification, I personally prefer splitting the host requirements from the router requirements. A host is a node which does not forward packets on behalf of another node, while a router does. In creating the current document, this seperation really helped in scoping it (perhaps it didn't scope it enough, I'm sure a few of you are saying ...) > It is important that the minimal host requirements of IPv6 be > applicable to low-end systems, such as cell phones, and that > should be reflected in our general IPv6 node requirements effort. Without a doubt. > However, I don't think that we want to have a fragmented set > of informational host requirements documents with different > requirements for different IPv6 application spaces (cellular hosts > vs network appliances vs. home gateways vs. car infotainment > equipment, etc.). If I'm missing some reason why cellular > hosts are special, that explains why they would need an > informational requirements document (when other applications > would not), please explain. We don't want a fragmented market, that is why we've thought that the work should be done here. I think the reason why we have been saying that they are special is because there is urgent need for this kind of document and there is nothing else out there. I don't think that anyone is going to argue on these 2 facts: 1) if we put out alot of IPv6 enabled cellular hosts, those hosts better behave well. 2) if we put out a lot of IPv6 enabled cellular hosts, IPv6 should work well over the cellular link. I guess we are just differing on how best to achieve ensuring the above. Oh, one additionally point, perhaps it is not as important since it is an implementation issue, but the initial implementations of IPv6 most likely will be in firmware, making tweaking extremely difficult, which puts more pressure on making sure we get it right. Does this make any sense? John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 03:15:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26BF1KL003016 for ; Wed, 6 Mar 2002 03:15:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26BF1nj003015 for ipng-dist; Wed, 6 Mar 2002 03:15:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26BEvKL003008 for ; Wed, 6 Mar 2002 03:14:57 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16882 for ; Wed, 6 Mar 2002 03:14:56 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA19149 for ; Wed, 6 Mar 2002 03:14:21 -0800 (PST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26BEPZ16363 for ; Wed, 6 Mar 2002 13:14:25 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 13:14:14 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 13:14:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 13:14:14 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B2A@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Thread-Index: AcHEby8V0hSamrq/Th2udJOZHQUocQAkHFTQ To: , Cc: , X-OriginalArrivalTime: 06 Mar 2002 11:14:14.0984 (UTC) FILETIME=[0CE12C80:01C1C500] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26BEwKL003009 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Keith, > that's bizarre. does that mean that apps on a host that's > connected to > a cell phone won't be able to communicate with apps on that > cell phone > unless the cell phone is talking to the network? and that > communications > between the host and the cell phone will have to go over the wireless > network? No, but they probably won't be using IP to communicate (or at least not at first & probably not for awhile). Right now, my cell phone can use infrared or bluetooth for synching my calendar, phone book, creating ringtones (yup, big excitement). My assumption would be that things would continue like that for some time. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 03:16:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26BG1KL003033 for ; Wed, 6 Mar 2002 03:16:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26BG1uW003032 for ipng-dist; Wed, 6 Mar 2002 03:16:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26BFvKL003025 for ; Wed, 6 Mar 2002 03:15:57 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA16494 for ; Wed, 6 Mar 2002 03:15:56 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA26347 for ; Wed, 6 Mar 2002 03:15:55 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g26BFsZc018154 for ; Wed, 6 Mar 2002 12:15:54 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Wed Mar 06 12:15:53 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 12:06:05 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFDF@esealnt117> From: "Karim El-Malki (ERA)" To: "'Jari Arkko'" , Erik Nordmark Cc: ipng@sunroof.eng.sun.com, Margaret Wasserman Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 12:14:50 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Erik Nordmark wrote: > > >>If there are decisions as to what to do with ND/DAD/whatever, > >>should those be made by (a) IPv6 WG, (b) 3GPP, or (c) > >>vendors? > >> > > > > Jari, > > > > I think the ND/DAD type issues can be dealt with by the > IPv6 over foo > > document which should be a lot quicker to produce than the > host requirements > > document. > > > True, but I guess I was more worried about the "whatever" part. > Looking at typical IPv6 over Foo documents, I would say ND, DAD, > PPP, and RFC 3041 issues fit those documents well. But what about > the rest? I have a similar issue in mind. If we have an "IPv6 over Cellular links" draft would that also include some discussion on the rest e.g. security? That is, a security section specifically for cellular links? For example, when you use IPsec, IP header compression on the 3g link is not efficient and one of the results is higher packet loss. I guess this is something that the implementer should be told since it has to do with the specific link. Just trying to figure out what the options are and what would go in an eventual "IPv6 over Cellular links" draft. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 03:28:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26BSRKL003108 for ; Wed, 6 Mar 2002 03:28:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26BSR57003107 for ipng-dist; Wed, 6 Mar 2002 03:28:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26BSOKL003100 for ; Wed, 6 Mar 2002 03:28:24 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18995 for ; Wed, 6 Mar 2002 03:28:23 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00200 for ; Wed, 6 Mar 2002 03:28:22 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26BSui04727 for ; Wed, 6 Mar 2002 13:28:56 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 13:28:17 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 13:28:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 13:28:17 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B2C@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Thread-Index: AcHEak4L77b1hbuxToOtdPK1eATIRgAl2Yxw To: , Cc: X-OriginalArrivalTime: 06 Mar 2002 11:28:17.0952 (UTC) FILETIME=[0353E200:01C1C502] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26BSOKL003101 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Maragaret, > There will be (at least) two prefixes in use on the link: a > global prefix (the delegated /64) and the link-local prefix. > It is my understanding that the GGSN will use a link-local > address on the link. And, it is important that the link-local > address in use by the GGSN _not_ conflict with the link-local > address(es) in use on the host. > > This could definitely be achieved by other means than running > DAD on the link, though, which is fine with me. So at least for this issue, I think we can agree that 1) DAD is must to implement 2) DAD may not always be needed to be sent (need to explicitly state the conditions that apply) Is it OK to document this - in some draft related to what we've been doing? John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 03:33:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26BXXKL003176 for ; Wed, 6 Mar 2002 03:33:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26BXWOi003175 for ipng-dist; Wed, 6 Mar 2002 03:33:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26BXTKL003168 for ; Wed, 6 Mar 2002 03:33:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18240 for ; Wed, 6 Mar 2002 03:33:23 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA07363 for ; Wed, 6 Mar 2002 04:33:22 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26BXMZ26619 for ; Wed, 6 Mar 2002 13:33:22 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 13:33:11 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 13:33:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 13:33:10 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B2E@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] Thread-Index: AcHEVciw6xut/1gaT5quylSx3p/OaQArJq/Q To: , Cc: , X-OriginalArrivalTime: 06 Mar 2002 11:33:11.0401 (UTC) FILETIME=[B23CA590:01C1C502] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26BXUKL003169 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Keith, > The point, I think, is that the network that is seen by the devices > atached to the terminal must support all features of an IPv6 network > so that any IPv6 hosts can function when their connectivity is > provided through such a terminal. (subject to the normal bandwidth, > delay, packet loss etc. constraints) Agreed. I think that in general, the hosts should be able to the same (meaning connecting to any network - subject to layer 2 / interface availability). Of course, discussing when some of the basic IPv6 signaling can be optimized, especially with respect to spefic interfaces / layer 2's, isn't a bad thing. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 05:55:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26DtlKL003516 for ; Wed, 6 Mar 2002 05:55:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Dtkql003515 for ipng-dist; Wed, 6 Mar 2002 05:55:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26DthKL003508 for ; Wed, 6 Mar 2002 05:55:43 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA20325 for ; Wed, 6 Mar 2002 05:55:43 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18724 for ; Wed, 6 Mar 2002 06:55:38 -0700 (MST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26DtlZ14608 for ; Wed, 6 Mar 2002 15:55:47 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 12:39:55 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 12:39:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 12:39:54 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B26@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHEdH1jO0riFwDlRhe4ObjNgd4reQAhkCUA To: , Cc: , X-OriginalArrivalTime: 06 Mar 2002 10:39:55.0110 (UTC) FILETIME=[41195860:01C1C4FB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26DtiKL003509 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Charlie, > > how long do you think producing the general document > > to an RFC will take? What should we say in the > > meantime to folks who want to deploy IPv6 now? > > What if we make some revision to "draft-ietf-ipv6-cellular-host", > and run that as Informational? Then we could have IPv6 Host > Requirements later on the standards track. We could even > have a later IPv6-over-3GPP standards track document which > would obsolete the Informational document, if desirable. > Or, would that be IPv6-over-3.75G? That could be one way forward. What would the downside to this be? I think that one of the current sticking points in our discussion is that there is no IPv6 Host Requirements document. If there was, we wouldn't have this problem. Additionally, I think that a IPv6 Host Requirements document is extremely important, I will gladly put effort into it, but I do think that it will take some time to create a good document that will gain consensus. In the meantime, some companies will be putting out more than a few IPv6 capable phones / PDAs / etc without clear guidence. This is what I worry about. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 05:56:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26DuiKL003539 for ; Wed, 6 Mar 2002 05:56:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26DuiOH003538 for ipng-dist; Wed, 6 Mar 2002 05:56:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26DufKL003531 for ; Wed, 6 Mar 2002 05:56:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA04468 for ; Wed, 6 Mar 2002 05:56:41 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA00450 for ; Wed, 6 Mar 2002 06:56:40 -0700 (MST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26DunZ17797 for ; Wed, 6 Mar 2002 15:56:49 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 12:56:13 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 12:56:13 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 12:56:10 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D57@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHEdg19ICU7LVkHRJua7ORqGm4zKQAhaSog To: , , X-OriginalArrivalTime: 06 Mar 2002 10:56:13.0530 (UTC) FILETIME=[884863A0:01C1C4FD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26DufKL003532 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Tony, Hi Tony, > Please don't take this as a personal attack, but you just > don't get it. What I suspect is that we are actually looking at the same problems, from a different direction & thinking that a different way forward is what is needed. I completely agree with you that we should (must) not change IPv6 to suit the immediate needs of the day. Doing otherwise would really kill the purpose of IPv6. I think we both agree that one way to ensure this is to have an IPv6 Host Requirement document, which is applicable to all of the devices we see as potentially implementing IPv6. Such a document won't be turned out overnight, but that's the IETF. Additionally, having IPv6 over Foo documents are always useful, and in Salt Lake City, there was interest in having an IPv6 over Cellular (or some variation of that theme). I have discussed with a number of folks writing such a document. However, I think even with the proper scoping, this document will take some time as well. Now where we differ is what to do now. In my opinion, some informational document (that could / should be obsoleted when the general host document is completed) is needed to assist in implementing & deploying IPv6 on small cellular hosts. Most of these hosts will not be using a standard POSIX operating system, so information on doing this kind of thing may be limited. Of course, a document could be written within 3GPP, 3GPP2, etc. but that would miss critical review that (in my opinion) is needed from the IPv6 WG - and potentially lead to different versions of IPv6 (3GPP's IPv6, 3GPP2's IPv6, IETF's IPv6). I think the technical comments that Margaret has brought up have been great & very useful. Additionally, I think that the entire discussion has been useful because it is clarifying some things which are needed to be clarified. If I am still not getting it, please let me know - I really do want this discussion to be constructive and lead to a useful resolution. best regards, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 05:56:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26DunKL003549 for ; Wed, 6 Mar 2002 05:56:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26DunqS003548 for ipng-dist; Wed, 6 Mar 2002 05:56:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26DujKL003541 for ; Wed, 6 Mar 2002 05:56:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA13776 for ; Wed, 6 Mar 2002 05:56:46 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA17804 for ; Wed, 6 Mar 2002 05:56:40 -0800 (PST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26DuoZ17817 for ; Wed, 6 Mar 2002 15:56:50 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 12:59:03 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 12:59:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 12:59:03 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B28@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHEkw9syc5SFqTsS3m6dnmfVYypWQAaqniw To: Cc: , X-OriginalArrivalTime: 06 Mar 2002 10:59:03.0832 (UTC) FILETIME=[EDCA6980:01C1C4FD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26DukKL003542 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, > I don't think there is problem with the content. Thanks for the clarification - it hasn't always been entirely clear. > I believe > the content needs to be separated. One part to discuss IPv6 > operation over cellular links and one part to discuss the minimal > IPv6 functionality for hosts. The second part really belongs in > a general host requirements document. At the end of the day, this discussion is seeming to point to one fact - we NEED a general host requirements draft. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 05:59:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26DxZKL003585 for ; Wed, 6 Mar 2002 05:59:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26DxY7H003584 for ipng-dist; Wed, 6 Mar 2002 05:59:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26DxVKL003577 for ; Wed, 6 Mar 2002 05:59:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14061 for ; Wed, 6 Mar 2002 05:59:32 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA14993 for ; Wed, 6 Mar 2002 06:59:25 -0700 (MST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26DxUZ24749 for ; Wed, 6 Mar 2002 15:59:30 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 13:37:09 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 13:37:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 13:37:09 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B2F@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] Thread-Index: AcHEXYbh+v4aBEHpTV6NBeOOiEYstwApXkMA To: , Cc: , , , X-OriginalArrivalTime: 06 Mar 2002 11:37:09.0729 (UTC) FILETIME=[404A9D10:01C1C503] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26DxWKL003578 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > We should also update some of the base IPv6 specs to expect that > certain portions of IPv6 behaviour (i.e. whether or not to use > DAD) will be dependent on the link type, and defined in the > "IPv6 over " documents for each link type. Of course, we > then have to define this behaviour for each of the link types > that we've already specified (ethernet, PPP, etc.). > > None of this is rocket science, but it will require some updates > to existing standards currently at DS. Is this something that > we want to do at this point? I think we should & we must. To be more specific, optimizations that do not cause interoperability problems are extremely useful. Updating documents to reflect current reality is important. Its a dirty job, but ... John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 06:06:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26E6GKL003619 for ; Wed, 6 Mar 2002 06:06:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26E6GPx003618 for ipng-dist; Wed, 6 Mar 2002 06:06:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26E6DKL003608 for ; Wed, 6 Mar 2002 06:06:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA22738 for ; Wed, 6 Mar 2002 06:06:13 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23947 for ; Wed, 6 Mar 2002 07:06:03 -0700 (MST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26E6fi14133 for ; Wed, 6 Mar 2002 16:06:41 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 6 Mar 2002 15:29:40 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 15:29:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: IPv6 Node Requirements Bar BOF? Date: Wed, 6 Mar 2002 15:29:40 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B3C@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making ND Optional [Was RE:draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Thread-Index: AcHEdYHDLbS21LC8QjStnXKC/xctyAAnQwhA To: X-OriginalArrivalTime: 06 Mar 2002 13:29:40.0852 (UTC) FILETIME=[F8463B40:01C1C512] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26E6DKL003609 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Would folks be interested in an IPv6 Node Requirements bar BOF in Minneapolis? The working group has tried to get interest in such a document before, perhaps there is interest now. I'd be happy to try to organize an informal meeting in Minneapolis about this. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 06:25:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26EPlKL003705 for ; Wed, 6 Mar 2002 06:25:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26EPlqv003704 for ipng-dist; Wed, 6 Mar 2002 06:25:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26EPiKL003697 for ; Wed, 6 Mar 2002 06:25:44 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA26162 for ; Wed, 6 Mar 2002 06:25:45 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA04552 for ; Wed, 6 Mar 2002 06:25:42 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id QAA21423; Wed, 6 Mar 2002 16:25:41 +0200 Date: Wed, 6 Mar 2002 16:25:41 +0200 Message-Id: <200203061425.QAA21423@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: ISROUTER rules? Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In last Decemeber I tried to get some clarifications to the IS-ROUTER bit handling in NA. Apparently my interpretation still differs from TAHI, and as I have hard time deciphering the rules from RFC-2461, I would like present the question here. In TAHI section "R flag vs. IsRouter" flag, there are following tests unicast rso NA w/o TLL exp:updated unicast rso NA w/ TLL, diff. LLA exp:unchanged Why in first case the ISROUTE is supposed to be updated? Because TLL is not present, it seems to me that logically we don't know whether LLA is same or not, so we should not change ISROUTER. Similarly, unicast rsO NA w/o TLL exp:updated unicast rsO NA w/ TLL, diff. LLA exp:updated the latter is clear, we have the address and update it, but the first NA does not have TLL, so why should ISROUTE be updated? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 06:52:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26EqAKL003729 for ; Wed, 6 Mar 2002 06:52:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26EqAib003728 for ipng-dist; Wed, 6 Mar 2002 06:52:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Eq7KL003721 for ; Wed, 6 Mar 2002 06:52:07 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21642 for ; Wed, 6 Mar 2002 06:52:06 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26636 for ; Wed, 6 Mar 2002 07:52:05 -0700 (MST) Received: from tarski.cs.uni-bonn.de (tarski.cs.uni-bonn.de [131.220.4.200]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id PAA01804 for ; Wed, 6 Mar 2002 15:52:04 +0100 (MET) Received: (from ignatios@localhost) by tarski.cs.uni-bonn.de (8.9.1a/8.9.1) id PAA18996 for ipng@sunroof.eng.sun.com; Wed, 6 Mar 2002 15:51:25 +0100 (CET) Date: Wed, 6 Mar 2002 15:51:25 +0100 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Message-ID: <20020306155125.M18365@tarski.cs.uni-bonn.de> References: <795A014AF92DD21182AF0008C7A404320DFBEFD6@esealnt117> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <795A014AF92DD21182AF0008C7A404320DFBEFD6@esealnt117>; from Karim.El-Malki@era.ericsson.se on Tue, Mar 05, 2002 at 06:01:37PM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, Mar 05, 2002 at 06:01:37PM +0100, Karim El-Malki (ERA) wrote: > > > > What happens when that host receives an NS message? > > > > > > It won't because a cellular host /e.g. 3gpp) is alone on its link. > > > > I don't see why this should necessarily be the case, unless > > 3gpp is trying to treat IPv6 as a link layer. > > No, it's just a normal point-to-point link as we discussed some mails > ago with Francis. There's only the router and the cellular host. Router > reachability can be handled using L2 information (possible in cellular links) > or through NUD. That's why NS/NAs are not strictly needed. Then this should be discussed in a "IPv6 over 3GPP point-to-point link" document, as has been already suggested. Regards -is -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 07:39:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26FdWKL003816 for ; Wed, 6 Mar 2002 07:39:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26FdW73003815 for ipng-dist; Wed, 6 Mar 2002 07:39:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26FdSKL003805 for ; Wed, 6 Mar 2002 07:39:28 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA08828 for ; Wed, 6 Mar 2002 07:39:27 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19319 for ; Wed, 6 Mar 2002 08:39:26 -0700 (MST) Received: from kenawang ([192.168.1.85]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA17968; Wed, 6 Mar 2002 07:38:42 -0800 (PST) Message-Id: <4.2.2.20020306103122.01cafc40@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 06 Mar 2002 10:32:10 -0500 To: john.loughney@nokia.com From: Margaret Wasserman Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Cc: , In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B2C@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >So at least for this issue, I think we can agree that > > 1) DAD is must to implement > 2) DAD may not always be needed to be sent > (need to explicitly state the conditions that apply) > >Is it OK to document this - in some draft related to what >we've been doing? Yes, this should be documented. I think that it should go in an "IPv6 over " document. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 07:56:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Fu2KL003856 for ; Wed, 6 Mar 2002 07:56:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Fu2Os003855 for ipng-dist; Wed, 6 Mar 2002 07:56:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26FtxKL003848 for ; Wed, 6 Mar 2002 07:55:59 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20980 for ; Wed, 6 Mar 2002 07:55:58 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01101 for ; Wed, 6 Mar 2002 08:55:57 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1B64E3571; Wed, 6 Mar 2002 10:55:57 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 10:55:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: PPP and Global Addresses Date: Wed, 6 Mar 2002 10:55:56 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B015206F2@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP and Global Addresses Thread-Index: AcG2QbwPbU/FDAq4QFqExcF2x7ZLIAO5VvIQ From: "Bound, Jim" To: "Francis Dupont" , "Dr. Subrata Goswami" Cc: X-OriginalArrivalTime: 06 Mar 2002 15:55:57.0018 (UTC) FILETIME=[6746E3A0:01C1C527] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26FtxKL003849 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, Catching up on old mail I saved for DHCPv6. Let me just start with your view is wrong. I don't see the point of arguing with you. DHCPv6 will be deployed and widely used. So will stateless. Its not an IETF discussion worth having in this vein IMO. You have your opinion and thats fine. Many of us who also have implemented IPv6, talking to customers, and working with the market think you are 100% wrong. They want DHCPv6. /jim > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Friday, February 15, 2002 11:55 AM > To: Dr. Subrata Goswami > Cc: ipng@sunroof.eng.sun.com > Subject: Re: PPP and Global Addresses > > > In your previous mail you wrote: > > Mr. Dupont, DHCP originally started with allowing dynamic > IP address allocation. A secondary benefit of utility is in > network operations, it is impossible to manually assign IP > address to 100's of hosts let alone 1,000,000's that IPv6 > would allow. This about a large network operator, how are they > going to manage their asset of IP address pool - send a person > to manually configure each host, that is silly. > > => RFC 2462 "IPv6 Stateless Address Autoconfiguration". > > Francis.Dupont@enst-bretagne.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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 07:57:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26FvFKL003873 for ; Wed, 6 Mar 2002 07:57:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26FvFsw003872 for ipng-dist; Wed, 6 Mar 2002 07:57:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26FvCKL003865 for ; Wed, 6 Mar 2002 07:57:12 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16009 for ; Wed, 6 Mar 2002 07:57:11 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14828 for ; Wed, 6 Mar 2002 07:57:09 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 5EF9C5B26; Wed, 6 Mar 2002 10:57:08 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 10:57:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: dynamic dns update / rtdavd Date: Wed, 6 Mar 2002 10:57:07 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B015206F3@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: dynamic dns update / rtdavd Thread-Index: AcG2R3DQWXMqhuB0Q9uONWy5zSb/OgO4AOkg From: "Bound, Jim" To: "Tony Hain" , "Abdul Basit" , X-OriginalArrivalTime: 06 Mar 2002 15:57:08.0205 (UTC) FILETIME=[91B529D0:01C1C527] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26FvCKL003866 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Compaq permits dynamic updates to DNS for stateless addresses if the user wishes to do that automatically if they configure IPv6 on our product that way. regards, /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Friday, February 15, 2002 12:35 PM > To: Abdul Basit; ipng@sunroof.eng.sun.com > Subject: RE: dynamic dns update / rtdavd > > > You are asking an implementation specific question. There is > nothing in > either mechanism specifically targeting DDNS updates, but you will > likely find products that do update dns whichever mechanism gets used. > One design assumption of RA based auto-config was that nodes > would most > likely register themselves using DDNS, but with RFC3041 auto-config > addresses, that is counter to the goal of anonymity. > > Tony > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Abdul Basit > > Sent: Friday, February 15, 2002 1:07 AM > > To: ipng@sunroof.eng.sun.com > > Subject: dynamic dns update / rtdavd > > > > > > > > Hi, > > > > Just want to know that if its possible to dynamically update > > dns if we are assigning ipv6 addresses dynamically by router > > advertisements(for e.g rtdavd or zebra that finally assignes > > a EUI64+ compaitable ipv6 address) kinda like DHCP mechanism. > > DHCP has a support for dynamic dns updates though .. > > so want to know about it in ipv6.. > > > > thanks > > -basit > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 08:01:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26G1xKL003896 for ; Wed, 6 Mar 2002 08:01:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26G1wHu003895 for ipng-dist; Wed, 6 Mar 2002 08:01:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26G1tKL003888 for ; Wed, 6 Mar 2002 08:01:55 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17218 for ; Wed, 6 Mar 2002 08:01:54 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA17200 for ; Wed, 6 Mar 2002 08:01:53 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 534062CE8; Wed, 6 Mar 2002 11:01:53 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 11:01:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: PPP and Global Addresses Date: Wed, 6 Mar 2002 11:01:52 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B015206F4@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP and Global Addresses Thread-Index: AcG3AfzbL9C2g6jJTO243IxeEinhNwOJbWjg From: "Bound, Jim" To: "Pekka Savola" , "Tony Hain" Cc: "Ole Troan" , "Francis Dupont" , "NOISETTE Yoann FTRD/DMI/CAE" , "Yamasaki Toshi" , "Lilian Fernandes" , , X-OriginalArrivalTime: 06 Mar 2002 16:01:53.0125 (UTC) FILETIME=[3B888150:01C1C528] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26G1uKL003889 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > > I also think DHCP and what not should not be used for router > configuration. In the military I had a seargent tell me once opinions are like rectums every one has one. Thats all this is and your entitled to it. But I don't really care about your opinion or others on what should be used or not used from the work we do in the IETF. What I care about is if you find a technical hole or error in our protocol specifications or interoperablity issues. Deployment of IPv6 and what is used and not used will not be decided on this list and the people that have the money and authority to make those decisions are not evening listening to these discussions. Lets not fool our egoes and think the market listens to these discussions they do not. They do listen to other lists for sure but not the IETF lists. /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 Mar 6 08:03:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26G3LKL003913 for ; Wed, 6 Mar 2002 08:03:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26G3K5h003912 for ipng-dist; Wed, 6 Mar 2002 08:03:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26G3HKL003905 for ; Wed, 6 Mar 2002 08:03:17 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17629 for ; Wed, 6 Mar 2002 08:03:17 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18005 for ; Wed, 6 Mar 2002 08:03:16 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id C50E62FE4; Wed, 6 Mar 2002 11:03:15 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 11:03:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: PPP and Global Addresses Date: Wed, 6 Mar 2002 11:03:15 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B015206F5@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP and Global Addresses Thread-Index: AcG3DxKEyKxo3AZLTbmCd9t1z+Kr5AOGTk1A From: "Bound, Jim" To: "Nathan Lutchansky" , X-OriginalArrivalTime: 06 Mar 2002 16:03:15.0742 (UTC) FILETIME=[6CC6DBE0:01C1C528] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26G3IKL003906 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk we can deploy DHCPv6 very quickly to provide prefixes. that will be the deciding factor but will the spec work? thats our job here. If you don't want to work on it don't. /jim > -----Original Message----- > From: Nathan Lutchansky [mailto:lutchann-sunipng@litech.org] > Sent: Saturday, February 16, 2002 12:25 PM > To: ipng@sunroof.eng.sun.com > Subject: Re: PPP and Global Addresses > > > IMO, there are two separate scenarios in which some sort of prefix > delegation needs to be used: > > 1) A router establishes a point-to-point connection to a provider. > 2) A new router is connected to a site's backbone link. > > From Brian Haberman's comments at the interim meeting, it > seemed that APD > was designed for scenario (2), providing a means to "grow a > network" (his > words) without need for manual configuration. > > However, scenario (1) seems much more common, and indeed was > the origin of > this thread. Small IPv6 sites are inevitably connected to > the 6bone with > either a p-t-p tunnel or PPP, and there is no good reason we > shouldn't > have some kind of mechanism to autoconfigure the border > routers at these > sites. A draft by Itojun > (draft-itojun-ipv6-dialup-requirement-02.txt) > describes some of the mechanisms that could be used for > configuration, but > makes no recommendations. > > Instead of using a stateful protocol like DHCPv6 or APD to configure > customer sites, perhaps it would be best to use router > advertisements on > the p-t-p link. This was one of the more popular candidates > for dialup > configuration during Itojun's presentation in Seattle (the > other popular > candidate was APD). Instead of overloading the Prefix > Information option, > however, we could add an additional option to the router advertisement > messages, "Delegated Prefix". This option could only be used on p-t-p > links, of course. > > This technique would be lightweight, would be easy to > implement for both > the ISP and client sides, and would provide all the > functionality needed > for 90% of sites. -Nathan > > -- > +-------------------+---------------------+------------------------+ > | Nathan Lutchansky | lutchann@litech.org | Lithium Technologies | > +------------------------------------------------------------------+ > | I dread success. To have succeeded is to have finished one's | > | business on earth... I like a state of continual becoming, | > | with a goal in front and not behind. - George Bernard Shaw | > +------------------------------------------------------------------+ > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 08:04:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26G4rKL003930 for ; Wed, 6 Mar 2002 08:04:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26G4rq4003929 for ipng-dist; Wed, 6 Mar 2002 08:04:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26G4oKL003922 for ; Wed, 6 Mar 2002 08:04:50 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03133 for ; Wed, 6 Mar 2002 08:04:50 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24052 for ; Wed, 6 Mar 2002 09:04:49 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E710C362A; Wed, 6 Mar 2002 11:04:48 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 11:04:48 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: PPP and Global Addresses Date: Wed, 6 Mar 2002 11:04:48 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B015206F6@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP and Global Addresses Thread-Index: AcG35Mu/4eRix4Z8RI+M39vYARw1/gNQ7j2A From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 06 Mar 2002 16:04:48.0764 (UTC) FILETIME=[A438E3C0:01C1C528] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26G4oKL003923 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ralph, It was brilliant to re-discover what dhcp can do for IPv6. This will also work with router renumbering very well in the real market. /jim > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Sunday, February 17, 2002 1:54 PM > To: ipng@sunroof.eng.sun.com > Subject: RE: PPP and Global Addresses > > > I have to ask - because I've never heard it raised as an issue outside > this mailing list - has anyone ever heard a *network administrator* or > other customer of IETF protocols say that "configuring > routers with what > is titled a host specific protocol will create more confusion than it > is worth." > > If the name is truly a problem, I'm happy to follow up on the > suggestion > that we rename DHCP to "Dynamic Node Configuration Protocol" > or "Dynamic > Site Configuration Protocol" or "Yet Another Configuration > Protocol". I'm > having a hard time believing we're making technical decisions about > protocol design based on the *name* of the protocols involved. > > Sheesh. > > BTW, just to review some ancient history, I added the > infamous sentence > "DHCP is not intended for use in configuring routers." (originally in > RFC1531 and carried forward to RFC1541 and RFC2131) to limit > the scope of > the problem we were trying to solve. That was (literally) 10 > years ago. > Maybe it's OK now to reconsider that constraint. > > The sentence is *not* included in draft-ietf-dhc-dhcpv6-23.txt. > > - Ralph > > On Sat, 16 Feb 2002, Pekka Savola wrote: > > > On Fri, 15 Feb 2002, Tony Hain wrote: > > > Ole Troan wrote: > > > > ... > > > > would you be happier if we renamed it to SNCP (Simple Node > > > > Configuration Protocol)? :-) > > > > > > Actually, yes. Routers are not hosts, so configuring > routers with what > > > is titled a host specific protocol will create more > confusion than it is > > > worth. > > > > Just a point: the value of router/host toggle is > interface-specific. This > > was dicussed, hmm, probably around 6-9 months ago here in > the context of > > RFC2461. > > > > I also think DHCP and what not should not be used for router > > configuration. > > > > > > > > for me this boils down to picking a packet format on > the wire. DHCP > > > > offers a more flexible option format, is more extensible, has a > > > > defined relay mechanism, offers a Reconfigure mechanism so it is > > > > possible to poke the requesting router. I have no > problem with using > > > > ICMP PD, my point is that as we move along it is going > to look awfully > > > > much like DHCP. > > > > > > If we are going to need a stateful protocol tied to an > authentication > > > system, using the wire format and option richness of a > widely deployed > > > protocol makes more sense than inventing a new one. At > the same time, > > > going that route requires a serious look at the defined > options to find > > > any potential security holes that may exist because there was a > > > historical assumption that the option applied to an end > system not a > > > router. If a router requesting one of the existing > options opens a big > > > hole, we really do need a new protocol. > > > > > > Tony > > > > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: > http://playground.sun.com/ipng > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > -------------------------------------------------------------------- > > > > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 08:09:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26G9SKL003952 for ; Wed, 6 Mar 2002 08:09:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26G9ShG003951 for ipng-dist; Wed, 6 Mar 2002 08:09:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26G9PKL003944 for ; Wed, 6 Mar 2002 08:09:25 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19783 for ; Wed, 6 Mar 2002 08:09:25 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21720 for ; Wed, 6 Mar 2002 08:09:24 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id A22C43685; Wed, 6 Mar 2002 11:09:23 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 11:09:23 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Configuring Routers Date: Wed, 6 Mar 2002 11:09:23 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B015206F7@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Configuring Routers Thread-Index: AcG58jjFGpVu8zVpRE6ktcZE5Wry+QLNsYxw From: "Bound, Jim" To: "Pekka Savola" , "Robert Elz" Cc: "Tony Hain" , "Ole Troan" , "Francis Dupont" , "NOISETTE Yoann FTRD/DMI/CAE" , "Yamasaki Toshi" , "Lilian Fernandes" , , X-OriginalArrivalTime: 06 Mar 2002 16:09:23.0513 (UTC) FILETIME=[47FC4290:01C1C529] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26G9PKL003945 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Have you read DHCPv6 or is this opinion based on what you have heard? The protocol DHCP (v4 or v6) is good for 'nodes' and optimized. With DHCPv6 we also added multicast to its capabilities which adds much value to dhcp. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Wednesday, February 20, 2002 4:33 AM > To: Robert Elz > Cc: Tony Hain; Ole Troan; Francis Dupont; NOISETTE Yoann FTRD/DMI/CAE; > 'Yamasaki Toshi'; Lilian Fernandes; ipng@sunroof.eng.sun.com; > shouchun@us.ibm.com > Subject: Re: Configuring Routers > > > On Mon, 18 Feb 2002, Robert Elz wrote: > > It could just be that people believe that the only way to > ever configure > > a router is manually, and that any protocol to automate the > process is > > necessarily flawed. If so, I'd like to understand why, > but I think I'd > > tend to ignore that sentiment - other than to make sure > that implementations > > keep on making it possible to manually configure, so that people who > > believe this don't have the rug yanked out from under them > (and in certain > > particular circumstances, I think this probably includes all of us). > > In my opinion, DHCP was not designed, from the start, to configure > routers. Now, as an afterthough, capabilities are added to > do just that. > My worry is that some of the basic assumptions of DHCP > architecture do not > necessarily fit well into the new requirements of configuring routers. > > From an operational point-of-view, I would not like have automatic > configuration mechanisms (apart from, possibly, NTP/DNS/... > settings) for > the important routers. > > However, to make renumbering even remotely possible, I don't see a > problem, as such, with configuring very simple routers (don't > run routing > protocols at all, no access-lists or acl's dynamically > created, etc.) like > DSL/Cable boxes via some mechanism. I think that would only > be sensible. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 08:29:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GTBKL004001 for ; Wed, 6 Mar 2002 08:29:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26GTBjL004000 for ipng-dist; Wed, 6 Mar 2002 08:29:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GT7KL003993 for ; Wed, 6 Mar 2002 08:29:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09089 for ; Wed, 6 Mar 2002 08:29:07 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10150 for ; Wed, 6 Mar 2002 09:29:06 -0700 (MST) Received: from kenawang ([192.168.1.85]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA14127; Wed, 6 Mar 2002 08:28:41 -0800 (PST) Message-Id: <4.2.2.20020306103447.01c8e1f0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 06 Mar 2002 11:20:52 -0500 To: john.loughney@nokia.com From: Margaret Wasserman Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Cc: In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B26@esebe004.NOE.Nokia. com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi John, > > What if we make some revision to "draft-ietf-ipv6-cellular-host", > > and run that as Informational? Then we could have IPv6 Host > > Requirements later on the standards track. We could even > > have a later IPv6-over-3GPP standards track document which > > would obsolete the Informational document, if desirable. > > Or, would that be IPv6-over-3.75G? > >That could be one way forward. What would the downside to this >be? I've tried to explain this in other messages, but I don't think that my reasons are coming across... If we publish this document as "informational" now, I think we all agree that the 3GPP community will treat this as a standard and implement to it. This raises one serious, immediate problem. This document contradicts things in IPv6 standards track documents. As a result, we may end up with two subtly incompatible "camps" of IPv6 nodes (cellular nodes and non-cellular nodes). Since we know that this document will be treated as a standard, giving it a cursory review and hurrying to publish it as an "informational" document is irresponsible. >I think that one of the current sticking points in our discussion >is that there is no IPv6 Host Requirements document. If there >was, we wouldn't have this problem. Additionally, I think >that a IPv6 Host Requirements document is extremely important, >I will gladly put effort into it, but I do think that it will >take some time to create a good document that will gain >consensus. Why do you think that it will take more time to gain consensus on the minimal IPv6 host requirements for a standards-based "IPv6 host requirements" effort, than it will to reach consensus on the minimal IPv6 host requirements for an informational "cellular hosts" effort? Either way, we need to reach consensus on the minimal set of specifications and features that comprise IPv6, right? Getting this right will take time, and I don't think that we should publish either document until we get it right. If we are going to undertake this effort, wouldn't you rather emerge with a standards-based host requirements document than with an informational cellular-specific document? Or are you suggesting that we should publish a "cellular host requirements" draft without going through the effort to get full consensus on the actual minimal requirements for IPv6 hosts? How would that work, and still avoid the "two camps" concern that I raised above? >In the meantime, some companies will be putting >out more than a few IPv6 capable phones / PDAs / etc without >clear guidence. This is what I worry about. Yes. They will be doing it based on the IPv6 standards. We've worked on those standards for years, subjected them to multiple rounds of scrutiny, and they have been implemented by many vendors. None of us would say they are perfect, but they are the best information we have about how to build compatible, compliant IPv6 hosts. I _do_ think that we need to do an "IPv6 over " document. This document should include everything that is really special about building hosts that talk on cellular links. One question: Are there enough differences between different cellular link types that we will need more than one of these documents? Or is there, effectively, a single type of cellular link, from an IPv6 perspective? Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 08:42:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Gg8KL004020 for ; Wed, 6 Mar 2002 08:42:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Gg8NZ004019 for ipng-dist; Wed, 6 Mar 2002 08:42:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Gg4KL004012 for ; Wed, 6 Mar 2002 08:42:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27020 for ; Wed, 6 Mar 2002 08:42:05 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17887 for ; Wed, 6 Mar 2002 09:42:04 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 8C9E435E5; Wed, 6 Mar 2002 11:42:03 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 11:42:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Date: Wed, 6 Mar 2002 11:42:03 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B015206F8@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Thread-Index: AcHCzjpMW0yWY4OSQhCcWVP0v8ptmQCXqd4w From: "Bound, Jim" To: "Margaret Wasserman" , "Hesham Soliman (ERA)" Cc: , X-OriginalArrivalTime: 06 Mar 2002 16:42:03.0461 (UTC) FILETIME=[D8349750:01C1C52D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26Gg5KL004013 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, First I full support the spec. Second this is for cellular hosts. That may not be end-2-end IP devices or architecture until release 6 of 3GPP. In the IETF we have specified things according to 2119. But, this is an implementation document and implementations may or may not do what we say here at the end of the day. Our job is to give them guidelines as standards. If vendors and the market pick and choose those there is NOTHING we can do about it. To address the issue of the issue this being perceived as IPv6 WG support. That again is not our job or fate. Again thats not how the market works or other standards bodies. Info RFC is just that. Info. We have statements what all our progressions mean to Full Standard to Best Current Practice. I fully support this being move to Info RFC and happen to agree with the authors implementation guidelines for cellular hosts. Now I don't agree with all of it for handheld devices that have been built, being tested, and in trial networks that are by passing the entire 3G problem of getting to Full IP (which it is not) and using 802.11 and will be using MIPv6 and taking the risk for early markets. Those handsets have to adhere to our 2119 recommendations for IPv6 specifications as they will use true IPv6 End-2-End for deployment into the market. IPv6 is being deployed and mandated now. This spec for cellular hosts is correct. regards, /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Sunday, March 03, 2002 11:11 AM > To: Hesham Soliman (ERA) > Cc: juha.wiljakka@nokia.com; ipng@sunroof.eng.sun.com > Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? > > > > > I do think that this document includes interesting and useful > information about the perspective of cellular handset vendors, > and the technical requirements and issues for cellular handsets. > Within the IETF, therefore, it might be useful to publish this > document as an Informational RFC. > > However, I am concerned about how outside groups (specifically > the 3GPP) will interpret publishing this document, even as an > Informational RFC. > > Hesham's comment illustrates my concern... > > >I don't know if someone already answered this, > >but I believe the agreement in SLC was to progress > >the cellular host draft independantly, mainly because > >of the very close 3GPP deadline. > > How are we expecting the 3GPP to use this document? Why is > it needed for a 3GPP deadline? > > Will outside groups believe that this document represents a > consensus of the IPv6 WG regarding what the minimal requirements > actually are for an IPv6 cellular host? If so, I don't think that > we should publish this document without a more significant discussion > within the WG. > > It is not my impression that the WG has reached consensus on some > of the issues raised in this document, specifically: > > - Forbidding the use of DAD on some links > - Situation where IP Security should be optional/disabled > (and the who distinction between "Core IP" and > "IP Security") > - Making ND optional on point-to-point links > - Making IPv6 autoconfiguration optional on hosts (rather > than mandatory on hosts and turned on/off for the > link in router advertisements) > > Also, some of the comments in this document might best be handled > as "applicability" portions of other documents (i.e. use of 6to4 > over a cellular link), rather than as specific requirements for > a class of hosts. > > I do think that the WG will need to do some work on defining the > official contents of IPv6, including the minimal requirements for > IPv6 nodes (or hosts and routers), but this will probably require > a considerable effort, and a good deal of negotiation within the > WG and with the IESG. > > I am concerned that we may bypass this effort, to our later detriment, > by publishing a document now that is mistakenly interpretted as a > standards-track host requirements document by outside groups. > > Does anyone else share this concern? What are our options to > ensure that this doesn't happen? > > Margaret > > > > > At 05:16 AM 3/3/02 , Hesham Soliman (ERA) wrote: > >Margaret, > > > >I don't know if someone already answered this, > >but I believe the agreement in SLC was to progress > >the cellular host draft independantly, mainly because > >of the very close 3GPP deadline. > > > >Cheers, > >Hesham > > > > > > > -----Original Message----- > > > From: Margaret Wasserman [mailto:mrw@windriver.com] > > > Sent: Thursday, February 28, 2002 3:53 PM > > > To: juha.wiljakka@nokia.com > > > Cc: ipng@sunroof.eng.sun.com > > > Subject: Re: draft-ietf-ipv6-cellular-host-00.txt -> wg > last call? > > > > > > > > > > > > Hi Juha, > > > > > > What type of last call are you proposing? Do you think > that this > > > document should become an informational RFC? Or do you think it > > > should be on the standards track? > > > > > > It was my impression that we (the WG) were hoping to move > > > towards a more general "node requirements" document, using this > > > document as (one of) the input(s). > > > > > > Margaret > > > > > > > > > At 07:28 AM 2/28/02 , juha.wiljakka@nokia.com wrote: > > > > > > > Hi! > > > > > > > >We "cellular host IPv6" draft authors believe that our draft > > > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellula > >r-host-00.txt > > > > > >would be ready for wg last call. > > > > > >Bob and Steve, if there are no objections from the WG, > > >could you please consider announcing last call for this draft? > > > > > >Thank You. > > > > > >On behalf of all the authors, > > > Juha Wiljakka > > > >-------------------------------------------------------------------- > > >IETF IPng Working Group Mailing List > > >IPng Home 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 > >-------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 08:44:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Gi2KL004037 for ; Wed, 6 Mar 2002 08:44:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Gi13n004036 for ipng-dist; Wed, 6 Mar 2002 08:44:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GhwKL004029 for ; Wed, 6 Mar 2002 08:43:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00508 for ; Wed, 6 Mar 2002 08:43:58 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29426 for ; Wed, 6 Mar 2002 09:43:58 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g26GhvZc010326 for ; Wed, 6 Mar 2002 17:43:57 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 06 17:42:35 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 17:34:08 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFE1@esealnt117> From: "Karim El-Malki (ERA)" To: "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 17:42:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I _do_ think that we need to do an "IPv6 over link of your choice>" document. This document should include > everything that is really special about building hosts that > talk on cellular links. I agree. If I remember correctly that was also one of the things that came out of the IPv6-3gpp design team effort. > > One question: Are there enough differences between different > cellular link types that we will need more than one of these > documents? Or is there, effectively, a single type of cellular > link, from an IPv6 perspective? Well, several things are the same: low bandwidth, point-to-point, lossy, needs header compression. I think that was the assumption behind the cellular hosts draft. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 08:44:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GiZKL004054 for ; Wed, 6 Mar 2002 08:44:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26GiZ9K004053 for ipng-dist; Wed, 6 Mar 2002 08:44:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GiVKL004046 for ; Wed, 6 Mar 2002 08:44:31 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00661 for ; Wed, 6 Mar 2002 08:44:31 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28470 for ; Wed, 6 Mar 2002 09:44:30 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 86B8E2E58; Wed, 6 Mar 2002 11:44:30 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 11:44:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Date: Wed, 6 Mar 2002 11:44:30 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B015206F9@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Thread-Index: AcHDMZZzMz3ndBwFRyqCaL/EjXuAzgB/GfSA From: "Bound, Jim" To: "Hesham Soliman (ERA)" , "Margaret Wasserman" Cc: , X-OriginalArrivalTime: 06 Mar 2002 16:44:30.0405 (UTC) FILETIME=[2FCA7750:01C1C52E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26GiWKL004047 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree with all of Hesham's comments. Except that this is wg consensus. I just don't think anyone cares in 3G now they just want a spec like right now. We can ship this here or we take it elsewhere. I don't really care cause the spec will work no matter where or how it is published. /jim > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Sunday, March 03, 2002 10:57 PM > To: 'Margaret Wasserman' > Cc: juha.wiljakka@nokia.com; ipng@sunroof.eng.sun.com > Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? > > > Hi Margaret, > > Thanks for the comments, I've been a bit concerned > about the lack of interest/comments so far. > I didn't think that we did a perfect job :) > My comments below. BTW, these are comments/questions > for all, hopefully we can get more feedback. > > > I do think that this document includes interesting and useful > > information about the perspective of cellular handset vendors, > > and the technical requirements and issues for cellular handsets. > > Within the IETF, therefore, it might be useful to publish this > > document as an Informational RFC. > > => OK. > > > >I don't know if someone already answered this, > > >but I believe the agreement in SLC was to progress > > >the cellular host draft independantly, mainly because > > >of the very close 3GPP deadline. > > > > How are we expecting the 3GPP to use this document? Why is > > it needed for a 3GPP deadline? > > => Because they would use it as a reference for > UMTS handsets implementors. > > > > > Will outside groups believe that this document represents a > > consensus of the IPv6 WG regarding what the minimal requirements > > actually are for an IPv6 cellular host? > > => Yes. > > If so, I don't think that > > we should publish this document without a more significant > > discussion > > within the WG. > > => Then let's begin the discussions. The only reason > for standardising the draft in the IPv6 WG was to make > sure that we're doing the right thing. Otherwise an > informational RFC wouldn't have to go through the > IPv6 WG or could have been replaced by a 3GPP spec. > But since the competence is here, it is crucial > that we get feedback. > > > It is not my impression that the WG has reached consensus on some > > of the issues raised in this document, specifically: > > > > - Forbidding the use of DAD on some links > > => DAD is not needed if address duplication is not > possible. Since each terminal gets a unique > /64 (as per the advice draft), and since all terminals > are on p2p links, DAD would be a waste of BW. > But please have a closer look and let us know > if something was missed. > > > > - Situation where IP Security should be optional/disabled > > (and the who distinction between "Core IP" and > > "IP Security") > > => The distinction between IP security and core IP > is merely an editorial distinciton. For example > you can see that in 'core IP' we list all the > IPv6 WG RFCs. > As to whether IP security (I assume you mean IPsec) > should be mandated or not, we can discuss that. > But some questions that we would need to answer: > > - By 'mandated' do we mean implementation or use? > - What should be mandated? > - Why should it be mandated? > > > - Making ND optional on point-to-point links > > => RFC 2461 MUST be implemented, the exceptions are > things like the Link layer suboption which is not > relevant for these links. Did we miss something else? > > > - Making IPv6 autoconfiguration optional on hosts (rather > > than mandatory on hosts and turned on/off for the > > link in router advertisements) > > => You mean 2462 shoud be a SHOULD/MUST? > That's possible for the generic cellular case, but for 3GPP, > since there is a separate 'autoconfig' mechanism, > this RFC is not needed. Would a SHOULD/MUST for the > general case, and a 'not needed' for 3GPP > be staisfactory? > > > Also, some of the comments in this document might best be handled > > as "applicability" portions of other documents (i.e. use of 6to4 > > over a cellular link), rather than as specific requirements for > > a class of hosts. > > > > I do think that the WG will need to do some work on defining the > > official contents of IPv6, including the minimal requirements for > > IPv6 nodes (or hosts and routers), but this will probably require > > a considerable effort, and a good deal of negotiation within the > > WG and with the IESG. > > > > I am concerned that we may bypass this effort, to our later > > detriment, > > by publishing a document now that is mistakenly interpretted as a > > standards-track host requirements document by outside groups. > > > > Does anyone else share this concern? What are our options to > > ensure that this doesn't happen? > > > > => I think you're making valid points and, as I said, > our intention (since the London meeting) was to try > to get as much feedback as possible. Very few comments > were made, I assumed due to lack of interest/time. > But, since the draft has been out for a long time > now, it would be good to get these comments ASAP. > Rushing the draft to become RFC is not good, but > delaying it for too long can be just as detrimental > to deployment. I hope more WG members would comment > on this. > > Cheers, > Hesham > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 08:44:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GigKL004064 for ; Wed, 6 Mar 2002 08:44:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26GigPG004063 for ipng-dist; Wed, 6 Mar 2002 08:44:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GicKL004056 for ; Wed, 6 Mar 2002 08:44:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA12416 for ; Wed, 6 Mar 2002 08:44:38 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA29938 for ; Wed, 6 Mar 2002 09:44:37 -0700 (MST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26GikZ25704 for ; Wed, 6 Mar 2002 18:44:47 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 18:44:36 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 18:44:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 18:44:35 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD38D59@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHFLAlBv0xlypnDSmuyrH80hf3zDQAAEJvg To: Cc: X-OriginalArrivalTime: 06 Mar 2002 16:44:36.0020 (UTC) FILETIME=[33233F40:01C1C52E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26GicKL004057 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Margaret, > If we publish this document as "informational" now, I think we > all agree that the 3GPP community will treat this as a standard and > implement to it. > > This raises one serious, immediate problem. This document > contradicts things in IPv6 standards track documents. As a > result, we may end up with two subtly incompatible "camps" of > IPv6 nodes (cellular nodes and non-cellular nodes). Right now, there is nothing for 3GPP community to implement towards. Divining the relationships between relevant IPv6 RFCs (and drafts which are updates to RFCs) is not at all clear. Evaluating a number of commercial IPv6 stacks has shown that a large number of them are not compliant to many of the standards we are listing in our document. Our document does not intend to create any incompatibilities, and we want to ensure that there are not. I have already been suggesting that we can adjust the requirements in the document, so we don't introduce incompatibilities & this is why we have been asking for comments on the document, so that there are no incompatibilities. > Why do you think that it will take more time to gain consensus > on the minimal IPv6 host requirements for a standards-based "IPv6 > host requirements" effort, than it will to reach consensus on > the minimal IPv6 host requirements for an informational "cellular > hosts" effort? Well, are we considering Minimum Host Requirements or Host Requirements or Node Requirements? We have been trying to scope our document, however, there has been no scoping of what you have been proposing. > Getting this right will take time, and I don't think that we > should publish either document until we get it right. If we > are going to undertake this effort, wouldn't you rather emerge > with a standards-based host requirements document than with an > informational cellular-specific document? I've always thought that we could do both, perhaps I am optimistic. > Yes. They will be doing it based on the IPv6 standards. > We've worked on those standards for years, subjected them to > multiple rounds of scrutiny, and they have been implemented by > many vendors. None of us would say they are perfect, but > they are the best information we have about how to build > compatible, compliant IPv6 hosts. I don't know who you have been discussing with - but most radio-heads that I know (folks who have been implementing cellular stuff) are very unfamiliar with the IETF & standards. I've gotten A LOT of feedback from many different groups based upon our draft on how the ietf works, etc. Remember, most phones do not use a POSIX type of environment, and it will be a while before your average consumer mobile host will have anything resembling a socket. Personally, I don't think that I want such a thing on my general purpose phone. > I _do_ think that we need to do an "IPv6 over link of your choice>" document. This document should include > everything that is really special about building hosts that > talk on cellular links. We have agreed that this work would be started in Salt Lake City. At least my understanding of the SLC Meeting was that our draft would become a WG document, work should be started on a general hosts document (I think I discussed with Ito-Jun and someone else about starting that at the meeting) and I think Jonne Soininen was interested in creating an "IPv6 over 3GPP" or something document. Jonne mentioned to me that the current 3GPP specs have settled enough that such a document could be started. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 08:45:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GjxKL004091 for ; Wed, 6 Mar 2002 08:45:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Gjwab004090 for ipng-dist; Wed, 6 Mar 2002 08:45:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GjsKL004083 for ; Wed, 6 Mar 2002 08:45:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01642 for ; Wed, 6 Mar 2002 08:45:55 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA25983 for ; Wed, 6 Mar 2002 08:45:54 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 150852F06; Wed, 6 Mar 2002 11:45:54 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 11:45:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Date: Wed, 6 Mar 2002 11:45:53 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B015206FA@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Thread-Index: AcHDUGP6avoOTDokQ82tu/wHEzHiSwB3ebMw From: "Bound, Jim" To: "Margaret Wasserman" , Cc: X-OriginalArrivalTime: 06 Mar 2002 16:45:54.0023 (UTC) FILETIME=[61A18F70:01C1C52E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26GjtKL004084 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, It does not contradict. It just says they don't apply in this case which is fine. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Monday, March 04, 2002 2:34 AM > To: john.loughney@nokia.com > Cc: ipng@sunroof.eng.sun.com > Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? > > > > Hi John, > > > > However, I am concerned about how outside groups (specifically > > > the 3GPP) will interpret publishing this document, even as an > > > Informational RFC. > > > >I think that we can discuss if we need to add any clarifying text > >here. It could be as simple as this document is informational > >and should not override any standards documents. Please note > >that many of the authors of the document are also involved in > >the 3GPP standardization process. > > It is possible that some sort of clarifying text could alleviate > some of my concerns. > > However, this document does seem (at least to me) to contradict > some standards-based IPv6 documents. For instance, this document > indicates that some features are optional that are listed as > mandatory in other documents (IP Security, DAD, some types of ND > processing, etc.). > > > > I do think that the WG will need to do some work on defining the > > > official contents of IPv6, including the minimal requirements for > > > IPv6 nodes (or hosts and routers), but this will probably require > > > a considerable effort, and a good deal of negotiation within the > > > WG and with the IESG. > > > >Agreed, we've been talking about this since London, and all of the > >authors have volunteered to help on this effort. I think a IPv6 > >Host Requirement document would be a very good thing. > > I mostly agree. I do have some concerns about defining the host > requirements too early, before we have enough deployment experience > with complete IPv6 implementations to make wise choices. This may > be a chicken and egg issue, though -- how will we get "complete" IPv6 > implementations before we define what that means? > > >I don't share your doubts. I believe that we need this kind of > >document, as there will be IPv6 enabled phones being produced, > >probably this year. The networks are already being deployed. > >Should we not, then try to specify & give guidence on IPv6 - or > >should we do nothing? > > I think that we should give guidance, and we have tried to do so > in other documents. However, I think that we need to be careful > not to give inconsistent or conflicting guidance. Specifically: > > - We should not publish guidance for cellular vendors > that conflicts with our published standards. > If the standards are wrong (or fail to take > into account all of the cases), we should > correct them. > - The IPv6 WG may not be the correct group to provide > guidance regarding transition mechanisms. I > believe that the v6trans (or is it still ngtrans?) > WG should be responsible for publish advice on > the applicability of their mechanisms in > different environments. > > Margaret > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 08:49:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Gn1KL004118 for ; Wed, 6 Mar 2002 08:49:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Gn13Q004117 for ipng-dist; Wed, 6 Mar 2002 08:49:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GmvKL004110 for ; Wed, 6 Mar 2002 08:48:57 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA02255 for ; Wed, 6 Mar 2002 08:48:57 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02735 for ; Wed, 6 Mar 2002 09:48:57 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 698EB588A; Wed, 6 Mar 2002 11:48:56 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 11:48:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 11:48:53 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B015206FB@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDUzawI63y4/2zRnCzH9aKLl2YiwB216UQ From: "Bound, Jim" To: "Margaret Wasserman" , "Hesham Soliman (ERA)" Cc: X-OriginalArrivalTime: 06 Mar 2002 16:48:54.0164 (UTC) FILETIME=[CD00E540:01C1C52E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26GmwKL004111 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, I think all vendors will provide option to disable DAD and take the risk. The IETF specs are not like laws where they can really be enforced. If a customer and set of vendors have a good reason to not use a MUST in a spec they will for business reasons. And there is not a thing the IETF can do about it. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Monday, March 04, 2002 2:58 AM > To: Hesham Soliman (ERA) > Cc: ipng@sunroof.eng.sun.com > Subject: Should DAD be optional? [Was > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > > Hi Hesham, > > Thanks for the quick response. > > >=> Then let's begin the discussions. The only reason > >for standardising the draft in the IPv6 WG was to make > >sure that we're doing the right thing. Otherwise an > >informational RFC wouldn't have to go through the > >IPv6 WG or could have been replaced by a 3GPP spec. > >But since the competence is here, it is crucial > >that we get feedback. > > That sounds good. Let's begin the discussions... > > I'll send separate threads for each issue. > > > > It is not my impression that the WG has reached > consensus on some > > > of the issues raised in this document, specifically: > > > > > > - Forbidding the use of DAD on some links > > > >=> DAD is not needed if address duplication is not > >possible. Since each terminal gets a unique > >/64 (as per the advice draft), and since all terminals > >are on p2p links, DAD would be a waste of BW. > >But please have a closer look and let us know > >if something was missed. > > Address duplication is possible on point-to-point links, because > one end may choose an address that is already in use by the other > end. I don't think that this is very likely, but it is possible. > > However, making DAD optional (and advising against the use of DAD) > on point-to-point links, is in direct conflict with RFC 2462, > which says: > > "Duplicate Address Detection MUST take place on all unicast > addresses, regardless of whether they are obtained through > stateful, stateless or manual configuration..." > > I don't think that we should publish an informational document that > advises some implementors to do something that specifically > disagrees with a MUST requirement in a standards-track document. > If the standards-track document is broken, we need to fix it > instead. > > [Please note that I actually think that we should be able to > disable DAD for some link types. I made a proposal to that effect > several years ago, but my arguments didn't win the day.] > > Margaret > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 08:52:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GqKKL004143 for ; Wed, 6 Mar 2002 08:52:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26GqKbJ004142 for ipng-dist; Wed, 6 Mar 2002 08:52:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GqHKL004135 for ; Wed, 6 Mar 2002 08:52:17 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01160 for ; Wed, 6 Mar 2002 08:52:17 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA15079 for ; Wed, 6 Mar 2002 08:52:16 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E211735DD; Wed, 6 Mar 2002 11:52:15 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 11:52:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 11:52:15 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B015206FC@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDVWZc/7GYlUlLS1q5yeDTIGNGHwB2XxzA From: "Bound, Jim" To: "Margaret Wasserman" , "Hesham Soliman (ERA)" Cc: X-OriginalArrivalTime: 06 Mar 2002 16:52:15.0793 (UTC) FILETIME=[452F0A10:01C1C52F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26GqHKL004136 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, What is required for a full implementation for IPv6 by the standards is set in stone. Vendors that don't adhere to this are risking to much. What they deploy and what standards is different issue. I can have IPsec (and do) in a product source pool and in the product. But I will give users the ability to disable it if they want to not take the performance hit and deal with the security risk. Not all want it in the first place when they see the cost on any system. A cellular host may or may not use all of the security. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Monday, March 04, 2002 3:17 AM > To: Hesham Soliman (ERA) > Cc: ipng@sunroof.eng.sun.com > Subject: Should IP Security be Optional? [Was RE: > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > > And the next issue, IP Security... > > > > - Situation where IP Security should be > optional/disabled > > > (and the whole distinction between > "Core IP" and > > > "IP Security") > > > >=> The distinction between IP security and core IP > >is merely an editorial distinction. For example > >you can see that in 'core IP' we list all the > >IPv6 WG RFCs. > > Publishing a document that makes this distinction, however, will give > the impression that IP Security (AKA IPSec) is not a _core_ part of > IPv6. Some people may take that to mean that they can produce a > complete IPv6 implementation that does not include IP Security. > > >As to whether IP security (I assume you mean IPsec) > >should be mandated or not, we can discuss that. > >But some questions that we would need to answer: > > > >- By 'mandated' do we mean implementation or use? > >- What should be mandated? > >- Why should it be mandated? > > RFC 2460 says: > > "A full implementation of IPv6 includes implementation of the > following extension headers: > > Hop-by-Hop Options > Routing (Type 0) > Fragment > Destination Options > Authentication > Encapsulating Security Payload > > The first four are specified in this document; the last two are > specified in [RFC-2402] and [RFC-2406], respectively." > > So, a "full" implementation of IPv6 must include an implementation > of the Authentication and ESP headers from RFCs 2402 and 2406. > > Obviously, it is possible for a host to implement RFCs 2402 and 2406, > but to be configured such that no traffic is ever authenticated and/or > encrypted. > > The draft-ietf-ipv6-cellular-host-00.txt document, however, seems to > assume that there may be hosts that do not implement these headers. > It says: > > " - AH and ESP headers: In the case of the Core IP functionality > only, AH and ESP headers are treated as if the Security > Association had not existed, i.e. - packets with > these headers > are dropped. When the IP Security functionality is > in use, they > are processed as specified in RFCs 2401, 2402, and 2406." > > I am not sure about the wording here, but this paragraph implies to > me that cellular hosts that only implement the "Core IP" functionality > may not actually implement AH or ESP processing. This conflicts > directly with RFC 2460. > > Now, I don't actually live under a rock, so I do understand that most > of today's IPv6 nodes don't actually implement IP Security. In the > past, however, the IESG had mandated that IP Security would be a > mandatory part of IPv6, and I don't believe that they've changed that > statement. > > So, where do we go from here? > > No document can be published as an RFC without IESG approval, > and I don't > think that we'll get IESG approval for a document that says (or even > strongly implies) that IP Security is optional in IPv6. Maybe our > ADs could comment on this? > > Margaret > > > > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 08:54:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GsXKL004160 for ; Wed, 6 Mar 2002 08:54:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26GsXoC004159 for ipng-dist; Wed, 6 Mar 2002 08:54:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GsTKL004152 for ; Wed, 6 Mar 2002 08:54:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01849 for ; Wed, 6 Mar 2002 08:54:30 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06214 for ; Wed, 6 Mar 2002 09:54:28 -0700 (MST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26GscZ00729 for ; Wed, 6 Mar 2002 18:54:38 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 18:54:25 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 18:54:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 18:54:26 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B4D@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDUzawI63y4/2zRnCzH9aKLl2YiwB216UQAAApHwA= To: , , Cc: X-OriginalArrivalTime: 06 Mar 2002 16:54:27.0294 (UTC) FILETIME=[93907FE0:01C1C52F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26GsUKL004153 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, > I think all vendors will provide option to disable DAD and take the > risk. > > The IETF specs are not like laws where they can really be > enforced. If a customer and set of vendors have a good reason to > not use a MUST in a spec they will for business reasons. And there > is not a thing the IETF can do about it. Actually, I think what we (the IETF) should do about it is create specifications which explain what the reason for the specification is used for, and under what circumstances optimizations may be useful. This is actually what one of intentions has been for the Cellular Hosts document. In discussing RFCs with non-IETF folks, some of the requirements in RFCs can seem to be rather arbitrary. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 08:54:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GsnKL004170 for ; Wed, 6 Mar 2002 08:54:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26GsnPd004169 for ipng-dist; Wed, 6 Mar 2002 08:54:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GsiKL004162 for ; Wed, 6 Mar 2002 08:54:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14744 for ; Wed, 6 Mar 2002 08:54:45 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00021 for ; Wed, 6 Mar 2002 08:54:44 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id C98543638; Wed, 6 Mar 2002 11:54:43 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 11:54:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 11:54:43 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B015206FD@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDVud3GbtxGQ/USiisj9JHLSvxxwB2HY7Q From: "Bound, Jim" To: "Margaret Wasserman" , "Hesham Soliman (ERA)" Cc: X-OriginalArrivalTime: 06 Mar 2002 16:54:43.0820 (UTC) FILETIME=[9D6A2AC0:01C1C52F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26GsjKL004163 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, One clarification John made is that IPv6 is only for part of the 3G system thus far. Maybe the title should be changed to reflect 3GGP Release 4 or 5 (authors?) It will be used if stateless addr conf is used for sure. So I think the issue is moot. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Monday, March 04, 2002 3:24 AM > To: Hesham Soliman (ERA) > Cc: ipng@sunroof.eng.sun.com > Subject: Making ND Optional [Was RE: > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > > And another issue: > > > > > - Making ND optional on point-to-point links > > > >=> RFC 2461 MUST be implemented, the exceptions are > >things like the Link layer suboption which is not > >relevant for these links. Did we miss something else? > > The cellular hosts document says: > > "Therefore, Neighbor Solicitation and Advertisement messages MAY > be implemented for the cellular interface." > > However, these messages are mandatory in RFCs 2461 and 2462, both > for DAD and for the basic neighbor discovery mechanism, which needs > to be used to establish two-way connectivity before other messages > are exchanged. > > Margaret > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 08:59:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GxfKL004203 for ; Wed, 6 Mar 2002 08:59:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26GxfVb004202 for ipng-dist; Wed, 6 Mar 2002 08:59:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26GxcKL004195 for ; Wed, 6 Mar 2002 08:59:38 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA15796 for ; Wed, 6 Mar 2002 08:59:38 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18579 for ; Wed, 6 Mar 2002 08:59:37 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id A23E335A7; Wed, 6 Mar 2002 11:59:36 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 11:59:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 11:59:36 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B015206FE@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDVue5djzljp4hS86f2GbhDEZ6bQB2MWsA From: "Bound, Jim" To: "Margaret Wasserman" , "Hesham Soliman (ERA)" Cc: , X-OriginalArrivalTime: 06 Mar 2002 16:59:36.0602 (UTC) FILETIME=[4BED27A0:01C1C530] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26GxcKL004196 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Magaret, We can't mandate stateless or anything for early implementation deployment for 3G handsets its too much work. I predict the winners will have path to 2462 but the first step is make IPv6 work in the IMN system. To do that MAY is being used by the authors. MAY in this context is not the same MAY we use for a spec like 2462. The objective is to get this as guideline to 3G and its fine. I think your giving to much weight to the standard for real deployment for handsets that are mostly not going to be e2e IPv6 for UMTS anyway. Again for the 802.11 deployment that won't work. And based on this conversation I will make sure they don't come here if I can to discuss their IPv6 deployment requirements we will just ship the product and deploy. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Monday, March 04, 2002 3:28 AM > To: Hesham Soliman (ERA) > Cc: juha.wiljakka@nokia.com; ipng@sunroof.eng.sun.com > Subject: Making Autoconfig Optional [Was RE: > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > > And the last issue that I raised in my message: > > > > - Making IPv6 autoconfiguration optional on > hosts (rather > > > than mandatory on hosts and turned > on/off for the > > > link in router advertisements) > > > >=> You mean 2462 shoud be a SHOULD/MUST? > >That's possible for the generic cellular case, but for 3GPP, > >since there is a separate 'autoconfig' mechanism, > >this RFC is not needed. Would a SHOULD/MUST for the > >general case, and a 'not needed' for 3GPP > >be satisfactory? > > My understanding is that the 3GPP group is actually migrating towards > a more standard IPv6 configuration mechanism, using router > advertisements > and allowing hosts to generate their own interface IDs. > > Currently the cellular hosts draft says: > > "IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be > supported." > > However, I think that RFC 2462 should be a MUST for all IPv6 nodes. > > There are probably other technical issues in the current draft that > should be discussed, I've just listed what I consider to be the most > pressing issues. > > Margaret > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:01:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26H15KL004220 for ; Wed, 6 Mar 2002 09:01:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26H15YK004219 for ipng-dist; Wed, 6 Mar 2002 09:01:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26H11KL004212 for ; Wed, 6 Mar 2002 09:01:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA06010 for ; Wed, 6 Mar 2002 09:01:02 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29103 for ; Wed, 6 Mar 2002 10:01:01 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 8335D3473; Wed, 6 Mar 2002 12:01:00 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:01:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 12:01:00 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B015206FF@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDWdOZdcxPBiGsSz27jDVHasnHkgB1omOw From: "Bound, Jim" To: "Pekka Savola" , "Margaret Wasserman" Cc: "Hesham Soliman (ERA)" , X-OriginalArrivalTime: 06 Mar 2002 17:01:00.0492 (UTC) FILETIME=[7DEDC0C0:01C1C530] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26H12KL004213 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, DAD works and should be mandated in our specs and is. Its done. But your free to ship products however you choose. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Monday, March 04, 2002 3:46 AM > To: Margaret Wasserman > Cc: Hesham Soliman (ERA); ipng@sunroof.eng.sun.com > Subject: Re: Should DAD be optional? [Was > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > On Mon, 4 Mar 2002, Margaret Wasserman wrote: > > However, making DAD optional (and advising against the use of DAD) > > on point-to-point links, is in direct conflict with RFC 2462, > > which says: > > > > "Duplicate Address Detection MUST take place on all unicast > > addresses, regardless of whether they are obtained through > > stateful, stateless or manual configuration..." > > > > I don't think that we should publish an informational document that > > advises some implementors to do something that specifically > > disagrees with a MUST requirement in a standards-track document. > > If the standards-track document is broken, we need to fix it > > instead. > > > > [Please note that I actually think that we should be able to > > disable DAD for some link types. I made a proposal to that effect > > several years ago, but my arguments didn't win the day.] > > I think DAD should be disableable for default for: > - addresses generated randomly > - addresses that are generated from e.g. EUI64 (this might > be more prone > to errors, e.g. manufacturing or "stupid" multi-port NIC's > where every > port has the same MAC address) > > Most definitely not: > - manually configured addresses > > Because DAD is not a perfect (or even nearly so) solution anyway. > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:02:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26H2NKL004239 for ; Wed, 6 Mar 2002 09:02:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26H2NI9004238 for ipng-dist; Wed, 6 Mar 2002 09:02:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26H2JKL004231 for ; Wed, 6 Mar 2002 09:02:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16620 for ; Wed, 6 Mar 2002 09:02:19 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29885 for ; Wed, 6 Mar 2002 10:02:18 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id F3DAF3758; Wed, 6 Mar 2002 12:02:16 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:02:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 12:02:16 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520700@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDX+/3HytAyOgfQBmxqFGLdTV+VQB0J8zg From: "Bound, Jim" To: "Francis Dupont" , "Margaret Wasserman" Cc: "Hesham Soliman (ERA)" , X-OriginalArrivalTime: 06 Mar 2002 17:02:16.0945 (UTC) FILETIME=[AB7F8E10:01C1C530] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26H2KKL004232 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk DAD already has rough consensus and running code? What are you talking about? This is a bit more than a research issue now IPv6 products are shipping. /jim > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Monday, March 04, 2002 4:28 AM > To: Margaret Wasserman > Cc: Hesham Soliman (ERA); ipng@sunroof.eng.sun.com > Subject: Re: Should DAD be optional? [Was > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > In your previous mail you wrote: > > > > It is not my impression that the WG has reached > consensus on some > > > of the issues raised in this document, specifically: > > > > > > - Forbidding the use of DAD on some links > > > >=> DAD is not needed if address duplication is not > >possible. Since each terminal gets a unique > >/64 (as per the advice draft), and since all terminals > >are on p2p links, DAD would be a waste of BW. > >But please have a closer look and let us know > >if something was missed. > > Address duplication is possible on point-to-point links, because > one end may choose an address that is already in use by the other > end. I don't think that this is very likely, but it is possible. > > => I disagree for addresses using the explicitely negociated > interface IDs with in the first position the link-local addresses. > > However, making DAD optional (and advising against the use of DAD) > on point-to-point links, is in direct conflict with RFC 2462, > which says: > > "Duplicate Address Detection MUST take place on all unicast > addresses, regardless of whether they are obtained through > stateful, stateless or manual configuration..." > > => the point-to-point link is one case DAD is overkilling. > But as too many persons want to make DAD optional I agree > we have to be carefull. For instance we should ask that > all DAD stuff must get rough consensus in the IPv6 WG. > Another point is who makes the choice to avoid the DAD check: > my opinion is this must be the "link manager" (i.e. the manager > of the network where is the link). > > I don't think that we should publish an informational > document that > advises some implementors to do something that specifically > disagrees with a MUST requirement in a standards-track document. > If the standards-track document is broken, we need to fix it > instead. > > => I agree we have a procedural case at least. > > [Please note that I actually think that we should be able to > disable DAD for some link types. I made a proposal to that effect > several years ago, but my arguments didn't win the day.] > > => so basically we agree! > > Thanks > > Francis.Dupont@enst-bretagne.fr > > PS: DAD is not a toy, at least one time I saw it saved us > from a disaster. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:03:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26H3fKL004262 for ; Wed, 6 Mar 2002 09:03:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26H3fcV004261 for ipng-dist; Wed, 6 Mar 2002 09:03:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26H3bKL004254 for ; Wed, 6 Mar 2002 09:03:37 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05835 for ; Wed, 6 Mar 2002 09:03:37 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA00717 for ; Wed, 6 Mar 2002 10:03:37 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 160145BC4; Wed, 6 Mar 2002 12:03:36 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:03:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 12:03:35 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520701@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDYVKu05OPihTvRoC4iY4brCyTSgBz2Q7w From: "Bound, Jim" To: "Francis Dupont" , "Margaret Wasserman" Cc: "Hesham Soliman (ERA)" , X-OriginalArrivalTime: 06 Mar 2002 17:03:35.0976 (UTC) FILETIME=[DA9ABA80:01C1C530] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26H3bKL004255 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree security is important and IPsec is good. But the market and vendors will ship and use what they want. And many will not use Ipsec in handsets for sure. /jim > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Monday, March 04, 2002 4:40 AM > To: Margaret Wasserman > Cc: Hesham Soliman (ERA); ipng@sunroof.eng.sun.com > Subject: Re: Should IP Security be Optional? [Was RE: > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > I agree with you and Hesham: IPsec is required for any compliant > IPv6 implementations and we should not accept an exemption for > a device which can get a global address in the Internet. > BTW the complexity argument is not very sound because IPsec > with IKE is already available on PalmPilot and PSions (cf ipsec > wg mailing list). > Security should not be a compromise! > > Thanks > > Francis.Dupont@enst-bretagne.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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 09:07:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26H7KKL004298 for ; Wed, 6 Mar 2002 09:07:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26H7KgU004297 for ipng-dist; Wed, 6 Mar 2002 09:07:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26H7HKL004290 for ; Wed, 6 Mar 2002 09:07:17 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18223 for ; Wed, 6 Mar 2002 09:07:17 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23051 for ; Wed, 6 Mar 2002 09:07:16 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 893A65A85; Wed, 6 Mar 2002 12:07:15 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:07:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 12:07:14 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520702@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDYzXuvspGH+xmSEyz0rKLbNKu+wBzenHQ From: "Bound, Jim" To: "Tim Chown" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 06 Mar 2002 17:07:15.0195 (UTC) FILETIME=[5D44E4B0:01C1C531] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26H7HKL004291 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This has been the long and standing case as Tim found all the way back to the IPng Directorate. Simply because the IETF cannot mandate use. This doc is recommending use not adherence to the standard. I suggest maybe to wrap this up in the doc in front of all sections with MAY, SHOULD, or MUST put "use". /jim > -----Original Message----- > From: Tim Chown [mailto:tjc@ecs.soton.ac.uk] > Sent: Monday, March 04, 2002 4:57 AM > To: Margaret Wasserman > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Should IP Security be Optional? [Was RE: > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > > Margaret, > > Another important reference is in RFC2401, "Security Architecture for > the Internet Protocol" > > 10. Conformance Requirements > > All IPv4 systems that claim to implement IPsec MUST comply with all > requirements of the Security Architecture document. All > IPv6 systems > MUST comply with all requirements of the Security Architecture > document. > > There was a thread along these lines a few months back, the conclusion > of which was that full implementations of IPv6 must implement > IPsec, but > that use of IPsec was not mandatory. So the cellular hosts > document may > choose to distinguish between implementation and use also. > > Tim > > On Mon, 4 Mar 2002, Margaret Wasserman wrote: > > > > > And the next issue, IP Security... > > > > > > - Situation where IP Security should be > optional/disabled > > > > (and the whole distinction between > "Core IP" and > > > > "IP Security") > > > > > >=> The distinction between IP security and core IP > > >is merely an editorial distinction. For example > > >you can see that in 'core IP' we list all the > > >IPv6 WG RFCs. > > > > Publishing a document that makes this distinction, however, > will give > > the impression that IP Security (AKA IPSec) is not a _core_ part of > > IPv6. Some people may take that to mean that they can produce a > > complete IPv6 implementation that does not include IP Security. > > > > >As to whether IP security (I assume you mean IPsec) > > >should be mandated or not, we can discuss that. > > >But some questions that we would need to answer: > > > > > >- By 'mandated' do we mean implementation or use? > > >- What should be mandated? > > >- Why should it be mandated? > > > > RFC 2460 says: > > > > "A full implementation of IPv6 includes implementation of the > > following extension headers: > > > > Hop-by-Hop Options > > Routing (Type 0) > > Fragment > > Destination Options > > Authentication > > Encapsulating Security Payload > > > > The first four are specified in this document; the last two are > > specified in [RFC-2402] and [RFC-2406], respectively." > > > > So, a "full" implementation of IPv6 must include an implementation > > of the Authentication and ESP headers from RFCs 2402 and 2406. > > > > Obviously, it is possible for a host to implement RFCs 2402 > and 2406, > > but to be configured such that no traffic is ever > authenticated and/or > > encrypted. > > > > The draft-ietf-ipv6-cellular-host-00.txt document, however, > seems to > > assume that there may be hosts that do not implement these headers. > > It says: > > > > " - AH and ESP headers: In the case of the Core IP functionality > > only, AH and ESP headers are treated as if the Security > > Association had not existed, i.e. - packets with > these headers > > are dropped. When the IP Security functionality is > in use, they > > are processed as specified in RFCs 2401, 2402, and 2406." > > > > I am not sure about the wording here, but this paragraph implies to > > me that cellular hosts that only implement the "Core IP" > functionality > > may not actually implement AH or ESP processing. This conflicts > > directly with RFC 2460. > > > > Now, I don't actually live under a rock, so I do understand > that most > > of today's IPv6 nodes don't actually implement IP Security. In the > > past, however, the IESG had mandated that IP Security would be a > > mandatory part of IPv6, and I don't believe that they've > changed that > > statement. > > > > So, where do we go from here? > > > > No document can be published as an RFC without IESG > approval, and I don't > > think that we'll get IESG approval for a document that says (or even > > strongly implies) that IP Security is optional in IPv6. Maybe our > > ADs could comment on this? > > > > Margaret > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 09:09:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26H95KL004315 for ; Wed, 6 Mar 2002 09:09:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26H95Op004314 for ipng-dist; Wed, 6 Mar 2002 09:09:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26H92KL004307 for ; Wed, 6 Mar 2002 09:09:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08812 for ; Wed, 6 Mar 2002 09:09:02 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04094 for ; Wed, 6 Mar 2002 10:09:02 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 7EBD02EC7; Wed, 6 Mar 2002 12:09:01 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:09:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 12:09:01 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520703@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDY8J7uub3T8pQRGODPOaglkRgZABzaLYQ From: "Bound, Jim" To: "Francis Dupont" , "Pekka Savola" Cc: "Margaret Wasserman" , "Hesham Soliman (ERA)" , X-OriginalArrivalTime: 06 Mar 2002 17:09:01.0349 (UTC) FILETIME=[9C8AB550:01C1C531] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26H92KL004308 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, I object strongly to your assumption we should change RFC 2462. You have presented no operational problem or spec or protocol problem. If you don't think its "useful" thats fine, don't use it. /jim > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Monday, March 04, 2002 5:00 AM > To: Pekka Savola > Cc: Margaret Wasserman; Hesham Soliman (ERA); ipng@sunroof.eng.sun.com > Subject: Re: Should DAD be optional? [Was > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > In your previous mail you wrote: > > I think DAD should be disableable for default for: > - addresses generated randomly > > => I *strongly* disagree: even if the probability is small it > is not zero. > > - addresses that are generated from e.g. EUI64 (this > might be more prone > to errors, e.g. manufacturing or "stupid" multi-port NIC's > where every > port has the same MAC address) > > => I agree: if two boxes have the same hardware number the address > collision is no more than a detail. > > Most definitely not: > - manually configured addresses > > => agree > > Because DAD is not a perfect (or even nearly so) solution anyway. > > => DAD is not perfect but only the network manager should take the > decision to forget DAD in such or such situations. Of course this > implies the "DAD avoidance" is negociated by the link-layer before > (so PPP again is a good candidate for optional DAD). > > Regards > > Francis.Dupont@enst-bretagne.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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 09:12:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HCcKL004338 for ; Wed, 6 Mar 2002 09:12:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HCb0c004337 for ipng-dist; Wed, 6 Mar 2002 09:12:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HCYKL004330 for ; Wed, 6 Mar 2002 09:12:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA19714 for ; Wed, 6 Mar 2002 09:12:35 -0800 (PST) Received: from megisto-sql1.megisto.com ([63.113.114.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22650 for ; Wed, 6 Mar 2002 10:12:33 -0700 (MST) Received: by MEGISTO-SQL1 with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Mar 2002 12:05:34 -0500 Message-ID: From: Phil Roberts To: "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 12:05:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >That could be one way forward. What would the downside to this be? > > I've tried to explain this in other messages, but I don't > think that my reasons are coming across... > > If we publish this document as "informational" now, I think we > all agree that the 3GPP community will treat this as a > standard and implement to it. > > This raises one serious, immediate problem. This document > contradicts things in IPv6 standards track documents. As a > result, we may end up with two subtly incompatible "camps" of > IPv6 nodes (cellular nodes and non-cellular nodes). > > Since we know that this document will be treated as a > standard, giving it a cursory review and hurrying to publish > it as an "informational" document is irresponsible. I hear you and agree with you that this is a valid concern. > Getting this right will take time, and I don't think that we > should publish either document until we get it right. If we > are going to undertake this effort, wouldn't you rather emerge > with a standards-based host requirements document than with an > informational cellular-specific document? Also agree. > > >In the meantime, some companies will be putting > >out more than a few IPv6 capable phones / PDAs / etc without clear > >guidence. This is what I worry about. > > Yes. They will be doing it based on the IPv6 standards. > We've worked on those standards for years, subjected them to > multiple rounds of scrutiny, and they have been implemented by > many vendors. None of us would say they are perfect, but > they are the best information we have about how to build > compatible, compliant IPv6 hosts. Which raises a question - if all these vendors are capable of building interoperable hosts and routers, what is the big concern about the cellular handset vendors - other than the subtle and specific differences of communicating over specifically the 3gpp defined interfaces? The danger seems not that they will implement too much, but that they will implement too little. The doc seems to want to give permission to skip required v6 features which is not something this WG should bless. > > I _do_ think that we need to do an "IPv6 over cellular link of your choice>" document. This document > should include > everything that is really special about building hosts that > talk on cellular links. > > One question: Are there enough differences between different > cellular link types that we will need more than one of these > documents? Or is there, effectively, a single type of > cellular link, from an IPv6 perspective? One big difference between the 3gpp architecture and the 3gpp2 architecture is that 3gpp2 uses Mobile IP for all mobility management and 3gpp uses it for nothing really (although one could do internetwork mobility with a second interface). 3gpp2 is not that far down the IP v6 path yet, I believe, to be able to say much of significance about specific concerns they may have. At least that is my perception, perhaps someone involved with that effort could clarify. Phil Phil > > Margaret > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:14:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HE8KL004355 for ; Wed, 6 Mar 2002 09:14:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HE8Pj004354 for ipng-dist; Wed, 6 Mar 2002 09:14:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HE4KL004347 for ; Wed, 6 Mar 2002 09:14:04 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10065 for ; Wed, 6 Mar 2002 09:14:04 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA26566 for ; Wed, 6 Mar 2002 09:14:03 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id AF7C62C4F; Wed, 6 Mar 2002 12:14:02 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:14:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should IP Security be Optional? [Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 12:14:02 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520704@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional? [Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] Thread-Index: AcHDZsO/Q9Wm1yXaSJ6mpvwFvD2COQByuf2A From: "Bound, Jim" To: , , Cc: , X-OriginalArrivalTime: 06 Mar 2002 17:14:02.0550 (UTC) FILETIME=[50125560:01C1C532] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HE5KL004348 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Matt, Thats what we try to do as vendors with many many different horizontal customer needs. I have already had customers tell me they want to turn off DAD, IPsec, and not permitting RAs to send Lifetime of Zero in RFC 2462 and they don't care or are worried about Privacy RFC 3041. Its their choice, their risk, and their money paying for the implementation. Other customers will say make it so a user can't turn off IPsec EVER. That will be supported too. Its all about choice in the market. Yes we have a tough job but these customers keep product software engineers employed. Sometimes in the IETF folks get over excited and think they can tell the market what to do and what and when to do stuff with our specs. Thats an illusion and I am sure frustrating to some who are on some kind of social mission. But I don't feel sorry for them :-----) /jim > -----Original Message----- > From: matthew.ford@bt.com [mailto:matthew.ford@bt.com] > Sent: Monday, March 04, 2002 5:21 AM > To: Jari.Arkko@lmf.ericsson.se; mrw@windriver.com > Cc: hesham.soliman@era.ericsson.se; ipng@sunroof.eng.sun.com > Subject: RE: Should IP Security be Optional? [Was > RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] > > > > Therefore we feel that on size- and power-constrained > > devices one should select the implemented security > > mechanisms based on the requirements of the applications > > rather than a general rule. The general rules aren't > > very good if in the end the application RFC you were running > > would demand something else than the general rule, or if > > the deployment at the other end was something else. > > This seems to presume that you can predict in advance all of the > applications that a user will wish to execute on a particular > node. Can you > do that? > > Also, please note well that the 'deployment at the other end' won't be > 'something else' if we get IPsec in every IPv6 node. I > thought that was the > whole point.... > > Regards, > Mat. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:15:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HFtKL004372 for ; Wed, 6 Mar 2002 09:15:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HFsNv004371 for ipng-dist; Wed, 6 Mar 2002 09:15:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HFoKL004364 for ; Wed, 6 Mar 2002 09:15:51 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08980 for ; Wed, 6 Mar 2002 09:15:40 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA25376 for ; Wed, 6 Mar 2002 10:15:33 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 250675AED; Wed, 6 Mar 2002 12:15:09 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:15:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 12:15:08 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520705@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] Thread-Index: AcHDaJMrfajbJxsUQSGO3psdkVinJABydNEg From: "Bound, Jim" To: "Jari Arkko" , Cc: , , X-OriginalArrivalTime: 06 Mar 2002 17:15:08.0992 (UTC) FILETIME=[77AC9400:01C1C532] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HFpKL004365 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, yes you can on all nodes if you write the code. /jim > -----Original Message----- > From: Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se] > Sent: Monday, March 04, 2002 5:32 AM > To: matthew.ford@bt.com > Cc: mrw@windriver.com; hesham.soliman@era.ericsson.se; > ipng@sunroof.eng.sun.com > Subject: Re: Should IP Security be Optional?[Was > RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] > > > matthew.ford@bt.com wrote: > > > This seems to presume that you can predict in advance all of the > > applications that a user will wish to execute on a > particular node. Can you > > do that? > > On a workstation you can't. On a tiny cellular device you > often can. > > > Also, please note well that the 'deployment at the other > end' won't be > > 'something else' if we get IPsec in every IPv6 node. I > thought that was the > > whole point.... > > Well, the other end could still require TLS if the RFC-for-app-X > required that. Regardless of what other RFC states something about > security at IP layer... > > Jari > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:16:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HG5KL004382 for ; Wed, 6 Mar 2002 09:16:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HG5eV004381 for ipng-dist; Wed, 6 Mar 2002 09:16:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HG1KL004374 for ; Wed, 6 Mar 2002 09:16:02 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20767 for ; Wed, 6 Mar 2002 09:16:02 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08174 for ; Wed, 6 Mar 2002 10:16:01 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 20BAB57F2; Wed, 6 Mar 2002 12:16:01 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:16:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 12:16:00 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520706@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] Thread-Index: AcHDaMZF+RUt0AqhRMq8PtzyrGEaKQBybwNQ From: "Bound, Jim" To: "Karim El-Malki (ERA)" , "Francis Dupont" Cc: "Margaret Wasserman" , "Hesham Soliman (ERA)" , , X-OriginalArrivalTime: 06 Mar 2002 17:16:01.0003 (UTC) FILETIME=[96ACD3B0:01C1C532] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HG2KL004375 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Agree. But they need not "use" ...is better than "do". /jim > -----Original Message----- > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: Monday, March 04, 2002 5:34 AM > To: 'Francis Dupont' > Cc: 'Margaret Wasserman'; Hesham Soliman (ERA); > juha.wiljakka@nokia.com; > ipng@sunroof.eng.sun.com > Subject: RE: Making Autoconfig Optional [Was RE: > draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] > > > > A way to solve your DAD/autoconf issue is to "delegate" the > > /64 prefix > > and to keep only link-local addresses using link-layer negociated > > interface IDs (negociation is very simple and just checks > > the interface > > IDs of the both ends are different). The link has to be > > point-to-point > > but this is the only constraint (you can even use PPP if > you'd like). > > That's exactly what we've pointed to in the 3gpp-advice draft and > this is what 3GPP is following. Currently PPP is used. So I think we > agree that 3gpp hosts need not do DAD, which explains the cellular > hosts requirement. > > /Karim > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:17:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HHxKL004420 for ; Wed, 6 Mar 2002 09:17:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HHwm5004419 for ipng-dist; Wed, 6 Mar 2002 09:17:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HHpKL004412 for ; Wed, 6 Mar 2002 09:17:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA09682 for ; Wed, 6 Mar 2002 09:17:51 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20729 for ; Wed, 6 Mar 2002 10:17:50 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1B3B13503; Wed, 6 Mar 2002 12:17:50 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:17:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 12:17:49 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520707@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDVUv/4/6kSjBJQH2Sa+80ZFq3vQAE+ANgAHJcuGA= From: "Bound, Jim" To: , , Cc: X-OriginalArrivalTime: 06 Mar 2002 17:17:50.0086 (UTC) FILETIME=[D7B19260:01C1C532] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HHpKL004413 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, Basic is better yes. A few of us started using core to describe the first set of Ipv6 specs to implement. That was fine. Base or Basic is better but an even better term is needed as we may add base functions as we do in IPv4 this summer or next year. So at least say "current" base. regards, /jim > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Monday, March 04, 2002 5:47 AM > To: mrw@windriver.com; hesham.soliman@era.ericsson.se > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Should IP Security be Optional? [Was RE: > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > Hi Margaret, > > > > Publishing a document that makes this distinction, however, > will give > > the impression that IP Security (AKA IPSec) is not a _core_ part of > > IPv6. Some people may take that to mean that they can produce a > > complete IPv6 implementation that does not include IP Security. > > Perhaps 'core' is not correct - would 'basic' be a better term, > or will that cause confusion? The section on Security attempts > to inject some reality into the security discussion. For the > last several years, the Security Area ADs have said that IPsec > is not a magic bullet (i.e. - having a standard that just says - > All security can be provided by IPsec) is not sufficient. MIPv6 > had tried to use IPsec to protect BUs, that has been found to be > insufficient. There are concerns about IKE scalability, lack of > PKI, etc. Of course, we should have a discussion on what is > applicable, > what is useful, and what is manditory. I think we should avoid > stating that because RFC xyz says so, it is so. > > I think that Jari has addressed this issue better than I, though ... > > John > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:19:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HJWKL004443 for ; Wed, 6 Mar 2002 09:19:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HJVul004442 for ipng-dist; Wed, 6 Mar 2002 09:19:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HJSKL004435 for ; Wed, 6 Mar 2002 09:19:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21701 for ; Wed, 6 Mar 2002 09:19:28 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10384 for ; Wed, 6 Mar 2002 10:19:28 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 77ED4595D; Wed, 6 Mar 2002 12:19:27 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:19:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 12:19:26 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520708@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] Thread-Index: AcHDbFqFNGLZdXRJSWykFxXuZ6UjUQBxp2LA From: "Bound, Jim" To: "Francis Dupont" , "Karim El-Malki (ERA)" Cc: "Margaret Wasserman" , "Hesham Soliman (ERA)" , , X-OriginalArrivalTime: 06 Mar 2002 17:19:27.0173 (UTC) FILETIME=[118FDF50:01C1C533] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HJTKL004436 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, This is just an addendum to and for DAD. It does not alter 2462 which we should not do at this point for product and deployment reasons. /jim > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Monday, March 04, 2002 5:58 AM > To: Karim El-Malki (ERA) > Cc: 'Margaret Wasserman'; Hesham Soliman (ERA); > juha.wiljakka@nokia.com; > ipng@sunroof.eng.sun.com > Subject: Re: Making Autoconfig Optional [Was RE: > draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] > > > In your previous mail you wrote: > > > A way to solve your DAD/autoconf issue is to "delegate" the > > /64 prefix > > and to keep only link-local addresses using link-layer > negociated > > interface IDs (negociation is very simple and just checks > > the interface > > IDs of the both ends are different). The link has to be > > point-to-point > > but this is the only constraint (you can even use PPP > if you'd like). > > That's exactly what we've pointed to in the 3gpp-advice draft and > this is what 3GPP is following. Currently PPP is used. So > I think we > agree that 3gpp hosts need not do DAD, which explains the cellular > hosts requirement. > > => so we agree. The only problem is we have to find a way to explain > that in a standard track document and to get rough consensus not only > for the idea but also for the way to specify it. I don't know > if the agenda is already closed (it should not): does someone ask > for a short slot in the next meeting agenda? > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: I'd like to get this (DAD considerations) for PPP in general. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:21:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HLDKL004466 for ; Wed, 6 Mar 2002 09:21:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HLDid004465 for ipng-dist; Wed, 6 Mar 2002 09:21:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HLAKL004458 for ; Wed, 6 Mar 2002 09:21:10 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22379 for ; Wed, 6 Mar 2002 09:21:10 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00244 for ; Wed, 6 Mar 2002 09:21:09 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id E6BF72EAE; Wed, 6 Mar 2002 12:21:08 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:21:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 12:21:08 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520709@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDbo6s1/Cy45w1Q/uHuJayRbrLlABxJMZw From: "Bound, Jim" To: "Francis Dupont" , "Jari Arkko" Cc: "Margaret Wasserman" , "Hesham Soliman (ERA)" , X-OriginalArrivalTime: 06 Mar 2002 17:21:08.0820 (UTC) FILETIME=[4E25F940:01C1C533] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HLAKL004459 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It will take us years to secure all that we have to. IPsec has been mandated since 1996 at least. Yet is was the last IPv6 spec in products and I think compaq and ibm are the only vendors with product ipsec for ipv6. /jim > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Monday, March 04, 2002 6:14 AM > To: Jari Arkko > Cc: Margaret Wasserman; Hesham Soliman (ERA); ipng@sunroof.eng.sun.com > Subject: Re: Should IP Security be Optional? [Was RE: > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > In your previous mail you wrote: > > But we should avoid adding other mechanisms that we do not need. > > => we need IPsec and we need even other mechanisms because IPsec > is not all the security. For instance for mails between humans > we need PGP or S/MIME too. > > > Security should not be a compromise! > > Please note that I do NOT want to say that we shouldn't > use IPsec. Rather, you could say that I'd like to get > a more appropriate applicability statement for it than > we currently have. > > => there is an IAB statement about security. IPsec support was > made mandatory according to this statement and IMHO this was > a big step forward. There are other security mechanisms, > including some at the transport layer (SSL/TLS, IMHO IPsec > is better but real world considerations have to be considered :-) > and some at the application layer, with in some cases a very > different usage (PGP). > I have in favor of to make all core security mechanisms mandatory > (MUST or strong SHOULD), cf RFC 2316 section 10. IPsec is only > the first in the list. > > For instance, the recommendations we have > in some base IPv6 RFCs on the use of IPsec for ICMP protection > are at least misleading -- and this is from personal > experience on actually trying to do that. Have you tried > it? > > => yes, ICMP is hard to protect and to use it for small services > does not make things simpler... > > Regards > > Francis.Dupont@enst-bretagne.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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 09:21:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HLjKL004483 for ; Wed, 6 Mar 2002 09:21:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HLjL6004482 for ipng-dist; Wed, 6 Mar 2002 09:21:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HLQKL004468 for ; Wed, 6 Mar 2002 09:21:27 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22553 for ; Wed, 6 Mar 2002 09:21:27 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA11632 for ; Wed, 6 Mar 2002 10:21:26 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA11174; Wed, 6 Mar 2002 09:21:26 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g26HLPG17143; Wed, 6 Mar 2002 09:21:25 -0800 X-mProtect:  Wed, 6 Mar 2002 09:21:25 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpda4c9xg; Wed, 06 Mar 2002 09:21:22 PST Message-ID: <3C865013.6FEC84C9@iprg.nokia.com> Date: Wed, 06 Mar 2002 09:21:23 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman CC: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? References: <4.2.2.20020306103447.01c8e1f0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Margaret, Margaret Wasserman wrote: > I've tried to explain this in other messages, but I don't > think that my reasons are coming across... > > If we publish this document as "informational" now, I think we > all agree that the 3GPP community will treat this as a standard and > implement to it. I got that part of your message, and I think the problem is able to be avoided. Maybe we should not have process discussions here, but generally I feel that if we can't use the Informational RFC mechanism as it was intended to be used, then something is wrong. > This raises one serious, immediate problem. This document > contradicts things in IPv6 standards track documents. As a > result, we may end up with two subtly incompatible "camps" of > IPv6 nodes (cellular nodes and non-cellular nodes). Then a good idea would be to make sure that the Informational document does NOT contradict IPv6 standards track documents. In my previous notes, I suggested some language that would be useful to ensure that result, partially motivated by work done elsewhere in the IETF. > Since we know that this document will be treated as a standard, > giving it a cursory review and hurrying to publish it as an > "informational" document is irresponsible. But on the other hand we can easily imagine giving the document thorough review and making responsible decisions about what belongs in it. > Why do you think that it will take more time to gain consensus > on the minimal IPv6 host requirements for a standards-based "IPv6 > host requirements" effort, than it will to reach consensus on > the minimal IPv6 host requirements for an informational "cellular > hosts" effort? Then the Informational document should not be labeled "minimal". Maybe IPv6-over-3GPP-PDP is the right name. The reason that it can be done faster, is because the discussion can be more focussed. I agree with you, that such a document should not contain language contradicting the Draft Standard documents. Right now, I don't know any reason that would force this result. > Either way, we need to reach consensus on the minimal set of > specifications and features that comprise IPv6, right? Determining what is "minimal" will take longer than determining what is useful for 3GPP-over-PDP. > Getting this right will take time, and I don't think that we > should publish either document until we get it right. Agreed -- but the time requirement for the focussed document can be a lot shorter than a general document. And, a lot of work has already gone into it. > If we > are going to undertake this effort, wouldn't you rather emerge > with a standards-based host requirements document than with an > informational cellular-specific document? All else being equal, yes. But, not all things are equal here. > Or are you suggesting that we should publish a "cellular host > requirements" draft without going through the effort to get > full consensus on the actual minimal requirements for IPv6 > hosts? How would that work, and still avoid the "two camps" > concern that I raised above? That would be my suggestion. It could work, because the Informational document would not be interpreted as an broadly applicable "minimal" draft. In fact, by definition the "minimal" draft should have _fewer_ features than the IPv6-over-3GPP-PDP draft. I think this is able to be accomplished by (i) not contradicting IPv6 standards, and (ii) focussing exactly on what PDP needs. I am not a crusader, nor even proponent, for PDP, since I think that was designed without much attention given to connectionless traffic. But I am hopeful that we can get IPv6 deployed and functional ASAP; that will happen faster if we have a responsible, compatible story for 3GPP. > I _do_ think that we need to do an "IPv6 over link of your choice>" document. This document should include > everything that is really special about building hosts that > talk on cellular links. That could be the Informational document. > One question: Are there enough differences between different > cellular link types that we will need more than one of these > documents? Or is there, effectively, a single type of cellular > link, from an IPv6 perspective? The similarities are more numerous than the differences, from the standpoint of IPv6, but I'm not sure whether there would be one, or perhaps a very small single-digit number of them (like, 2). Keep in mind that the total number of nodes conforming to either one of 2 such documents could easily outnumber the entire current IPv6 population. Or, that the IPv6 implementation on such nodes could be poorly done without appropriate Informational guidance, giving IPv6 generally a bad name. It could happen. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 09:25:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HP9KL004537 for ; Wed, 6 Mar 2002 09:25:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HP9KW004536 for ipng-dist; Wed, 6 Mar 2002 09:25:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HP6KL004529 for ; Wed, 6 Mar 2002 09:25:06 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23389 for ; Wed, 6 Mar 2002 09:25:03 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA01445 for ; Wed, 6 Mar 2002 10:25:02 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id DED332BFD; Wed, 6 Mar 2002 12:25:01 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:25:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should connecting to the Internet be Optional? Date: Wed, 6 Mar 2002 12:25:01 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0152070A@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should connecting to the Internet be Optional? Thread-Index: AcHDn3IAqbuBBGvUTdWNLESmD00oTQBlE9iQ From: "Bound, Jim" To: "Tony Hain" , X-OriginalArrivalTime: 06 Mar 2002 17:25:01.0734 (UTC) FILETIME=[D8F9D460:01C1C533] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HP6KL004530 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't agree. But I am thinking the authors bag the IETF and take this elsewhere unless we can agree on use vs compliant systems. /jim > -----Original Message----- > From: Tony Hain [mailto:tony@tndh.net] > Sent: Monday, March 04, 2002 12:07 PM > To: ipng@sunroof.eng.sun.com > Subject: Should connecting to the Internet be Optional? > Importance: High > > > Margret has raised several valuable questions about > draft-ietf-ipv6-cellular-host-00.txt, which show it is clearly is not > ready for last call. While I am willing to believe that there > are valid > reasons to make adjustments based on characteristics of the link, this > document is fundamentally flawed because it is based around > the pretense > that small footprint devices are somehow special. We MUST NOT allow > ourselves to modify well thought out architectural > fundamentals based on > point-in-time engineering constraints that are dubious at best. If a > device wants to participate as an Internet node, there are basic > requirements. Of course, participating in the Internet is optional, so > if a device would prefer to avoid the requirements, it may choose to > create its own universe. > > The argument that small devices have limited processors or memory > overlooks the fact that the processor and memory of many hand-held > devices today is significantly greater than the workstations that were > available when IPv4 was defined. Interesting point; there was > no problem > getting the stack and an array of applications to fit then. Another > interesting point; there are frequently rumors that laptops > will include > cellular interfaces, so where does the processing and memory > constraint > fit in that case? > > On the subject of applications, the absolute BS about limiting the > application set to avoid an IPsec requirement is something > that belongs > in a product development discussion, NOT a standards > discussion. The one > point that should be clear is that over time the number of > applications > used via wireless (cellular or otherwise) will grow, and that we can't > predict what they are, much less what they will need from the > stack. To > that point, we MUST reiterate that ***ALL IPv6 IMPLEMENTATIONS MUST > INCLUDE SUPPORT FOR IPSEC***. If we relax that requirement, > applications > will never be able to expect support, therefore will have to keep > inventing their own mechanisms. The only way to prevent new > applications > from appearing on computing devices is to put the executable code in > non-rewritable, non-replaceable, rom. > > If a document on cellular requirements makes any sense, it has to be > based on differences in fundamental characteristics of the > air link, not > the device on either end. Avoiding DAD simply due to expense is not a > valid justification, but if the loss characteristics of the > link make it > more problematic than valuable, there may be an argument. Keep in mind > that doing so precludes the use of RFC3041 addresses, so the > applications where anonymity is most valuable (as one moves around and > doesn't movement traced) are precluded. A non-zero probability of > collision requires a mechanism to resolve duplicates, and DAD is the > currently defined one. If another one exists that makes more > sense over > a lossy air-link, we should consider replacing DAD because it will > probably be more reliable in the general case as well. > > Tony > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 09:28:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HSMKL004557 for ; Wed, 6 Mar 2002 09:28:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HSMNI004556 for ipng-dist; Wed, 6 Mar 2002 09:28:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HSIKL004549 for ; Wed, 6 Mar 2002 09:28:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA12142 for ; Wed, 6 Mar 2002 09:28:19 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15694 for ; Wed, 6 Mar 2002 10:28:18 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 1815E5879; Wed, 6 Mar 2002 12:28:18 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:27:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 12:27:44 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0152070B@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDpk8K/dWVy+hSQCKCbvcvISRaHgBjb5+w From: "Bound, Jim" To: "James Kempf" , "Hesham Soliman (ERA)" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 06 Mar 2002 17:27:45.0086 (UTC) FILETIME=[3A575DE0:01C1C534] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HSJKL004550 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James, I do not think we need to change 2462. Vendors just provide an option to disable. Erik's comments on why we did it still apply. We as protocol designers must require DAD. /jim > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, March 04, 2002 12:55 PM > To: Hesham Soliman (ERA); Margaret Wasserman > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Should DAD be optional? [Was > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > Margaret, > > > I don't think that we should publish an informational document that > > advises some implementors to do something that specifically > > disagrees with a MUST requirement in a standards-track document. > > If the standards-track document is broken, we need to fix it > > instead. > > > > DAD has a substantial performance impact on handover if the > Mobile IPv6 care of address is changed. If the address provision > scheme is such that duplicate addresses are not possible, then > I believe it should be possible to disable it. > > I agree that the change must be made in the standards-track document. > Perhaps we could quickly get a short document that describes when > DAD can be disabled, so that the issue can be resolved as quickly > as possible. In the Mobile IPv6 specification, DAD is only a MAY. > > jak > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:30:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HUSKL004582 for ; Wed, 6 Mar 2002 09:30:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HUSOu004581 for ipng-dist; Wed, 6 Mar 2002 09:30:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HUPKL004574 for ; Wed, 6 Mar 2002 09:30:25 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16227 for ; Wed, 6 Mar 2002 09:30:25 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16616 for ; Wed, 6 Mar 2002 09:30:24 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 5DF5D372C; Wed, 6 Mar 2002 12:30:24 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:30:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Date: Wed, 6 Mar 2002 12:30:23 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0152070C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? Thread-Index: AcHDscXTEPUeErwRSl68DJqMagg5FQBgpiaw From: "Bound, Jim" To: "Phil Roberts" , , , Cc: X-OriginalArrivalTime: 06 Mar 2002 17:30:24.0086 (UTC) FILETIME=[991CD760:01C1C534] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HUPKL004575 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Phil, The wording is fine. It does not mandate or cause it to be required. Many have already implemented draft 15 and will begin deployment and fix what MIPv6 decides later. This draft is in the current state and is very clear about the risks. I see no need to change the drift of that section of the spec. /jim > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: Monday, March 04, 2002 2:12 PM > To: 'juha.wiljakka@nokia.com'; hinden@iprg.nokia.com; > deering@cisco.com > Cc: ipng@sunroof.eng.sun.com > Subject: RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? > > > > I'm a little bit concerned about the mobility sections of this > doc. It recommends supporting two drafts that are far from complete > in the MIP working group (HMIP and fast handovers) and where it's hard > to say exactly how those drafts will dome out. I'm also not > sure how fast handovers would be used in this context. > > Hopefully MIPv6 itself will be done soon.... > > > > -----Original Message----- > > From: juha.wiljakka@nokia.com [mailto:juha.wiljakka@nokia.com] > > Sent: Thursday, February 28, 2002 7:29 AM > > To: hinden@iprg.nokia.com; deering@cisco.com > > Cc: ipng@sunroof.eng.sun.com > > Subject: draft-ietf-ipv6-cellular-host-00.txt -> wg last call? > > > > > > > > Hi! > > > > We "cellular host IPv6" draft authors believe that our draft > > > http://www.ietf.org/internet-drafts/draft-ietf-ipv6-cellular-h ost-00.txt would be ready for wg last call. Bob and Steve, if there are no objections from the WG, could you please consider announcing last call for this draft? Thank You. On behalf of all the authors, Juha Wiljakka -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 09:33:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HXJKL004604 for ; Wed, 6 Mar 2002 09:33:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HXJXi004603 for ipng-dist; Wed, 6 Mar 2002 09:33:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HXGKL004596 for ; Wed, 6 Mar 2002 09:33:16 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17009 for ; Wed, 6 Mar 2002 09:33:16 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17925 for ; Wed, 6 Mar 2002 09:33:15 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 6AB022F1B; Wed, 6 Mar 2002 12:33:15 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:33:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should connecting to the Internet be Optional? Date: Wed, 6 Mar 2002 12:33:11 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0152070D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should connecting to the Internet be Optional? Thread-Index: AcHDuw7yOKuZv2/sSXOPCTrU2iOxygBeclwQ From: "Bound, Jim" To: "Phil Roberts" , "Karim El-Malki (ERA)" , "Tony Hain" , X-OriginalArrivalTime: 06 Mar 2002 17:33:11.0699 (UTC) FILETIME=[FD048E30:01C1C534] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HXGKL004597 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This doc should only be for 3G air interfaces and based on 3GGP rel 5 specifically. It is not for WLAN or other air interfaces I know of being deployed right here in the U.S. for IPv6. /jim > -----Original Message----- > From: Phil Roberts [mailto:PRoberts@MEGISTO.com] > Sent: Monday, March 04, 2002 3:18 PM > To: 'Karim El-Malki (ERA)'; Phil Roberts; 'Tony Hain'; > ipng@sunroof.eng.sun.com > Subject: RE: Should connecting to the Internet be Optional? > > > > > > -----Original Message----- > > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > > Sent: Monday, March 04, 2002 3:14 PM > > To: 'Phil Roberts'; 'Tony Hain'; ipng@sunroof.eng.sun.com > > Subject: RE: Should connecting to the Internet be Optional? > > > > > > > Having read through this thread now, might it be better to > > > recast this document more along the lines of functions > > > supported on the cellular interface rather than > > requirements > for host? Some substantial number of devices > > for which this > is targeted will be dual network interface > > capable and for the > other interface some of these > > optimizations don't make sense. > > > > The Mobile IPv6 related specifications for the time being > > > only make sense with such a dual network interface capable > > > device, which means the optimizations recommended on the > > cell > facing interface in many cases SHOULDN'T be > > recommended on > the other interfaces. > > > > The cellular host requirements draft is only aimed at minimum > > cellular host functionality. So if a host has a DSL interface > > this draft doesn't apply to it. I believe this is already an > > assumption of the current draft. If instead you have multiple > > wireless interfaces it would apply. > > But if your multiple wireless interfaces include something like > WLAN it needs to be spelled out which of these recommendations > apply to which interfaces. No? > > > > > /Karim > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:35:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HZ3KL004624 for ; Wed, 6 Mar 2002 09:35:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HZ30r004623 for ipng-dist; Wed, 6 Mar 2002 09:35:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HZ0KL004616 for ; Wed, 6 Mar 2002 09:35:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA17737 for ; Wed, 6 Mar 2002 09:35:00 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA07102 for ; Wed, 6 Mar 2002 10:35:00 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 73B852C69; Wed, 6 Mar 2002 12:34:59 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:34:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Applicability of draft-ietf-ipv6-cellular-host-00.txt Date: Wed, 6 Mar 2002 12:34:58 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0152070E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Applicability of draft-ietf-ipv6-cellular-host-00.txt Thread-Index: AcHDx8cM56EBIQP7R82sp7bEHtGSrQBbV7xg From: "Bound, Jim" To: "Erik Nordmark" , X-OriginalArrivalTime: 06 Mar 2002 17:34:59.0039 (UTC) FILETIME=[3CFF56F0:01C1C535] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HZ0KL004617 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, If the working group solves the applicability definition the problem is in the small. that would be good. /jim > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Monday, March 04, 2002 4:50 PM > To: ipng@sunroof.eng.sun.com > Subject: Applicability of draft-ietf-ipv6-cellular-host-00.txt > > > > I think part of the questions are around the applicability of > the document. > The document doesn't seem to constrain this very much: > > For the purposes of this document, a cellular host is > considered to > be a terminal that uses an air interface to connect to a cellular > access network (i.e. GPRS, UMTS, CDMA2000) in order to > provide IPv6 > connectivity to an IP network. > > So unless "terminal" is a well-defined term in the IETF context this > seems to apply to e.g. a full-powered laptop with a PCMCIA radio card, > a cellular phone with a Java JVM that allows it to run downloaded > applications, and perhaps even a router with such an air interface. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 09:38:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HcIKL004649 for ; Wed, 6 Mar 2002 09:38:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HcIhS004648 for ipng-dist; Wed, 6 Mar 2002 09:38:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HcFKL004641 for ; Wed, 6 Mar 2002 09:38:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15377 for ; Wed, 6 Mar 2002 09:38:11 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01405 for ; Wed, 6 Mar 2002 10:38:10 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id C406337B7; Wed, 6 Mar 2002 12:38:09 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:38:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should IP Security be Optional? Date: Wed, 6 Mar 2002 12:38:09 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0152070F@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional? Thread-Index: AcHDsuGGUI9UsJhMRmOXRqKaLzjVXgAZEOUgAEeb3iA= From: "Bound, Jim" To: , , Cc: , , , , , X-OriginalArrivalTime: 06 Mar 2002 17:38:09.0680 (UTC) FILETIME=[AEA0D900:01C1C535] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HcFKL004642 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, If this is a "use" draft you can't say must anything without "use" in the sentence. /jim > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Tuesday, March 05, 2002 2:30 AM > To: jari.arkko@kolumbus.fi; mat@cisco.com > Cc: mat@cisco.com; nov@tahi.org; Jari.Arkko@lmf.ericsson.se; > Francis.Dupont@enst-bretagne.fr; mrw@windriver.com; > ipng@sunroof.eng.sun.com > Subject: RE: Should IP Security be Optional? > > > Hi all, > > > I do agree that the ESP and AH are really > > simple and easy compared to the rest. Unfortunately, > > this isn't going to be quite as easy as that. > > > > As we point out in section 3.8 the current > > cellular networks sometimes have dynamic IP > > address changes, and therefore manually keyed IPsec > > isn't going to work as such and key management is > > needed. While there might be multiple options > > here, interoperability is a concern and hence > > I feel that we must have a mandated key management > > scheme. In the cellular host requirements draft, we > > have chosen to say that IKE is a MUST in those > > cases where we mandate IPsec. Do you disagree? > > > > (In a way you could say that the cellular draft goes > > *beyond* what the current IETF MUSTs are, given > > that we mandate a full security solution in all cases, > > though at the same time we don't mandate the current > > requirement of AH and ESP in all cases.) > > > > Anyway, this is just *our* proposal on what we think > > would make sense. But the document is controlled by the > > WG; please state your proposed security MUSTs for > > IPv6 hosts, cellular or otherwise. Mike, what would you > > like to have there, for instance? > > Just to add onto Jari - it would be a no-brainer to > state that IPsec (AH & ESP) MUST be supported, > IKE MAY/SHOULD be supported. However, does this > give users anything? Will it increase security for > these devices, or is it just something that will make > folks happy? The authors prefer to have a reasonable > discussion on security within the draft. Knowledge of > the field of Internet Security has increased since > some of the initial IPv6 documents were published ... > > thanks, > John > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:41:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HfiKL004672 for ; Wed, 6 Mar 2002 09:41:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HfiOs004671 for ipng-dist; Wed, 6 Mar 2002 09:41:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HfeKL004664 for ; Wed, 6 Mar 2002 09:41:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28893 for ; Wed, 6 Mar 2002 09:41:36 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21716 for ; Wed, 6 Mar 2002 09:41:36 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 947F83654; Wed, 6 Mar 2002 12:41:35 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:41:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 12:41:33 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520710@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHEJ5QvB3+VBQZ/R1aD2LAQCSZhcQBDotJQ From: "Bound, Jim" To: "Markku Savela" , Cc: , , , X-OriginalArrivalTime: 06 Mar 2002 17:41:34.0587 (UTC) FILETIME=[28C32CB0:01C1C536] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HffKL004665 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk HP has DHCPv6. /jim > -----Original Message----- > From: Markku Savela [mailto:msa@burp.tkv.asdf.org] > Sent: Tuesday, March 05, 2002 4:21 AM > To: john.loughney@nokia.com > Cc: mrw@windriver.com; hesham.soliman@era.ericsson.se; > juha.wiljakka@nokia.com; ipng@sunroof.eng.sun.com > Subject: Re: Making Autoconfig Optional [Was RE: > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > > X-Authentication-Warning: sunroof.eng.sun.com: majordomo > set sender to owner-ipng@sunroof.eng.sun.com using -f > > From: john.loughney@nokia.com > > > > This leads me to think that IPv6 MUST support either stateless or > > stateful, but stateless is not mandatory. > > This seems quite warped, as stateless is much simpler than stateful > (at least with PPP6, which can negotiate ID part). And probably every > existing IPv6 stack has stateless supported, and stateful is an option > that is supposed to be DHCP6, which nobody has... > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:44:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HiwKL004695 for ; Wed, 6 Mar 2002 09:44:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Hiw5s004694 for ipng-dist; Wed, 6 Mar 2002 09:44:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HitKL004687 for ; Wed, 6 Mar 2002 09:44:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22601 for ; Wed, 6 Mar 2002 09:44:55 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23297 for ; Wed, 6 Mar 2002 09:44:55 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 179115B85; Wed, 6 Mar 2002 12:44:55 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:44:54 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 12:44:54 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520711@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHEXTg9HUWVzzy0QIasEe56bWRj0AA2SSMA From: "Bound, Jim" To: "Margaret Wasserman" , X-OriginalArrivalTime: 06 Mar 2002 17:44:54.0960 (UTC) FILETIME=[A031AB00:01C1C536] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HitKL004688 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't think we need a general nodes reqs document. Isn't that what standards are for? If we cannot be reasonable to get specific node docs done quickly here and shipped then we should not do them or do them and implementors will go do them elsewhere. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Tuesday, March 05, 2002 10:46 AM > To: ipng@sunroof.eng.sun.com > Subject: Updating draft-ietf-ipv6-cellular-host-00.txt? > > > > Before folks go and do a lot of additional work to update > draft-ietf-ipv6-cellular-host-00.txt based on our discussions, > I think we have to answer a fundamental question: > > Should the WG publish an informational RFC detailing the IPv6 > requirements for cellular hosts? > > If so, how can we prevent the two most likely bad outcomes: > > - 3GPP (or other) folks thinking that this document > is an IETF standard? [May be handled by > a strongly worded disclaimer in the document?] > - Everyone with an agenda attempting to publish a > similar document for their "special" > category of IPv6 host? [Can we just say 'no'?] > > I also think that we should start work on two standards-track > documents, both of which would use the current draft as > input: > > - An "IPv6 over " document for 3GPP links. > - A general "IPv6 Node Requirements" document. > > Margaret > > > > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:46:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Hk4KL004712 for ; Wed, 6 Mar 2002 09:46:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Hk4ad004711 for ipng-dist; Wed, 6 Mar 2002 09:46:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Hk0KL004704 for ; Wed, 6 Mar 2002 09:46:00 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23026 for ; Wed, 6 Mar 2002 09:46:01 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06144 for ; Wed, 6 Mar 2002 10:46:00 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4940536A5; Wed, 6 Mar 2002 12:46:00 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:46:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 12:45:59 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520712@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Thread-Index: AcHEXVAlC4GktjthRnCVq/tti2RjVAA2WKPA From: "Bound, Jim" To: "Margaret Wasserman" , Cc: X-OriginalArrivalTime: 06 Mar 2002 17:46:00.0195 (UTC) FILETIME=[C713BD30:01C1C536] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26Hk1KL004705 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, If you shutdown NA and NS there is no NUD. Thats the discussion I think not if NS and NA are on. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Tuesday, March 05, 2002 10:24 AM > To: john.loughney@nokia.com > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Making ND Optional [Was RE: > draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] > > > > Hi John, > > > This router > > most likely will not be a final destination for the > host's traffic. > > Additionally, due to special characteristics of the > cellular link, > > lower layer connectivity information should make it > unnecessary to > > track the reachability of the router. > > We have defined a mechanism to locate and maintain reachability > information about neighbours in IPv6, called "Neighbor Discovery". > This isn't an optional part of IPv6 that it would be appropriate > to disable on a particular link type. > > However, it is expected for ND to receive "advice" from other layers > regarding the "reachability" of another host -- so it would be > great if the L2 mechanism gave ongoing advice to IPv6 regarding > the reachability of the router, which would result in suppressing > IPv6 NS messages. > > I don't believe that your conclusion is sound... > > >Therefore, Neighbor > > Solicitation and Advertisement messages MAY be > implemented for the > > cellular interface. > > An implementor could read this and believe that it was acceptable > to build a 3GPP cell phone (with only one cellular interface) that > didn't even contain the _code_ necessary to generate IPv6 NS and > NA messages. > > What happens when that host receives an NS message? > > Do you think that people may ever want to set-up redundant > 3GPP networks, or make a choice between two possible 3GPP > routers, based on their current reachability? If you don't > use ND, how will this information be available for IPv6 > routing decisions? > > There seems to be a mis-perception in the 3GPP community that > ND will result in a lot of extra traffic. The idea of ND is > to locate the other node _once_ and maintain reachability > information about that node on an ongoing basis, using advice > from other layers, _without_ sending additional ND messages > unless absolutely necessary. > > Are there reasons why you think that this won't work on 3GPP > hosts? > > >In addition, a cellular host SHOULD NOT send the > > link layer sub-option on its cellular interface, and > SHOULD silently > > ignore it if received on the same interface. > > This is fine, and would be an excellent piece of information > to put in a standards-track "IP over " document. > > >2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration > > > > IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be > > supported. > > This should be a MUST. IPv6 hosts MUST support address > autoconfiguration, > although it is possible for the routers to be configured so > that it isn't > used (if desired). > > > A cellular host SHOULD NOT perform Duplicate Address > Detection on > > its cellular interface, as each delegated prefix is > unique within > > its scope when allocated using the 3GPP IPv6 Stateless Address > > Autoconfiguration. > > Will the router end of the link allocate any addresses within the > unique /64 assigned to the PDP context? If so, what mechanism will > be used to ensure that the host doesn't allocate the same address? > > If it's actually true that a conflict can never occur, then we should > indicate that DAD won't be used on these link types in an > "IPv6 over " document, as previously discussed. > > Margaret > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:48:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Hm8KL004732 for ; Wed, 6 Mar 2002 09:48:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Hm8D8004731 for ipng-dist; Wed, 6 Mar 2002 09:48:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Hm5KL004724 for ; Wed, 6 Mar 2002 09:48:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23853 for ; Wed, 6 Mar 2002 09:48:06 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA27546 for ; Wed, 6 Mar 2002 10:48:05 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id F0A2A3470; Wed, 6 Mar 2002 12:48:04 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:48:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 12:48:04 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520713@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHEYZzhi+ZeowjMRqyvFzg/7jfCDwA1TtzA From: "Bound, Jim" To: "Brian Haberman" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 06 Mar 2002 17:48:04.0819 (UTC) FILETIME=[115BDA30:01C1C537] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26Hm5KL004725 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian may be right. John et al. Bag this lets go build a cellular host consortia with vendors that want to ship and deploy IPv6 and build our use requirements out of here. Or we will be hacking on this in January 2003. It was a good thing to try but it might not work to do use / implementation reqs in the IETF. Thats fine though. /jim > -----Original Message----- > From: Brian Haberman [mailto:haberman@lorien.sc.innovationslab.net] > Sent: Tuesday, March 05, 2002 11:17 AM > To: Margaret Wasserman > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? > > > Margaret, > > Margaret Wasserman wrote: > > > > Before folks go and do a lot of additional work to update > > draft-ietf-ipv6-cellular-host-00.txt based on our discussions, > > I think we have to answer a fundamental question: > > > > Should the WG publish an informational RFC detailing the IPv6 > > requirements for cellular hosts? > > I don't think we should. It just starts us down that slippery slope > of creating new "foo hosts" requirements docs. Your following > arguments are reason enough to avoid this path. > > > > > If so, how can we prevent the two most likely bad outcomes: > > > > - 3GPP (or other) folks thinking that this document > > is an IETF standard? [May be handled by > > a strongly worded disclaimer in the document?] > > - Everyone with an agenda attempting to publish a > > similar document for their "special" > > category of IPv6 host? [Can we just say 'no'?] > > > > I also think that we should start work on two standards-track > > documents, both of which would use the current draft as > > input: > > > > - An "IPv6 over " document for 3GPP links. > > - A general "IPv6 Node Requirements" document. > > Definitely agree with this. > > Brian > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:50:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HoPKL004772 for ; Wed, 6 Mar 2002 09:50:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HoP3k004771 for ipng-dist; Wed, 6 Mar 2002 09:50:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HoMKL004760 for ; Wed, 6 Mar 2002 09:50:22 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23338 for ; Wed, 6 Mar 2002 09:50:22 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA09274 for ; Wed, 6 Mar 2002 10:50:22 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 0D49F5900; Wed, 6 Mar 2002 12:50:22 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:50:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 12:50:21 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520714@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Thread-Index: AcHEao6Tqn119bi2S+GUvHEo/4StRQAzKTgg From: "Bound, Jim" To: "Margaret Wasserman" , "Karim El-Malki (ERA)" Cc: , X-OriginalArrivalTime: 06 Mar 2002 17:50:22.0023 (UTC) FILETIME=[63238570:01C1C537] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HoMKL004762 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The link is the PDP Context. If more than one host is attached > via a cell phone (using the cell phone as a layer 2 "modem"), each > attached host will establish a separate PDP context (and a separate > IPv6 link), and receive a separate /64 delegation. So, I agree > that there won't be more than 2 nodes on a 3GPP cellular link, the > way things are currently specified. The last sentence is key. In 3GPP that is how IT IS SPECIFIED. The doc addresses the current state of affairs not rel 6 or 7 or 4G. /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 Mar 6 09:51:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HpiKL004789 for ; Wed, 6 Mar 2002 09:51:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Hpi6C004788 for ipng-dist; Wed, 6 Mar 2002 09:51:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HpeKL004781 for ; Wed, 6 Mar 2002 09:51:40 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23712 for ; Wed, 6 Mar 2002 09:51:41 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16159 for ; Wed, 6 Mar 2002 09:51:40 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 9C59C5A78; Wed, 6 Mar 2002 12:51:39 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:51:39 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 12:51:39 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520715@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Thread-Index: AcHEazvXVJ3NZ/gcRHuyitX5L+tBQQAzD6Iw From: "Bound, Jim" To: "Tony Hain" , "Karim El-Malki (ERA)" , "Margaret Wasserman" , Cc: X-OriginalArrivalTime: 06 Mar 2002 17:51:39.0520 (UTC) FILETIME=[9154A000:01C1C537] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HpfKL004782 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 3041 is deemed unnecessary for this deployment. /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Tuesday, March 05, 2002 12:27 PM > To: Karim El-Malki (ERA); 'Margaret Wasserman'; > john.loughney@nokia.com > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Making ND Optional [Was RE: > draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] > > > Karim El-Malki wrote: > > No, the router doesn't allocate any addresses on the > > "delegated" prefix. > > That was the assumption behind our 3gpp-advice draft and has > > been followed > > by 3gpp. > > The router has to allocate at least 1 address in the prefix, > even if it > is just the all-routers address. It is also likely to create > another one > that is unique to itself, so there has to be a mechanism in that which > will ensure that the remote end doesn't collide when it chooses a 3041 > address. The only obvious choice is to make sure that bit 6 is set, > which in turn means that the router is using an EUI-64 > derived address. > Since I don't have access to the 3G specs, is that all true? > > Tony > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 09:54:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Hs7KL004820 for ; Wed, 6 Mar 2002 09:54:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HroSP004819 for ipng-dist; Wed, 6 Mar 2002 09:53:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HrjKL004812 for ; Wed, 6 Mar 2002 09:53:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24575 for ; Wed, 6 Mar 2002 09:53:45 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27781 for ; Wed, 6 Mar 2002 09:53:45 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 18D38598B; Wed, 6 Mar 2002 12:53:45 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:53:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 12:53:44 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520716@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Thread-Index: AcHEb5YsMr1XXkzgTJWdTButbpvuRgAyCn1A From: "Bound, Jim" To: "Keith Moore" , "Margaret Wasserman" Cc: "Karim El-Malki (ERA)" , , X-OriginalArrivalTime: 06 Mar 2002 17:53:45.0008 (UTC) FILETIME=[DC209300:01C1C537] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HrjKL004813 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith, Yep. Until we deploy wireless to wireline enablers which many of us are working on. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Tuesday, March 05, 2002 12:57 PM > To: Margaret Wasserman > Cc: Karim El-Malki (ERA); john.loughney@nokia.com; > ipng@sunroof.eng.sun.com > Subject: Re: Making ND Optional [Was RE: > draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] > > > > >It won't because a cellular host /e.g. 3gpp) is alone on its link. > > > > On a point-to-point link, there must be at least two nodes... > > In this case, one node is the cellular host and the other is > > the 3GPP router (GGSN). > > > > The link is the PDP Context. If more than one host is attached > > via a cell phone (using the cell phone as a layer 2 "modem"), each > > attached host will establish a separate PDP context (and a separate > > IPv6 link), and receive a separate /64 delegation. So, I agree > > that there won't be more than 2 nodes on a 3GPP cellular link, the > > way things are currently specified. > > that's bizarre. does that mean that apps on a host that's > connected to > a cell phone won't be able to communicate with apps on that > cell phone > unless the cell phone is talking to the network? and that > communications > between the host and the cell phone will have to go over the wireless > network? > > Keith > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:54:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HsMKL004836 for ; Wed, 6 Mar 2002 09:54:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HsM6B004835 for ipng-dist; Wed, 6 Mar 2002 09:54:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HsHKL004828 for ; Wed, 6 Mar 2002 09:54:17 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA20483 for ; Wed, 6 Mar 2002 09:54:18 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA12834 for ; Wed, 6 Mar 2002 10:54:17 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 06DCF58F3; Wed, 6 Mar 2002 12:54:17 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:54:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 12:54:16 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520717@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Thread-Index: AcHEb71kj18Ot+J2Qq6KwdcT6CRsmAAyC2Vg From: "Bound, Jim" To: "Karim El-Malki (ERA)" , "Tony Hain" , "Margaret Wasserman" , Cc: X-OriginalArrivalTime: 06 Mar 2002 17:54:16.0894 (UTC) FILETIME=[EF21FDE0:01C1C537] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HsHKL004829 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes. /jim > -----Original Message----- > From: Karim El-Malki (ERA) [mailto:Karim.El-Malki@era.ericsson.se] > Sent: Tuesday, March 05, 2002 12:58 PM > To: 'Tony Hain'; 'Margaret Wasserman'; john.loughney@nokia.com > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Making ND Optional [Was RE: > draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] > > > > Karim El-Malki wrote: > > > No, the router doesn't allocate any addresses on the > > > "delegated" prefix. > > > That was the assumption behind our 3gpp-advice draft and has > > > been followed > > > by 3gpp. > > > > The router has to allocate at least 1 address in the prefix, > > even if it > > is just the all-routers address. It is also likely to create > > another one > > that is unique to itself, > > This special router is called a GGSN and it knows it MUST NOT > configure > itself with a unicast address on that prefix. That means there's no > conflict. Does that make sense? > > /Karim > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 09:58:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HwnKL004875 for ; Wed, 6 Mar 2002 09:58:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26HwmmN004874 for ipng-dist; Wed, 6 Mar 2002 09:58:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26HwjKL004867 for ; Wed, 6 Mar 2002 09:58:45 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27902 for ; Wed, 6 Mar 2002 09:58:46 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00284 for ; Wed, 6 Mar 2002 09:58:45 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id AC5725830; Wed, 6 Mar 2002 12:58:44 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 12:58:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Making ND Optional [Was RE:draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 12:58:44 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520718@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making ND Optional [Was RE:draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Thread-Index: AcHEddMklH58DrjvQwymC7X5wK+m+gAwk9RQ From: "Bound, Jim" To: "Charles E. Perkins" , "Margaret Wasserman" Cc: , X-OriginalArrivalTime: 06 Mar 2002 17:58:44.0570 (UTC) FILETIME=[8EAE1BA0:01C1C538] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26HwkKL004868 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk thats not the intention of the doc. I do think it fine to say in this situation XXX is not required and XXX is for deployment. Lets not discuss what XXX is because we don't want to reinvent the wheel here either. Also different vendors in the past implemented different parts of 1122 and 1123 depending on their markets thats what this is really all about which is what is needed today for current and short term markets for current 3GPP cellular hosts. /jim > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Tuesday, March 05, 2002 1:42 PM > To: Margaret Wasserman > Cc: john.loughney@nokia.com; ipng@sunroof.eng.sun.com > Subject: Re: Making ND Optional [Was > RE:draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] > > > > Hello, > > Disclaimer: I am not fully caught up on this discussion. > > I hope that cellular hosts would be able to run DAD and ND > whenever they need to. I would hope that the IETF would > not approve a document that says "some" IPv6 hosts MUST NOT > (or even SHOULD NOT!) implement DAD/ND. This would be a > problem, if for instance some operators would then use it > to DISALLOW IPv6 addressable devices from running those > protocols. They could claim non-conformance to RFC nnnn! > I reckon that it would be better to determine certain > conditions under which an IPv6 node would experience > better performance by not running those protocols, but > still to expect the protocols to be part of the IPv6 node > implementation. > > My own interest lies in having the ability for some 3G > device to serve as a router for personal devices that > I may carry with me. I'd also like for those devices > to be autoconfigurable, and to find the 3G router by > using standard techniques. All of this could be done > so that my devices would share the same prefix as my 3G > router device. Why not? > > Again, please excuse if this is all duplication of previous > discussion. > > Regards, > Charlie P. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 10:00:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26I0pKL004898 for ; Wed, 6 Mar 2002 10:00:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26I0oXx004897 for ipng-dist; Wed, 6 Mar 2002 10:00:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26I0lKL004890 for ; Wed, 6 Mar 2002 10:00:47 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27420 for ; Wed, 6 Mar 2002 10:00:48 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA22551 for ; Wed, 6 Mar 2002 11:00:47 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 468C93648; Wed, 6 Mar 2002 13:00:46 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 13:00:46 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 13:00:45 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520719@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHEgGVm762gnnzOSQK7vtuE0zkzfgAuFrZQ From: "Bound, Jim" To: "Margaret Wasserman" , Cc: X-OriginalArrivalTime: 06 Mar 2002 18:00:46.0195 (UTC) FILETIME=[D72C9C30:01C1C538] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26I0lKL004891 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Info RFC is NOT a STANDARDS track doc. So if its info do you still have a problem. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Tuesday, March 05, 2002 2:57 PM > To: john.loughney@nokia.com > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? > > > > Hi John, > > >I am having a hard time understanding what your objections > >to the document are. You have raised some good technical > >points & we are looking at how to address them & revise > >the document. However, you seem to be saying now that the > >technical issues are not important. > > I don't believe that the technical issues that you have > raised are unimportant. I think that they are very important -- > important enough that they should be addressed in standards-track > documents. > > But, I don't think that this document is in quite the right > form to move on to the standards track as written, and I don't > think that it makes sense to publish it as an informational > document. > > Your document and your arguments have convinced me that we > should publish a standard definition of the minimal requirements > for an IPv6 node, an "IPv6 Node Requirements" document (or perhaps > two documents, one for hosts and one for routers?). This should > be a standards-track document, not an informational one, and I > think that your document would serve as an excellent starting > point for this work. > > It is important that the minimal host requirements of IPv6 be > applicable to low-end systems, such as cell phones, and that > should be reflected in our general IPv6 node requirements effort. > > However, I don't think that we want to have a fragmented set > of informational host requirements documents with different > requirements for different IPv6 application spaces (cellular hosts > vs network appliances vs. home gateways vs. car infotainment > equipment, etc.). If I'm missing some reason why cellular > hosts are special, that explains why they would need an > informational requirements document (when other applications > would not), please explain. > > Most of the things that make the hosts you've discussed unique > are related to the fact that they run over a specific link > type. In my opinion, these differences, and the behaviour that > is required because of them, should be captured in a link-specific > standards-track "IPv6 over " document, such as "IPv6 > over 3GPP PDP Contexts". This document could be based on > portions of your current document. > > Of course, I don't personally get to decide what the IPv6 > WG publishes. I'm just voicing my opinion... > > > > If so, how can we prevent the two most likely bad outcomes: > > > > > > - 3GPP (or other) folks thinking that this document > > > is an IETF standard? [May be handled by > > > a strongly worded disclaimer in the document?] > > > >If the draft can go through the process of becoming an > >RFC, with work group consensus, etc. what is the problem? > > Well, this is the process of trying to find that consensus. > > Consensus on publishing an RFC doesn't just mean that no one can > find any technical problems with the contents. It also means > getting the consensus of the WG and the IESG that a document is > needed in this area, and that publishing that document would be > useful. > > I have voiced technical issues with the document AND reasons > why I thnk the WG may not want to publish this specific document as > an Informational RFC, even if the technical issues were addressed. > > > > - Everyone with an agenda attempting to publish a > > > similar document for their "special" > > > category of IPv6 host? [Can we just say 'no'?] > > > >Of course, I do think that you are being very unfair in > >this statement. Most of the authors are IETF participants, > >not 3GPP participants. We have no 'agenda' - or at > >least no more than your average IETF participant. > > I can see how you interpreted my comments this way, but this > isn't what I meant... > > I don't think that the authors of this draft have an "agenda" > (in the negative connotation sense) that runs contrary to the > interests of the IETF, IPv6 or any related work. > > I meant "agenda" more in the sense of "focus" or "area of > interest". > > There are a lot of people involved in the IETF (myself included) > who have a strong interest in making sure that IPv6 is applicable > for certain types of uses. This is a positive thing, because > we often have a lot of technical knowledge about those environments, > and we can add to the quality and wide applicability of IPv6 by > reviewing documents and representing our differing perspectives. > > However, I don't think that the WG should publish a number of > different informational RFCs, representing all of these different > positions regarding what the minimal contents of IPv6 should be for > each type of application. Instead, we should bring all of our > knowledge and skills together to write a single standards- > based "IPv6 Node Requirements" document that defines what the > minimal requirements are for all IPv6 nodes. > > >This > >is not 3GPP trying to push anything in the IETF. Also, > >I really don't think that involving a more diverse set > >of participants in the IETF is a bad thing. I think > >we ought to encourage more direct participation in the > >IETF rather than less. Do you feel it is a problem if > >folks from the FOO SDO starting participating in the IETF, > >and functioning under IETF rules? I really could not > >find a problem with that. > > No, I have no problem with that at all! In fact, I'd like > to see even more of it. > > Margaret > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 10:01:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26I1hKL004915 for ; Wed, 6 Mar 2002 10:01:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26I1h2Z004914 for ipng-dist; Wed, 6 Mar 2002 10:01:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26I1dKL004907 for ; Wed, 6 Mar 2002 10:01:39 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27731 for ; Wed, 6 Mar 2002 10:01:40 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA21232 for ; Wed, 6 Mar 2002 10:01:39 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id AA8185888; Wed, 6 Mar 2002 13:01:33 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 13:01:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Multiple link local addresses Date: Wed, 6 Mar 2002 13:01:33 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0152071A@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Multiple link local addresses Thread-Index: AcHEg/QZLI9f9FxcQhOQ0ETkIw720QAtOuRg From: "Bound, Jim" To: "Tony Hain" , "Vinayak Prabhu" , X-OriginalArrivalTime: 06 Mar 2002 18:01:33.0664 (UTC) FILETIME=[F377CE00:01C1C538] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26I1dKL004908 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk we actually permit this at the Data Link but it must appear as one ll to the ip layer. /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Tuesday, March 05, 2002 3:22 PM > To: Vinayak Prabhu; ipng@sunroof.eng.sun.com > Subject: RE: Multiple link local addresses > > > Vinayak Prabhu wrote: > > Can a node have multiple link local addresses? > > There is nothing to prevent a node from having multiple link local > addresses, but what would be the value? The only thing it would appear > to do is consume resources on the node that has multiple > addresses, and > require all other nodes to decide which address to use when talking to > it. > > Tony > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 10:04:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26I4BKL004941 for ; Wed, 6 Mar 2002 10:04:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26I4BG5004940 for ipng-dist; Wed, 6 Mar 2002 10:04:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26I48KL004933 for ; Wed, 6 Mar 2002 10:04:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA24144 for ; Wed, 6 Mar 2002 10:04:09 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA07557 for ; Wed, 6 Mar 2002 11:04:08 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E663C34E9; Wed, 6 Mar 2002 13:04:07 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 13:04:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 13:04:07 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0152071B@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHElBXtY2KIiaO9ST+8IGUWbRxj0AApQZ2w From: "Bound, Jim" To: "Erik Nordmark" , "Margaret Wasserman" Cc: X-OriginalArrivalTime: 06 Mar 2002 18:04:07.0883 (UTC) FILETIME=[4F63C1B0:01C1C539] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26I48KL004934 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, We can't possilbly to a standards ip over 3gpp its not possible. It also none of our business and could cause big liaison problem. The other one needs to break down to different node types. /jim > -----Original Message----- > From: Erik Nordmark [mailto:Erik.Nordmark@eng.sun.com] > Sent: Tuesday, March 05, 2002 5:13 PM > To: Margaret Wasserman > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? > > > > > I also think that we should start work on two standards-track > > documents, both of which would use the current draft as > > input: > > > > - An "IPv6 over " document for 3GPP links. > > - A general "IPv6 Node Requirements" document. > > I think the above two documents make a lot of sense. > > I wonder if there is utility in having a third document; > an informational and non-prescriptive > document (i.e. no MUST, SHOULD, MAY language) which is more like a > document roadmap plus issues for hosts of category X (where X > is a rather > narrowly defined subset of the 3g/cellular host). > > For instance, listing the set of documents that implementors > need to take > into account seems quite useful. > > Also, discussing tradeoffs of what optional things to > implement also sounds > useful. And talking about how things fit together i.e. the > relationship between > IPsec/IKE vs. TLS also sounds like useful information to > implementors. But > "discussing issues" and not having any normative MUST, > SHOULD, MAY language. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 10:06:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26I6IKL004967 for ; Wed, 6 Mar 2002 10:06:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26I6IvG004966 for ipng-dist; Wed, 6 Mar 2002 10:06:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26I6FKL004959 for ; Wed, 6 Mar 2002 10:06:15 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00820 for ; Wed, 6 Mar 2002 10:06:15 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25828 for ; Wed, 6 Mar 2002 11:06:14 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3B18C2CD9; Wed, 6 Mar 2002 13:06:14 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 13:06:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 13:06:13 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0152071C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHEn2S2Oj9SzyG3SayHPF2P7IcnMAAmfaZQ From: "Bound, Jim" To: "Margaret Wasserman" , "Jari Arkko" Cc: X-OriginalArrivalTime: 06 Mar 2002 18:06:14.0195 (UTC) FILETIME=[9AAD7030:01C1C539] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26I6FKL004960 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't agree on the expedite optimism. We have important people in the working group who are not even sure what a GGSN does technically. PDP Context or 802.11 EAP with AAA will use IPv6. Its like device drivers. They will be custom. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Tuesday, March 05, 2002 6:40 PM > To: Jari Arkko > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? > > > > >Now, my concern is this: > >how long do you think producing the general document > >to an RFC will take? What should we say in the > >meantime to folks who want to deploy IPv6 now? > >If there are decisions as to what to do with ND/DAD/whatever, > >should those be made by (a) IPv6 WG, (b) 3GPP, or (c) > >vendors? > > This is a valid concern... > > Many of the issues that are raised in your document > could be handled in an "IPv6 over 3GPP PDP Contexts" > document. I think that we should be able to produce > that document fairly quickly, probably quicker than > we will reach consensus on any requirements document, > even your informational one. > > Margaret > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 10:22:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26IMoKL005030 for ; Wed, 6 Mar 2002 10:22:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26IMoZL005029 for ipng-dist; Wed, 6 Mar 2002 10:22:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26IMlKL005022 for ; Wed, 6 Mar 2002 10:22:47 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00377 for ; Wed, 6 Mar 2002 10:22:46 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00735 for ; Wed, 6 Mar 2002 11:22:45 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id ED54A595D; Wed, 6 Mar 2002 13:22:44 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 13:22:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 13:22:44 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B348@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHDUzawI63y4/2zRnCzH9aKLl2YiwB216UQAAApHwAAAtrngA== From: "Bound, Jim" To: , , Cc: X-OriginalArrivalTime: 06 Mar 2002 18:22:44.0867 (UTC) FILETIME=[E929FD30:01C1C53B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26IMmKL005023 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, For years I used to fight that all specs in the IETF should have rationale appendices as in the IEEE. But no one wants to do the work. Your being overly optimistic if you believe what you ask is achievable. I don't think the wordage for actual protocol operation is arbitrary for the technologies I have worked on in the IETF for 9 years. But I do think the policy is and often who yells the loudest or a default that is less than optimal and no one implements it the same for policy then. That is the part that is arbitrary I say as IMO (IMO not IMHO I will not be humble anymore in this community it don't work). Your also correct about implementations as we track that very carefully in the IPv6 Forum and what I believe is happening is folks are implementing what they can "sell" and will be deployed first. I think IPsec is picking up steam especially around more mission critical early adoption deployment. Me telling a lady I want to have dinner with her on my 3GGP IPv6 cell phone is simply not mission critical (well hopefully :---)) And I also don't care if its secure either and don't want IPsec slowing down my phone connection to the lady :-----------) I think it may be we who really care about real IPv6 deployment take this to a new consortia and send it to 3GPP or send it in directly to 3GPP and have them put it as reqs in an appendix and by pass this totally non productive process for this topic. I do think reducing the scope in title to "current 3GGP UMTS celluar hosts" would be a good political and technical move. /jim > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: Wednesday, March 06, 2002 11:54 AM > To: Bound, Jim; mrw@windriver.com; hesham.soliman@era.ericsson.se > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Should DAD be optional? [Was > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > Hi Jim, > > > I think all vendors will provide option to disable DAD and take the > > risk. > > > > The IETF specs are not like laws where they can really be > > enforced. If a customer and set of vendors have a good reason to > > not use a MUST in a spec they will for business reasons. And there > > is not a thing the IETF can do about it. > > Actually, I think what we (the IETF) should do about it is create > specifications which explain what the reason for the specification > is used for, and under what circumstances optimizations may be useful. > This is actually what one of intentions has been for the > Cellular Hosts > document. > > In discussing RFCs with non-IETF folks, some of the requirements > in RFCs can seem to be rather arbitrary. > > thanks, > John > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 10:32:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26IWMKL005057 for ; Wed, 6 Mar 2002 10:32:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26IWMUb005056 for ipng-dist; Wed, 6 Mar 2002 10:32:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26IWIKL005049 for ; Wed, 6 Mar 2002 10:32:18 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA12671 for ; Wed, 6 Mar 2002 10:32:18 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08389 for ; Wed, 6 Mar 2002 10:32:16 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id CF6642F5D; Wed, 6 Mar 2002 13:32:15 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 13:32:15 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 13:32:15 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0152071E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHFMmIBht/PtF4tQxyR3i3JtqnARAACeCpQ From: "Bound, Jim" To: "Phil Roberts" , "Margaret Wasserman" , Cc: X-OriginalArrivalTime: 06 Mar 2002 18:32:15.0630 (UTC) FILETIME=[3D5D82E0:01C1C53D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26IWJKL005050 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Phil, I don't agree with your view at all. But below is important to the decision IMO. > Which raises a question - if all these vendors are capable > of building interoperable hosts and routers, what is the > big concern about the cellular handset vendors - other than > the subtle and specific differences of communicating over > specifically the 3gpp defined interfaces? The danger seems > not that they will implement too much, but that they will > implement too little. The doc seems to want to give > permission to skip required v6 features which is not something > this WG should bless. I have to agree if the doc is saying an IPv6 implementation should not implement everything and it has an IETF RFC. Not for technical reasons or I think it bad. But because I am practical and know our community. This would not see the light of day politically and that is just the way it is. I strongly suggest we who care (again) just submit this to 3GPP and end this IETF discussion. As to node reqs for IPv6. Thats an important discussion but I will argue I have all those reqs as a vendor and implementor currently in our specs. I will implement those that will be wanted by customers and for the product set supporting them. Thats what this is really all about and we may have headed down the wrong path back at the seattle meeting. The reason I say this is that we cannot control IPv6 deployment in the IETF for any market and in particular 3GPP. Also as you stated 3GPP2 has different reqs than 3GPP. regards, /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 Mar 6 10:37:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26IbXKL005123 for ; Wed, 6 Mar 2002 10:37:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26IbXpZ005122 for ipng-dist; Wed, 6 Mar 2002 10:37:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26IbTKL005112 for ; Wed, 6 Mar 2002 10:37:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05174 for ; Wed, 6 Mar 2002 10:37:28 -0800 (PST) Received: from roam.psg.com ([198.32.16.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA09368 for ; Wed, 6 Mar 2002 11:37:28 -0700 (MST) Received: from randy by roam.psg.com with local (Exim 4.00) id 16igGN-0000dT-00; Wed, 06 Mar 2002 10:35:43 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Bound, Jim" Cc: "Francis Dupont" , "Margaret Wasserman" , "Hesham Soliman (ERA)" , Subject: RE: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] References: <9C422444DE99BC46B3AD3C6EAFC9711B01520701@tayexc13.americas.cpqcorp.net> Message-Id: Date: Wed, 06 Mar 2002 10:35:43 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I agree security is important and IPsec is good. > But the market and vendors will ship and use what they want. we are not a vendor. we are the ietf. we make the bestquality standards we can. if there are vendors which do not follow them, then if this is not due to lack of quality of a standard, it is not our problem. buyer beware. randy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 10:39:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26IdvKL005167 for ; Wed, 6 Mar 2002 10:39:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Idvor005166 for ipng-dist; Wed, 6 Mar 2002 10:39:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26IdsKL005159 for ; Wed, 6 Mar 2002 10:39:54 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17327 for ; Wed, 6 Mar 2002 10:39:53 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10621 for ; Wed, 6 Mar 2002 11:39:52 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 3EE4F348D; Wed, 6 Mar 2002 13:39:52 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 13:39:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 13:39:51 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0152071F@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHFM50Of4Bcmh/jRh68s0JTO50MeAACfAyg From: "Bound, Jim" To: "Charles E. Perkins" , "Margaret Wasserman" Cc: , X-OriginalArrivalTime: 06 Mar 2002 18:39:51.0814 (UTC) FILETIME=[4D45AA60:01C1C53E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26IdsKL005160 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk charlie, the problem is that for a few years now people have begun to use info rfc as political tool either to stop a good idea or abuse the info status and then put its an RFC # in their marketing literature alluding to that its a standard but not really doing so. I agree with you info should be what it was a long time ago. like just info or fyi. And like you I believe in caveat emptor (let the buyer beware) and if someone is stupid enough to not check what mumbo jumbo rfc means and its state and intention they deserve what happens to them. we document clearly what info means in our ietf community. but if folks won't treat info as it was intended and they are not in most cases anymore we are wasting our fingers, mind, and a few other things on this discussion and the authors should submit this to 3GPP and we should submit different doc for 3GPP2 also and not even attempt info rfc for this doc. time-to-market is to important in this case to mess around here for this particular task for the next year. /jim > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Wednesday, March 06, 2002 12:21 PM > To: Margaret Wasserman > Cc: john.loughney@nokia.com; ipng@sunroof.eng.sun.com > Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? > > > > Hello Margaret, > > Margaret Wasserman wrote: > > > I've tried to explain this in other messages, but I don't > > think that my reasons are coming across... > > > > If we publish this document as "informational" now, I think we > > all agree that the 3GPP community will treat this as a standard and > > implement to it. > > I got that part of your message, and I think the problem is > able to be avoided. Maybe we should not have process discussions > here, but generally I feel that if we can't use the Informational > RFC mechanism as it was intended to be used, then something is > wrong. > > > This raises one serious, immediate problem. This document > > contradicts things in IPv6 standards track documents. As a > > result, we may end up with two subtly incompatible "camps" of > > IPv6 nodes (cellular nodes and non-cellular nodes). > > Then a good idea would be to make sure that the Informational > document does NOT contradict IPv6 standards track documents. > In my previous notes, I suggested some language that would be > useful to ensure that result, partially motivated by work done > elsewhere in the IETF. > > > Since we know that this document will be treated as a standard, > > giving it a cursory review and hurrying to publish it as an > > "informational" document is irresponsible. > > But on the other hand we can easily imagine giving the document > thorough review and making responsible decisions about what belongs > in it. > > > Why do you think that it will take more time to gain consensus > > on the minimal IPv6 host requirements for a standards-based "IPv6 > > host requirements" effort, than it will to reach consensus on > > the minimal IPv6 host requirements for an informational "cellular > > hosts" effort? > > Then the Informational document should not be labeled "minimal". > Maybe IPv6-over-3GPP-PDP is the right name. The reason that > it can be done faster, is because the discussion can be more > focussed. I agree with you, that such a document should > not contain language contradicting the Draft Standard documents. > Right now, I don't know any reason that would force this result. > > > Either way, we need to reach consensus on the minimal set of > > specifications and features that comprise IPv6, right? > > Determining what is "minimal" will take longer > than determining what is useful for 3GPP-over-PDP. > > > Getting this right will take time, and I don't think that we > > should publish either document until we get it right. > > Agreed -- but the time requirement for the focussed document > can be a lot shorter than a general document. And, a lot of > work has already gone into it. > > > If we > > are going to undertake this effort, wouldn't you rather emerge > > with a standards-based host requirements document than with an > > informational cellular-specific document? > > All else being equal, yes. But, not all things are equal here. > > > Or are you suggesting that we should publish a "cellular host > > requirements" draft without going through the effort to get > > full consensus on the actual minimal requirements for IPv6 > > hosts? How would that work, and still avoid the "two camps" > > concern that I raised above? > > That would be my suggestion. It could work, because the Informational > document would not be interpreted as an broadly applicable "minimal" > draft. In fact, by definition the "minimal" draft should have _fewer_ > features than the IPv6-over-3GPP-PDP draft. I think this is able > to be accomplished by (i) not contradicting IPv6 standards, and > (ii) focussing exactly on what PDP needs. I am not a crusader, > nor even proponent, for PDP, since I think that was designed > without much attention given to connectionless traffic. But I > am hopeful that we can get IPv6 deployed and functional ASAP; > that will happen faster if we have a responsible, compatible > story for 3GPP. > > > I _do_ think that we need to do an "IPv6 over > link of your choice>" document. This document should include > > everything that is really special about building hosts that > > talk on cellular links. > > That could be the Informational document. > > > One question: Are there enough differences between different > > cellular link types that we will need more than one of these > > documents? Or is there, effectively, a single type of cellular > > link, from an IPv6 perspective? > > The similarities are more numerous than the differences, from > the standpoint of IPv6, but I'm not sure whether there would be > one, or perhaps a very small single-digit number of them (like, 2). > Keep in mind that the total number of nodes conforming to either > one of 2 such documents could easily outnumber the entire current > IPv6 population. Or, that the IPv6 implementation on such nodes > could be poorly done without appropriate Informational guidance, > giving IPv6 generally a bad name. It could happen. > > Regards, > Charlie P. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 10:47:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26IlTKL005202 for ; Wed, 6 Mar 2002 10:47:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26IlTV3005201 for ipng-dist; Wed, 6 Mar 2002 10:47:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26IlPKL005194 for ; Wed, 6 Mar 2002 10:47:25 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07370 for ; Wed, 6 Mar 2002 10:47:24 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA16071 for ; Wed, 6 Mar 2002 10:47:24 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 5680436CF; Wed, 6 Mar 2002 13:47:23 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 13:47:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 13:47:20 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520720@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHFPfNgm3rctO9WT/uKOHLI7ua7lwAAUceQ From: "Bound, Jim" To: "Randy Bush" Cc: "Francis Dupont" , "Margaret Wasserman" , "Hesham Soliman (ERA)" , X-OriginalArrivalTime: 06 Mar 2002 18:47:21.0164 (UTC) FILETIME=[591B08C0:01C1C53F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26IlQKL005195 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk 100% agree. as I just said to charlie buyer beware or suffer. /jim > -----Original Message----- > From: Randy Bush [mailto:randy@psg.com] > Sent: Wednesday, March 06, 2002 1:36 PM > To: Bound, Jim > Cc: Francis Dupont; Margaret Wasserman; Hesham Soliman (ERA); > ipng@sunroof.eng.sun.com > Subject: RE: Should IP Security be Optional? [Was RE: > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > > I agree security is important and IPsec is good. > > But the market and vendors will ship and use what they want. > > we are not a vendor. we are the ietf. we make the > bestquality standards we > can. if there are vendors which do not follow them, then if > this is not due > to lack of quality of a standard, it is not our problem. > buyer beware. > > randy > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 11:07:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26J6xKL005258 for ; Wed, 6 Mar 2002 11:06:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26J6xnS005257 for ipng-dist; Wed, 6 Mar 2002 11:06:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26J6tKL005250 for ; Wed, 6 Mar 2002 11:06:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA29806 for ; Wed, 6 Mar 2002 11:06:55 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25565 for ; Wed, 6 Mar 2002 12:06:54 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g26J4Jt00720; Wed, 6 Mar 2002 14:04:19 -0500 (EST) Message-Id: <200203061904.g26J4Jt00720@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Bound, Jim" cc: "Margaret Wasserman" , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] In-reply-to: (Your message of "Wed, 06 Mar 2002 11:48:53 EST.") <9C422444DE99BC46B3AD3C6EAFC9711B015206FB@tayexc13.americas.cpqcorp.net> Date: Wed, 06 Mar 2002 14:04:19 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The IETF specs are not like laws where they can really be enforced. I think most of us understand this already. However, the IETF specs do establish widely-held assumptions for what is needed to allow products to interoperate. Vendors who ship products that violate those specs are risking that their products will not harm interoperability. Customers can hold those vendors liable for violating the specifications, especially if they don't bother to document the violations and/or problems that result. Admittedly this doesn't happen as often as it should. Within IETF, the best we can do is to produce clear guidelines for what is expected. The harm that will result if the expectations are violated is not always possible to document in advance. Just look at the level of denial that's still occuring about the harm that NATs cause. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 11:42:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Jg5KL005367 for ; Wed, 6 Mar 2002 11:42:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Jg5s4005366 for ipng-dist; Wed, 6 Mar 2002 11:42:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Jg1KL005359 for ; Wed, 6 Mar 2002 11:42:01 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA12697 for ; Wed, 6 Mar 2002 11:42:01 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01017 for ; Wed, 6 Mar 2002 12:42:00 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 38C32580C; Wed, 6 Mar 2002 14:42:00 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 14:41:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 14:41:59 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520739@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHFQbrySv+el9ZeQd+ntR4Y7wWkxAABIQtQ From: "Bound, Jim" To: "Keith Moore" Cc: "Margaret Wasserman" , "Hesham Soliman (ERA)" , X-OriginalArrivalTime: 06 Mar 2002 19:41:59.0806 (UTC) FILETIME=[FB5419E0:01C1C546] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26Jg2KL005360 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Keith, No argument from me. Your right. But not all reqs are needed for all devices. I do not believe for the current time-to-market needs of vendors or users for cellular hosts has time to mess around here either. I also don't think given all the protocol work we have to do that documenting in our community what is and not needed for each device is a high priority in fact because of your mail on our list of work or all the specs the IESG has to read and parse. Not saying it would not be nice just two things: one its not a priority to me, and two: the authors spec for cellular hosts has time-to-market for IPv6 deployment and no way are we or can we meet those needs (like right now) and they should go to the public sector and publish this. UNLESS: We go back to what informational means as Charlie and I believe as it used to be? I doubt that is possible. /jim > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > Sent: Wednesday, March 06, 2002 2:04 PM > To: Bound, Jim > Cc: Margaret Wasserman; Hesham Soliman (ERA); ipng@sunroof.eng.sun.com > Subject: Re: Should DAD be optional? [Was > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > > The IETF specs are not like laws where they can really be enforced. > > I think most of us understand this already. However, the IETF specs > do establish widely-held assumptions for what is needed to allow > products to interoperate. Vendors who ship products that > violate those > specs are risking that their products will not harm interoperability. > Customers can hold those vendors liable for violating the > specifications, > especially if they don't bother to document the violations > and/or problems > that result. Admittedly this doesn't happen as often as it should. > > Within IETF, the best we can do is to produce clear > guidelines for what > is expected. The harm that will result if the expectations > are violated > is not always possible to document in advance. Just look at the level > of denial that's still occuring about the harm that NATs cause. > > Keith > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 12:01:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26K17KL005425 for ; Wed, 6 Mar 2002 12:01:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26K17bX005424 for ipng-dist; Wed, 6 Mar 2002 12:01:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26K14KL005417 for ; Wed, 6 Mar 2002 12:01:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18642 for ; Wed, 6 Mar 2002 12:01:04 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA22802 for ; Wed, 6 Mar 2002 13:01:03 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA23721; Wed, 6 Mar 2002 12:01:03 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g26K12B13051; Wed, 6 Mar 2002 12:01:02 -0800 X-mProtect:  Wed, 6 Mar 2002 12:01:02 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd9qJSpp; Wed, 06 Mar 2002 12:01:00 PST Message-ID: <3C86757C.34E5DD1F@iprg.nokia.com> Date: Wed, 06 Mar 2002 12:01:00 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Bound, Jim" CC: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] References: <9C422444DE99BC46B3AD3C6EAFC9711B01520739@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Bound, Jim" wrote: > UNLESS: We go back to what informational means as Charlie and I believe > as it used to be? > > I doubt that is possible. Well, it's worth a shot, and the draft could include enough text to make it obvious what is meant. That would only make a difference to people who bother to even glance at the document, but anybody implementing the platform would be likely to see it, and any marketing literature would probably not risk the black eye of provably misconstruing the document. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 13:04:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26L4MKL005732 for ; Wed, 6 Mar 2002 13:04:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26L4MYP005731 for ipng-dist; Wed, 6 Mar 2002 13:04:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26L4IKL005724 for ; Wed, 6 Mar 2002 13:04:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03970 for ; Wed, 6 Mar 2002 13:04:18 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA23994 for ; Wed, 6 Mar 2002 13:04:18 -0800 (PST) Received: from kenawang (d_73nuj.wrs.com [147.11.46.202] (may be forged)) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id NAA28764; Wed, 6 Mar 2002 13:03:41 -0800 (PST) Message-Id: <4.2.2.20020306155434.01cd6ed0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 06 Mar 2002 15:58:58 -0500 To: "Charles E. Perkins" From: Margaret Wasserman Subject: Re: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Cc: "Bound, Jim" , ipng@sunroof.eng.sun.com In-Reply-To: <3C86757C.34E5DD1F@iprg.nokia.com> References: <9C422444DE99BC46B3AD3C6EAFC9711B01520739@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd be amenable some sort of "guidelines" document that offers some guidance to 3GPP vendors on which portions of which IPv6 specifications should be implemented in cellular hosts. With the following characteristics: - The document should clearly state that it is not a standard, and that it doesn't modify any other standards. I know that "informational" status implies this, but I think it should be explicit in the document. - The MUST, MAY, SHOULD... wording should be removed. - All conflicts with existing IPv6 standards should be eliminated. - The document should be re-worked to focus more on referring cellular implementers to the correct IPv6 standards. - We should not recommend anything that we don't agree with -- for instance, if we think that IP Sec should be included in all IPv6 hosts, this document shouldn't say otherwise. Margaret At 03:01 PM 3/6/02 , Charles E. Perkins wrote: >"Bound, Jim" wrote: > > > UNLESS: We go back to what informational means as Charlie and I believe > > as it used to be? > > > > I doubt that is possible. > >Well, it's worth a shot, and the draft could include enough >text to make it obvious what is meant. That would only make >a difference to people who bother to even glance at the document, >but anybody implementing the platform would be likely to see it, >and any marketing literature would probably not risk the black >eye of provably misconstruing the document. > >Regards, >Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 13:17:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26LHwKL005768 for ; Wed, 6 Mar 2002 13:17:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26LHw2E005767 for ipng-dist; Wed, 6 Mar 2002 13:17:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26LHtKL005760 for ; Wed, 6 Mar 2002 13:17:55 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27100 for ; Wed, 6 Mar 2002 13:17:55 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA25125 for ; Wed, 6 Mar 2002 13:17:55 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA29107; Wed, 6 Mar 2002 13:17:54 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g26LHsb19295; Wed, 6 Mar 2002 13:17:54 -0800 X-mProtect:  Wed, 6 Mar 2002 13:17:54 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdvFU74D; Wed, 06 Mar 2002 13:17:52 PST Message-ID: <3C868780.4A84D08F@iprg.nokia.com> Date: Wed, 06 Mar 2002 13:17:52 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Margaret Wasserman CC: "Bound, Jim" , ipng@sunroof.eng.sun.com Subject: Re: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00.txt -> wg last call?] References: <9C422444DE99BC46B3AD3C6EAFC9711B01520739@tayexc13.americas.cpqcorp.net> <4.2.2.20020306155434.01cd6ed0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Margaret, Your proposal works very well for me. I might suggest that the normative capitalization could be changed to lower-case, along with an explanation that the reason for doing so is to prevent the informational recommendations from being construed as IETF IPv6 mandates. I would also like the title to be changed to "IPv6-over-3GPP-PDP", since I would like to eventually see 3++G systems look a lot more like what we're used to, instead of so many point-to-point tunnels. Regards, Charlie P. Margaret Wasserman wrote: > > I'd be amenable some sort of "guidelines" document that offers > some guidance to 3GPP vendors on which portions of which IPv6 > specifications should be implemented in cellular hosts. With > the following characteristics: > > - The document should clearly state that it is not > a standard, and that it doesn't modify any > other standards. I know that "informational" > status implies this, but I think it should > be explicit in the document. > - The MUST, MAY, SHOULD... wording should be removed. > - All conflicts with existing IPv6 standards should be > eliminated. > - The document should be re-worked to focus more on > referring cellular implementers to the correct > IPv6 standards. > - We should not recommend anything that we don't > agree with -- for instance, if we think that > IP Sec should be included in all IPv6 hosts, > this document shouldn't say otherwise. > > Margaret > > At 03:01 PM 3/6/02 , Charles E. Perkins wrote: > >"Bound, Jim" wrote: > > > > > UNLESS: We go back to what informational means as Charlie and I believe > > > as it used to be? > > > > > > I doubt that is possible. > > > >Well, it's worth a shot, and the draft could include enough > >text to make it obvious what is meant. That would only make > >a difference to people who bother to even glance at the document, > >but anybody implementing the platform would be likely to see it, > >and any marketing literature would probably not risk the black > >eye of provably misconstruing the document. > > > >Regards, > >Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 13:28:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26LSGKL005792 for ; Wed, 6 Mar 2002 13:28:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26LSGIk005791 for ipng-dist; Wed, 6 Mar 2002 13:28:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26LSCKL005784 for ; Wed, 6 Mar 2002 13:28:12 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA16634 for ; Wed, 6 Mar 2002 13:28:13 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13733 for ; Wed, 6 Mar 2002 14:28:12 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g26LSBZc008805 for ; Wed, 6 Mar 2002 22:28:11 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Mar 06 22:26:49 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Mar 2002 22:28:10 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFE5@esealnt117> From: "Karim El-Malki (ERA)" To: "'Charles E. Perkins'" , Margaret Wasserman Cc: "Bound, Jim" , ipng@sunroof.eng.sun.com Subject: RE: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 22:27:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Your proposal works very well for me. > > I might suggest that the normative capitalization could > be changed to lower-case, along with an explanation that > the reason for doing so is to prevent the informational > recommendations from being construed as IETF IPv6 mandates. > > I would also like the title to be changed to > "IPv6-over-3GPP-PDP", since I would like to eventually > see 3++G systems look a lot more like what we're used > to, instead of so many point-to-point tunnels. I agree that it would be good to see some guidelines in an informational doc. However I disagree on the title change to IPv6 over cellular/3g. That is a different spec which we should also work on. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 13:38:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26LcCKL005817 for ; Wed, 6 Mar 2002 13:38:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26LcC79005816 for ipng-dist; Wed, 6 Mar 2002 13:38:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Lc9KL005809 for ; Wed, 6 Mar 2002 13:38:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15465 for ; Wed, 6 Mar 2002 13:38:09 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA09289 for ; Wed, 6 Mar 2002 14:38:08 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA00565; Wed, 6 Mar 2002 13:38:08 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g26Lc8C19181; Wed, 6 Mar 2002 13:38:08 -0800 X-mProtect:  Wed, 6 Mar 2002 13:38:08 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdtqeHIU; Wed, 06 Mar 2002 13:38:06 PST Message-ID: <3C868C3E.44A42857@iprg.nokia.com> Date: Wed, 06 Mar 2002 13:38:06 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Karim El-Malki (ERA)" CC: ipng@sunroof.eng.sun.com Subject: Re: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00.txt -> wg last call?] References: <795A014AF92DD21182AF0008C7A404320DFBEFE5@esealnt117> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Karim, "Karim El-Malki (ERA)" wrote: > I agree that it would be good to see some guidelines in an > informational doc. However I disagree on the title change to > IPv6 over cellular/3g. That is a different spec which we should > also work on. It is possible to design "cellular" systems where the 3GPP/PDP address assignment is completely replaced by localized, stateless methods. The way that addresses are assigned is not related to bandwidth, nor even to essential authorization issues. It's an artifact of near-compatibility with existing 2.5G layouts. GGSN does not NECESSARILY need to control this process. Thus, any document which recommends that DAD or Neighbor Discovery might be executed rarely if ever, would not fit such "cellular" systems as I would hope eventually do come about. Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 13:45:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Lj8KL005858 for ; Wed, 6 Mar 2002 13:45:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Lj81p005857 for ipng-dist; Wed, 6 Mar 2002 13:45:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Lj6KL005850 for ; Wed, 6 Mar 2002 13:45:06 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g26LiMuX015215 for ; Wed, 6 Mar 2002 13:44:22 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g26LiL1w015214 for ipng@sunroof.eng.sun.com; Wed, 6 Mar 2002 13:44:21 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g260Q1KL001275 for ; Tue, 5 Mar 2002 16:26:01 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA04301 for ; Tue, 5 Mar 2002 16:26:02 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24317 for ; Tue, 5 Mar 2002 16:25:59 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id RAA16384 for ; Tue, 5 Mar 2002 17:25:58 -0700 (MST)] Received: [from brc9exm01.ipsg.mot.com (brc9exm01.ipsg.mot.com [138.242.16.16]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id RAA25174 for ; Tue, 5 Mar 2002 17:25:58 -0700 (MST)] Received: by brc9exm01.ipsg.mot.com with Internet Mail Service (5.5.2654.52) id <1KCH2BHD>; Tue, 5 Mar 2002 16:25:57 -0800 Message-ID: From: Delecki Andrew-Y10658 To: "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Tue, 5 Mar 2002 16:25:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, 3GPP implementation of stateless address autoconfiguration is a superposition of "true" stateless and stateful address autoconfigurations. The reason for this is that the "wireless equivalent link layer", which is "the PDP context pipe" extending from GGSN to the cellular host, has to be first established in order to convey any IPv6 messages. This severely limits the use of many IPv6 protocol features, e.g. neighbor discovery, router advertisement etc. In my view, the document in question (draft-ietf-ipv6-cellular-host-00. txt) omits this fact concentrating on the scenario in which "the PDP context" is established. The entire 3GPP mobility, session and connection management happens outside the user plane (IPv6 over PDP context) where IPv6 is not used. For this reason, the this document will have limited impact on the 3GPP and it does not fully explore many IPv6 protocol features. Regards, Andrew Delecki Motorola -----Original Message----- From: Margaret Wasserman [mailto:mrw@windriver.com] Sent: Tuesday, March 05, 2002 7:24 AM To: john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Hi John, > This router > most likely will not be a final destination for the host's traffic. > Additionally, due to special characteristics of the cellular link, > lower layer connectivity information should make it unnecessary to > track the reachability of the router. We have defined a mechanism to locate and maintain reachability information about neighbours in IPv6, called "Neighbor Discovery". This isn't an optional part of IPv6 that it would be appropriate to disable on a particular link type. However, it is expected for ND to receive "advice" from other layers regarding the "reachability" of another host -- so it would be great if the L2 mechanism gave ongoing advice to IPv6 regarding the reachability of the router, which would result in suppressing IPv6 NS messages. I don't believe that your conclusion is sound... >Therefore, Neighbor > Solicitation and Advertisement messages MAY be implemented for the > cellular interface. An implementor could read this and believe that it was acceptable to build a 3GPP cell phone (with only one cellular interface) that didn't even contain the _code_ necessary to generate IPv6 NS and NA messages. What happens when that host receives an NS message? Do you think that people may ever want to set-up redundant 3GPP networks, or make a choice between two possible 3GPP routers, based on their current reachability? If you don't use ND, how will this information be available for IPv6 routing decisions? There seems to be a mis-perception in the 3GPP community that ND will result in a lot of extra traffic. The idea of ND is to locate the other node _once_ and maintain reachability information about that node on an ongoing basis, using advice from other layers, _without_ sending additional ND messages unless absolutely necessary. Are there reasons why you think that this won't work on 3GPP hosts? >In addition, a cellular host SHOULD NOT send the > link layer sub-option on its cellular interface, and SHOULD silently > ignore it if received on the same interface. This is fine, and would be an excellent piece of information to put in a standards-track "IP over " document. >2.6 RFC2462 - IPv6 Stateless Address Autoconfiguration > > IPv6 Stateless Address Autoconfiguration [RFC-2462] MAY be > supported. This should be a MUST. IPv6 hosts MUST support address autoconfiguration, although it is possible for the routers to be configured so that it isn't used (if desired). > A cellular host SHOULD NOT perform Duplicate Address Detection on > its cellular interface, as each delegated prefix is unique within > its scope when allocated using the 3GPP IPv6 Stateless Address > Autoconfiguration. Will the router end of the link allocate any addresses within the unique /64 assigned to the PDP context? If so, what mechanism will be used to ensure that the host doesn't allocate the same address? If it's actually true that a conflict can never occur, then we should indicate that DAD won't be used on these link types in an "IPv6 over " document, as previously discussed. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Mar 6 13:45:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26LjYKL005868 for ; Wed, 6 Mar 2002 13:45:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26LjY6v005867 for ipng-dist; Wed, 6 Mar 2002 13:45:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26LjWKL005860 for ; Wed, 6 Mar 2002 13:45:32 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g26LimuX015223 for ; Wed, 6 Mar 2002 13:44:48 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g26Limjt015222 for ipng@sunroof.eng.sun.com; Wed, 6 Mar 2002 13:44:48 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26DPWKL003475 for ; Wed, 6 Mar 2002 05:25:32 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10192 for ; Wed, 6 Mar 2002 05:25:32 -0800 (PST) From: Jonne.Soininen@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA08191 for ; Wed, 6 Mar 2002 05:25:32 -0800 (PST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g26DRex01834 for ; Wed, 6 Mar 2002 07:27:41 -0600 (CST) Received: from daebh002.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 6 Mar 2002 07:25:30 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Wed, 6 Mar 2002 07:24:59 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Wed, 6 Mar 2002 05:24:57 -0800 Message-ID: <4D7B558499107545BB45044C63822DDE0A076A@mvebe001.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHFEk8iQfkjlJ4kT8GXDsx9ox6mbw== To: Cc: X-OriginalArrivalTime: 06 Mar 2002 13:24:59.0005 (UTC) FILETIME=[5047CAD0:01C1C512] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26DPWKL003476 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Karim wrote:] > I have a similar issue in mind. >If we have an "IPv6 over Cellular links" draft would that also include >some discussion on the rest e.g. security? That is, a security >section specifically for cellular links? For example, when you use IPsec, >IP header compression on the 3g link is not efficient and one of the >results is higher packet loss. I guess this is something that the >implementer should be told since it has to do with the specific link. >Just trying to figure out what the options are and what would go in an >eventual "IPv6 over Cellular links" draft. I have been in the process of writing an "IPv6 over PDP Context" or similar document. The 3GPP system has changed a bit in this aspect in the last few months, and that's why the document did not make it to this submission deadline. I try to better after IETF#53. I think there might be some things from this document that can be copied to the IPv6-over-... doc, but not all of this should be there. In addition, I am of the opinion that this "minimum requirements" document in a form or another is really needed. I think that this quite extensive discussion in the mailing list already proves that to some extent. The issues is not quite clear, what you actually have to implement, and what not, if you try to make a minimal implementation. I think the cellular host (here meaning a host with very limited capacity, burned-in stack, and a single low-bandwidth link) has some special characteristics, and will be quite significant in numbers that it already justified its own document. It might be that some of the wordings in the document have to be changed, and maybe a disclaimer put that what assumptions have to be fulfilled, if you drop some functionality out. Basically for instance stating that if you do not DAD, you better know what you are doing, and you better be on a point-to-point link - alone. Cheers, Jonne. -------- Jonne Soininen Nokia Tel. +1 650 864 6794 Cellular: +1 650 714 7733 Email: jonne.soininen@nokia.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 Mar 6 14:46:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26MkBKL006247 for ; Wed, 6 Mar 2002 14:46:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26MkBYR006246 for ipng-dist; Wed, 6 Mar 2002 14:46:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Mk7KL006239 for ; Wed, 6 Mar 2002 14:46:07 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA20205 for ; Wed, 6 Mar 2002 14:46:06 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03590 for ; Wed, 6 Mar 2002 14:46:05 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12634; Wed, 6 Mar 2002 17:45:59 -0500 (EST) Message-Id: <200203062245.RAA12634@ietf.org> To: IETF-Announce: ; Cc: RFC Editor , Internet Architecture Board , mmusic@ietf.org, ipng@sunroof.eng.sun.com From: The IESG Subject: Protocol Action: Support for IPv6 in SDP to Proposed Standard Date: Wed, 06 Mar 2002 17:45:59 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Support for IPv6 in SDP' as a Proposed Standard. This document is the product of the Multiparty Multimedia Session Control Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. It is a text format description that provides many details of a multimedia session including: the originator of the session, a URL related to the session, the connection address for the session media(s), and optional attributes for session media. Each of these pieces of information may involve one or more IPv6 addresses. The ABNF for IP addresses in the SDP specification (RFC2327) currently leaves the syntax for IPv6 address undefined. This specification clarifies the IPv6 address usage for SDP by filling in the IP6 address type syntax. It also defines the syntax of use of an IPv6 address literal in URI's carried as a field in SDP, following RFC2732. Accordingly, the address type "IP6" indicating an IPv6 address, becomes a clear part of the SDP standard. The ABNF style used in this draft matches that of RFC 2373 for consistency purposes. Working Group Summary The MMUSIC working group reached quick consensus on this specification. The working group is currently revising RFC2327 for advancement to Draft Standard. But pressing needs for SDP use of IPv6 addresses, including literals in many cases, due to construction of SDP fields after DNS lookup, urged the publication of this spec to clarify IP6 syntax now. The revised SDP specification will incorporate this added syntax. Protocol Quality The specification was Last Called in the IPv6 Working Group as well as MMUSIC. It received a large number of careful reviews by IPv6 specialists and was revised to reflect consensus from Last Call comments. The specification was reviewed for the IESG by Allison Mankin, Jonne Soininen and Margaret Wasserman. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 15:09:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26N9XKL006351 for ; Wed, 6 Mar 2002 15:09:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26N9XvA006350 for ipng-dist; Wed, 6 Mar 2002 15:09:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26N9UKL006343 for ; Wed, 6 Mar 2002 15:09:30 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA11939 for ; Wed, 6 Mar 2002 15:09:30 -0800 (PST) Received: from msgbas2.sgp.agilent.com (msgbas2x.net.asiapac.agilent.com [192.25.46.26]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14395 for ; Wed, 6 Mar 2002 15:09:29 -0800 (PST) Received: from msgrel1.sgp.agilent.com (msgrel1.sgp.agilent.com [141.183.101.233]) by msgbas2.sgp.agilent.com (Postfix) with ESMTP id 0B730F8; Thu, 7 Mar 2002 07:10:07 +0800 (SGP) Received: from apbrg1.sgp.agilent.com (apbrg1.sgp.agilent.com [141.183.6.40]) by msgrel1.sgp.agilent.com (Postfix) with SMTP id 473B25D4; Thu, 7 Mar 2002 07:08:53 +0800 (SGP) Received: from 141.183.6.40 by apbrg1.sgp.agilent.com (InterScan E-Mail VirusWall NT); Thu, 07 Mar 2002 07:09:27 +0800 Received: by apbrg1.sgp.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 07:09:27 +0800 Message-ID: <050F1F49D79BD3118F3B0090278CB91803A39D1F@apmail7.aus.agilent.com> From: "FIELD,GEOFF (A-Australia,ex1)" To: "'Karim El-Malki (ERA)'" , "FIELD,GEOFF (A-Australia,ex1)" , "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Thu, 7 Mar 2002 06:58:29 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It would be good if we kept 3G radio network architecture discussions > off this list. Fair enough, Karim, but this particular discussion is about IPv6 on 3G hosts. I felt that a very brief reminder of the architecture would help those (very) few on this list who aren't already familiar with it. > P.S. As a note the RNC, Node B, SGSN have nothing to do with > what we're > discussing and they're not involved in any of the IPv6 mechanisms > discussed so far. In point of fact, these three devices sit between the host (terminal) and the Internet, so they have to at least carry the data. I'm reasonably certain that at least one of them (probably the SGSN) will have to act as an IPv6 router for the purposes of connecting to the terminal. Geoff -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 15:26:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26NQlKL006414 for ; Wed, 6 Mar 2002 15:26:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26NQlAV006413 for ipng-dist; Wed, 6 Mar 2002 15:26:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26NQiKL006406 for ; Wed, 6 Mar 2002 15:26:44 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24454 for ; Wed, 6 Mar 2002 15:26:43 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA21255 for ; Wed, 6 Mar 2002 15:26:43 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g26NQfZc024999 for ; Thu, 7 Mar 2002 00:26:41 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 07 00:25:15 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 00:16:49 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA7C@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charles E. Perkins'" , "Karim El-Malki (ERA)" Cc: ipng@sunroof.eng.sun.com Subject: RE: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Thu, 7 Mar 2002 00:23:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Charlie I finally read the thread. > > I agree that it would be good to see some guidelines in an > > informational doc. However I disagree on the title change to > > IPv6 over cellular/3g. That is a different spec which we should > > also work on. > > It is possible to design "cellular" systems where the > 3GPP/PDP address assignment is completely replaced by > localized, stateless methods. The way that addresses > are assigned is not related to bandwidth, nor even to > essential authorization issues. It's an artifact of > near-compatibility with existing 2.5G layouts. GGSN > does not NECESSARILY need to control this process. > => That's fine, but we have to deal with what *is* right now and not what *may come*. There are people that want to roll out systems with IPv6 support today, R&D will no doubt improve things, but in this draft we need to deal with the current specs. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 15:26:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26NQeKL006404 for ; Wed, 6 Mar 2002 15:26:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26NQeZg006403 for ipng-dist; Wed, 6 Mar 2002 15:26:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26NQbKL006396 for ; Wed, 6 Mar 2002 15:26:37 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01303 for ; Wed, 6 Mar 2002 15:26:37 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18510 for ; Wed, 6 Mar 2002 16:26:36 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g26NQZZc024942 for ; Thu, 7 Mar 2002 00:26:35 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 07 00:25:12 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 00:25:12 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA7A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Margaret Wasserman'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 23:09:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry if this was already answered, but I'm not keeping up with email. > >=> Right, but would you agree that on a p2p link you > >don't actually *need* NS and NA? > >It's not a shared link, the prefix is implicitly > >delegated to the UE only. So I don't see why > >(apart from NUD) you would need NSs and NAs. > >Hence the MAY. > > I understand the argument for why you would not need to > use DAD. > > However, you would need to use NS and NA messages to > establish two-way reachability to the router, before > sending other IP packets to (or through) that router. > This is the basic neighbor discovery mechanism, and > I don't believe that it is optional on point-to-point > links. > => An RS and RA are used for this purpose. That's all you need in this particular scenario. They (RSs and RAs) are of course mandated in the draft. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 15:36:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26NaPKL006438 for ; Wed, 6 Mar 2002 15:36:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26NaPcm006437 for ipng-dist; Wed, 6 Mar 2002 15:36:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26NaMKL006430 for ; Wed, 6 Mar 2002 15:36:22 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15782 for ; Wed, 6 Mar 2002 15:36:22 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25500 for ; Wed, 6 Mar 2002 15:36:21 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA08498; Wed, 6 Mar 2002 15:36:21 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g26NaKa24095; Wed, 6 Mar 2002 15:36:20 -0800 X-mProtect:  Wed, 6 Mar 2002 15:36:20 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdFFxNMM; Wed, 06 Mar 2002 15:36:18 PST Message-ID: <3C86A7F3.6B783B24@iprg.nokia.com> Date: Wed, 06 Mar 2002 15:36:19 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" CC: ipng@sunroof.eng.sun.com Subject: Re: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00.txt -> wg last call?] References: <4DA6EA82906FD511BE2F00508BCF053802C6AA7C@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Hesham Soliman (ERA)" wrote: > => That's fine, but we have to deal with what *is* > right now and not what *may come*. > There are people that want to roll out systems with > IPv6 support today, R&D will no doubt improve > things, but in this draft we need to deal with > the current specs. That's exactly right, and I am suggesting that the draft be renamed to be "IPv6-support-for-what-exists-today". Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 15:41:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Nf2KL006477 for ; Wed, 6 Mar 2002 15:41:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Nf25m006476 for ipng-dist; Wed, 6 Mar 2002 15:41:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26NevKL006466 for ; Wed, 6 Mar 2002 15:40:57 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA19708 for ; Wed, 6 Mar 2002 15:40:57 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA18808 for ; Wed, 6 Mar 2002 16:40:56 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g26NetZc026868 for ; Thu, 7 Mar 2002 00:40:55 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Mar 07 00:40:54 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 00:39:33 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA7E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'FIELD,GEOFF (A-Australia,ex1)'" , "Karim El-Malki (ERA)" , "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Thu, 7 Mar 2002 00:34:12 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Geoff > > P.S. As a note the RNC, Node B, SGSN have nothing to do with > > what we're > > discussing and they're not involved in any of the IPv6 mechanisms > > discussed so far. > > In point of fact, these three devices sit between the host > (terminal) > and the Internet, so they have to at least carry the data. I'm > reasonably certain that at least one of them (probably the SGSN) > will have to act as an IPv6 router for the purposes of connecting > to the terminal. => No. The GGSN is the default router. Nothing else is seen by the end host. So in this discussion we should be concerned with the Host (UE in 3GPP specs) and the default router (GGSN) for all link-local issues. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 15:40:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26NepKL006457 for ; Wed, 6 Mar 2002 15:40:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26NepPh006456 for ipng-dist; Wed, 6 Mar 2002 15:40:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26NemKL006449 for ; Wed, 6 Mar 2002 15:40:48 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA17291 for ; Wed, 6 Mar 2002 15:40:48 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24842 for ; Wed, 6 Mar 2002 16:40:44 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id B8D575A07; Wed, 6 Mar 2002 18:40:43 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 18:40:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 18:40:43 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520756@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHFSajtdsavjQgxTEedBG0JFnIwLgAHqE3A From: "Bound, Jim" To: "Charles E. Perkins" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 06 Mar 2002 23:40:43.0742 (UTC) FILETIME=[550F47E0:01C1C568] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26NemKL006450 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hey I am all for giving it shot. /jim > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Wednesday, March 06, 2002 3:01 PM > To: Bound, Jim > Cc: Margaret Wasserman; ipng@sunroof.eng.sun.com > Subject: Re: Should DAD be optional? [Was > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > "Bound, Jim" wrote: > > > UNLESS: We go back to what informational means as Charlie > and I believe > > as it used to be? > > > > I doubt that is possible. > > Well, it's worth a shot, and the draft could include enough > text to make it obvious what is meant. That would only make > a difference to people who bother to even glance at the document, > but anybody implementing the platform would be likely to see it, > and any marketing literature would probably not risk the black > eye of provably misconstruing the document. > > Regards, > Charlie P. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 15:41:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Nf0KL006474 for ; Wed, 6 Mar 2002 15:41:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26Nf0tF006473 for ipng-dist; Wed, 6 Mar 2002 15:41:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26NetKL006459 for ; Wed, 6 Mar 2002 15:40:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05543 for ; Wed, 6 Mar 2002 15:40:55 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA24919 for ; Wed, 6 Mar 2002 16:40:54 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g26NerZc026853 for ; Thu, 7 Mar 2002 00:40:53 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 07 00:40:52 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 00:31:04 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA7D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Delecki Andrew-Y10658'" , "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Thu, 7 Mar 2002 00:31:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 3GPP implementation of stateless address autoconfiguration > is a superposition of "true" stateless and stateful address > autoconfigurations. > > The reason for this is that the "wireless equivalent link > layer", which is "the PDP context pipe" extending from GGSN > to the cellular host, has to be first established in order > to convey any IPv6 messages. > This severely limits the use of many IPv6 protocol > features, e.g. neighbor discovery, router advertisement etc. => It doesn't limit anything to do with RAs. It only eliminates the need for ethernet-type information like the link layer suboption. DAD is not needed, but people _can_ certainly send DAD messages if they really want to. NUD is also possible. GGSNs should support NUD as was mentioned earlier. > In my view, the document in question > (draft-ietf-ipv6-cellular-host-00. txt) omits this fact > concentrating on the scenario in which "the PDP context" is > established. => Which part of the document does that? > For this reason, the this document will have limited impact > on the 3GPP and it does not fully explore many IPv6 > protocol features. > => I'm not sure what mean. The document is not intended to affect 3GPP specs. The document does not eliminate any IPv6 features. For the generic cellular host, almost all features are included, but there are exceptions for 3GPP hosts due to the _3GPP_system_ which makes some functions (like DAD) unnecessary. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 15:43:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26NhBKL006508 for ; Wed, 6 Mar 2002 15:43:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g26NhAGf006507 for ipng-dist; Wed, 6 Mar 2002 15:43:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g26Nh7KL006500 for ; Wed, 6 Mar 2002 15:43:07 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29916 for ; Wed, 6 Mar 2002 15:43:07 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26702 for ; Wed, 6 Mar 2002 15:43:07 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 982162F19; Wed, 6 Mar 2002 18:43:06 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 18:43:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Wed, 6 Mar 2002 18:43:06 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520757@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHFUn0s6WvZdCaBR/y9+PsM2wAP9QAFeycw From: "Bound, Jim" To: "Margaret Wasserman" , "Charles E. Perkins" Cc: X-OriginalArrivalTime: 06 Mar 2002 23:43:06.0510 (UTC) FILETIME=[AA27F2E0:01C1C568] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g26Nh7KL006501 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't know about others but I don't support what your ammenable to. Your watering it down. I don't want it watered down. Do it out of the IETF. /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Wednesday, March 06, 2002 3:59 PM > To: Charles E. Perkins > Cc: Bound, Jim; ipng@sunroof.eng.sun.com > Subject: Re: Should DAD be optional? [Was > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > > I'd be amenable some sort of "guidelines" document that offers > some guidance to 3GPP vendors on which portions of which IPv6 > specifications should be implemented in cellular hosts. With > the following characteristics: > > - The document should clearly state that it is not > a standard, and that it doesn't modify any > other standards. I know that "informational" > status implies this, but I think it should > be explicit in the document. > - The MUST, MAY, SHOULD... wording should be removed. > - All conflicts with existing IPv6 standards should be > eliminated. > - The document should be re-worked to focus more on > referring cellular implementers to the correct > IPv6 standards. > - We should not recommend anything that we don't > agree with -- for instance, if we think that > IP Sec should be included in all IPv6 hosts, > this document shouldn't say otherwise. > > Margaret > > > At 03:01 PM 3/6/02 , Charles E. Perkins wrote: > >"Bound, Jim" wrote: > > > > > UNLESS: We go back to what informational means as Charlie > and I believe > > > as it used to be? > > > > > > I doubt that is possible. > > > >Well, it's worth a shot, and the draft could include enough > >text to make it obvious what is meant. That would only make > >a difference to people who bother to even glance at the document, > >but anybody implementing the platform would be likely to see it, > >and any marketing literature would probably not risk the black > >eye of provably misconstruing the document. > > > >Regards, > >Charlie P. > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 19:17:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g273HaKL006756 for ; Wed, 6 Mar 2002 19:17:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g273Haun006755 for ipng-dist; Wed, 6 Mar 2002 19:17:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g273HWKL006748 for ; Wed, 6 Mar 2002 19:17:33 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05958 for ; Wed, 6 Mar 2002 19:17:33 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA03036 for ; Wed, 6 Mar 2002 19:17:33 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id TAA23553 for ; Wed, 6 Mar 2002 19:17:32 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g273HVI17833 for ; Wed, 6 Mar 2002 19:17:31 -0800 X-mProtect:  Wed, 6 Mar 2002 19:17:31 -0800 Nokia Silicon Valley Messaging Protection Received: from vijayd.iprg.nokia.com (205.226.2.94, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBkDONc; Wed, 06 Mar 2002 19:17:30 PST Message-ID: <3C86DBCA.C25E6E6@iprg.nokia.com> Date: Wed, 06 Mar 2002 19:17:30 -0800 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: source and dst addr for Neighbor Solicitation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi, A simple question. When would you ever use global source and destination addresses for a neighbor solicitation. And why? IMO, link local addresses must be used. But RFC 2461 does not say this. It just says an address configured to the interface. That can mean global addresses. I saw such a packet at Connectathon (going on in San Jose). Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 20:29:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g274TcKL006977 for ; Wed, 6 Mar 2002 20:29:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g274TcVP006976 for ipng-dist; Wed, 6 Mar 2002 20:29:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g274TYKL006969 for ; Wed, 6 Mar 2002 20:29:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA02825 for ; Wed, 6 Mar 2002 20:29:35 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA19227 for ; Wed, 6 Mar 2002 20:29:35 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id CDF243549; Wed, 6 Mar 2002 23:29:34 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 23:29:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: source and dst addr for Neighbor Solicitation Date: Wed, 6 Mar 2002 23:29:34 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520758@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: source and dst addr for Neighbor Solicitation Thread-Index: AcHFh2Q5glDIFMulTZGmXmLxYUfiwgACUKBA From: "Bound, Jim" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 07 Mar 2002 04:29:34.0883 (UTC) FILETIME=[AF398730:01C1C590] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g274TZKL006970 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Because you can. /jim > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Wednesday, March 06, 2002 10:18 PM > To: ipng@sunroof.eng.sun.com > Subject: source and dst addr for Neighbor Solicitation > > > hi, > > A simple question. When would you ever use global source > and destination addresses for a neighbor solicitation. > And why? > > IMO, link local addresses must be used. But RFC 2461 does > not say this. It just says an address configured to the > interface. That can mean global addresses. I saw such a > packet at Connectathon (going on in San Jose). > > Vijay > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 6 20:41:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g274fYKL007026 for ; Wed, 6 Mar 2002 20:41:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g274fYvt007025 for ipng-dist; Wed, 6 Mar 2002 20:41:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g274fUKL007018 for ; Wed, 6 Mar 2002 20:41:31 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA09100 for ; Wed, 6 Mar 2002 20:41:32 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08431 for ; Wed, 6 Mar 2002 20:41:30 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g274g8i10043 for ; Thu, 7 Mar 2002 06:42:08 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 7 Mar 2002 06:41:29 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 7 Mar 2002 06:41:29 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Thu, 7 Mar 2002 06:41:28 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B58@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Thread-Index: AcHFY/mQPWLkYd6GQ7OYRohwJgN1oQALifag To: , , Cc: X-OriginalArrivalTime: 07 Mar 2002 04:41:29.0198 (UTC) FILETIME=[58FD58E0:01C1C592] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g274fVKL007019 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Geoff, > Fair enough, Karim, but this particular discussion is about IPv6 on > 3G hosts. I felt that a very brief reminder of the architecture > would help those (very) few on this list who aren't already > familiar with it. Would it be helpful if we have additional information about what the layer 2 is providing in this case - I don't know if heavy architectural details are needed, but at least an explanation of the mechanism - with references for those who want to read more. thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 21:03:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2753hKL007078 for ; Wed, 6 Mar 2002 21:03:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2753hWd007077 for ipng-dist; Wed, 6 Mar 2002 21:03:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2753eKL007070 for ; Wed, 6 Mar 2002 21:03:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA21804 for ; Wed, 6 Mar 2002 21:03:41 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA24927 for ; Wed, 6 Mar 2002 22:03:40 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 4C420377D; Thu, 7 Mar 2002 00:03:40 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Thu, 7 Mar 2002 00:03:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Thu, 7 Mar 2002 00:03:39 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B34C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHFUn0s6WvZdCaBR/y9+PsM2wAP9QAQI+Ag From: "Bound, Jim" To: "Margaret Wasserman" , "Charles E. Perkins" Cc: X-OriginalArrivalTime: 07 Mar 2002 05:03:40.0336 (UTC) FILETIME=[7268E300:01C1C595] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2753eKL007071 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, OK people want to keep trying. > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Wednesday, March 06, 2002 3:59 PM > To: Charles E. Perkins > Cc: Bound, Jim; ipng@sunroof.eng.sun.com > Subject: Re: Should DAD be optional? [Was > draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > > I'd be amenable some sort of "guidelines" document that offers > some guidance to 3GPP vendors on which portions of which IPv6 > specifications should be implemented in cellular hosts. With > the following characteristics: I would suggest a set for guidelines for the current 3GGP Release 5 vendors shipping IPv6 for that stated use and keep the focus of the document as limited as possible. The purpose of the doc is state which specifications "are most likely to be used" (NOT IMPLEMENTED) by a 3GGP Release 5 UMTS Cellular Host. VEry very specific. Note this is a use document not a what must, should, or may be implemented. It is truly an implementation guideline for Release 5. > > - The document should clearly state that it is not > a standard, and that it doesn't modify any > other standards. I know that "informational" > status implies this, but I think it should > be explicit in the document. I suggest that if use the scope and method I state above then this is not necessary. What an overview should do is state in better and more words what I am suggesting above. Not only is not a standard but by its very nature its not even close to suggesting that in the document. > - The MUST, MAY, SHOULD... wording should be removed. I would keep them in another context why something will or will not be used in Release 5 and why it will or why not. The doc does this good enough for me now but I understand 3GPP implementation, how to build a 3GPP product, and the market needs for Rel 5. So I am at an advantage and may see more than others so a bit more words I can accept is needed if it must be reviewed by this working group. > - All conflicts with existing IPv6 standards should be > eliminated. This is a non issue with my approach the entire point is not in conflict. The conflict is that all the standards are not needed for this initial deployment at this time. > - The document should be re-worked to focus more on > referring cellular implementers to the correct > IPv6 standards. This is a shot at the authors and wrong. At least thats how I read it. The authors have the correct standards just saying they are all not needed for Rel 5. These authors are some of the most knowledgable people for 3GGP and IPv6 on the planet. Give them a break. This is not an issue no matter how this gets resolved. But this is the kind of tone that really wants me to influence these authors to take it out of the IETF and be done with this discussion. > - We should not recommend anything that we don't > agree with -- for instance, if we think that > IP Sec should be included in all IPv6 hosts, > this document shouldn't say otherwise. The suggestion above is a recommendation of use not what is implemented on cellular hosts. John et al this is about as much as I will compromise from my view. If we can't get folks to buy into what I suggest or at least in between what I suggest and Magarets decree I strongly suggest to you that you will miss what we know is a time to market issue and you are better off working this through the ITU, 3GGP, and 3GGP2 and I will go there and am confident that others from here will too, to support you. regards, /jim > > Margaret > > > At 03:01 PM 3/6/02 , Charles E. Perkins wrote: > >"Bound, Jim" wrote: > > > > > UNLESS: We go back to what informational means as Charlie > and I believe > > > as it used to be? > > > > > > I doubt that is possible. > > > >Well, it's worth a shot, and the draft could include enough > >text to make it obvious what is meant. That would only make > >a difference to people who bother to even glance at the document, > >but anybody implementing the platform would be likely to see it, > >and any marketing literature would probably not risk the black > >eye of provably misconstruing the document. > > > >Regards, > >Charlie P. > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 6 21:07:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2757vKL007097 for ; Wed, 6 Mar 2002 21:07:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2757vOW007096 for ipng-dist; Wed, 6 Mar 2002 21:07:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2757sKL007089 for ; Wed, 6 Mar 2002 21:07:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA14083 for ; Wed, 6 Mar 2002 21:07:55 -0800 (PST) Received: from msgbas1.sgp.agilent.com (msgbas1x.net.asiapac.agilent.com [192.25.42.26]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA29935 for ; Wed, 6 Mar 2002 22:07:52 -0700 (MST) Received: from msgrel1.sgp.agilent.com (msgrel1.sgp.agilent.com [141.183.101.233]) by msgbas1.sgp.agilent.com (Postfix) with ESMTP id 3FD232CD; Thu, 7 Mar 2002 13:07:51 +0800 (SGP) Received: from apbrg2.jpn.agilent.com (apbrg2.jpn.agilent.com [146.208.102.163]) by msgrel1.sgp.agilent.com (Postfix) with SMTP id 6697D556; Thu, 7 Mar 2002 13:07:16 +0800 (SGP) Received: from 146.208.102.163 by apbrg2.jpn.agilent.com (InterScan E-Mail VirusWall NT); Thu, 07 Mar 2002 14:07:47 +0900 Received: by apbrg2.jpn.agilent.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 14:07:46 +0900 Message-ID: <050F1F49D79BD3118F3B0090278CB91803A39D26@apmail7.aus.agilent.com> From: "FIELD,GEOFF (A-Australia,ex1)" To: "'john.loughney@nokia.com'" , "FIELD,GEOFF (A-Australia,ex1)" , Karim.El-Malki@era.ericsson.se, mrw@windriver.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Thu, 7 Mar 2002 14:07:23 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Fair enough, Karim, but this particular discussion is about IPv6 on > > 3G hosts. I felt that a very brief reminder of the architecture > > would help those (very) few on this list who aren't already > > familiar with it. > > Would it be helpful if we have additional information about what > the layer 2 is providing in this case - I don't know if heavy > architectural details are needed, but at least an explanation > of the mechanism - with references for those who want to read > more. In the 3G stacks, IP runs over AAL-5 (spec I.363.5), which runs over ATM (spec I.361). However, it's not as simple as that - each link actually has *two* stacks - a User-Plane stack and a Control-Plane stack. In the Control Plane, it's RANAP (TS 25-413) over SCCP (Q.711) over M3UA (RFC2719 I think) over SCTP (RFC2960) over IP. In the User Plane it's IuUP (TS25.415) over GTP-u (TS 29.060) over UDP over IP. This is between the RNC and the SGSN. To be honest, I'm not sure where it occurs in between the RNC and the terminal/host - the Radio Network stack on the User Plane is PDCP/RLC/MAC/FP. (I don't have a reference for the spec numbers handy at the moment.) These sit on a Transport stack of AAL-2/ATM between the Node B and the RNC. I suspect IP between the terminal and the Internet would sit on top of the User Plane stacks. There are others on this list with far more expertise in this field than I. Is this helpful to the discussion? Only if we know what the lower layers are providing to IP. Virtually every layer provides addressing for the point-to-point link. FP provides encryption if desired. The RNC provides considerable intelligence for mapping connection IDs to mobile terminals. Based on what, I'm not entirely sure, but I suspect it's more to do with the telephone number than the IP address. Similarly, the SGSN provides mapping between the connection ID and the RNC(s). As I said, both these devices provide router-like functionality. Actually, it's probably closer to a telephone exchange system - after all, most of the companies making these products are telephony equipment manufacturers. I am coming to believe, however, that the manufacturers of 3G mobile terminals will need to implement standard IPv6 host requirements in the products, or at least a way of informing the fixed infrastructure of what isn't implemented. The problems of interoperability and mobile routing systems contribute to this opinion. I also agree with the point about triggering a plethora of "IPv6 over " documents, each listing an individual set of exceptions, and each based on a slightly different draft of the base document - I'm sure you could do without these nightmares as well. Geoff -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 22:28:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g276SRKL007286 for ; Wed, 6 Mar 2002 22:28:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g276SRHZ007285 for ipng-dist; Wed, 6 Mar 2002 22:28:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g276SOKL007278 for ; Wed, 6 Mar 2002 22:28:24 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA21295 for ; Wed, 6 Mar 2002 22:28:24 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA03417 for ; Wed, 6 Mar 2002 23:28:23 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g276SMZc024983 for ; Thu, 7 Mar 2002 07:28:22 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 07 07:28:21 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 07:28:22 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA81@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Delecki Andrew-Y10658'" , "Hesham Soliman (ERA)" , "'Charles E. Perkins'" , "Karim El-Malki (ERA)" Cc: ipng@sunroof.eng.sun.com Subject: RE: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Thu, 7 Mar 2002 07:28:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew and all, > > This what is in current 3GPP specifications, is not > necessarily the "right thing". => Let's keep this discussion within the scope of 'what's relevant' to our work and this WG. Please note 2 points: - We are NOT interested in fixing every SDOs architecture. I can think of a dozen things that would improve 3GPP/2's systems, but as far as this work and IETF in general are concerned, this is irrelevant. - We want to run IPv6 ASAP for obvious reasons. This would mean we take what's out there and see how we can run IPv6 over it. > > Recommendation shall include the right network topology and > IPv6 mechanism, not deal with system, which is only "half" right. => Getting the right architecture ...etc is not our job in this WG. This is something for you and your 3GPP colleagues. So please try to provide us with concrete technical comments on the draft. All we want is to improve the work in a way that makes it useful for implementors. I don't see a point in redesigning cellular systems on this mailing list. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 22:31:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g276V1KL007306 for ; Wed, 6 Mar 2002 22:31:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g276V1Xu007305 for ipng-dist; Wed, 6 Mar 2002 22:31:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g276UwKL007298 for ; Wed, 6 Mar 2002 22:30:58 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA21776 for ; Wed, 6 Mar 2002 22:30:58 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA04174 for ; Wed, 6 Mar 2002 23:30:57 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g276UuZc025771 for ; Thu, 7 Mar 2002 07:30:56 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 07 07:30:55 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 07:30:56 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA82@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Delecki Andrew-Y10658'" , "Hesham Soliman (ERA)" , "'FIELD,GEOFF (A-Australia,ex1)'" , "Karim El-Malki (ERA)" , "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Thu, 7 Mar 2002 07:30:54 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew, > => No. The GGSN is the default router. Nothing else > >is seen by the end host. So in this discussion > >we should be concerned with the Host (UE in 3GPP specs) > >and the default router (GGSN) for all link-local > >issues. > > Not true. > > The host sees GGSN only through PDP context pipe if PDP > context is set to IPv6/v4 type. > > Through control plane it is talking only to SGSN, which > handles entire call control and mobility management > (distinct from mobile IP). > => As far as the IP LAYER is concerned, we only care about the GGSN as the default router. Anything else we can label L2! Let's not confuse the issues at hand. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 6 22:39:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g276dcKL007325 for ; Wed, 6 Mar 2002 22:39:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g276dcY2007324 for ipng-dist; Wed, 6 Mar 2002 22:39:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g276dYKL007317 for ; Wed, 6 Mar 2002 22:39:34 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA22780 for ; Wed, 6 Mar 2002 22:39:34 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA24669 for ; Wed, 6 Mar 2002 23:39:33 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g276dWB04765 for ; Thu, 7 Mar 2002 07:39:32 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 07 07:39:31 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 07:29:43 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA83@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Delecki Andrew-Y10658'" , "Hesham Soliman (ERA)" , "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Thu, 7 Mar 2002 07:32:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The main problem with using the Router Advertisement is > that the cellular host shall have its knowledge before the > PDP context is established. => What knowledge? will it know the global prefix for example? Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 01:34:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g279YiKL007608 for ; Thu, 7 Mar 2002 01:34:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g279Yh6w007607 for ipng-dist; Thu, 7 Mar 2002 01:34:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g279YeKL007600 for ; Thu, 7 Mar 2002 01:34:40 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA15279 for ; Thu, 7 Mar 2002 01:34:41 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03895 for ; Thu, 7 Mar 2002 02:34:36 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g279YCB29138; Thu, 7 Mar 2002 10:34:12 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id KAA29040; Thu, 7 Mar 2002 10:34:12 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g279YCg17735; Thu, 7 Mar 2002 10:34:12 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203070934.g279YCg17735@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli cc: ipng@sunroof.eng.sun.com Subject: Re: source and dst addr for Neighbor Solicitation In-reply-to: Your message of Wed, 06 Mar 2002 19:17:30 PST. <3C86DBCA.C25E6E6@iprg.nokia.com> Date: Thu, 07 Mar 2002 10:34:12 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: A simple question. When would you ever use global source and destination addresses for a neighbor solicitation. => there is no real constraint on addresses, only some special cases (unspecified source and multicast destination). This keeps the door open for some optimizations. And why? => if the two neighbors initiate a direct communication using global addresses, to use global addresses in neighbor solicitation avoid to create context (aka neighbor cache entries) for both global addresses and link-local addresses. IMO, link local addresses must be used. => please don't shut doors on our fingers (:-)... But RFC 2461 does not say this. It just says an address configured to the interface. That can mean global addresses. I saw such a packet at Connectathon (going on in San Jose). => yes, local traffic usually is with global addresses in NSs, not local one uses nearly always link-locals because routers are known by their link-local addresses (some implementations even enforce link-local addresses in the gateway field of routes). Regards Francis.Dupont@enst-bretagne.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 Thu Mar 7 02:57:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27AvJKL007781 for ; Thu, 7 Mar 2002 02:57:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27AvJcP007780 for ipng-dist; Thu, 7 Mar 2002 02:57:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27AvGKL007773 for ; Thu, 7 Mar 2002 02:57:16 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA24485 for ; Thu, 7 Mar 2002 02:57:16 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15315 for ; Thu, 7 Mar 2002 02:57:15 -0800 (PST) Received: from tarski.cs.uni-bonn.de (tarski.cs.uni-bonn.de [131.220.4.200]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id LAA15297; Thu, 7 Mar 2002 11:57:12 +0100 (MET) Received: (from ignatios@localhost) by tarski.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA21192; Thu, 7 Mar 2002 11:56:35 +0100 (CET) Date: Thu, 7 Mar 2002 11:56:35 +0100 From: Ignatios Souvatzis To: "Bound, Jim" Cc: Francis Dupont , Jari Arkko , Margaret Wasserman , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Message-ID: <20020307115634.A21175@tarski.cs.uni-bonn.de> References: <9C422444DE99BC46B3AD3C6EAFC9711B01520709@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B01520709@tayexc13.americas.cpqcorp.net>; from Jim.Bound@compaq.com on Wed, Mar 06, 2002 at 12:21:08PM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Wed, Mar 06, 2002 at 12:21:08PM -0500, Bound, Jim wrote: > It will take us years to secure all that we have to. IPsec has been > mandated since 1996 at least. Yet is was the last IPv6 spec in products > and I think compaq and ibm are the only vendors with product ipsec for > ipv6. - Plus Solaris8, at least according to the man... ah, _for ipv6_? This I don't know. - Plus people intrating KAME based stacks. Regards, -is --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPIdHXTCn4om+4LhpAQGquwgAomkvJKYOpuUWcfsCyEaM2hT/BvY++0ET QjaEHvttl0X3L+PU/FnISVdgbX+66y7Kc7UDfqdMslN3Il79vCp6ubokQuB0Unhr DGSCH0L8A0ssTKMi8tpJVclpjRDquNfMR8OM02NXp5uZLAfvUXq+wC+HGi4fvZcx pzsRfx10wOWiZe5r85AgdsXNtOLpa607BCNTnOlMxIfGp6JE54j4RGH201+Ze9uF XDK7iESNN9zfj2f40entA/taJOrZY6uV/VoVcvnccEa5clkUDufNRvxXF+aVL9l9 XKgCeN/o7S3rdxczr08Ona2iIbFBDEoKQyjgYoTr/AwmJcL+ERcbTQ== =5ZCA -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 03:02:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27B2XKL007806 for ; Thu, 7 Mar 2002 03:02:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27B2XY5007805 for ipng-dist; Thu, 7 Mar 2002 03:02:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27B2UKL007798 for ; Thu, 7 Mar 2002 03:02:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA23962 for ; Thu, 7 Mar 2002 03:02:30 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA24580 for ; Thu, 7 Mar 2002 04:02:28 -0700 (MST) Received: from tarski.cs.uni-bonn.de (tarski.cs.uni-bonn.de [131.220.4.200]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id MAA15459 for ; Thu, 7 Mar 2002 12:02:26 +0100 (MET) Received: (from ignatios@localhost) by tarski.cs.uni-bonn.de (8.9.1a/8.9.1) id MAA21238 for ipng@sunroof.eng.sun.com; Thu, 7 Mar 2002 12:01:48 +0100 (CET) Date: Thu, 7 Mar 2002 12:01:48 +0100 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Message-ID: <20020307120148.B21175@tarski.cs.uni-bonn.de> References: <9C422444DE99BC46B3AD3C6EAFC9711B015206FC@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="U+BazGySraz5kW0T" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B015206FC@tayexc13.americas.cpqcorp.net>; from Jim.Bound@compaq.com on Wed, Mar 06, 2002 at 11:52:15AM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --U+BazGySraz5kW0T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 06, 2002 at 11:52:15AM -0500, Bound, Jim wrote: > Margaret, >=20 > What is required for a full implementation for IPv6 by the standards is > set in stone. Vendors that don't adhere to this are risking to much. > What they deploy and what standards is different issue. =20 >=20 > I can have IPsec (and do) in a product source pool and in the product. > But I will give users the ability to disable it if they want to not take > the performance hit and deal with the security risk. =2E.. and the interoperability problem ... are they aware of that? I can understand people want to disable DAD for very specialized links, but= ... IPSec is no link layer feature, it is a (mostly-)END to END feature (where END might be your trusted border router). Regards, -is --U+BazGySraz5kW0T Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPIdImjCn4om+4LhpAQEpoAgAh6K3JDaAoSUh02e5e8ZygGUN9XQMha4y 9stmTnSauLFgTdX1MvzCt1hQrMEBdQUnvXp1TQj6VJXhEE73fk2XrLAHmK+gum6g M0qiC0KCVJCzwfcO8HgJzozPpBkFg3QAyImnA5fV3b/Eu0VoElyETD44AVH9EkbJ nxGB+3GWyDnt4XWyx1p4qF/puhA6o0YaoyAEsax1aNCmhAbIsQn8dnzDXzDfqgQP zIyYVCiE7+VE/d4c/oLVg6+JRQLWOBMq6EQ92fGZREE7Xfqr3nSFuiuNZOmau3si JdIV4853GjUfM4ZjFVX51/eN03P9SZfqBXGp9z9oADjoUlN125BcAg== =3pmM -----END PGP SIGNATURE----- --U+BazGySraz5kW0T-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 03:03:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27B32KL007823 for ; Thu, 7 Mar 2002 03:03:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27B3295007822 for ipng-dist; Thu, 7 Mar 2002 03:03:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27B2xKL007815 for ; Thu, 7 Mar 2002 03:02:59 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25698 for ; Thu, 7 Mar 2002 03:02:58 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA26426 for ; Thu, 7 Mar 2002 04:02:57 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g27B2uZc022887 for ; Thu, 7 Mar 2002 12:02:56 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 07 12:00:54 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 11:51:05 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFE8@esealnt117> From: "Karim El-Malki (ERA)" To: "'Delecki Andrew-Y10658'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Thu, 7 Mar 2002 11:59:44 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew, Can we keep 3gpp architecture discussions OFF this list? What we are talking about is an IPv6 host with a point-to-point link to a router. They run PPP and the router delegates a global prefix to the host. The router doesn't configure any address on the delegated prefix and it supports NS/NAs. I know the 3gpp specs well and that's the scenario that is portrayed. It's not an abnormal IPv6 scenario as is clear from above, so there's no "half right" stuff. Statements like yours just try to take away value from the effort that 3gpp and ietf have done so far to get 3gpp in line with IPv6. And they're not succeeding either. /Karim > -----Original Message----- > From: Delecki Andrew-Y10658 [mailto:AndrewDelecki@motorola.com] > Sent: den 7 mars 2002 01:11 > To: 'Hesham Soliman (ERA)'; 'Charles E. Perkins'; Karim > El-Malki (ERA) > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Should DAD be optional? > [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] > Importance: High > > > Dear Hesham, > > This what is in current 3GPP specifications, is not > necessarily the "right thing". > > Recommendation shall include the right network topology and > IPv6 mechanism, not deal with system, which is only "half" right. > > Andrew D. > > Motorola > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Wednesday, March 06, 2002 3:24 PM > To: 'Charles E. Perkins'; Karim El-Malki (ERA) > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Should DAD be optional? > [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] > > > Hi Charlie > > I finally read the thread. > > > > I agree that it would be good to see some guidelines in an > > > informational doc. However I disagree on the title change to > > > IPv6 over cellular/3g. That is a different spec which we should > > > also work on. > > > > It is possible to design "cellular" systems where the > > 3GPP/PDP address assignment is completely replaced by > > localized, stateless methods. The way that addresses > > are assigned is not related to bandwidth, nor even to > > essential authorization issues. It's an artifact of > > near-compatibility with existing 2.5G layouts. GGSN > > does not NECESSARILY need to control this process. > > > > => That's fine, but we have to deal with what *is* > right now and not what *may come*. > There are people that want to roll out systems with > IPv6 support today, R&D will no doubt improve > things, but in this draft we need to deal with > the current specs. > > > Hesham > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 7 03:07:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27B7eKL007848 for ; Thu, 7 Mar 2002 03:07:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27B7eY2007847 for ipng-dist; Thu, 7 Mar 2002 03:07:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27B7bKL007840 for ; Thu, 7 Mar 2002 03:07:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA26523 for ; Thu, 7 Mar 2002 03:07:36 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA26330 for ; Thu, 7 Mar 2002 04:07:35 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g27B7YZc025504 for ; Thu, 7 Mar 2002 12:07:34 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Mar 07 12:07:34 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 12:07:34 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFEA@esealnt117> From: "Karim El-Malki (ERA)" To: "'FIELD,GEOFF (A-Australia,ex1)'" , "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Thu, 7 Mar 2002 12:06:21 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > P.S. As a note the RNC, Node B, SGSN have nothing to do with > > what we're > > discussing and they're not involved in any of the IPv6 mechanisms > > discussed so far. > > In point of fact, these three devices sit between the host (terminal) > and the Internet, so they have to at least carry the data. I'm > reasonably certain that at least one of them (probably the SGSN) > will have to act as an IPv6 router for the purposes of connecting > to the terminal. That's wrong. But anyway, these are 3gpp architecture discussions which are best kept in 3gpp. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 03:41:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27BffKL007963 for ; Thu, 7 Mar 2002 03:41:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27Bffh7007962 for ipng-dist; Thu, 7 Mar 2002 03:41:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27BfbKL007955 for ; Thu, 7 Mar 2002 03:41:37 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA09355 for ; Thu, 7 Mar 2002 03:41:37 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA21003 for ; Thu, 7 Mar 2002 04:41:36 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g27BfZB28109 for ; Thu, 7 Mar 2002 12:41:35 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 07 12:40:14 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 12:30:25 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFEB@esealnt117> From: "Karim El-Malki (ERA)" To: "'Ignatios Souvatzis'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cel lular-host-00.txt -> wg last call?] Date: Thu, 7 Mar 2002 12:39:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On Wed, Mar 06, 2002 at 11:52:15AM -0500, Bound, Jim wrote: > > Margaret, > > > > What is required for a full implementation for IPv6 by the > standards is > > set in stone. Vendors that don't adhere to this are > risking to much. > > What they deploy and what standards is different issue. > > > > I can have IPsec (and do) in a product source pool and in > the product. > > But I will give users the ability to disable it if they > want to not take > > the performance hit and deal with the security risk. > > ... and the interoperability problem ... are they aware of that? > > I can understand people want to disable DAD for very > specialized links, but... > IPSec is no link layer feature, it is a (mostly-)END to END > feature (where > END might be your trusted border router). You want to support IPsec and that's fine. However I don't think you always want to run IPsec when the result is for example a possible higher packet loss rate. That depends on the cellular link where IP headers are compressed (see ROHC WG). Smaller packets have a lower probability of errors over the air. If you encrypt using IPsec you can't compress headers as well any more. So the implementer/user must be aware of this link specific issue which may affect IPsec traffic. In that case he may very well want to disable IPsec and deal with it. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 04:19:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27CJ9KL008029 for ; Thu, 7 Mar 2002 04:19:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27CJ9cv008028 for ipng-dist; Thu, 7 Mar 2002 04:19:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27CJ6KL008021 for ; Thu, 7 Mar 2002 04:19:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03381 for ; Thu, 7 Mar 2002 04:19:06 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA20212 for ; Thu, 7 Mar 2002 05:19:04 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g27CM3f03158; Thu, 7 Mar 2002 19:22:09 +0700 (ICT) From: Robert Elz To: "Karim El-Malki (ERA)" cc: "'Ignatios Souvatzis'" , ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cel lular-host-00.txt -> wg last call?] In-Reply-To: <795A014AF92DD21182AF0008C7A404320DFBEFEB@esealnt117> References: <795A014AF92DD21182AF0008C7A404320DFBEFEB@esealnt117> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 19:22:03 +0700 Message-ID: <3156.1015503723@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 7 Mar 2002 12:39:07 +0100 From: "Karim El-Malki (ERA)" Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFEB@esealnt117> | You want to support IPsec and that's fine. However I don't | think you always want to run IPsec when the result is for | example a possible higher packet loss rate. No, of course you don't always want to run it. Why you you think that anyone always wants to run it? But when you need IPsec, you need it - and that you happen to be using a cellular link for some particular communications is irrelevant. Whether to use IPsec or not will depend upon the particular communications at any particular instant, and needs to be able to be determined by the user - certainly never by the implementor, who has no idea what environment (which includes the remote end of communications) the equipment will be used in. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 7 04:30:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27CUpKL008054 for ; Thu, 7 Mar 2002 04:30:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27CUpI2008053 for ipng-dist; Thu, 7 Mar 2002 04:30:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27CUlKL008046 for ; Thu, 7 Mar 2002 04:30:47 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA17947 for ; Thu, 7 Mar 2002 04:30:47 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA26658 for ; Thu, 7 Mar 2002 05:30:46 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g27CUkB10621 for ; Thu, 7 Mar 2002 13:30:46 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 07 13:30:07 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 13:19:38 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFEC@esealnt117> From: "Karim El-Malki (ERA)" To: "'Charles E. Perkins'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Thu, 7 Mar 2002 13:28:18 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'd prefer dealing with what we have now first since I'd like to see v6 deployed in 3g in the near term. We could discuss for a long time on how to improve a certain cellular system and we probably all have our ideas but that discussion would not belong here. Regarding the DAD issue, it's the same thing that can be done on any PPP link between a host and a router with prefix delegation. DAD can be disabled there, so no point of saying it can't be done in a cellular system that is the same as that PPP link from the IPv6 point of view. /Karim > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: den 6 mars 2002 22:38 > To: Karim El-Malki (ERA) > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Should DAD be optional? > [Wasdraft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > Hello Karim, > > "Karim El-Malki (ERA)" wrote: > > > I agree that it would be good to see some guidelines in an > > informational doc. However I disagree on the title change to > > IPv6 over cellular/3g. That is a different spec which we should > > also work on. > > It is possible to design "cellular" systems where the > 3GPP/PDP address assignment is completely replaced by > localized, stateless methods. The way that addresses > are assigned is not related to bandwidth, nor even to > essential authorization issues. It's an artifact of > near-compatibility with existing 2.5G layouts. GGSN > does not NECESSARILY need to control this process. > > Thus, any document which recommends that DAD or Neighbor > Discovery might be executed rarely if ever, would not fit > such "cellular" systems as I would hope eventually do > come about. > > Regards, > Charlie P. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 7 04:33:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27CXOKL008074 for ; Thu, 7 Mar 2002 04:33:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27CXObe008073 for ipng-dist; Thu, 7 Mar 2002 04:33:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27CXKKL008066 for ; Thu, 7 Mar 2002 04:33:20 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15155 for ; Thu, 7 Mar 2002 04:33:21 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA23491 for ; Thu, 7 Mar 2002 04:33:20 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g27CZMf03175; Thu, 7 Mar 2002 19:35:22 +0700 (ICT) From: Robert Elz To: "Karim El-Malki (ERA)" cc: "'Delecki Andrew-Y10658'" , ipng@sunroof.eng.sun.com Subject: Re: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] In-Reply-To: <795A014AF92DD21182AF0008C7A404320DFBEFE8@esealnt117> References: <795A014AF92DD21182AF0008C7A404320DFBEFE8@esealnt117> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Mar 2002 19:35:22 +0700 Message-ID: <3173.1015504522@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 7 Mar 2002 11:59:44 +0100 From: "Karim El-Malki (ERA)" Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFE8@esealnt117> | Can we keep 3gpp architecture discussions OFF this list? As far as it goes, probably yes - but as long as you keep referring to peculiarities of it, to justify other decisions, then no... The problem here is that there's no spec for IPv6 over those links. Define one of those first, until that's done, attempting to define host requirements for hosts connected to such a link is straight out silly - how can anyone run IPv6 over any random link in any kind of standardised way, when there's no existing spec on how to do that? It is frightening to think that people seem to be contemplating actual implementations of this, with no spec at all to base their implementation on. This needs to be fixed, and quickly. | What we are talking about is an IPv6 host with a point-to-point | link to a router. They run PPP and the router delegates | a global prefix to the host. The router doesn't configure | any address on the delegated prefix and it supports NS/NAs. It sounds as if what you're really describing is an "unnumbered" link. (From the global point of view anyway) - the delegated prefix would be for the host (terminal, phone, ...) to use as it sees fit? Is that how it always *must* be done? If so, that's what the IPv6 over whatever doc should be saying (along with the appropriate justification). But in any case, any link is going to have the link local prefix on it, and on that one, the router is supposed to go and configure the "any routers" anycast address, aside from a unicast address for itself usually - there's absolutely no reason why it shouldn't - regardless of any prefix length that might be used for a global prefix on the link (were there to be one), the link local is always a /64 - so there really are plenty of addresses there for there to be one for the host/terminal/phone/... and one for the router. Not allowing the router to have a link local address on the link would need very good justification, as it would break all kinds of assumptions made everywhere else. There absolutely needs to be a description of how to run IPv6 over any link type it is intended to run over - for some links this spec is close to trivial, for others it is complex - but it needs to exist for all. If it existed here, and you were attempting to write a "guidelines for implementors of 3GPP hosts" then most of the discussion that's been held here recently would never have happened (some of it would doubtless have been held in the context of the IPv6 over foo document - but in that context some of the arguments, from both sides, simply make no sense). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 7 04:40:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27Ce9KL008102 for ; Thu, 7 Mar 2002 04:40:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27Ce9GN008101 for ipng-dist; Thu, 7 Mar 2002 04:40:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27Ce5KL008094 for ; Thu, 7 Mar 2002 04:40:05 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19092 for ; Thu, 7 Mar 2002 04:40:05 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA16599 for ; Thu, 7 Mar 2002 04:40:03 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g27Ce1B18876 for ; Thu, 7 Mar 2002 13:40:01 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 07 13:35:04 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 13:35:04 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFED@esealnt117> From: "Karim El-Malki (ERA)" To: "'Robert Elz'" Cc: "'Ignatios Souvatzis'" , ipng@sunroof.eng.sun.com Subject: RE: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cel lular-host-00.txt -> wg last call?] Date: Thu, 7 Mar 2002 13:33:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | You want to support IPsec and that's fine. However I don't > | think you always want to run IPsec when the result is for > | example a possible higher packet loss rate. > > No, of course you don't always want to run it. Why you you think > that anyone always wants to run it? But when you need IPsec, you > need it - and that you happen to be using a cellular link for some > particular communications is irrelevant. Whether to use IPsec or > not will depend upon the particular communications at any particular > instant, and needs to be able to be determined by the user - > certainly > never by the implementor, who has no idea what environment > (which includes > the remote end of communications) the equipment will be used in. The mail I responded to was about disabling DAD and IPsec. /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 04:51:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27CpLKL008122 for ; Thu, 7 Mar 2002 04:51:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27CpKk3008121 for ipng-dist; Thu, 7 Mar 2002 04:51:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27CpHKL008114 for ; Thu, 7 Mar 2002 04:51:17 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA17972 for ; Thu, 7 Mar 2002 04:51:18 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28356 for ; Thu, 7 Mar 2002 04:51:17 -0800 (PST) Received: from tarski.cs.uni-bonn.de (tarski.cs.uni-bonn.de [131.220.4.200]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id NAA17317; Thu, 7 Mar 2002 13:51:15 +0100 (MET) Received: (from ignatios@localhost) by tarski.cs.uni-bonn.de (8.9.1a/8.9.1) id NAA21521; Thu, 7 Mar 2002 13:50:37 +0100 (CET) Date: Thu, 7 Mar 2002 13:50:37 +0100 From: Ignatios Souvatzis To: "Karim El-Malki (ERA)" Cc: "'Robert Elz'" , "'Ignatios Souvatzis'" , ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cel lular-host-00.txt -> wg last call?] Message-ID: <20020307135037.A21502@tarski.cs.uni-bonn.de> References: <795A014AF92DD21182AF0008C7A404320DFBEFED@esealnt117> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="LQksG6bCIzRHxTLp" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <795A014AF92DD21182AF0008C7A404320DFBEFED@esealnt117>; from Karim.El-Malki@era.ericsson.se on Thu, Mar 07, 2002 at 01:33:46PM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --LQksG6bCIzRHxTLp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 07, 2002 at 01:33:46PM +0100, Karim El-Malki (ERA) wrote: > > | You want to support IPsec and that's fine. However I don't > > | think you always want to run IPsec when the result is for > > | example a possible higher packet loss rate. > >=20 > > No, of course you don't always want to run it. Why you you think > > that anyone always wants to run it? But when you need IPsec, you > > need it - and that you happen to be using a cellular link for some > > particular communications is irrelevant. Whether to use IPsec or > > not will depend upon the particular communications at any particular > > instant, and needs to be able to be determined by the user -=20 > > certainly > > never by the implementor, who has no idea what environment=20 > > (which includes > > the remote end of communications) the equipment will be used in. >=20 > The mail I responded to was about disabling DAD and IPsec. yes... and it told you - to do whatever you deem appropriate about DAD in a IPv6 over 3gpp LINK document, because any interoperability is between the 3gpp err... "terminal" and the 3gpp network and doesn't affect the global internet - not to touch the implementation of IPSec (read: to implement it with at least the minimum required functionality), because IPSec is END-to-END and your customer won't be able to communicate with some nodes out there on the global Internet if it isn't at least available. Sorry if my wording wasn't clear. I'm fighting with a 'flu. Regards, -is --LQksG6bCIzRHxTLp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPIdiGDCn4om+4LhpAQES8wgAj20pKy03xIeuGhKEHekXIFJ1l7SVyGGe 7LbxbX4GU+HG/zZalg7YywElLSAueg35PeWBbejKkiaTJpRxosZZxpMBcy1HiHTi ZV6F1vJWhFwOabi59VYRd4ut+lv6j66VDypjGIIy3A6/LUA7si1j/rCfIUc0C2/v WRYb7aYvhoh7x/Zusl+G4WjeTuDCUo45K1hjvD32yaTGGfNXkikz4JF7yD9EvLYl KDoKbPuDlCIa8Iz8FiEcN+/Rroip9MWo5BW/fGK3K/JMzRnnwEo/n1u2BA74g0zE feJwThm+MtLd43uhRNo02J1Xr8ujM83nUl8z/FZHeLXyxknNojmbtg== =QRgo -----END PGP SIGNATURE----- --LQksG6bCIzRHxTLp-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 04:56:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27Cu1KL008147 for ; Thu, 7 Mar 2002 04:56:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27Cu1D9008146 for ipng-dist; Thu, 7 Mar 2002 04:56:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27CtwKL008139 for ; Thu, 7 Mar 2002 04:55:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA18442 for ; Thu, 7 Mar 2002 04:55:58 -0800 (PST) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA29640 for ; Thu, 7 Mar 2002 05:55:57 -0700 (MST) Received: from lorien.sc.innovationslab.net ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Thu, 7 Mar 2002 07:55:54 -0500 Message-ID: <3C876380.F1D5F710@lorien.sc.innovationslab.net> Date: Thu, 07 Mar 2002 07:56:32 -0500 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng Mailing List Subject: Automatic Prefix Delegation draft Content-Type: multipart/mixed; boundary="------------DBEBC375430BE6A44FEDDCA5" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------DBEBC375430BE6A44FEDDCA5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Jim and I have updated the Automatic Prefix Delegation draft to take into account comments and suggestions made in the last few months. I submitted it to the I-D editor last week, but have not seen it posted yet so it is attached. Comments and suggestions are always welcome. Brian --------------DBEBC375430BE6A44FEDDCA5 Content-Type: text/plain; charset=us-ascii; name="draft-haberman-ipngwg-auto-prefix-02.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-haberman-ipngwg-auto-prefix-02.txt" Individual Submission B. Haberman Internet Draft J. Martin draft-haberman-ipngwg-auto-prefix-02.txt February 2002 Expires August 2002 Automatic Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The expansion of the IP address space provided by IPv6 makes it both possible and reasonable to allocate entire subnets to environments that had been previously limited to a few individual IP addresses. Other protocols such as Neighbor Discovery and Stateless Address Autoconfiguration allow hosts within those subnets to be automatically configured. The router between this subnet and the upstream world requires just one more piece to make this process automatic, a network prefix. This document describes a mechanism for the automated delegation of an IPv6 network prefix. It allows routers to request either a specific prefix or any prefix. Upon authorizing the request the delegating router then returns a prefix and a lifetime for the use of the prefix. Optionally, the delegating and requesting routers can exchange routing protocol information. Haberman, Martin 1 Internet Draft February 2002 1. Introduction This specification defines the Prefix Delegation (PD) protocol for Internet Protocol Version 6 (IPv6). Routers use Prefix Delegation to request a network prefix for use on directly attached networks. Upon receipt of the request, the delegating router may authenticate the request, and will establish if the requested prefix size is acceptable. The delegating router then specifies the prefix for use and the length of time for which that prefix is delegated. The Prefix Delegation protocol supports extensible options. These options may be used to negotiate additional operational parameters, such as routing protocol information. 2. Terminology 2.1 General This document uses the terminology defined in [RFC 2460] and [RFC 2461] and in addition: - Requesting Router - The router that is requesting that a prefix be assigned - Delegating Router - The router that is responding to the prefix request 2.2 Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 3. Scope of Work This proposal is meant to give a singly homed leaf router the ability to obtain an IPv6 prefix that can be used within its leaf network. Future revisions of this document may support a more generic approach to dynamic prefix delegation. It is also assumed that the delegating server/router shares a network connection with the requesting router. Future revisions may remove this restriction and allow for either multi-hop messages or a relay function. 4. Protocol Overview Haberman, Martin 2 Internet Draft February 2002 The Prefix Delegation protocol defines two new ICMP message types, the Prefix Request and the Prefix Delegation. The Prefix Request is used by the Requesting Router to communicate requests to the Delegating Router. Conversely, the Prefix Delegation is used by the Delegating Router to communicate prefix and error information with the Requesting Router. 4.1 Delegator Query The Requesting Router begins the Prefix Delegation process by sending a Prefix Request message of type [DELEGATOR QUERY] to the All-Routers link-local multicast address (FF02::2). Upon receipt of the Delegator query, a Delegating Router determines if it is configured to provide prefixes of the specified scope. If so, it unicasts a Prefix Delegation of type [PREFIX DELEGATOR] to the Requestor. If not, the message is silently discarded. After sending the query, the Requestor waits for Query Interval (Default: 5) seconds for one or more Delegating Routers to respond. If there is no response, the Delegator Query is sent again up to Max Query times (Default: 3). If no response is received, there are no Prefix Delegation services available, and Prefix Delegation has failed. If more than one response is received to the query within the Query Interval, the response with the numerically highest source IP address is used. 4.2 Initial Request Once a Delegating Router is chosen, the Requestor sends a Prefix Request message of type Initial Request to the unicast IP address of the chosen Delegating Router. The Requestor may or may not have a Security Association with the Delegating Router, however if Authentication is required and no SA is present, the Delegator will reject the request with an error response indicating that Authentication is required. The Requestor then builds a Security Association with the Delegator and sends another Initial Request including the SA information. If no response is heard within Request Timeout seconds (Default: 5), the Initial Request should be sent again, up to Max Initial Request (Default: 3) tries. If no response is heard, a Delegator Query is sent and the process restarted. If this cycle is repeated Max Delegation Attempts times (Default: 3), Prefix Delegation has failed. 4.3 Message Security Haberman, Martin 3 Internet Draft February 2002 Upon receipt of the Prefix Request of any type, the Delegating Router establishes if there is a need for Authentication and/or Encryption, based upon local policy. If either is required and none is provided, the Delegator will return a Prefix Delegation message, with a code of Authentication Required. The building of a Security Association between the Delegator and the Requestor is based on the Authentication and/or Encapsulated Security Payload extension headers defined in [RFC 2402] and [RFC 2406]. 4.4 Prefix Delegation After the request is verified to be acceptable, the Delegating Router allocates the requested prefix size from its pool of available addresses. The creation and management of that pool is beyond the scope of this document, but it can be supposed that minimalistically a Delegating Router will be statically configured with a fixed pool. If no acceptable prefix is available, a Prefix Delegation message with a code of Prefix Unavailable is returned. The Delegating Router then sends a Prefix Delegation message to the Requesting Router containing a code of Prefix Delegation and all of the prefix information. The Requesting Router then activates the prefix on its interface of choice. 4.5 Prefix Refresh All Prefix Delegations have a lifetime that MUST follow the rules defined in Section 4.6.2 of [RFC 2461]. Upon receiving a Prefix Delegation, the requesting router initiates a timer such that before the lifetime expires, the Requesting Router sends a Prefix Request with code=REFRESH directly to the Delegating router. If the Requestor receives no response within [RENEWAL TIMEOUT] seconds (Default: 5), the Renewal Request should be sent again, up to [MAX RENEWAL REQUEST] (Default: 3) tries. If no response is heard the previously allocated prefix is not renewed. A Requesting Router receiving the Prefix Unavailable code, or no response at all, has not had the prefix renewed. It will expire at the end of the initial lifetime. To acquire a new prefix, the Requesting Router must begin anew as described in Section 4.1. 4.6 Prefix Return If the Requesting Router no longer requires the use of a prefix, it can return that prefix to the control of the Delegating Router through the use of the Prefix Return code in a Prefix Request. The requesting router sends a Prefix Request directly to the Delegating Router. Haberman, Martin 4 Internet Draft February 2002 Upon receipt and verification (if needed) of this message, the Delegating Router returns the prefix to the pool and issues a Prefix Delegation with a code of Prefix Returned. 5. Messages All messages have the following general format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Message Body + | | The following sections describe the specific messages and options used in delegating IPv6 prefixes. 5.1 Prefix Request Message The Prefix Request Message is sent to request, renew, or release a prefix. IP Fields Source Address An IP address assigned to the sending interface. Destination Address The All-Routers link-local multicast address (FF02::2)for Delegator Query messages. All other Prefix Request messages should be sent to a unicast address of the Delegating Router. Authentication Header If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. No such header is required for the initial prefix request that is multicast, but may be required for further progress. ICMP Fields Type XXX (Where XXX is assigned by IANA) Haberman, Martin 5 Internet Draft February 2002 Code They Type of Request Code: Delegator Query (0) The Delegator Query is used by the Requestor to identify potential Delegating Routers. It is sent to the All-Routers link-local multicast address with no Authentication Header. Initial Request (1) The Initial Request is used to initiate the request process. It is sent to the unicast IP address of the Delegating Router, and may carry an Authentication Header. Unused fields MUST be set to zero. An Initial Request code MAY contain a Prefix Option. Renewal Request (2) The Renewal Request is used to renew a prefix that has been previously allocated. It is sent to a unicast IP address of the Delegating Router and may carry an Authentication Header. A Renewal Request code MUST contain at least one Prefix Option. Prefix Return (3) The Prefix Return is used to return an unused prefix, or portion of a prefix to the control of the Delegating Router. It is sent to a unicast IP address of the Delegating Router and may carry an Authentication Header. A Prefix Return code MUST contain at least one Prefix Option. Checksum The ICMP checksum as defined in [RFC 2463]. 5.2 Prefix Delegation Message Format The Prefix Delegation Messages are sent to provide the addresses of available Prefix Delegators, to provide prefix data, and for error returns. IP Fields Source Address An IP address assigned to the sending interface. Destination Address The IP address of the Requestor as specified by the IP Source Address in the Prefix Request message. Authentication Header Haberman, Martin 6 Internet Draft February 2002 If a Security Association for the IP Authentication Header exists between the sender and the destination address, then the sender SHOULD include this header. ICMP Fields Type XXX+1 (Where XXX+1 is assigned by IANA) Code The Type of Response Code: Prefix Delegator (0) The Prefix Delegator is used by the Delegator to inform the Requestor that it is available to provide prefixes of the desired type. It is sent to the unicast IP address in the Source Address portion of the Prefix Request packet. Unused fields MUST be set to zero. Authentication Required (1) The Authentication Required message indicates to the Requestor that a Security Association must be established before a prefix can be delegated. It is sent to the unicast IP address in the Source Address portion of the Prefix Request packet. Unused fields MUST be set to zero. Authorization Failed (2) The Authorization Failed message indicates to the Requestor that either it is not authorized to request a prefix, or that the prefix requested fell outside of local policy. It is sent to the unicast IP address in the Source Address portion of the Prefix Request packet. Unused fields MUST be set to zero. Prefix Unavailable (3) The Prefix Unavailable indicates that the Prefix Request was acceptable, but the Delegator does not have sufficient available address space to fulfill the request. It is sent to the unicast IP address in the Source Address portion of the Prefix Request packet. Unused fields MUST be set to zero. Prefix Delegated (4) The Prefix Delegated message actually provides the prefix information that the Requestor has requested. It is sent to the unicast IP address in the Source Address portion of the Prefix Request packet. For this message, a Prefix Option MUST be included. Prefix Returned (5) Haberman, Martin 7 Internet Draft February 2002 The Prefix Return is used to confirm the return of a prefix. It is sent to the unicast IP address in the Source Address portion of the Prefix Request packet. For this message, the Prefix Option MUST be included. Checksum The ICMP checksum. 5.3 Prefix Option The Subnet Prefix Option is used to relay prefix information between Requestors and Delegators. It has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prefix Option Fields Type = 0x01 This field identifies the presence of a subnet prefix. This option MUST follow either a Prefix Request header or a Prefix Delegation header. Length The length of the prefix contained in the option. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Prefix Lifetime The lifetime of the prefix contained in the option. IPv6 Prefix The Prefix field is used to carry a subnet prefix. The host portion of the IP address MUST be padded with zeros. Haberman, Martin 8 Internet Draft February 2002 6. Security Considerations The ability to automate the delegation of prefixes opens several security vulnerabilities. Rogue delegators can issue bogus prefixes to requestors. This may cause denial of service due to unreachability. Rogue requestors may consume valuable resources from legitimate delegators, thus denying others the use of the prefixes. For these reasons, the use of IPSec-based Authentication and/or Encryption is suggested. 7. To Do's - Additional security discussion - Relay functionality - Routing capabilities option 8. Acknowledgements We would like to acknowledge and thank Jun-ichiro itojun Hagino, Dave Thaler, Yamasaki Toshi, Ole Troan, and Kazuaki Tsuchiya for their feedback and suggestions on this document. 9. References [RFC 2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC 2461] T. Narten, E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC 2463] A. Conta and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. Authors' Addresses Brian Haberman haberman@lorien.sc.innovationslab.net Jim Martin jim@interop.net Haberman, Martin 9 --------------DBEBC375430BE6A44FEDDCA5-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 05:18:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27DI9KL008428 for ; Thu, 7 Mar 2002 05:18:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27DI99e008427 for ipng-dist; Thu, 7 Mar 2002 05:18:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27DI6KL008420 for ; Thu, 7 Mar 2002 05:18:06 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA28284 for ; Thu, 7 Mar 2002 05:18:06 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA24234 for ; Thu, 7 Mar 2002 06:18:05 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g27DEdB29313; Thu, 7 Mar 2002 14:14:39 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA04749; Thu, 7 Mar 2002 14:14:40 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g27DEdg18583; Thu, 7 Mar 2002 14:14:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203071314.g27DEdg18583@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Karim El-Malki (ERA)" cc: "'Margaret Wasserman'" , "Hesham Soliman (ERA)" , juha.wiljakka@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Making Autoconfig Optional [Was RE: draft-ietf-ipv6-cellular- host-00.txt -> wg last call?] In-reply-to: Your message of Mon, 04 Mar 2002 12:25:16 +0100. <795A014AF92DD21182AF0008C7A404320DFBEFBB@esealnt117> Date: Thu, 07 Mar 2002 14:14:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > PS: I'd like to get this (DAD considerations) for PPP in general. Agreed. I'd also be in favour of allowing PPP links on which there's some form of prefix delegation (doesn't have to be a prefix del. protocol) to disable DAD. Some more work is needed on RFC2472, which was also one of the outputs of the ipv6-3gpp design team. => I answer to Robert Elz and Jim too: I agree the document to fix is the RFC 2472 (IPv6 over PPP), not the RFC 2462 (autoconf) or a new IPv6 over foo (only because foo is PPP). Can the chairs allow for a short discussion on this? => perhaps this is the time to revisit RFC 2472 (many things have changed in PPP, for instance ROHC). Thanks Francis.Dupont@enst-bretagne.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 Thu Mar 7 05:30:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27DUCKL008486 for ; Thu, 7 Mar 2002 05:30:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27DUCHM008485 for ipng-dist; Thu, 7 Mar 2002 05:30:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27DU9KL008478 for ; Thu, 7 Mar 2002 05:30:09 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA23393 for ; Thu, 7 Mar 2002 05:30:10 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09688 for ; Thu, 7 Mar 2002 05:30:05 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g27DTsB32367; Thu, 7 Mar 2002 14:29:54 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA05249; Thu, 7 Mar 2002 14:29:54 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g27DTrg18745; Thu, 7 Mar 2002 14:29:53 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203071329.g27DTrg18745@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Bound, Jim" cc: "Dr. Subrata Goswami" , ipng@sunroof.eng.sun.com Subject: Re: PPP and Global Addresses In-reply-to: Your message of Wed, 06 Mar 2002 10:55:56 EST. <9C422444DE99BC46B3AD3C6EAFC9711B015206F2@tayexc13.americas.cpqcorp.net> Date: Thu, 07 Mar 2002 14:29:53 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Catching up on old mail I saved for DHCPv6. Let me just start with your view is wrong. => do you argue we need dynamic address allocation for IPv6? I don't see the point of arguing with you. DHCPv6 will be deployed and widely used. => Jim, you already said that 5 years ago. I tried to believe in DHCPv6 but this is too hard, after years of discussion we still have no published specs! Its not an IETF discussion worth having in this vein IMO. => a document in the standard track should have to prove its utility, so this is still a valid IETF discussion topic. Many of us who also have implemented IPv6, talking to customers, and working with the market think you are 100% wrong. => near all IPv6 implementors are against DHCPv6 or are indifferent. You are the only notable exception. They want DHCPv6. => they believe they need it because they have not yet understood the differences between IPv6 and IPv4, or with other words, that allocation and management are not the same thing. Regards Francis.Dupont@enst-bretagne.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 Thu Mar 7 05:34:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27DYqKL008523 for ; Thu, 7 Mar 2002 05:34:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27DYptI008522 for ipng-dist; Thu, 7 Mar 2002 05:34:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27DYmKL008515 for ; Thu, 7 Mar 2002 05:34:48 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01755 for ; Thu, 7 Mar 2002 05:34:49 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20160 for ; Thu, 7 Mar 2002 06:34:48 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g27DYlZc004736 for ; Thu, 7 Mar 2002 14:34:47 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 07 14:27:59 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 14:27:59 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFEE@esealnt117> From: "Karim El-Malki (ERA)" To: "'Robert Elz'" Cc: "'Delecki Andrew-Y10658'" , ipng@sunroof.eng.sun.com Subject: RE: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Thu, 7 Mar 2002 14:26:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | Can we keep 3gpp architecture discussions OFF this list? > > As far as it goes, probably yes - but as long as you keep referring > to peculiarities of it, to justify other decisions, then no... ??? What does this have to do with cellular architectures? We need to consider particulars of the link but that's a totally different thing from the internal architecture of a cellular system which belongs elsewhere. > > The problem here is that there's no spec for IPv6 over those links. > Define one of those first, until that's done, attempting to define > host requirements for hosts connected to such a link is straight out > silly - how can anyone run IPv6 over any random link in any kind of > standardised way, when there's no existing spec on how to do that? > > It is frightening to think that people seem to be > contemplating actual > implementations of this, with no spec at all to base their > implementation > on. This needs to be fixed, and quickly. 3gpp has defined how the IPv6 behaviour over cellular links works with IETF input in terms of 3gpp-advice. It's in a spec called 23.060. So it's simply not true that people don't have a spec. However it is important that we quickly get some form of minimum host requirements spec which today just isn't there to guarantee host compatibility. This could then be used by 3gpp implementers to ensure compatibility but it needs to be done in a short time. In parallel we could do the IPv6 over cellular spec which would give non-3gpp people something to use. It's already been mentioned by Jonne that work has started on this. > > | What we are talking about is an IPv6 host with a point-to-point > | link to a router. They run PPP and the router delegates > | a global prefix to the host. The router doesn't configure > | any address on the delegated prefix and it supports NS/NAs. > > It sounds as if what you're really describing is an > "unnumbered" link. > (From the global point of view anyway) - the delegated > prefix would be > for the host (terminal, phone, ...) to use as it sees fit? Yes. Please read the previous emails on this. > > Is that how it always *must* be done? If so, that's what > the IPv6 over > whatever doc should be saying (along with the appropriate > justification). > > But in any case, any link is going to have the link local > prefix on it, > and on that one, the router is supposed to go and configure > the "any routers" > anycast address, aside from a unicast address for itself > usually - there's > absolutely no reason why it shouldn't - regardless of any > prefix length > that might be used for a global prefix on the link (were > there to be one), > the link local is always a /64 - so there really are plenty > of addresses > there for there to be one for the host/terminal/phone/... > and one for the > router. Not allowing the router to have a link local address on the > link would need very good justification, as it would break > all kinds of > assumptions made everywhere else. Well, if you had read the previous emails you'd have realised that 3gpp is using PPP to guarantee uniqueness of the router and host's link-local. And no, once again, the router does not configure any address on the delegated global prefix. It is a special router. I'm starting to sound like a broken record :( /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 05:40:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27DeBKL008548 for ; Thu, 7 Mar 2002 05:40:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27DeBlf008547 for ipng-dist; Thu, 7 Mar 2002 05:40:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27De8KL008540 for ; Thu, 7 Mar 2002 05:40:08 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA29974 for ; Thu, 7 Mar 2002 05:40:08 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15328 for ; Thu, 7 Mar 2002 06:40:07 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g27DdVB01646; Thu, 7 Mar 2002 14:39:31 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id OAA05536; Thu, 7 Mar 2002 14:39:31 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g27DdTg18814; Thu, 7 Mar 2002 14:39:29 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203071339.g27DdTg18814@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Bound, Jim" cc: "Pekka Savola" , "Tony Hain" , "Ole Troan" , "NOISETTE Yoann FTRD/DMI/CAE" , "Yamasaki Toshi" , "Lilian Fernandes" , ipng@sunroof.eng.sun.com, shouchun@us.ibm.com Subject: Re: PPP and Global Addresses In-reply-to: Your message of Wed, 06 Mar 2002 11:01:52 EST. <9C422444DE99BC46B3AD3C6EAFC9711B015206F4@tayexc13.americas.cpqcorp.net> Date: Thu, 07 Mar 2002 14:39:29 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: But I don't really care about your opinion or others on what should be used or not used from the work we do in the IETF. => I disagree: the resources of IETF are not infinite so waste is a common concern. What I care about is if you find a technical hole or error in our protocol specifications or interoperablity issues. => I'd like to see any of the security concerns of draft-prigent-dhcpv6-threats-00.txt addressed, or a proof that "the capability of automatic allocation of reusable network addresses" has a meaning for IPv6 addresses (note that we have 5 years of proof of the opposite). Regards Francis.Dupont@enst-bretagne.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 Thu Mar 7 05:40:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27DeHKL008558 for ; Thu, 7 Mar 2002 05:40:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27DeHSv008557 for ipng-dist; Thu, 7 Mar 2002 05:40:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27DeDKL008550 for ; Thu, 7 Mar 2002 05:40:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24539 for ; Thu, 7 Mar 2002 05:40:14 -0800 (PST) Received: from ims2.hub.nih.gov (ims2.hub.nih.gov [128.231.90.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA15371 for ; Thu, 7 Mar 2002 06:40:13 -0700 (MST) Received: by ims2.hub.nih.gov with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 08:40:12 -0500 Message-ID: <64BC9A2B18FC5843BA0DE93548F745F3338367@NIHEXCHANGE3.nih.gov> From: "Januszewski, Joseph (CIT)" To: "'ipng@sunroof.eng.sun.com'" Subject: FW: Should IP Security be Optional? Date: Thu, 7 Mar 2002 08:40:10 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -----Original Message----- From: Januszewski, Joseph (CIT) Sent: Tuesday, March 05, 2002 3:08 PM To: Subject: FW: Should IP Security be Optional? I think this has taken on a larger context than just cellular. (Which is I guess why the Subject line has changed). Don't forget that IPv4 is that it was designed in the early 70's, and people were surrounded by IBM 360s and DEC PDP-11s, and a whole bunch of other machines that no longer exist. But, one of its strengths, although designed in that environment, is that it allowed for growth through the Web phase of the Internet. Radiotelephones were the closest you got to mobile telephones at that time, and today's wireless Email clients are starting to look like something out of a Dick Tracy comic. Beyond a short trip down memory lane (or to the Smithsonian, depending on your age), I guess what I am suggesting is that we would be limiting the applicability of IPv6 if we just thought in terms of cellular media and wireless browsers. In 1974, when the "@" sign started to be used for "the new electronic mail application", how many people were thinking "BlackBerry"? It has been said that no one intends on being around when IPv8 or IPv12 (or what have you) has to be designed. In that case, what needs to happen is a larger, more generic framework needs to be designed that new technologies can be merged into. Also, that means that IP security should not be optional. Whether September 11th took place, or not, the world has been and is full of all kinds of people - most nice, but some not nice. For commerce, communications and information transfer of all sorts to take place, we need to think in these terms. Cordless phones have scrambling features, and police scanners that were the rage 20 years ago are mostly obsolete because the authorities realized that everyone - including criminals - could listen in on their operations. The Internet is nearing maturity, and should have these features built-in now, before it is totally ubiquitous, and we have to continue to bolt-on security just like we've done with IPv4, and every so-called modern operating system. My $.02 -----Original Message----- From: Jonne.Soininen@nokia.com [mailto:Jonne.Soininen@nokia.com] Sent: Monday, March 04, 2002 8:40 PM To: moore@cs.utk.edu Cc: ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] > > > This seems to presume that you can predict in advance all of the > > > applications that a user will wish to execute on a particular node. Can you > > > do that? > > > > On a workstation you can't. On a tiny cellular device you > > often can. > only if the device doesn't have a data port. Actually then (especially in 3GPP devices) the IP stack will actually also be behind that dataport, i.e. in the laptop. That is then a different story. -Jonne. -------- Jonne Soininen Nokia Tel. +1 650 864 6794 Cellular: +1 650 714 7733 Email: jonne.soininen@nokia.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 Thu Mar 7 05:44:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27DijKL008597 for ; Thu, 7 Mar 2002 05:44:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27DijmX008596 for ipng-dist; Thu, 7 Mar 2002 05:44:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27DigKL008589 for ; Thu, 7 Mar 2002 05:44:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24991 for ; Thu, 7 Mar 2002 05:44:43 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05189 for ; Thu, 7 Mar 2002 06:44:42 -0700 (MST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-128.cisco.com [161.44.149.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA09289; Thu, 7 Mar 2002 08:44:30 -0500 (EST) Message-Id: <4.3.2.7.2.20020307083510.00b60e40@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Mar 2002 08:44:28 -0500 To: Francis Dupont From: Ralph Droms Subject: Re: PPP and Global Addresses Cc: "Bound, Jim" , "Dr. Subrata Goswami" , ipng@sunroof.eng.sun.com In-Reply-To: <200203071329.g27DTrg18745@givry.rennes.enst-bretagne.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, I have to jump in here - DHCPv6 is *not* just for dynamic address allocation. Have those who are claiming that DHCPv6 will not be used actually read the spec? It will be used for other configuration parameters, as described in draft-droms-dnsconfig-dhcpv6-01.txt Arguments that DHCPv6 has no utility because of stateless address autoconfiguration are bogus. Once again, stateless address autoconfiguration is great. But it's not enough. An IPv6 host needs *at least* DNS configuration information to be useful. DHCPv6 is a reasonable way to provide that additional configuration information. Is there a buzz from network designers, managers or admins - folks who actually *run* networks and who understand IPv6 - asking for DHCP to go away? - Ralph At 02:29 PM 3/7/2002 +0100, Francis Dupont wrote: > In your previous mail you wrote: > > Catching up on old mail I saved for DHCPv6. Let me just start with your > view is wrong. > >=> do you argue we need dynamic address allocation for IPv6? > > I don't see the point of arguing with you. DHCPv6 will be deployed and > widely used. > >=> Jim, you already said that 5 years ago. I tried to believe in DHCPv6 >but this is too hard, after years of discussion we still have no >published specs! > > Its not an IETF discussion worth having in this vein IMO. > >=> a document in the standard track should have to prove its utility, >so this is still a valid IETF discussion topic. > > Many of us who also have implemented IPv6, talking to customers, > and working with the market think you are 100% wrong. > >=> near all IPv6 implementors are against DHCPv6 or are indifferent. >You are the only notable exception. > > They want DHCPv6. > >=> they believe they need it because they have not yet understood >the differences between IPv6 and IPv4, or with other words, that >allocation and management are not the same thing. > >Regards > >Francis.Dupont@enst-bretagne.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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 05:46:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27DkaKL008617 for ; Thu, 7 Mar 2002 05:46:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27Dkak3008616 for ipng-dist; Thu, 7 Mar 2002 05:46:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27DkXKL008609 for ; Thu, 7 Mar 2002 05:46:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA04055 for ; Thu, 7 Mar 2002 05:46:34 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06014 for ; Thu, 7 Mar 2002 06:46:33 -0700 (MST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-128.cisco.com [161.44.149.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA09356; Thu, 7 Mar 2002 08:45:59 -0500 (EST) Message-Id: <4.3.2.7.2.20020307084459.018d3c28@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Mar 2002 08:45:57 -0500 To: Francis Dupont From: Ralph Droms Subject: Re: PPP and Global Addresses Cc: "Bound, Jim" , "Pekka Savola" , "Tony Hain" , "Ole Troan" , "NOISETTE Yoann FTRD/DMI/CAE" , "Yamasaki Toshi" , "Lilian Fernandes" , ipng@sunroof.eng.sun.com, shouchun@us.ibm.com In-Reply-To: <200203071339.g27DdTg18814@givry.rennes.enst-bretagne.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk With all due respect, I've read draft-prigent-dhcpv6-threats-00.txt. The authors based this doc on an old draft of the DHCPv6, which they did not understand very well. - Ralph At 02:39 PM 3/7/2002 +0100, Francis Dupont wrote: > In your previous mail you wrote: > > But I don't really care about your opinion or others on what should be > used or not used from the work we do in the IETF. > >=> I disagree: the resources of IETF are not infinite so waste is >a common concern. > > What I care about is if you find a technical hole or error in our > protocol specifications or interoperablity issues. > >=> I'd like to see any of the security concerns of >draft-prigent-dhcpv6-threats-00.txt addressed, or >a proof that "the capability of automatic allocation of >reusable network addresses" has a meaning for IPv6 addresses >(note that we have 5 years of proof of the opposite). > >Regards > >Francis.Dupont@enst-bretagne.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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 06:53:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27ErqKL008693 for ; Thu, 7 Mar 2002 06:53:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27Erq09008692 for ipng-dist; Thu, 7 Mar 2002 06:53:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27ErnKL008685 for ; Thu, 7 Mar 2002 06:53:49 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16367 for ; Thu, 7 Mar 2002 06:53:49 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13261 for ; Thu, 7 Mar 2002 06:53:47 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id QAA23692; Thu, 7 Mar 2002 16:53:45 +0200 Date: Thu, 7 Mar 2002 16:53:45 +0200 Message-Id: <200203071453.QAA23692@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: RA with lifetime=0 and clearing Destination Cache? Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In RFC-2461 "6.3.5 Timing out Prefixes adn Default Routers" it says: Whenever the Lifetime of an entry in the Default Router List expires, that entry is discarded. When removing a router from the Default Router list, the node MUST update the Destination Cache in such a way that all entries using the router perform next-hop determination again rather than continue sending traffic to the (deleted) router. My problem with this is: if RA has lifetime=0, it only means it stops being a default router, router is *NOT* "(deleted)". It can still act as a router for other more specific prefixes (for example, from draft-ietf-ipv6-router-selection-01.txt). It not a big deal to delete destination cache entries, they will just get reinserted, when needed. But I just wanted to hear if anyone else has opinions about this? - if router is advertising "More Specific routes" every 15s, but does not want to be a default router, the side effect is that destination cache entries for that router are flushed on every RA, even for "specific routes" - if we have a special non-default router, which gets its "clients" only through "redirects", those entries are cleared also on RA from this router. [The reason I noticed, once again TAHI test failed, because *I* only removed those destinations that actually are related to the default route. I didn't remove redirections, for example... I suppose I have to fix this feature to be RFC compliant? :-] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 07:16:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27FGuKL008753 for ; Thu, 7 Mar 2002 07:16:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27FGu0P008752 for ipng-dist; Thu, 7 Mar 2002 07:16:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27FGpKL008745 for ; Thu, 7 Mar 2002 07:16:51 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g27FGmx11154; Thu, 7 Mar 2002 16:16:48 +0100 (MET) Date: Thu, 7 Mar 2002 16:11:44 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: source and dst addr for Neighbor Solicitation To: Vijay Devarapalli Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C86DBCA.C25E6E6@iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > hi, > > A simple question. When would you ever use global source > and destination addresses for a neighbor solicitation. > And why? For an NS it makes sense to use an IP source address that the peer will try to send packets to so that the NS (with a source link-layer address option) can create/update the neighbor cache entry on the peer. If you don't do this you'll end up with twice the number of ND packets as in A ---> NS --> B A <--- NA <-- B A now has NCE for B A ---> TCP --> B When B wants to respond it doesn't have a NCE for A A <--- NS <-- B A ---> NA --> B B now has NCE for A A <-- TCP <-- B Also, for NUD you want to probe the actual destination in the NCE by sending to that unicast address. Thus the destination in a unicast NS should be a global address if the NCE is for a global address. > IMO, link local addresses must be used. But RFC 2461 does > not say this. It just says an address configured to the > interface. That can mean global addresses. I saw such a > packet at Connectathon (going on in San Jose). RFC 2461 should say something consistent with the above somewhere. E.g section 7.2.2 and reading between the lines in 7.3.3+4.3. Any suggestions on how it can be made more clear? 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 Mar 7 07:30:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27FURKL008813 for ; Thu, 7 Mar 2002 07:30:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27FUR1K008812 for ipng-dist; Thu, 7 Mar 2002 07:30:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27FUNKL008802 for ; Thu, 7 Mar 2002 07:30:23 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24611 for ; Thu, 7 Mar 2002 07:30:23 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29593 for ; Thu, 7 Mar 2002 07:30:21 -0800 (PST) Received: from piuha.net ([62.248.153.185]) by fep02-app.kolumbus.fi with ESMTP id <20020307153020.YGJZ12987.fep02-app.kolumbus.fi@piuha.net>; Thu, 7 Mar 2002 17:30:20 +0200 Message-ID: <3C875D39.1040302@kolumbus.fi> Date: Thu, 07 Mar 2002 14:29:45 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: "Bound, Jim" CC: Brian Haberman , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? References: <9C422444DE99BC46B3AD3C6EAFC9711B01520713@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bound, Jim wrote: > John et al. Bag this lets go build a cellular host consortia with > vendors that want to ship and deploy IPv6 and build our use requirements > out of here. > > Or we will be hacking on this in January 2003. It was a good thing to > try but it might not work to do use / implementation reqs in the IETF. > Thats fine though. Given that deployment starts this year and standards releases are weeks or at most months away, I'm sure decisions *will* be made as to what goes to the devices. The guestion is who will make the recommendations on what the devices do. My strong preference though is that this WG makes them, because the expertise is here. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 07:30:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27FUaKL008823 for ; Thu, 7 Mar 2002 07:30:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27FUaaR008822 for ipng-dist; Thu, 7 Mar 2002 07:30:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27FUUKL008815 for ; Thu, 7 Mar 2002 07:30:30 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g27FURx12365; Thu, 7 Mar 2002 16:30:28 +0100 (MET) Date: Thu, 7 Mar 2002 16:25:24 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: RA with lifetime=0 and clearing Destination Cache? To: Markku Savela Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200203071453.QAA23692@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > In RFC-2461 "6.3.5 Timing out Prefixes adn Default Routers" it says: > > Whenever the Lifetime of an entry in the Default Router List > expires, that entry is discarded. When removing a router from the > Default Router list, the node MUST update the Destination Cache in > such a way that all entries using the router perform next-hop > determination again rather than continue sending traffic to the > (deleted) router. > > My problem with this is: if RA has lifetime=0, it only means it stops > being a default router, router is *NOT* "(deleted)". It can still act > as a router for other more specific prefixes (for example, from > draft-ietf-ipv6-router-selection-01.txt). > > It not a big deal to delete destination cache entries, they will just > get reinserted, when needed. But I just wanted to hear if anyone else > has opinions about this? Note that the above quoted text does not say to delete the destination cache entries. It says to update date is to make sure that the destination cache entries are consistent with the router no longer being a default router. Presumably the draft-ietf-ipv6-router-selection-01.txt draft will make it clear how next-hop determination happens with more specific routes in place. If the next-hop determination would return the same result after the router is removed from the default router list (but still has more specific routes) then there isn't any need to change anything. An implementation can use whatever technique works to efficiently find the destination cache entries. For example, an implementation of more specific routes could presumably track which route (default or not) was used to create a particular destination cache entry and use that as a faster way to find which entries need to redo next hop determination. > - if router is advertising "More Specific routes" every 15s, but does > not want to be a default router, the side effect is that destination > cache entries for that router are flushed on every RA, even for > "specific routes" That seems to be an implementation choice not required by the specification. > > - if we have a special non-default router, which gets its "clients" > only through "redirects", those entries are cleared also on RA from > this router. > > [The reason I noticed, once again TAHI test failed, because *I* only > removed those destinations that actually are related to the default > route. I didn't remove redirections, for example... I suppose I have > to fix this feature to be RFC compliant? :-] Since redirects (unless I misremember) create/modify destination cache entries (and not 128 bit prefix routes in a routing table) it seems like the TAHI tests follow the letter of RFC 2461. One can of course debate whether this behavior for redirects is the optimal one i.e. whether the specification should be clarified that destination cache entries created or modified due to a redirect should not be re-evaulated when the router stops to be a default router. If redirects are kept around the worst case is that NUD will need to discard them should the router really disappear. 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 Mar 7 07:30:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27FUNKL008801 for ; Thu, 7 Mar 2002 07:30:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27FUN75008799 for ipng-dist; Thu, 7 Mar 2002 07:30:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27FUHKL008785 for ; Thu, 7 Mar 2002 07:30:17 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28436 for ; Thu, 7 Mar 2002 07:30:17 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA29548 for ; Thu, 7 Mar 2002 07:30:15 -0800 (PST) Received: from piuha.net ([62.248.153.185]) by fep02-app.kolumbus.fi with ESMTP id <20020307153010.YGJO12987.fep02-app.kolumbus.fi@piuha.net>; Thu, 7 Mar 2002 17:30:10 +0200 Message-ID: <3C872B27.4000301@kolumbus.fi> Date: Thu, 07 Mar 2002 10:56:07 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Margaret Wasserman CC: "Charles E. Perkins" , "Bound, Jim" , ipng@sunroof.eng.sun.com Subject: Re: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] References: <9C422444DE99BC46B3AD3C6EAFC9711B01520739@tayexc13.americas.cpqcorp.net> <4.2.2.20020306155434.01cd6ed0@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > I'd be amenable some sort of "guidelines" document that offers > some guidance to 3GPP vendors on which portions of which IPv6 > specifications should be implemented in cellular hosts. Interestingly, that was roughly in line what we were *trying* to do. Could discuss exact title but still... > - All conflicts with existing IPv6 standards should be > eliminated. This is almost right, but I would still allow for the *possibility* that the WG now thinks something even if when it published something else earlier. Conditional on WG consensus on the particular issue of course, and there should be an explicit description in the document that explains why there is a discrepancy. > - We should not recommend anything that we don't > agree with -- for instance, if we think that > IP Sec should be included in all IPv6 hosts, > this document shouldn't say otherwise. Again, this seems pretty obvious and has been our intent all along. Naturally we have put some proposals on the table on various recommendations as a starting point and presented our reasoning, but like the work in all IETF WGs, the WG gets to decide. And I see a lot of good discussion on the various recommendations, so I'm hopeful some concensus will appear on them. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 07:30:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27FUNKL008803 for ; Thu, 7 Mar 2002 07:30:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27FUNA6008800 for ipng-dist; Thu, 7 Mar 2002 07:30:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27FUIKL008787 for ; Thu, 7 Mar 2002 07:30:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28460 for ; Thu, 7 Mar 2002 07:30:17 -0800 (PST) Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10330 for ; Thu, 7 Mar 2002 08:30:16 -0700 (MST) Received: from piuha.net ([62.248.153.185]) by fep02-app.kolumbus.fi with ESMTP id <20020307153015.YGJV12987.fep02-app.kolumbus.fi@piuha.net>; Thu, 7 Mar 2002 17:30:15 +0200 Message-ID: <3C873401.9000809@kolumbus.fi> Date: Thu, 07 Mar 2002 11:33:53 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Randy Bush CC: "Bound, Jim" , Francis Dupont , Margaret Wasserman , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] References: <9C422444DE99BC46B3AD3C6EAFC9711B01520701@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Randy Bush wrote: >>I agree security is important and IPsec is good. >>But the market and vendors will ship and use what they want. >> > > we are not a vendor. we are the ietf. we make the bestquality standards we > can. if there are vendors which do not follow them, then if this is not due > to lack of quality of a standard, it is not our problem. buyer beware. Randy and others, I'd like to take a step back and recommend that people take a second look at what we are trying to say about security in sections 3 and 5 of our draft. It seems that people are interpreting the proposals as the intent of some vendors to water down security. This really wasn't quite what we were trying to do, so perhaps we've been unclear. If so, I'd like to clarify the situation a bit. The main goals were: 1) Security is always mandatory (but not necessarily same type all the time) 2) Recommend the most suitable security for a particular function. 3) Figure out when particular security mechanisms work and when they don't. On a technical basis. For instance, we are going *beyond* current IETF MUSTs in the saying that in this particular environment (because of number of hosts and dynamic IP addressing) you MUST implement IKE with IPsec and manual keying isn't sufficient. On the other hand, we're also saying that IPsec isn't the right security mechanism for all functions and isn't needed in all cases. We are also saying -- perhaps contrary to the common belief in IETF -- that it isn't sufficient for protecting v6 local network control signaling (ND etc) due to a number of reasons (an issue of which I have implementation experience). Having said the above, I think we have still gotten excellent feedback on the security issue and have to work more on it, for instance on the effects of hosts that can download new apps or applets. And as we've stated elsewhere already, it's really the WG who gets to decide what eventually gets written to the RFCs, and naturally what the mailing list feels goes to the next revision of the document. One possible way ahead would be Michael Thomas' suggestion on keeping the current IETF MUST AH, ESP rules. This may well be the only acceptable solution to everyone. However, I must point out that with just AH and ESP you can't actually *use* them in an environment with e.g. dynamic addressing and lots of nodes, so the rules are sort of half-way. In conclusion, I'm hoping we could discuss some of the actual technical issues, because it's a bit more fine grained than a security-nosecurity. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 08:00:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27G0ZKL009130 for ; Thu, 7 Mar 2002 08:00:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27G0ZWm009129 for ipng-dist; Thu, 7 Mar 2002 08:00:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27G0WKL009122 for ; Thu, 7 Mar 2002 08:00:32 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03338 for ; Thu, 7 Mar 2002 08:00:32 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09950 for ; Thu, 7 Mar 2002 09:00:26 -0700 (MST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g27G0vi14003 for ; Thu, 7 Mar 2002 18:00:57 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 7 Mar 2002 18:00:17 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 7 Mar 2002 18:00:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Thu, 7 Mar 2002 18:00:17 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFD8DFAA@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should DAD be optional? [Was draft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHFQlk0NDrLLEnPRPeHdYoDoonqqAAYtsNA To: , Cc: , , X-OriginalArrivalTime: 07 Mar 2002 16:00:17.0977 (UTC) FILETIME=[2D3BD290:01C1C5F1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g27G0WKL009123 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Keith, > Within IETF, the best we can do is to produce clear guidelines for what > is expected. The harm that will result if the expectations are violated > is not always possible to document in advance. Just look at the level > of denial that's still occuring about the harm that NATs cause. Hopefully noone things that our document is comparible to NATs ;) My hope is that what we produce is clear, reaches consensus in the WG and is useful. I do think that giving assistance on when some IPv6 signaling is needed and when it is option to use is a good thing (bounded by consensus with the WG). thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 08:56:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27Gu7KL009373 for ; Thu, 7 Mar 2002 08:56:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27Gu6BS009372 for ipng-dist; Thu, 7 Mar 2002 08:56:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27Gu3KL009365 for ; Thu, 7 Mar 2002 08:56:03 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16735 for ; Thu, 7 Mar 2002 08:56:04 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA13192 for ; Thu, 7 Mar 2002 08:56:03 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g27Gq4B02189; Thu, 7 Mar 2002 17:52:04 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA10587; Thu, 7 Mar 2002 17:52:04 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g27Gq3g19662; Thu, 7 Mar 2002 17:52:03 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203071652.g27Gq3g19662@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ralph Droms cc: "Bound, Jim" , "Dr. Subrata Goswami" , ipng@sunroof.eng.sun.com Subject: Re: PPP and Global Addresses In-reply-to: Your message of Thu, 07 Mar 2002 08:44:28 EST. <4.3.2.7.2.20020307083510.00b60e40@funnel.cisco.com> Date: Thu, 07 Mar 2002 17:52:03 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I have to jump in here - DHCPv6 is *not* just for dynamic address allocation. Have those who are claiming that DHCPv6 will not be used actually read the spec? => I read the spec (one of the statements I used in a message to Jim is from the introduction of the draft). My concern is the primary objective of DHCPv6 is the dynamic address allocation, and a protocol which can fulfill all other functions should be far simpler. It will be used for other configuration parameters, as described in draft-droms-dnsconfig-dhcpv6-01.txt Arguments that DHCPv6 has no utility because of stateless address autoconfiguration are bogus. => the issue of DNS configuration is solved by another protocol. You can disagree with the DT conclusions (or the principle of DTs) but they propose a dedicated simpler protocol. DHCPv6 has to drag the dynamic address allocation ball & chain and shall ever be far more complex than any other solution for "additional configuration". Once again, stateless address autoconfiguration is great. But it's not enough. An IPv6 host needs *at least* DNS configuration information to be useful. => this is why a design team had to look for a solution. DHCPv6 is a reasonable way to provide that additional configuration information. => I strongly disagree and it seems my opinion is shared by many persons in the IPv6 WG (at the exception of Jim). Is there a buzz from network designers, managers or admins - folks who actually *run* networks and who understand IPv6 - asking for DHCP to go away? => we don't ask for DHCPv6 to go away. DHCPv6 is simply not here and for the addressing point of view stateless autoconfiguration proved it was enough. Regards Francis.Dupont@enst-bretagne.fr PS: I worked many years on DHCPv6 so I believe I won the right to express my opinion: I was tired to try to save DHCPv6 (to find another usage/utility) for instance so now I've given up. BTW at the interim meeting I was the only person who tried to make DHCPv6 an option for prefix delegation (it was my last attempt) and *nobody* voted in favor of it. (cf http://playground.sun.com/pub/ipng/html/minutes/ipng-meeting-may2001.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 Thu Mar 7 09:13:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27HDdKL009398 for ; Thu, 7 Mar 2002 09:13:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27HDd3I009397 for ipng-dist; Thu, 7 Mar 2002 09:13:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27HDZKL009390 for ; Thu, 7 Mar 2002 09:13:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05012 for ; Thu, 7 Mar 2002 09:13:36 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05743 for ; Thu, 7 Mar 2002 09:13:36 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA25174; Thu, 7 Mar 2002 09:13:36 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g27HDZC07984; Thu, 7 Mar 2002 09:13:35 -0800 X-mProtect:  Thu, 7 Mar 2002 09:13:35 -0800 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdJFgbES; Thu, 07 Mar 2002 09:13:33 PST Message-ID: <3C879FBD.91D07A5A@iprg.nokia.com> Date: Thu, 07 Mar 2002 09:13:33 -0800 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Karim El-Malki (ERA)" CC: ipng@sunroof.eng.sun.com Subject: Re: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00.txt -> wg last call?] References: <795A014AF92DD21182AF0008C7A404320DFBEFEC@esealnt117> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Karim, I have no problem with the words in your note, but then you have to rename the draft to be "IPv6-over-nearterm-3G", or better, "IPv6-over-3GPPr5-PDP". That gets the point across. If it's "IPv6-over-cellular", then you have to write the specification to apply to ALL cellular systems, current and future. That was the point in my note you quoted. Regards, Charlie P. "Karim El-Malki (ERA)" wrote: > > I'd prefer dealing with what we have now first since I'd > like to see v6 deployed in 3g in the near term. > We could discuss for a long time on how to improve a certain > cellular system and we probably all have our ideas > but that discussion would not belong here. > > Regarding the DAD issue, it's the same thing that > can be done on any PPP link between a host and a router > with prefix delegation. DAD can be disabled there, > so no point of saying it can't be done in a cellular system > that is the same as that PPP link from the IPv6 point of view. > > /Karim > > > -----Original Message----- > > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > Sent: den 6 mars 2002 22:38 > > To: Karim El-Malki (ERA) > > Cc: ipng@sunroof.eng.sun.com > > Subject: Re: Should DAD be optional? > > [Wasdraft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > > > > Hello Karim, > > > > "Karim El-Malki (ERA)" wrote: > > > > > I agree that it would be good to see some guidelines in an > > > informational doc. However I disagree on the title change to > > > IPv6 over cellular/3g. That is a different spec which we should > > > also work on. > > > > It is possible to design "cellular" systems where the > > 3GPP/PDP address assignment is completely replaced by > > localized, stateless methods. The way that addresses > > are assigned is not related to bandwidth, nor even to > > essential authorization issues. It's an artifact of > > near-compatibility with existing 2.5G layouts. GGSN > > does not NECESSARILY need to control this process. > > > > Thus, any document which recommends that DAD or Neighbor > > Discovery might be executed rarely if ever, would not fit > > such "cellular" systems as I would hope eventually do > > come about. > > > > Regards, > > Charlie P. > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 09:15:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27HFbKL009415 for ; Thu, 7 Mar 2002 09:15:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27HFa46009414 for ipng-dist; Thu, 7 Mar 2002 09:15:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27HFXKL009407 for ; Thu, 7 Mar 2002 09:15:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22477 for ; Thu, 7 Mar 2002 09:15:34 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA15469 for ; Thu, 7 Mar 2002 10:15:33 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g27HEuB06779; Thu, 7 Mar 2002 18:14:56 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA11236; Thu, 7 Mar 2002 18:14:57 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g27HEug19848; Thu, 7 Mar 2002 18:14:56 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203071714.g27HEug19848@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: RA with lifetime=0 and clearing Destination Cache? In-reply-to: Your message of Thu, 07 Mar 2002 16:53:45 +0200. <200203071453.QAA23692@burp.tkv.asdf.org> Date: Thu, 07 Mar 2002 18:14:56 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: In RFC-2461 "6.3.5 Timing out Prefixes adn Default Routers" it says: Whenever the Lifetime of an entry in the Default Router List expires, that entry is discarded. When removing a router from the Default Router list, the node MUST update the Destination Cache in such a way that all entries using the router perform next-hop determination again rather than continue sending traffic to the (deleted) router. => the deletion is *only* when the previous lifetime was not 0, i.e. there WAS an entry. [The reason I noticed, once again TAHI test failed, because *I* only removed those destinations that actually are related to the default route. I didn't remove redirections, for example... I suppose I have to fix this feature to be RFC compliant? :-] => you should remove redirections when the router stops to be a default router (cf. the reference) or to be a router (no R bit in NAs). The important detail is this is about transitions. Regards Francis.Dupont@enst-bretagne.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 Thu Mar 7 09:26:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27HQbKL009452 for ; Thu, 7 Mar 2002 09:26:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27HQaYf009451 for ipng-dist; Thu, 7 Mar 2002 09:26:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27HQXKL009444 for ; Thu, 7 Mar 2002 09:26:33 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08276 for ; Thu, 7 Mar 2002 09:26:34 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01303 for ; Thu, 7 Mar 2002 09:26:33 -0800 (PST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-128.cisco.com [161.44.149.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA26966; Thu, 7 Mar 2002 12:26:11 -0500 (EST) Message-Id: <4.3.2.7.2.20020307122231.00b74d78@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Mar 2002 12:26:09 -0500 To: Francis Dupont From: Ralph Droms Subject: Re: PPP and Global Addresses Cc: "Bound, Jim" , "Dr. Subrata Goswami" , ipng@sunroof.eng.sun.com In-Reply-To: <200203071652.g27Gq3g19662@givry.rennes.enst-bretagne.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 05:52 PM 3/7/2002 +0100, Francis Dupont wrote: > In your previous mail you wrote: > > It will be used for other configuration > parameters, as described in > draft-droms-dnsconfig-dhcpv6-01.txt Arguments > that DHCPv6 has no utility because of stateless address autoconfiguration > are bogus. > >=> the issue of DNS configuration is solved by another protocol. >You can disagree with the DT conclusions (or the principle of DTs) >but they propose a dedicated simpler protocol. DHCPv6 has to drag >the dynamic address allocation ball & chain and shall ever be far >more complex than any other solution for "additional configuration". I do disagree with the DT conclusion - as do other WG member who spoke up in SLC - but I'll let the rest of the WG members make up their own minds about the various protocol proposals. If the other solutions are so simple, why aren't they done yet? - 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 Thu Mar 7 09:58:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27Hw9KL009564 for ; Thu, 7 Mar 2002 09:58:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27Hw98j009563 for ipng-dist; Thu, 7 Mar 2002 09:58:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27Hw6KL009556 for ; Thu, 7 Mar 2002 09:58:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07062 for ; Thu, 7 Mar 2002 09:58:07 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10968 for ; Thu, 7 Mar 2002 10:58:06 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g27Hw6B23934 for ; Thu, 7 Mar 2002 18:58:06 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 07 18:58:04 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 18:58:05 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF0538037304A4@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: ipng@sunroof.eng.sun.com Subject: Cellular host draft - where we are and suggestions for moving for ward. Date: Thu, 7 Mar 2002 18:57:57 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I think we're having a pretty useful discussion about this draft which has highlighted a number of issues that need to be addressed. This is an attempt to summarise the issues that were discussed and see if we can find a way forward. Please note, this is not to suggest 1, 2 or 3 drafts ...etc, this is an attempt to resolve the technical issues first, editing them in documents is another issue that can be handled after we agree on what we're going to put in such documents. Before I list the issues and responses, I'd like to highlight an important point: This draft attempts to do 2 things: - Define the behaviour of a cellular host residing on a cellular link (in this case we only know of 3GPP networks because no one else has defined the use of IPv6 in their specific link) - List the host implementation requirements in a cellular network (not only 3GPP) based on the common characteristics of these networks (p2p channels, BW, resilience over the air interface ...etc) Perhaps the two points above can be separated in 2 documents, but I'm really interested in getting an agreement on the technical issues _first_. Editorial issues are secondary here. So the main issues that were brought up so far are (please let me know if I missed a major issue): Issue: What is a cellular host ? Suggestion: A cellular host is _any_ host that has a cellular interface. This would include low end devices like basic phones and high end devices like laptops. Low end devices will generally follow the behavioural aspects of the draft as well as the minimum implementation requirements, due to the lack of computing capacity. However, high end devices will implement whatever they want, but MUST follow the required behaviour _on_the_cellular_ interface. Please note that when it comes to implementation requirements, the draft never suggests that a standard MUST NOT be implemented, so everyone is free to implement more. The draft aims at the minimum, interoperable implementation. Issue: The use of the word 'terminal' is confusing. Suggestion: replace 'terminal' with Host. This was a mistake anyway. Issue: Should DAD be disallowed Answer: DAD for the general cellualar case is allowed in the draft. In the 3GPP-sepcific case, DAD is not needed because: - The link is p2p - The link-local address is given to the cellular host (it can't reject it). - A /64 is given to the cellular host _only_ - The GGSN will ensure the uniqueness of llA and will not use the host's /64 to configure any of its global addresses. The same goes for site-local if used. So DAD is not needed. This is analogous to a design decision to always assume an MTU of 1280, PMTU implementation becomes superfluous if the host will _never_ send a packet larger than 1280. I think we should close this issue unless someone points out a flaw above. Issue: Should IPsec be mandated? Suggestion: We should mandate AH and ESP for all hosts, following RFC2460. Issue: Should ND be mandated? Answer: ND is mandated in the draft. Certain options are not mandated on cellualar links (like LLA suboption) because it's not relevant. NUD is a MAY because there are other ways of detecting reachability in these links. If multiple default routers exist RSs and RAs will detect the failure of one of those routers. Issue: Stateless address autoconfig (2462) allowed? Answer: Yes it's allowed for the general cellualr case. However for the 3GPP case stateless address allocation works differently from RFC2462 (and does not break 3041), so come parts of RFC2462 are not relevant (the DAD part again!) Comments so far? Are these suggestions/answers accepatable? It took me 2.5 hours to write this email because of my wonderful mail server, so I probably won't be able to give quick responses. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 10:17:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27IH1KL009695 for ; Thu, 7 Mar 2002 10:17:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27IH1A6009694 for ipng-dist; Thu, 7 Mar 2002 10:17:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27IGwKL009687 for ; Thu, 7 Mar 2002 10:16:58 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21302 for ; Thu, 7 Mar 2002 10:16:55 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03847 for ; Thu, 7 Mar 2002 10:16:54 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g27IGrB28712 for ; Thu, 7 Mar 2002 19:16:53 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 07 19:16:52 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 19:16:52 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA9A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Charles E. Perkins'" , "Karim El-Malki (ERA)" Cc: ipng@sunroof.eng.sun.com Subject: RE: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Thu, 7 Mar 2002 19:08:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have no problem with the words in your note, but then you > have to rename the draft to be "IPv6-over-nearterm-3G", or > better, "IPv6-over-3GPPr5-PDP". That gets the point across. > > If it's "IPv6-over-cellular", then you have to write > the specification to apply to ALL cellular systems, current > and future. That was the point in my note you quoted. => Basically we're saying similar things in different ways. My note (hasn't made it to the list yet) said that we addressed both of the above in the draft. The secions titled 'X function in 3GPP' address the specifics. It seems that there is some confusion about whether cellular == 3GPP. That's certainly not the case as it is explicitly stated in the draft. So I do see the case for 2 documents, but the important issue right now is to have some agreement on the technical content, then decide if it should be split into more than one document. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 10:50:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27IoMKL009975 for ; Thu, 7 Mar 2002 10:50:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27IoMtJ009974 for ipng-dist; Thu, 7 Mar 2002 10:50:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27IoIKL009967 for ; Thu, 7 Mar 2002 10:50:18 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA22277 for ; Thu, 7 Mar 2002 10:50:18 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA17498 for ; Thu, 7 Mar 2002 10:50:17 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g27IoFt23142; Thu, 7 Mar 2002 13:50:15 -0500 (EST) Message-Id: <200203071850.g27IoFt23142@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (ERA)" cc: ipng@sunroof.eng.sun.com Subject: Re: Cellular host draft - where we are and suggestions for moving for ward. In-reply-to: (Your message of "Thu, 07 Mar 2002 18:57:57 +0100.") <4DA6EA82906FD511BE2F00508BCF0538037304A4@Esealnt861.al.sw.ericsson.se> Date: Thu, 07 Mar 2002 13:50:15 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - A /64 is given to the cellular host _only_ what does that mean? surely the purpose of delegating a /64 is so that multiple hosts can use it. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 7 10:52:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27IqVKL010009 for ; Thu, 7 Mar 2002 10:52:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27IqUYE010008 for ipng-dist; Thu, 7 Mar 2002 10:52:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27IqRKL010001 for ; Thu, 7 Mar 2002 10:52:27 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05202 for ; Thu, 7 Mar 2002 10:52:27 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13537 for ; Thu, 7 Mar 2002 10:52:26 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g27IqPB05600 for ; Thu, 7 Mar 2002 19:52:25 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 07 19:52:19 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 19:52:19 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA9D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Robert Elz'" , "Karim El-Malki (ERA)" Cc: "'Ignatios Souvatzis'" , ipng@sunroof.eng.sun.com Subject: RE: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cel lular-host-00.txt -> wg last call?] Date: Thu, 7 Mar 2002 19:31:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk But when you need IPsec, you > need it - and that you happen to be using a cellular link for some > particular communications is irrelevant. => Hmm. That's a pretty big statement. If someone decides to use IPsec for VoIP (an extreme example I know) then is it still irrelevant whether you are on a cellualr link or not? I think it will, very quickly, become relevant when you get your phone bill! So the point is, and Jari has already highlighted that, you have to be careful what kind of security you use for what functions Cheers, Hesham Whether to use IPsec or > not will depend upon the particular communications at any particular > instant, and needs to be able to be determined by the user > - certainly > never by the implementor, who has no idea what environment > (which includes > the remote end of communications) the equipment will be used in. > > kre > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 11:10:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27JAVKL010057 for ; Thu, 7 Mar 2002 11:10:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27JAVTl010056 for ipng-dist; Thu, 7 Mar 2002 11:10:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27JASKL010049 for ; Thu, 7 Mar 2002 11:10:28 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27873 for ; Thu, 7 Mar 2002 11:10:28 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21672 for ; Thu, 7 Mar 2002 11:10:27 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 07 Mar 2002 11:09:37 -0800 From: "Tony Hain" To: "Hesham Soliman \(ERA\)" , Subject: RE: Cellular host draft - where we are and suggestions for moving forward. Date: Thu, 7 Mar 2002 11:09:38 -0800 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4DA6EA82906FD511BE2F00508BCF0538037304A4@Esealnt861.al.sw.ericsson.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, I appreciate where you are trying to go, but I think you are still being blinded to issues because the focus is to centric on *host*. Yes people are motivated to worry about that problem first, but making design assumptions based on the mobile device on the end of an air-link being limited to a host will cause problems. The current logic appears to be 'we don't want to do DAD, so define the link in terms of a host so it is unnecessary, then worry about a router later'. The host perspective should always be a subset of the demands of a link technology, so starting there will only assure that the link can never be used outside that scope. A group that is so focused on overhead of bits on the air-link should really be concerned about the impact of forcing a router to use IPv6 over IPv6 tunneling to get a reasonable service over it. As a specific comment to your note, rather than assume that implementations will end up with an MTU of 1280, simply state that the interface MTU == 1280. In any case the infrastructure components will have to respond appropriately to nodes that implement PMTU, so don't assume that it won't happen just because it is not required for devices that are directly attached. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Hesham > Soliman (ERA) > Sent: Thursday, March 07, 2002 9:58 AM > To: ipng@sunroof.eng.sun.com > Subject: Cellular host draft - where we are and suggestions for moving > forward. > > > Hi all, > > I think we're having a pretty useful discussion > about this draft which has highlighted a number > of issues that need to be addressed. This > is an attempt to summarise the issues that were > discussed and see if we can find a way forward. > > Please note, this is not to suggest 1, 2 or 3 > drafts ...etc, this is an attempt to resolve the > technical issues first, editing them in documents > is another issue that can be handled after we > agree on what we're going to put in such documents. > > Before I list the issues and responses, I'd like > to highlight an important point: This draft attempts > to do 2 things: > > - Define the behaviour of a cellular host residing > on a cellular link (in this case we only know of > 3GPP networks because no one else has defined > the use of IPv6 in their specific link) > > - List the host implementation requirements in > a cellular network (not only 3GPP) based on > the common characteristics of these networks > (p2p channels, BW, resilience over the air > interface ...etc) > > Perhaps the two points above can be separated > in 2 documents, but I'm really interested in > getting an agreement on the technical issues > _first_. Editorial issues are secondary here. > > So the main issues that were brought up so far are > (please let me know if I missed a major issue): > > Issue: What is a cellular host ? > > Suggestion: A cellular host is _any_ host that > has a cellular interface. This would include > low end devices like basic phones and high > end devices like laptops. Low end devices will > generally follow the behavioural aspects of > the draft as well as the minimum implementation > requirements, due to the lack of computing capacity. > However, high end devices will implement whatever > they want, but MUST follow the required behaviour > _on_the_cellular_ interface. > Please note that when it comes to implementation > requirements, the draft never suggests that > a standard MUST NOT be implemented, so everyone > is free to implement more. The draft aims at > the minimum, interoperable implementation. > > Issue: The use of the word 'terminal' is > confusing. > > Suggestion: replace 'terminal' with Host. > This was a mistake anyway. > > Issue: Should DAD be disallowed > > Answer: DAD for the general cellualar > case is allowed in the draft. > In the 3GPP-sepcific case, DAD is not needed because: > > - The link is p2p > > - The link-local address is given to the > cellular host (it can't reject it). > > - A /64 is given to the cellular host _only_ > > - The GGSN will ensure the uniqueness of llA > and will not use the host's /64 to configure > any of its global addresses. The same goes > for site-local if used. > > So DAD is not needed. This is analogous to > a design decision to always assume an MTU > of 1280, PMTU implementation becomes superfluous > if the host will _never_ send a packet larger > than 1280. > I think we should close this issue unless someone > points out a flaw above. > > Issue: Should IPsec be mandated? > > Suggestion: We should mandate AH and ESP for > all hosts, following RFC2460. > > Issue: Should ND be mandated? > > Answer: ND is mandated in the draft. > Certain options are not mandated on cellualar > links (like LLA suboption) because it's not > relevant. NUD is a MAY because there are > other ways of detecting reachability in > these links. If multiple default routers exist > RSs and RAs will detect the failure of one > of those routers. > > Issue: Stateless address autoconfig (2462) > allowed? > > Answer: Yes it's allowed for the general > cellualr case. However for the 3GPP case > stateless address allocation works differently > from RFC2462 (and does not break 3041), so > come parts of RFC2462 are not relevant > (the DAD part again!) > > Comments so far? Are these suggestions/answers > accepatable? > > It took me 2.5 hours to write this email because > of my wonderful mail server, so I probably > won't be able to give quick responses. > > Hesham > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 7 11:12:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27JCoKL010077 for ; Thu, 7 Mar 2002 11:12:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27JCnjC010076 for ipng-dist; Thu, 7 Mar 2002 11:12:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27JCkKL010069 for ; Thu, 7 Mar 2002 11:12:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09823 for ; Thu, 7 Mar 2002 11:12:46 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29609 for ; Thu, 7 Mar 2002 12:12:45 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g27JCiB09250 for ; Thu, 7 Mar 2002 20:12:44 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 07 20:12:42 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 20:02:54 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA9E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Keith Moore'" Cc: ipng@sunroof.eng.sun.com Subject: RE: Cellular host draft - where we are and suggestions for moving for ward. Date: Thu, 7 Mar 2002 19:53:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > - A /64 is given to the cellular host _only_ > > what does that mean? surely the purpose of delegating a > /64 is so that > multiple hosts can use it. => It means something like this: A B GGSN ------- Host------- whatever you want tp put GGSNs MUST NOT use the /64 to configure addresses on their own interfaces. If another host behind the cellular host (router in this case?) configures an address it can do DAD as usual on link B. But no DAD is needed on link A. Makes sense? Hesham > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 11:35:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27JZ0KL010306 for ; Thu, 7 Mar 2002 11:35:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27JZ0Kh010305 for ipng-dist; Thu, 7 Mar 2002 11:35:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27JYuKL010298 for ; Thu, 7 Mar 2002 11:34:56 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19532 for ; Thu, 7 Mar 2002 11:34:56 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA23564 for ; Thu, 7 Mar 2002 12:34:56 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g27JYrt23247; Thu, 7 Mar 2002 14:34:53 -0500 (EST) Message-Id: <200203071934.g27JYrt23247@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Hesham Soliman (ERA)" cc: "'Keith Moore'" , ipng@sunroof.eng.sun.com Subject: Re: Cellular host draft - where we are and suggestions for moving for ward. In-reply-to: (Your message of "Thu, 07 Mar 2002 19:53:30 +0100.") <4DA6EA82906FD511BE2F00508BCF053802C6AA9E@Esealnt861.al.sw.ericsson.se> Date: Thu, 07 Mar 2002 14:34:53 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > GGSNs MUST NOT use the /64 to configure addresses on their own interfaces. > If another host behind the cellular host (router in this case?) > configures an address it can do DAD as usual on link B. But no DAD is > needed on link A. > > Makes sense? yes. thanks. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 11:53:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27JrdKL010362 for ; Thu, 7 Mar 2002 11:53:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27Jrc6q010361 for ipng-dist; Thu, 7 Mar 2002 11:53:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27JrZKL010354 for ; Thu, 7 Mar 2002 11:53:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19674 for ; Thu, 7 Mar 2002 11:53:36 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA15683 for ; Thu, 7 Mar 2002 12:53:34 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g27JrXZc027934 for ; Thu, 7 Mar 2002 20:53:33 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 07 20:53:32 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 20:43:43 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFF3@esealnt117> From: "Karim El-Malki (ERA)" To: "'Tony Hain'" , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: RE: Cellular host draft - where we are and suggestions for moving forward. Date: Thu, 7 Mar 2002 20:52:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, The right thing is to consider a basic host first, which is what the cellular hosts work is about. That is simply because 3gpp will make widespread deployment of v6 hosts in the near term. If we delay things further we're just going to end up with 3gpp people going off and doing their own thing as Jim pointed out. I hope we can make sure this doesn't happen. You want us to consider a router on the other end of a cellular link when we don't even have a minimum host requirements document. How can that make sense? Let's do one thing at a time, hosts first, and ensure that we'll have compatibility. In any case, I can't see that we have cut out any future development based on having routers there even if we disable DAD (on the cellular link ONLY). Anyway this is not the important issue right now since the problem we are facing is widespread host deployment. /Karim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: den 7 mars 2002 20:10 > To: Hesham Soliman (ERA); ipng@sunroof.eng.sun.com > Subject: RE: Cellular host draft - where we are and suggestions for > moving forward. > > > Hesham, > > I appreciate where you are trying to go, but I think you are > still being > blinded to issues because the focus is to centric on *host*. > Yes people > are motivated to worry about that problem first, but making design > assumptions based on the mobile device on the end of an > air-link being > limited to a host will cause problems. The current logic > appears to be > 'we don't want to do DAD, so define the link in terms of a > host so it is > unnecessary, then worry about a router later'. The host perspective > should always be a subset of the demands of a link technology, so > starting there will only assure that the link can never be > used outside > that scope. A group that is so focused on overhead of bits on the > air-link should really be concerned about the impact of > forcing a router > to use IPv6 over IPv6 tunneling to get a reasonable service over it. > > As a specific comment to your note, rather than assume that > implementations will end up with an MTU of 1280, simply > state that the > interface MTU == 1280. In any case the infrastructure components will > have to respond appropriately to nodes that implement PMTU, so don't > assume that it won't happen just because it is not required > for devices > that are directly attached. > > Tony > > > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Hesham > > Soliman (ERA) > > Sent: Thursday, March 07, 2002 9:58 AM > > To: ipng@sunroof.eng.sun.com > > Subject: Cellular host draft - where we are and > suggestions for moving > > forward. > > > > > > Hi all, > > > > I think we're having a pretty useful discussion > > about this draft which has highlighted a number > > of issues that need to be addressed. This > > is an attempt to summarise the issues that were > > discussed and see if we can find a way forward. > > > > Please note, this is not to suggest 1, 2 or 3 > > drafts ...etc, this is an attempt to resolve the > > technical issues first, editing them in documents > > is another issue that can be handled after we > > agree on what we're going to put in such documents. > > > > Before I list the issues and responses, I'd like > > to highlight an important point: This draft attempts > > to do 2 things: > > > > - Define the behaviour of a cellular host residing > > on a cellular link (in this case we only know of > > 3GPP networks because no one else has defined > > the use of IPv6 in their specific link) > > > > - List the host implementation requirements in > > a cellular network (not only 3GPP) based on > > the common characteristics of these networks > > (p2p channels, BW, resilience over the air > > interface ...etc) > > > > Perhaps the two points above can be separated > > in 2 documents, but I'm really interested in > > getting an agreement on the technical issues > > _first_. Editorial issues are secondary here. > > > > So the main issues that were brought up so far are > > (please let me know if I missed a major issue): > > > > Issue: What is a cellular host ? > > > > Suggestion: A cellular host is _any_ host that > > has a cellular interface. This would include > > low end devices like basic phones and high > > end devices like laptops. Low end devices will > > generally follow the behavioural aspects of > > the draft as well as the minimum implementation > > requirements, due to the lack of computing capacity. > > However, high end devices will implement whatever > > they want, but MUST follow the required behaviour > > _on_the_cellular_ interface. > > Please note that when it comes to implementation > > requirements, the draft never suggests that > > a standard MUST NOT be implemented, so everyone > > is free to implement more. The draft aims at > > the minimum, interoperable implementation. > > > > Issue: The use of the word 'terminal' is > > confusing. > > > > Suggestion: replace 'terminal' with Host. > > This was a mistake anyway. > > > > Issue: Should DAD be disallowed > > > > Answer: DAD for the general cellualar > > case is allowed in the draft. > > In the 3GPP-sepcific case, DAD is not needed because: > > > > - The link is p2p > > > > - The link-local address is given to the > > cellular host (it can't reject it). > > > > - A /64 is given to the cellular host _only_ > > > > - The GGSN will ensure the uniqueness of llA > > and will not use the host's /64 to configure > > any of its global addresses. The same goes > > for site-local if used. > > > > So DAD is not needed. This is analogous to > > a design decision to always assume an MTU > > of 1280, PMTU implementation becomes superfluous > > if the host will _never_ send a packet larger > > than 1280. > > I think we should close this issue unless someone > > points out a flaw above. > > > > Issue: Should IPsec be mandated? > > > > Suggestion: We should mandate AH and ESP for > > all hosts, following RFC2460. > > > > Issue: Should ND be mandated? > > > > Answer: ND is mandated in the draft. > > Certain options are not mandated on cellualar > > links (like LLA suboption) because it's not > > relevant. NUD is a MAY because there are > > other ways of detecting reachability in > > these links. If multiple default routers exist > > RSs and RAs will detect the failure of one > > of those routers. > > > > Issue: Stateless address autoconfig (2462) > > allowed? > > > > Answer: Yes it's allowed for the general > > cellualr case. However for the 3GPP case > > stateless address allocation works differently > > from RFC2462 (and does not break 3041), so > > come parts of RFC2462 are not relevant > > (the DAD part again!) > > > > Comments so far? Are these suggestions/answers > > accepatable? > > > > It took me 2.5 hours to write this email because > > of my wonderful mail server, so I probably > > won't be able to give quick responses. > > > > Hesham > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Thu Mar 7 12:43:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27KhiKL010399 for ; Thu, 7 Mar 2002 12:43:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27Khi8J010398 for ipng-dist; Thu, 7 Mar 2002 12:43:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27KheKL010391 for ; Thu, 7 Mar 2002 12:43:40 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA13507 for ; Thu, 7 Mar 2002 12:43:38 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA13610 for ; Thu, 7 Mar 2002 12:43:37 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g27KhaZc004664 for ; Thu, 7 Mar 2002 21:43:36 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Mar 07 21:43:34 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 21:43:34 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AAA0@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Tony Hain'" , ipng@sunroof.eng.sun.com Subject: RE: Cellular host draft - where we are and suggestions for moving forward. Date: Thu, 7 Mar 2002 21:11:11 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, > I appreciate where you are trying to go, but I think you > are still being > blinded to issues because the focus is to centric on > *host*. Yes people > are motivated to worry about that problem first, but making design > assumptions based on the mobile device on the end of an > air-link being > limited to a host will cause problems. The current logic > appears to be > 'we don't want to do DAD, so define the link in terms of a > host so it is > unnecessary, then worry about a router later'. The host perspective > should always be a subset of the demands of a link technology, so > starting there will only assure that the link can never be > used outside > that scope. A group that is so focused on overhead of bits on the > air-link should really be concerned about the impact of > forcing a router > to use IPv6 over IPv6 tunneling to get a reasonable service over it. => I think there is a bigger misunderstanding here that perhaps isn't obvious to one of us (you or me). What implications do you see (regarding DAD) which would cause us to distinguish between a host or a router? In the example I gave to Keith, if you have a router there are 2 separate links. The same rules about DAD on the cellular interface would still apply. What am I missing? > As a specific comment to your note, rather than assume that > implementations will end up with an MTU of 1280, simply > state that the > interface MTU == 1280. In any case the infrastructure > components will > have to respond appropriately to nodes that implement PMTU, so don't > assume that it won't happen just because it is not required > for devices > that are directly attached. => Sure, PMTU was used as an analogy. The difference of course is that DAD is link specific, so once you define the behaviour on a certain link, you know thatit will be interoperable for all devices with interfaces on that link. Hesham > > Tony > > > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Hesham > > Soliman (ERA) > > Sent: Thursday, March 07, 2002 9:58 AM > > To: ipng@sunroof.eng.sun.com > > Subject: Cellular host draft - where we are and > suggestions for moving > > forward. > > > > > > Hi all, > > > > I think we're having a pretty useful discussion > > about this draft which has highlighted a number > > of issues that need to be addressed. This > > is an attempt to summarise the issues that were > > discussed and see if we can find a way forward. > > > > Please note, this is not to suggest 1, 2 or 3 > > drafts ...etc, this is an attempt to resolve the > > technical issues first, editing them in documents > > is another issue that can be handled after we > > agree on what we're going to put in such documents. > > > > Before I list the issues and responses, I'd like > > to highlight an important point: This draft attempts > > to do 2 things: > > > > - Define the behaviour of a cellular host residing > > on a cellular link (in this case we only know of > > 3GPP networks because no one else has defined > > the use of IPv6 in their specific link) > > > > - List the host implementation requirements in > > a cellular network (not only 3GPP) based on > > the common characteristics of these networks > > (p2p channels, BW, resilience over the air > > interface ...etc) > > > > Perhaps the two points above can be separated > > in 2 documents, but I'm really interested in > > getting an agreement on the technical issues > > _first_. Editorial issues are secondary here. > > > > So the main issues that were brought up so far are > > (please let me know if I missed a major issue): > > > > Issue: What is a cellular host ? > > > > Suggestion: A cellular host is _any_ host that > > has a cellular interface. This would include > > low end devices like basic phones and high > > end devices like laptops. Low end devices will > > generally follow the behavioural aspects of > > the draft as well as the minimum implementation > > requirements, due to the lack of computing capacity. > > However, high end devices will implement whatever > > they want, but MUST follow the required behaviour > > _on_the_cellular_ interface. > > Please note that when it comes to implementation > > requirements, the draft never suggests that > > a standard MUST NOT be implemented, so everyone > > is free to implement more. The draft aims at > > the minimum, interoperable implementation. > > > > Issue: The use of the word 'terminal' is > > confusing. > > > > Suggestion: replace 'terminal' with Host. > > This was a mistake anyway. > > > > Issue: Should DAD be disallowed > > > > Answer: DAD for the general cellualar > > case is allowed in the draft. > > In the 3GPP-sepcific case, DAD is not needed because: > > > > - The link is p2p > > > > - The link-local address is given to the > > cellular host (it can't reject it). > > > > - A /64 is given to the cellular host _only_ > > > > - The GGSN will ensure the uniqueness of llA > > and will not use the host's /64 to configure > > any of its global addresses. The same goes > > for site-local if used. > > > > So DAD is not needed. This is analogous to > > a design decision to always assume an MTU > > of 1280, PMTU implementation becomes superfluous > > if the host will _never_ send a packet larger > > than 1280. > > I think we should close this issue unless someone > > points out a flaw above. > > > > Issue: Should IPsec be mandated? > > > > Suggestion: We should mandate AH and ESP for > > all hosts, following RFC2460. > > > > Issue: Should ND be mandated? > > > > Answer: ND is mandated in the draft. > > Certain options are not mandated on cellualar > > links (like LLA suboption) because it's not > > relevant. NUD is a MAY because there are > > other ways of detecting reachability in > > these links. If multiple default routers exist > > RSs and RAs will detect the failure of one > > of those routers. > > > > Issue: Stateless address autoconfig (2462) > > allowed? > > > > Answer: Yes it's allowed for the general > > cellualr case. However for the 3GPP case > > stateless address allocation works differently > > from RFC2462 (and does not break 3041), so > > come parts of RFC2462 are not relevant > > (the DAD part again!) > > > > Comments so far? Are these suggestions/answers > > accepatable? > > > > It took me 2.5 hours to write this email because > > of my wonderful mail server, so I probably > > won't be able to give quick responses. > > > > Hesham > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Mar 7 13:02:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27L2sKL010434 for ; Thu, 7 Mar 2002 13:02:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27L2rV8010433 for ipng-dist; Thu, 7 Mar 2002 13:02:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27L2lKL010426 for ; Thu, 7 Mar 2002 13:02:49 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24507 for ; Thu, 7 Mar 2002 13:02:48 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-068-120.evrtwa1.vz.dsl.gtei.net [4.60.68.120]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA12234 for ; Thu, 7 Mar 2002 13:02:46 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Thu, 07 Mar 2002 13:02:45 -0800 From: "Tony Hain" To: "Karim El-Malki \(ERA\)" , "Hesham Soliman \(ERA\)" , Subject: RE: Cellular host draft - where we are and suggestions for moving forward. Date: Thu, 7 Mar 2002 13:02:45 -0800 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <795A014AF92DD21182AF0008C7A404320DFBEFF3@esealnt117> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Karim El-Malki wrote: > The right thing is to consider a basic host first, which is > what the cellular hosts work is about. That is simply because > 3gpp will make widespread deployment of v6 hosts in the near term. That is exactly why it is critical that this be done right the first time. Once a widespread deployment happens it will be impossible to change. > If we delay things further we're just going to end up with 3gpp > people going off and doing their own thing as Jim pointed out. Threatening to go away and do the wrong thing as a justification to do the wrong thing here is a waste of time. > I hope we can make sure this doesn't happen. You want us to > consider a router on the other end of a cellular link when we > don't even have a minimum host requirements document. How can that > make sense? Let's do one thing at a time, hosts first, and ensure > that we'll have compatibility. I have been very consistent in that I want you to describe the characteristics of the link. The device on the end could be either a host or router, but the current focus on limited capability hosts is preventing progress. The micro-handset *IS NOT SPECIAL*, so just get over it. What you need is a standard way of using a link that has different characteristics than other link technologies already defined. > > In any case, I can't see that we have cut out any future development > based on having routers there even if we disable DAD (on the > cellular link ONLY). Anyway this is not the important issue right > now since the problem we are facing is widespread host deployment. You are talking about product design issues, not standards development issues. The standards issue is that we need to describe the characteristics of a specific air-link technology so it can be used in a consistent manner with other link technologies across all IPv6 capable hosts AND routers. The longer people persist on trying to solve day-job problems by inisiting on solving the limited case first, the longer it will take to make any progress. I am not against making progress on a document that can be used for 3G host deployments. I just can't see any real need to special case this and limit the long term potential of the link just because some people thought time-to-market was more important than doing it right. Tony > > /Karim > > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > Sent: den 7 mars 2002 20:10 > > To: Hesham Soliman (ERA); ipng@sunroof.eng.sun.com > > Subject: RE: Cellular host draft - where we are and suggestions for > > moving forward. > > > > > > Hesham, > > > > I appreciate where you are trying to go, but I think you are > > still being > > blinded to issues because the focus is to centric on *host*. > > Yes people > > are motivated to worry about that problem first, but making design > > assumptions based on the mobile device on the end of an > > air-link being > > limited to a host will cause problems. The current logic > > appears to be > > 'we don't want to do DAD, so define the link in terms of a > > host so it is > > unnecessary, then worry about a router later'. The host perspective > > should always be a subset of the demands of a link technology, so > > starting there will only assure that the link can never be > > used outside > > that scope. A group that is so focused on overhead of bits on the > > air-link should really be concerned about the impact of > > forcing a router > > to use IPv6 over IPv6 tunneling to get a reasonable > service over it. > > > > As a specific comment to your note, rather than assume that > > implementations will end up with an MTU of 1280, simply > > state that the > > interface MTU == 1280. In any case the infrastructure > components will > > have to respond appropriately to nodes that implement > PMTU, so don't > > assume that it won't happen just because it is not required > > for devices > > that are directly attached. > > > > Tony > > > > > > > > > -----Original Message----- > > > From: owner-ipng@sunroof.eng.sun.com > > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Hesham > > > Soliman (ERA) > > > Sent: Thursday, March 07, 2002 9:58 AM > > > To: ipng@sunroof.eng.sun.com > > > Subject: Cellular host draft - where we are and > > suggestions for moving > > > forward. > > > > > > > > > Hi all, > > > > > > I think we're having a pretty useful discussion > > > about this draft which has highlighted a number > > > of issues that need to be addressed. This > > > is an attempt to summarise the issues that were > > > discussed and see if we can find a way forward. > > > > > > Please note, this is not to suggest 1, 2 or 3 > > > drafts ...etc, this is an attempt to resolve the > > > technical issues first, editing them in documents > > > is another issue that can be handled after we > > > agree on what we're going to put in such documents. > > > > > > Before I list the issues and responses, I'd like > > > to highlight an important point: This draft attempts > > > to do 2 things: > > > > > > - Define the behaviour of a cellular host residing > > > on a cellular link (in this case we only know of > > > 3GPP networks because no one else has defined > > > the use of IPv6 in their specific link) > > > > > > - List the host implementation requirements in > > > a cellular network (not only 3GPP) based on > > > the common characteristics of these networks > > > (p2p channels, BW, resilience over the air > > > interface ...etc) > > > > > > Perhaps the two points above can be separated > > > in 2 documents, but I'm really interested in > > > getting an agreement on the technical issues > > > _first_. Editorial issues are secondary here. > > > > > > So the main issues that were brought up so far are > > > (please let me know if I missed a major issue): > > > > > > Issue: What is a cellular host ? > > > > > > Suggestion: A cellular host is _any_ host that > > > has a cellular interface. This would include > > > low end devices like basic phones and high > > > end devices like laptops. Low end devices will > > > generally follow the behavioural aspects of > > > the draft as well as the minimum implementation > > > requirements, due to the lack of computing capacity. > > > However, high end devices will implement whatever > > > they want, but MUST follow the required behaviour > > > _on_the_cellular_ interface. > > > Please note that when it comes to implementation > > > requirements, the draft never suggests that > > > a standard MUST NOT be implemented, so everyone > > > is free to implement more. The draft aims at > > > the minimum, interoperable implementation. > > > > > > Issue: The use of the word 'terminal' is > > > confusing. > > > > > > Suggestion: replace 'terminal' with Host. > > > This was a mistake anyway. > > > > > > Issue: Should DAD be disallowed > > > > > > Answer: DAD for the general cellualar > > > case is allowed in the draft. > > > In the 3GPP-sepcific case, DAD is not needed because: > > > > > > - The link is p2p > > > > > > - The link-local address is given to the > > > cellular host (it can't reject it). > > > > > > - A /64 is given to the cellular host _only_ > > > > > > - The GGSN will ensure the uniqueness of llA > > > and will not use the host's /64 to configure > > > any of its global addresses. The same goes > > > for site-local if used. > > > > > > So DAD is not needed. This is analogous to > > > a design decision to always assume an MTU > > > of 1280, PMTU implementation becomes superfluous > > > if the host will _never_ send a packet larger > > > than 1280. > > > I think we should close this issue unless someone > > > points out a flaw above. > > > > > > Issue: Should IPsec be mandated? > > > > > > Suggestion: We should mandate AH and ESP for > > > all hosts, following RFC2460. > > > > > > Issue: Should ND be mandated? > > > > > > Answer: ND is mandated in the draft. > > > Certain options are not mandated on cellualar > > > links (like LLA suboption) because it's not > > > relevant. NUD is a MAY because there are > > > other ways of detecting reachability in > > > these links. If multiple default routers exist > > > RSs and RAs will detect the failure of one > > > of those routers. > > > > > > Issue: Stateless address autoconfig (2462) > > > allowed? > > > > > > Answer: Yes it's allowed for the general > > > cellualr case. However for the 3GPP case > > > stateless address allocation works differently > > > from RFC2462 (and does not break 3041), so > > > come parts of RFC2462 are not relevant > > > (the DAD part again!) > > > > > > Comments so far? Are these suggestions/answers > > > accepatable? > > > > > > It took me 2.5 hours to write this email because > > > of my wonderful mail server, so I probably > > > won't be able to give quick responses. > > > > > > Hesham > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home 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 Thu Mar 7 13:43:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27LhCKL010465 for ; Thu, 7 Mar 2002 13:43:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27LhCeE010464 for ipng-dist; Thu, 7 Mar 2002 13:43:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27Lh9KL010457 for ; Thu, 7 Mar 2002 13:43:09 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA03237 for ; Thu, 7 Mar 2002 13:43:10 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29030 for ; Thu, 7 Mar 2002 13:43:08 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g27Lh7B29856 for ; Thu, 7 Mar 2002 22:43:07 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 07 22:41:52 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Mar 2002 22:33:17 +0100 Message-ID: <795A014AF92DD21182AF0008C7A404320DFBEFF5@esealnt117> From: "Karim El-Malki (ERA)" To: "'Tony Hain'" , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: RE: Cellular host draft - where we are and suggestions for moving forward. Date: Thu, 7 Mar 2002 22:42:00 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > If we delay things further we're just going to end up with 3gpp > > people going off and doing their own thing as Jim pointed out. > > Threatening to go away and do the wrong thing as a > justification to do > the wrong thing here is a waste of time. So far I haven't seen your proof that there's something technically wrong. Rather claiming I'm threatening to go away and do the wrong thing is a waste of time when we could be discussing the technical issues. > > > I hope we can make sure this doesn't happen. You want us to > > consider a router on the other end of a cellular link when we > > don't even have a minimum host requirements document. How can that > > make sense? Let's do one thing at a time, hosts first, and ensure > > that we'll have compatibility. > > I have been very consistent in that I want you to describe the > characteristics of the link. The device on the end could be either a > host or router, but the current focus on limited capability hosts is > preventing progress. The micro-handset *IS NOT SPECIAL*, so just get > over it. What you need is a standard way of using a link that has > different characteristics than other link technologies > already defined. Great, but then what is wrong with what I've been saying? One thing is the cellular link, the other is the minimum host requirements. We've already said that an IPv6 over cellular link doc was a good idea and something has been started. But without a minimum host requirements we'll go nowhere towards deployment. That is what can really delay things and cause problems. In the host requirements doc we won't consider routers of course. > I am not against making progress on a document that can be > used for 3G > host deployments. I just can't see any real need to special case this > and limit the long term potential of the link just because > some people > thought time-to-market was more important than doing it right. Well, we're both on the same side then since we want to make progress on docs enabling 3G host deployment. However how the 3gpp v6 link works is specified in 3gpp. Is that what you are arguing against? /Karim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 7 15:17:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27NHPKL010569 for ; Thu, 7 Mar 2002 15:17:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g27NHOK1010568 for ipng-dist; Thu, 7 Mar 2002 15:17:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27NHLKL010561 for ; Thu, 7 Mar 2002 15:17:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA26552 for ; Thu, 7 Mar 2002 15:17:22 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09192 for ; Thu, 7 Mar 2002 16:17:21 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g27NHKZc022997 for ; Fri, 8 Mar 2002 00:17:20 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Mar 08 00:17:19 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 00:17:19 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AAA2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Tony Hain'" , "Karim El-Malki (ERA)" , "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: RE: Cellular host draft - where we are and suggestions for moving forward. Date: Fri, 8 Mar 2002 00:06:45 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have been very consistent in that I want you to describe the > characteristics of the link. The device on the end could be either a > host or router, but the current focus on limited capability hosts is > preventing progress. The micro-handset *IS NOT SPECIAL*, so just get > over it. What you need is a standard way of using a link that has > different characteristics than other link technologies > already defined. => Tony, Your consistent claims that the draft is only considering size, weight ...etc is not accurate as I've explained in my earlier email (about moving forward). By this claim you're ignoring every 3GPP-specific section in the draft, which describes how to behave on those interfaces. So to re-iterate, the draft _already_ includes the information required for IPv6 over foo, but it also adds the minimal requirements. Splitting it into 10 documents is not what I'm concerned about. I want to make sure that each one of those 10 includes the right information. Simply assuming that starting over with a new document will solve technical problems is clearly not going to work, and we can't afford it (time wise). Hesham > > > > > In any case, I can't see that we have cut out any future > development > > based on having routers there even if we disable DAD (on the > > cellular link ONLY). Anyway this is not the important issue right > > now since the problem we are facing is widespread host deployment. > > You are talking about product design issues, not standards > development > issues. The standards issue is that we need to describe the > characteristics of a specific air-link technology so it can > be used in a > consistent manner with other link technologies across all > IPv6 capable > hosts AND routers. The longer people persist on trying to > solve day-job > problems by inisiting on solving the limited case first, > the longer it > will take to make any progress. > > I am not against making progress on a document that can be > used for 3G > host deployments. I just can't see any real need to special > case this > and limit the long term potential of the link just because > some people > thought time-to-market was more important than doing it right. > > Tony > > > > > > /Karim > > > > > > > -----Original Message----- > > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > > Sent: den 7 mars 2002 20:10 > > > To: Hesham Soliman (ERA); ipng@sunroof.eng.sun.com > > > Subject: RE: Cellular host draft - where we are and > suggestions for > > > moving forward. > > > > > > > > > Hesham, > > > > > > I appreciate where you are trying to go, but I think you are > > > still being > > > blinded to issues because the focus is to centric on *host*. > > > Yes people > > > are motivated to worry about that problem first, but > making design > > > assumptions based on the mobile device on the end of an > > > air-link being > > > limited to a host will cause problems. The current logic > > > appears to be > > > 'we don't want to do DAD, so define the link in terms of a > > > host so it is > > > unnecessary, then worry about a router later'. The > host perspective > > > should always be a subset of the demands of a link > technology, so > > > starting there will only assure that the link can never be > > > used outside > > > that scope. A group that is so focused on overhead of > bits on the > > > air-link should really be concerned about the impact of > > > forcing a router > > > to use IPv6 over IPv6 tunneling to get a reasonable > > service over it. > > > > > > As a specific comment to your note, rather than assume that > > > implementations will end up with an MTU of 1280, simply > > > state that the > > > interface MTU == 1280. In any case the infrastructure > > components will > > > have to respond appropriately to nodes that implement > > PMTU, so don't > > > assume that it won't happen just because it is not required > > > for devices > > > that are directly attached. > > > > > > Tony > > > > > > > > > > > > > -----Original Message----- > > > > From: owner-ipng@sunroof.eng.sun.com > > > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Hesham > > > > Soliman (ERA) > > > > Sent: Thursday, March 07, 2002 9:58 AM > > > > To: ipng@sunroof.eng.sun.com > > > > Subject: Cellular host draft - where we are and > > > suggestions for moving > > > > forward. > > > > > > > > > > > > Hi all, > > > > > > > > I think we're having a pretty useful discussion > > > > about this draft which has highlighted a number > > > > of issues that need to be addressed. This > > > > is an attempt to summarise the issues that were > > > > discussed and see if we can find a way forward. > > > > > > > > Please note, this is not to suggest 1, 2 or 3 > > > > drafts ...etc, this is an attempt to resolve the > > > > technical issues first, editing them in documents > > > > is another issue that can be handled after we > > > > agree on what we're going to put in such documents. > > > > > > > > Before I list the issues and responses, I'd like > > > > to highlight an important point: This draft attempts > > > > to do 2 things: > > > > > > > > - Define the behaviour of a cellular host residing > > > > on a cellular link (in this case we only know of > > > > 3GPP networks because no one else has defined > > > > the use of IPv6 in their specific link) > > > > > > > > - List the host implementation requirements in > > > > a cellular network (not only 3GPP) based on > > > > the common characteristics of these networks > > > > (p2p channels, BW, resilience over the air > > > > interface ...etc) > > > > > > > > Perhaps the two points above can be separated > > > > in 2 documents, but I'm really interested in > > > > getting an agreement on the technical issues > > > > _first_. Editorial issues are secondary here. > > > > > > > > So the main issues that were brought up so far are > > > > (please let me know if I missed a major issue): > > > > > > > > Issue: What is a cellular host ? > > > > > > > > Suggestion: A cellular host is _any_ host that > > > > has a cellular interface. This would include > > > > low end devices like basic phones and high > > > > end devices like laptops. Low end devices will > > > > generally follow the behavioural aspects of > > > > the draft as well as the minimum implementation > > > > requirements, due to the lack of computing capacity. > > > > However, high end devices will implement whatever > > > > they want, but MUST follow the required behaviour > > > > _on_the_cellular_ interface. > > > > Please note that when it comes to implementation > > > > requirements, the draft never suggests that > > > > a standard MUST NOT be implemented, so everyone > > > > is free to implement more. The draft aims at > > > > the minimum, interoperable implementation. > > > > > > > > Issue: The use of the word 'terminal' is > > > > confusing. > > > > > > > > Suggestion: replace 'terminal' with Host. > > > > This was a mistake anyway. > > > > > > > > Issue: Should DAD be disallowed > > > > > > > > Answer: DAD for the general cellualar > > > > case is allowed in the draft. > > > > In the 3GPP-sepcific case, DAD is not needed because: > > > > > > > > - The link is p2p > > > > > > > > - The link-local address is given to the > > > > cellular host (it can't reject it). > > > > > > > > - A /64 is given to the cellular host _only_ > > > > > > > > - The GGSN will ensure the uniqueness of llA > > > > and will not use the host's /64 to configure > > > > any of its global addresses. The same goes > > > > for site-local if used. > > > > > > > > So DAD is not needed. This is analogous to > > > > a design decision to always assume an MTU > > > > of 1280, PMTU implementation becomes superfluous > > > > if the host will _never_ send a packet larger > > > > than 1280. > > > > I think we should close this issue unless someone > > > > points out a flaw above. > > > > > > > > Issue: Should IPsec be mandated? > > > > > > > > Suggestion: We should mandate AH and ESP for > > > > all hosts, following RFC2460. > > > > > > > > Issue: Should ND be mandated? > > > > > > > > Answer: ND is mandated in the draft. > > > > Certain options are not mandated on cellualar > > > > links (like LLA suboption) because it's not > > > > relevant. NUD is a MAY because there are > > > > other ways of detecting reachability in > > > > these links. If multiple default routers exist > > > > RSs and RAs will detect the failure of one > > > > of those routers. > > > > > > > > Issue: Stateless address autoconfig (2462) > > > > allowed? > > > > > > > > Answer: Yes it's allowed for the general > > > > cellualr case. However for the 3GPP case > > > > stateless address allocation works differently > > > > from RFC2462 (and does not break 3041), so > > > > come parts of RFC2462 are not relevant > > > > (the DAD part again!) > > > > > > > > Comments so far? Are these suggestions/answers > > > > accepatable? > > > > > > > > It took me 2.5 hours to write this email because > > > > of my wonderful mail server, so I probably > > > > won't be able to give quick responses. > > > > > > > > Hesham > > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPng Working Group Mailing List > > > > IPng Home 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 Thu Mar 7 17:56:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g281uwKL010867 for ; Thu, 7 Mar 2002 17:56:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g281uvgB010866 for ipng-dist; Thu, 7 Mar 2002 17:56:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g281usKL010859 for ; Thu, 7 Mar 2002 17:56:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA29832 for ; Thu, 7 Mar 2002 17:56:54 -0800 (PST) Received: from inet-tsb.toshiba.co.jp (inet-tsb.toshiba.co.jp [202.33.96.40]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA14396 for ; Thu, 7 Mar 2002 18:56:53 -0700 (MST) Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id KAA11462; Fri, 8 Mar 2002 10:56:50 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp (8.11.5/3.7W) id g281uoI15083; Fri, 8 Mar 2002 10:56:50 +0900 (JST) Received: from tis2 [133.199.160.66] by tsb-wall.toshiba.co.jp with SMTP id LAA15081 ; Fri, 8 Mar 2002 10:56:50 +0900 Received: from mx4.toshiba.co.jp by tis2.tis.toshiba.co.jp (8.8.4+2.7Wbeta4/3.3W9-95082317) id KAA02800; Fri, 8 Mar 2002 10:56:50 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id KAA11256; Fri, 8 Mar 2002 10:56:49 +0900 (JST) Received: from localhost ([172.30.24.111]) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0GSM0051GTEK1R@tsbpo1.po.toshiba.co.jp>; Fri, 8 Mar 2002 10:56:48 +0900 (JST) Date: Thu, 07 Mar 2002 20:56:16 -0500 (EST) From: NAKAJIMA Nobuyasu Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? In-reply-to: <4.2.2.20020305103309.00e4c6c0@mail.windriver.com> To: mrw@windriver.com Cc: ipng@sunroof.eng.sun.com Message-id: <20020307.205616.01363269.nobuyasu.nakajima@toshiba.co.jp> MIME-version: 1.0 X-Mailer: Mew version 2.1 on Emacs 20.7 / Mule 4.1 (AOI) Content-type: Text/Plain; charset=us-ascii Content-transfer-encoding: 7bit References: <4.2.2.20020305103309.00e4c6c0@mail.windriver.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, > I also think that we should start work on two standards-track > documents, both of which would use the current draft as > input: > > - An "IPv6 over " document for 3GPP links. > - A general "IPv6 Node Requirements" document. I think some documents or at least descriptions of requirements for - exemption from performing DAD - exemption from the exchange of packets related to ND or NUD (- any others?) are also useful, for possible upcoming "IPv6 over " documents. I am personally interested in DAD issue in particular, and I would like general requirements for not performing DAD. Regards --- Nobuyasu Nakajima Toshiba America Research, 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 Mar 8 00:16:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g288G4KL011637 for ; Fri, 8 Mar 2002 00:16:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g288G4Y4011636 for ipng-dist; Fri, 8 Mar 2002 00:16:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g288FxKL011629 for ; Fri, 8 Mar 2002 00:16:00 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA02794 for ; Fri, 8 Mar 2002 00:15:59 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA27505 for ; Fri, 8 Mar 2002 01:15:57 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g288G6Z17603 for ; Fri, 8 Mar 2002 10:16:06 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 10:15:56 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 10:15:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Fri, 8 Mar 2002 10:15:55 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B76@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Thread-Index: AcHFy5AollGHEduFRCymM9HHkbhVpwArZNrw To: Cc: X-OriginalArrivalTime: 08 Mar 2002 08:15:56.0317 (UTC) FILETIME=[78CDA4D0:01C1C679] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g288G1KL011630 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Karim, > > > P.S. As a note the RNC, Node B, SGSN have nothing to do with > > > what we're > > > discussing and they're not involved in any of the IPv6 mechanisms > > > discussed so far. > > > > In point of fact, these three devices sit between the host > > (terminal) > > and the Internet, so they have to at least carry the data. I'm > > reasonably certain that at least one of them (probably the SGSN) > > will have to act as an IPv6 router for the purposes of connecting > > to the terminal. > > That's wrong. But anyway, these are 3gpp architecture discussions > which are best kept in 3gpp. It might be reasonable for us to check that our explanation in the draft is clear enough, so that everyone who reads the draft understands what we are suggesting. Essentially, I think we want to ensure that we advise that ND MUST be implemented, but to clearly state when ND is not needed to be used; what are the conditions that need to be met and what the 3G architecture does to meet those conditions. If we can explain this well, perhaps we'll will close this issue. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 8 00:44:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g288iJKL011786 for ; Fri, 8 Mar 2002 00:44:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g288iJaJ011785 for ipng-dist; Fri, 8 Mar 2002 00:44:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g288iFKL011778 for ; Fri, 8 Mar 2002 00:44:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA01105 for ; Fri, 8 Mar 2002 00:44:15 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07665 for ; Fri, 8 Mar 2002 01:44:13 -0700 (MST) Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g288ha327395 for ; Fri, 8 Mar 2002 10:43:37 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 10:44:12 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 10:44:12 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cel lular-host-00.txt -> wg last call?] Date: Fri, 8 Mar 2002 10:44:11 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B7E@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should IP Security be Optional? [Was RE: draft-ietf-ipv6-cel lular-host-00.txt -> wg last call?] Thread-Index: AcHGCakVnr+hXrOyRAqEw0jaKFEyQwAc4ipQ To: Cc: X-OriginalArrivalTime: 08 Mar 2002 08:44:12.0276 (UTC) FILETIME=[6BAC7340:01C1C67D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g288iGKL011779 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham & Robert, > But when you need IPsec, you > > need it - and that you happen to be using a cellular link for some > > particular communications is irrelevant. > > => Hmm. That's a pretty big statement. If someone > decides to use IPsec for VoIP (an extreme example > I know) then is it still irrelevant whether > you are on a cellualr link or not? > I think it will, very quickly, become relevant > when you get your phone bill! > > So the point is, and Jari has already highlighted > that, you have to be careful what kind of security > you use for what functions In summary, are we all saying: IPsec is manditory to implement & optional to use? I don't know if that is anything new. I do think we have tried to capture in our document some pros & cons with regards to security usage. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 8 01:06:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2896bKL011963 for ; Fri, 8 Mar 2002 01:06:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2896bpe011962 for ipng-dist; Fri, 8 Mar 2002 01:06:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2896XKL011955 for ; Fri, 8 Mar 2002 01:06:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA05441 for ; Fri, 8 Mar 2002 01:06:32 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA04212 for ; Fri, 8 Mar 2002 02:06:31 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2896eZ29568 for ; Fri, 8 Mar 2002 11:06:40 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 11:06:30 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 11:06:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Cellular host draft - where we are and suggestions for moving forward. Date: Fri, 8 Mar 2002 11:06:29 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64B84@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Cellular host draft - where we are and suggestions for moving forward. Thread-Index: AcHGLrfgcFr40bWHR3K8hdVoqd0E9gAUT8nw To: , , , X-OriginalArrivalTime: 08 Mar 2002 09:06:30.0310 (UTC) FILETIME=[89343C60:01C1C680] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2896XKL011956 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Hesham & Tony, > So to re-iterate, the draft _already_ includes > the information required for IPv6 over foo, > but it also adds the minimal requirements. > > Splitting it into 10 documents is not what I'm > concerned about. I want to make sure that > each one of those 10 includes the right information. Our draft by no means precludes a General IPv6 Host/Node Requirements draft, nor does it preclude a more general IP over Foo draft. Actually, the authors have been considering those 2 drafts as well. However, I do not see any conflict between these documents, and I see them as clearly distinct documents. In other words, even if we had an IP over Foo RFC and a Minimum Requirements for an IPv6 Host, there would still be need for an information document like the one we have been writing. The purpose of doing it here in the IPv6 WG is to ensure that the document is compliant to IPv6 and that we have considered the correct features, etc. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 8 08:54:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g28GsdKL013273 for ; Fri, 8 Mar 2002 08:54:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28Gsd0q013272 for ipng-dist; Fri, 8 Mar 2002 08:54:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g28GsZKL013265 for ; Fri, 8 Mar 2002 08:54:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18554 for ; Fri, 8 Mar 2002 08:54:36 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02309 for ; Fri, 8 Mar 2002 08:54:30 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g28GsTB11756 for ; Fri, 8 Mar 2002 17:54:29 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Fri Mar 08 17:54:28 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 8 Mar 2002 17:54:28 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AAAC@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'manet@ietf.org'" , ipng@sunroof.eng.sun.com, "'mobile-ip@sunroof.eng.sun.com'" Subject: MONET BOF Date: Fri, 8 Mar 2002 17:50:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, Sorry if you receive multiple copies of this. This is an announcement of the MONET BOF. All the necessary information can be found at: http://www.ietf.org/ietf/02mar/monet.txt. We look forward to your participation. Thierry Ernst Hesham Soliman -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 8 11:13:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g28JDKKL013731 for ; Fri, 8 Mar 2002 11:13:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28JDKO1013730 for ipng-dist; Fri, 8 Mar 2002 11:13:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g28JDHKL013723 for ; Fri, 8 Mar 2002 11:13:17 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03436 for ; Fri, 8 Mar 2002 11:13:16 -0800 (PST) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28202 for ; Fri, 8 Mar 2002 12:13:13 -0700 (MST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g28JAH303376; Fri, 8 Mar 2002 14:10:27 -0500 Message-Id: <200203081910.g28JAH303376@cichlid.adsl.duke.edu> To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: DAD and unique ID on link? In-Reply-To: Message from Markku Savela of "Wed, 06 Mar 2002 12:12:06 +0200." <200203061012.MAA21120@burp.tkv.asdf.org> Date: Fri, 08 Mar 2002 14:10:17 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Note: folks may want to reread the thread from last year on this topic before commenting. I've appended it below for convenience. Markku Savela writes: > Last year, in Seattle, I asked that RFC-2462 should be changed so that > at any specific point of time, the id-part of address should be unique > for each host on the link. This is one solution to the problem. But first, is there an understanding and agreement on what the problem is that needs fixing? (more below). > That is, it should not be legal for two hosts on same link to use same > ID part of the IPv6-address, regardless of the prefix. Why? Note that this is a solution to the problem, but may be more restrictive a solution than is necessary to address the actual problem at hand. > The main reason for this request is that, if id alone is not required > to be unique on link, then *EVERY HOST* on the link must do DAD on > every assigned id on every new prefix it sees from RA. On a link with > many nodes, this causes a flood of DAD's after RA! [a host may have > multilple ID's due to privacy drafts, and due other reasons]. Actually, I made a proposal in which one would not need to run DAD on addresses other than link-local if the ids were globally unique (e.g., generated from the EUI-64 identifier). One would still need to run DAD on other addresses (e.g., temprorary addresses). It seems to me that your proposal would result in the running of DAD in exactly the same situations. I.e, it would not eliminate the need to run DAD on all temporary addresses, for example. Right? > Apparently my request has been totally forgotten. It's really a minor > issue, and should just be clarified. Not totally forgotten, but no concrete action either. :-( Thomas From: itojun@iijlab.net To: ipng@sunroof.eng.sun.com Date: Sat, 02 Jun 2001 01:13:25 +0900 Subject: DAD at the interim meeting, there was a discussion on DAD (whether it is mandatory for all address, or we can do it just for link-local and omit for globals that share the same interface id). the original text is in the second bullet. i believe it is a bit confusing at best. the first sentence recommends (SHOULD) running DAD on every address you have, and then the following sentences say that you MAY omit it in certain conditions. my suggestion is to keep the first sentence and remove the exception sentences. it still leaves me a bit fuzzy feeling as DAD works only if everyone does it - so MUST sounds necessary to me for DAD to be useful. DAD does not always work anyways, due to network partition or ethernet chip initialization delays. so i'm okay with SHOULD on the first line. in was mentioned that TAHI test files "FAILED" if people omits DAD. first of all I would like to comment that we cannot take test result in binary form - when we see "FAILED", we need to diagnose result carefully. it may be an implementation choice, it may be TAHI's interpretation, whatever. when TAHI guys run their test on KAME stack, they give detailed interpretation on why they marked some test "FAIL" (if they have enough time). i guess the result "FAILED" for the DAD test is based on the following interpretation on "SHOULD" the first sentence. RFC2119 >3. SHOULD This word, or the adjective "RECOMMENDED", mean that there > may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course. itojun 5.4. Duplicate Address Detection Duplicate Address Detection is performed on unicast addresses prior to assigning them to an interface whose DupAddrDetectTransmits variable is greater than zero. Duplicate Address Detection MUST take place on all unicast addresses, regardless of whether they are obtained through stateful, stateless or manual configuration, with the exception of the following cases: - Duplicate Address Detection MUST NOT be performed on anycast addresses. - Each individual unicast address SHOULD be tested for uniqueness. However, when stateless address autoconfiguration is used, address uniqueness is determined solely by the interface identifier, assuming that subnet prefixes are assigned correctly (i.e., if all of an interface's addresses are generated from the same identifier, either all addresses or none of them will be duplicates). Thus, for a set of addresses formed from the same interface identifier, it is sufficient to check that the link- local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier. (snip) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From: Thomas Narten To: itojun@iijlab.net cc: ipng@sunroof.eng.sun.com Date: Fri, 01 Jun 2001 14:46:39 -0400 Subject: Re: DAD Here is a suggestion for how to plug the main vulnerabilities that were discussed in the meeting. Problem (as I understand it): the main issue is that there are some (non-link local scope) addresses that may be assigned to an interface (e.g., manually configured, temporary addresses, DHCP assigned, etc.), but for which there is no corresponding link-local address using the same interface identifier. The stateless addrconf document (RFC 2462) says that a node can skip DAD for global (and site local) scope addresses generated from the same interface ID as the link-local address. This opens up a potential hole where a node (doing normal addrconf) has run DAD on the link-local address, but has not yet configured a global-scope address using the same interface identifier. Then, some other node (e.g., via DHCP, a temporary address etc.) chooses the same interface identifier and creates such an address, runs DAD successfully (since no other node is currently using that address), and then assigns the address to its interface. Later, the first node (which is running normal addrconf) also generates the address, but skips DAD, and now there are two nodes using the same address. Oops. Proposal: update specs to require that nodes MUST run DAD on all addresses for which the interface identifier is NOT globally unique (per the setting of the 'u' bit in interface identifier). DAD can be skipped on addresses that contain IEEE EUI-64-derived interface identifiers (and for which DAD has already been run on the corresponding link-local address). This means: still no need to run DAD on global addresses when doing normal addrconf, provided the interface identifier comes from an IEEE identifier. But one would have to run DAD for links with randomly generated identifiers (e.g., some PPP links). One would also still need to run DAD for temporary addresses. For DHCP addresses, we'd need to make sure that the server sets the 'u' bit properly, and clients would need to run DAD if the 'u' bit indicated locally unique only. Does this solve the underlying problem in an acceptable fashion? Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From: Markku Savela To: narten@raleigh.ibm.com CC: itojun@iijlab.net, ipng@sunroof.eng.sun.com Date: Sat, 2 Jun 2001 04:44:38 +0300 Subject: Re: DAD > Proposal: update specs to require that nodes MUST run DAD on all > addresses for which the interface identifier is NOT globally unique > (per the setting of the 'u' bit in interface identifier). DAD can be > skipped on addresses that contain IEEE EUI-64-derived interface > identifiers (and for which DAD has already been run on the > corresponding link-local address). I would prefer the IPv6 address architecture leaves it open for future address formats which do not use IEEE EUI-64 ID-format, and still have all the machinery of Neighbor Discovery and ADDRCONF available. Designs which force the stack to dig into insides of any id part are very unappealing to me. Address is n-bit prefix 128-n bit id, and as far as my current implementation goes, the link layer may specify *any* n (0..128) to be used [to prevent obvious replies, I do admit that the kinky values of n=0 or n=128 may not quite work]. ..although, one might consider a point-to-point link without link layer addresses as "n=128". -- Markku Savela From: "Sellers, Julian P" To: "'Thomas Narten'" Cc: "'itojun@iijlab.net'" , "'ipng@sunroof.eng.sun.com'" Date: Tue, 5 Jun 2001 16:04:13 -0500 Subject: RE: DAD Thomas, Is there a problem with requiring nodes to perform DAD on the link-local address generated from a given interface identifier, even if they only want to use the site-local or the global address? That's what I thought the following sentences from 5.4 of RFC 2462 required: Thus, for a set of addresses formed from the same interface identifier, it is sufficient to check that the link- local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier. It's not clear to me what the qualifier "In such cases" refers to. Maybe this paragraph just needs to state clearly that - If a node has successfully performed DAD on a link-local address, the node has the right to all addresses on the same link that contain the same interface identifier. - If a node has not performed DAD on the link-local address, or if the link-local address has failed DAD, the node must not use any address on that link generated with the same interface identifier. Julian > -----Original Message----- > From: Thomas Narten [mailto:narten@raleigh.ibm.com] > Sent: Friday, June 01, 2001 1:47 PM > To: itojun@iijlab.net > Cc: ipng@sunroof.eng.sun.com > Subject: Re: DAD > > > Here is a suggestion for how to plug the main vulnerabilities that > were discussed in the meeting. > > Problem (as I understand it): the main issue is that there are some > (non-link local scope) addresses that may be assigned to an interface > (e.g., manually configured, temporary addresses, DHCP assigned, etc.), > but for which there is no corresponding link-local address using the > same interface identifier. The stateless addrconf document (RFC 2462) > says that a node can skip DAD for global (and site local) scope > addresses generated from the same interface ID as the link-local > address. This opens up a potential hole where a node (doing normal > addrconf) has run DAD on the link-local address, but has not yet > configured a global-scope address using the same interface > identifier. Then, some other node (e.g., via DHCP, a temporary address > etc.) chooses the same interface identifier and creates such an > address, runs DAD successfully (since no other node is currently using > that address), and then assigns the address to its interface. Later, > the first node (which is running normal addrconf) also generates the > address, but skips DAD, and now there are two nodes using the same > address. Oops. > > Proposal: update specs to require that nodes MUST run DAD on all > addresses for which the interface identifier is NOT globally unique > (per the setting of the 'u' bit in interface identifier). DAD can be > skipped on addresses that contain IEEE EUI-64-derived interface > identifiers (and for which DAD has already been run on the > corresponding link-local address). > > This means: still no need to run DAD on global addresses when doing > normal addrconf, provided the interface identifier comes from an IEEE > identifier. But one would have to run DAD for links with randomly > generated identifiers (e.g., some PPP links). One would also still > need to run DAD for temporary addresses. For DHCP addresses, we'd need > to make sure that the server sets the 'u' bit properly, and clients > would need to run DAD if the 'u' bit indicated locally unique only. > > Does this solve the underlying problem in an acceptable fashion? > > Thomas > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > From: "Brian Zill" To: "Sellers, Julian P" Cc: Date: Tue, 5 Jun 2001 16:51:53 -0700 Subject: RE: DAD Thread-Topic: DAD thread-index: AcDuBCKGkPjmAWCZROiV02r53J3DrQAFXQlA Julian, When this idea was suggested at the Interim Meeting, several people expressed concern about needing to have a link-local address for every interface identifier you might be using. A node may want to have a large number of global addresses, for example, and the overhead of requiring that it keep a corresponding link-local address for each might be prohibitive. I think I'd prefer to just perfom DAD on all the global addresses instead. It's the same amount of DADing going on, and you don't need to keep all those link-local addresses around. --Brian > -----Original Message----- > From: Sellers, Julian P [mailto:Julian.Sellers@UNISYS.com] > Sent: Tuesday, 05 June, 2001 14:04 > To: 'Thomas Narten' > Cc: 'itojun@iijlab.net'; 'ipng@sunroof.eng.sun.com' > Subject: RE: DAD > > > Thomas, > > Is there a problem with requiring nodes to perform DAD on the > link-local address generated from a given interface > identifier, even if they only want to use the site-local or > the global address? That's what I thought the following > sentences from 5.4 of RFC 2462 required: > > Thus, for a set of addresses formed from the same > interface identifier, it is sufficient to check that the link- > local address generated from the identifier is unique on the > link. In such cases, the link-local address MUST be tested for > uniqueness, and if no duplicate address is detected, an > implementation MAY choose to skip Duplicate Address Detection > for additional addresses derived from the same interface > identifier. > > It's not clear to me what the qualifier "In such cases" > refers to. Maybe this paragraph just needs to state clearly that > > - If a node has successfully performed DAD on a > link-local address, the node has the > right to all addresses on the same link that contain > the same interface identifier. > - If a node has not performed DAD on the link-local > address, or if the link-local > address has failed DAD, the node must not use any > address on that link generated with > the same interface identifier. > > Julian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From: Markku Savela To: bzill@microsoft.com CC: Julian.Sellers@UNISYS.com, ipng@sunroof.eng.sun.com Date: Wed, 6 Jun 2001 09:14:55 +0300 Subject: Re: DAD > From: "Brian Zill" > When this idea was suggested at the Interim Meeting, several people > expressed concern about needing to have a link-local address for every > interface identifier you might be using. A node may want to have a > large number of global addresses, for example, and the overhead of > requiring that it keep a corresponding link-local address for each might > be prohibitive. I think I'd prefer to just perfom DAD on all the global > addresses instead. It's the same amount of DADing going on, and you > don't need to keep all those link-local addresses around. My proposal, doing the DAD related comparison only with the ID part, solves the same problem, but lets you do single DAD / Id, regardless of the number of prefixes you combine with this id. And, you don't need to generate link-local address, if you are not using it. There was some concern about the backwards compatibility, but I *still* cannot see this introducing any more problems than what already exists legally by the current specification, where you can have hosts reserving ID for all combinations by DAD on link local, and hosts that don't do that. And, if you change specification, might as well change it to what I proposed :-). -- Markku Savela -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Fri Mar 8 11:53:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g28Jr9KL013827 for ; Fri, 8 Mar 2002 11:53:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28Jr9e3013826 for ipng-dist; Fri, 8 Mar 2002 11:53:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g28Jr5KL013819 for ; Fri, 8 Mar 2002 11:53:05 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA16341 for ; Fri, 8 Mar 2002 11:53:05 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA15464 for ; Fri, 8 Mar 2002 12:53:04 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29670; Fri, 8 Mar 2002 14:53:01 -0500 (EST) Message-Id: <200203081953.OAA29670@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-default-addr-select-07.txt Date: Fri, 08 Mar 2002 14:53:01 -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 IP Version 6 Working Group Working Group of the IETF. Title : Default Address Selection for IPv6 Author(s) : R. Draves Filename : draft-ietf-ipv6-default-addr-select-07.txt Pages : 22 Date : 08-Mar-02 This document describes two algorithms, for source address selection and for destination address selection. The algorithms specify default behavior for all IPv6 implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common framework, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual stack implementations, the framework allows the destination address selection algorithm to consider both IPv4 and IPv6 addresses - depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice-versa. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-default-addr-select-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipv6-default-addr-select-07.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-ipv6-default-addr-select-07.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: <20020308093953.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-default-addr-select-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-default-addr-select-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020308093953.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 Fri Mar 8 11:54:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g28JsBKL013844 for ; Fri, 8 Mar 2002 11:54:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g28JsBJr013843 for ipng-dist; Fri, 8 Mar 2002 11:54:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g28Js6KL013836 for ; Fri, 8 Mar 2002 11:54:06 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13667 for ; Fri, 8 Mar 2002 11:54:06 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10954 for ; Fri, 8 Mar 2002 11:54:01 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29683; Fri, 8 Mar 2002 14:53:06 -0500 (EST) Message-Id: <200203081953.OAA29683@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipng@sunroof.eng.sun.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipv6-dns-discovery-04.txt Date: Fri, 08 Mar 2002 14:53:06 -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 IP Version 6 Working Group Working Group of the IETF. Title : IPv6 Stateless DNS Discovery Author(s) : D. Thaler, J. Hagino Filename : draft-ietf-ipv6-dns-discovery-04.txt Pages : 12 Date : 08-Mar-02 This document specifies the steps a host takes in deciding how to autoconfigure the addresses of DNS Servers required for name resolution in IP version 6. The autoconfiguration process includes determining whether such information should be obtained through the stateless mechanism, the stateful mechanism, or both. This document defines the process for acquiring a list of DNS server addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipv6-dns-discovery-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-ipv6-dns-discovery-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-ipv6-dns-discovery-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: <20020308094014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipv6-dns-discovery-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipv6-dns-discovery-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020308094014.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 Fri Mar 8 16:36:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g290a1KL014099 for ; Fri, 8 Mar 2002 16:36:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g290a1LU014098 for ipng-dist; Fri, 8 Mar 2002 16:36:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g290ZvKL014086 for ; Fri, 8 Mar 2002 16:35:58 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16272 for ; Fri, 8 Mar 2002 16:35:58 -0800 (PST) Received: from fridge.docomo-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA18624 for ; Fri, 8 Mar 2002 17:35:57 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id g290Zue00227 for ; Fri, 8 Mar 2002 16:35:56 -0800 (PST) Message-ID: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> From: "James Kempf" To: Subject: Securing Neighbor Discovery Date: Fri, 8 Mar 2002 16:34:18 -0800 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've submitted a draft on securing neighbor discovery, draft-kempf-secure-nd-00.txt. Since I forgot to put an IPNG in it, the drafts editor didn't send a notice to this list, but it was supposed to be for consideration by the IPNG group. Please send comments. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 8 17:59:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g291xkKL014372 for ; Fri, 8 Mar 2002 17:59:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g291xkBY014371 for ipng-dist; Fri, 8 Mar 2002 17:59:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g291xiKL014364 for ; Fri, 8 Mar 2002 17:59:44 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g291wuuX017001 for ; Fri, 8 Mar 2002 17:58:56 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g291wu7I017000 for ipng@sunroof.eng.sun.com; Fri, 8 Mar 2002 17:58:56 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g270BVKL006536 for ; Wed, 6 Mar 2002 16:11:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26851 for ; Wed, 6 Mar 2002 16:11:31 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA22855 for ; Wed, 6 Mar 2002 17:11:31 -0700 (MST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id RAA21088 for ; Wed, 6 Mar 2002 17:11:30 -0700 (MST)] Received: [from brc9exm01.ipsg.mot.com (brc9exm01.ipsg.mot.com [138.242.16.16]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA19988 for ; Wed, 6 Mar 2002 16:59:45 -0700 (MST)] Received: by brc9exm01.ipsg.mot.com with Internet Mail Service (5.5.2654.52) id <1KCH21AH>; Wed, 6 Mar 2002 16:11:28 -0800 Message-ID: From: Delecki Andrew-Y10658 To: "'Hesham Soliman (ERA)'" , "'Charles E. Perkins'" , "Karim El-Malki (ERA)" Cc: ipng@sunroof.eng.sun.com Subject: RE: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 16:11:26 -0800 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Hesham, This what is in current 3GPP specifications, is not necessarily the "right thing". Recommendation shall include the right network topology and IPv6 mechanism, not deal with system, which is only "half" right. Andrew D. Motorola -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 06, 2002 3:24 PM To: 'Charles E. Perkins'; Karim El-Malki (ERA) Cc: ipng@sunroof.eng.sun.com Subject: RE: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Hi Charlie I finally read the thread. > > I agree that it would be good to see some guidelines in an > > informational doc. However I disagree on the title change to > > IPv6 over cellular/3g. That is a different spec which we should > > also work on. > > It is possible to design "cellular" systems where the > 3GPP/PDP address assignment is completely replaced by > localized, stateless methods. The way that addresses > are assigned is not related to bandwidth, nor even to > essential authorization issues. It's an artifact of > near-compatibility with existing 2.5G layouts. GGSN > does not NECESSARILY need to control this process. > => That's fine, but we have to deal with what *is* right now and not what *may come*. There are people that want to roll out systems with IPv6 support today, R&D will no doubt improve things, but in this draft we need to deal with the current specs. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Fri Mar 8 18:00:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2920CKL014382 for ; Fri, 8 Mar 2002 18:00:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2920CcN014381 for ipng-dist; Fri, 8 Mar 2002 18:00:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2920AKL014374 for ; Fri, 8 Mar 2002 18:00:10 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g291xMuX017009 for ; Fri, 8 Mar 2002 17:59:22 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g291xMON017008 for ipng@sunroof.eng.sun.com; Fri, 8 Mar 2002 17:59:22 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g270HUKL006547 for ; Wed, 6 Mar 2002 16:17:30 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28278 for ; Wed, 6 Mar 2002 16:17:30 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA04569 for ; Wed, 6 Mar 2002 17:17:29 -0700 (MST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id RAA09744 for ; Wed, 6 Mar 2002 17:17:29 -0700 (MST)] Received: [from brc9exm01.ipsg.mot.com (brc9exm01.ipsg.mot.com [138.242.16.16]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id RAA05736 for ; Wed, 6 Mar 2002 17:17:28 -0700 (MST)] Received: by brc9exm01.ipsg.mot.com with Internet Mail Service (5.5.2654.52) id <1KCH21AZ>; Wed, 6 Mar 2002 16:17:28 -0800 Message-ID: From: Delecki Andrew-Y10658 To: "'Hesham Soliman (ERA)'" , "'FIELD,GEOFF (A-Australia,ex1)'" , "Karim El-Malki (ERA)" , "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 16:17:25 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 06, 2002 3:34 PM To: 'FIELD,GEOFF (A-Australia,ex1)'; Karim El-Malki (ERA); 'Margaret Wasserman'; john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Geoff > > P.S. As a note the RNC, Node B, SGSN have nothing to do with > > what we're > > discussing and they're not involved in any of the IPv6 mechanisms > > discussed so far. > > In point of fact, these three devices sit between the host > (terminal) > and the Internet, so they have to at least carry the data. I'm > reasonably certain that at least one of them (probably the SGSN) > will have to act as an IPv6 router for the purposes of connecting > to the terminal. => No. The GGSN is the default router. Nothing else >is seen by the end host. So in this discussion >we should be concerned with the Host (UE in 3GPP specs) >and the default router (GGSN) for all link-local >issues. Not true. The host sees GGSN only through PDP context pipe if PDP context is set to IPv6/v4 type. Through control plane it is talking only to SGSN, which handles entire call control and mobility management (distinct from mobile IP). Andrew -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Fri Mar 8 18:00:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2920YKL014392 for ; Fri, 8 Mar 2002 18:00:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2920Y5B014391 for ipng-dist; Fri, 8 Mar 2002 18:00:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2920WKL014384 for ; Fri, 8 Mar 2002 18:00:32 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g291xiuX017017 for ; Fri, 8 Mar 2002 17:59:44 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g291xiZO017016 for ipng@sunroof.eng.sun.com; Fri, 8 Mar 2002 17:59:44 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g270knKL006591 for ; Wed, 6 Mar 2002 16:46:49 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA09284 for ; Wed, 6 Mar 2002 16:46:49 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA22035 for ; Wed, 6 Mar 2002 17:46:45 -0700 (MST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id RAA22171 for ; Wed, 6 Mar 2002 17:35:45 -0700 (MST)] Received: [from brc9exm01.ipsg.mot.com (brc9exm01.ipsg.mot.com [138.242.16.16]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id RAA11472 for ; Wed, 6 Mar 2002 17:34:55 -0700 (MST)] Received: by brc9exm01.ipsg.mot.com with Internet Mail Service (5.5.2654.52) id <1KCH21DP>; Wed, 6 Mar 2002 16:46:38 -0800 Message-ID: From: Delecki Andrew-Y10658 To: "'Hesham Soliman (ERA)'" , Delecki Andrew-Y10658 , "'Margaret Wasserman'" , john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Wed, 6 Mar 2002 16:46:33 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The main problem with using the Router Advertisement is that the cellular host shall have its knowledge before the PDP context is established. In this case, the host would know whether it is allowed to perform stateless address autoconfiguration or not from value Stateful Configuration flag. This information is needed by host before the PDP Context is established, i.e. before any IPv6 message can be sent. Andrew D. Motorola -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Wednesday, March 06, 2002 3:31 PM To: 'Delecki Andrew-Y10658'; 'Margaret Wasserman'; john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] > 3GPP implementation of stateless address autoconfiguration > is a superposition of "true" stateless and stateful address > autoconfigurations. > > The reason for this is that the "wireless equivalent link > layer", which is "the PDP context pipe" extending from GGSN > to the cellular host, has to be first established in order > to convey any IPv6 messages. > This severely limits the use of many IPv6 protocol > features, e.g. neighbor discovery, router advertisement etc. => It doesn't limit anything to do with RAs. It only eliminates the need for ethernet-type information like the link layer suboption. DAD is not needed, but people _can_ certainly send DAD messages if they really want to. NUD is also possible. GGSNs should support NUD as was mentioned earlier. > In my view, the document in question > (draft-ietf-ipv6-cellular-host-00. txt) omits this fact > concentrating on the scenario in which "the PDP context" is > established. => Which part of the document does that? > For this reason, the this document will have limited impact > on the 3GPP and it does not fully explore many IPv6 > protocol features. > => I'm not sure what mean. The document is not intended to affect 3GPP specs. The document does not eliminate any IPv6 features. For the generic cellular host, almost all features are included, but there are exceptions for 3GPP hosts due to the _3GPP_system_ which makes some functions (like DAD) unnecessary. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 8 18:00:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2920rKL014409 for ; Fri, 8 Mar 2002 18:00:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2920q9Q014408 for ipng-dist; Fri, 8 Mar 2002 18:00:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2920oKL014401 for ; Fri, 8 Mar 2002 18:00:50 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g29202uX017025 for ; Fri, 8 Mar 2002 18:00:02 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g292029a017024 for ipng@sunroof.eng.sun.com; Fri, 8 Mar 2002 18:00:02 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g272xsKL006730 for ; Wed, 6 Mar 2002 18:59:54 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA03133 for ; Wed, 6 Mar 2002 18:59:54 -0800 (PST) Received: from ccpl.carr.org (ccpl.carr.org [204.255.213.26]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22292 for ; Wed, 6 Mar 2002 19:59:53 -0700 (MST) Received: from pavilion (use218-47.carr.org [63.64.218.47]) by ccpl.carr.org (Switch-2.0.1/Switch-2.0.1) with ESMTP id g272xou20111; Wed, 6 Mar 2002 21:59:51 -0500 (EST) Message-ID: <001801c1c584$d044a880$2fda403f@pavilion> Reply-To: "JJTJ" From: "JJTJ" To: Subject: Re: Should IP Security be Optional? Date: Wed, 6 Mar 2002 22:04:34 -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 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I think this has taken on a larger context than just cellular. (Which is I guess why the Subject line has changed). Don't forget that IPv4 is that it was designed in the early 70's, and people were surrounded by IBM 360s and DEC PDP-11s, and a whole bunch of other machines that no longer exist. But, one of its strengths, although designed in that environment, is that it allowed for growth through the Web phase of the Internet. Radiotelephones were the closest you got to mobile telephones at that time, and today's wireless Email clients are starting to look like something out of a Dick Tracy comic. Beyond a short trip down memory lane (or to the Smithsonian, depending on your age), I guess what I am suggesting is that we would be limiting the applicability of IPv6 if we just thought in terms of cellular media and wireless browsers. In 1974, when the "@" sign started to be used for "the new electronic mail application", how many people were thinking "BlackBerry"? It has been said that no one intends on being around when IPv8 or IPv12 (or what have you) has to be designed. In that case, what needs to happen is a larger, more generic framework needs to be designed that new technologies can be merged into. Also, that means that IP security should not be optional. Whether September 11th took place, or not, the world has been and is full of all kinds of people - most nice, but some not nice. For commerce, communications and information transfer of all sorts to take place, we need to think in these terms. Cordless phones have scrambling features, and police scanners that were the rage 20 years ago are mostly obsolete because the authorities realized that everyone - including criminals - could listen in on their operations. The Internet is nearing maturity, and should have these features built-in now, before it is totally ubiquitous, and we have to continue to bolt-on security just like we've done with IPv4, and every so-called modern operating system. My $.02 -----Original Message----- From: Jonne.Soininen@nokia.com [mailto:Jonne.Soininen@nokia.com] Sent: Monday, March 04, 2002 8:40 PM To: moore@cs.utk.edu Cc: ipng@sunroof.eng.sun.com Subject: Re: Should IP Security be Optional?[Was RE:draft-ietf-ipv6-cellu lar-host-00.txt -> wg last call?] > > > This seems to presume that you can predict in advance all of the > > > applications that a user will wish to execute on a particular node. Can you > > > do that? > > > > On a workstation you can't. On a tiny cellular device you > > often can. > only if the device doesn't have a data port. Actually then (especially in 3GPP devices) the IP stack will actually also be behind that dataport, i.e. in the laptop. That is then a different story. -Jonne. -------- Jonne Soininen Nokia Tel. +1 650 864 6794 Cellular: +1 650 714 7733 Email: jonne.soininen@nokia.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 Fri Mar 8 18:01:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2921HKL014426 for ; Fri, 8 Mar 2002 18:01:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2921H9c014425 for ipng-dist; Fri, 8 Mar 2002 18:01:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2921EKL014418 for ; Fri, 8 Mar 2002 18:01:15 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2920RuX017033 for ; Fri, 8 Mar 2002 18:00:27 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g2920QKZ017032 for ipng@sunroof.eng.sun.com; Fri, 8 Mar 2002 18:00:26 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g27JSgKL010228 for ; Thu, 7 Mar 2002 11:28:42 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA02387 for ; Thu, 7 Mar 2002 11:28:43 -0800 (PST) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA29333 for ; Thu, 7 Mar 2002 11:28:41 -0800 (PST) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 8782E1C7D for ; Thu, 7 Mar 2002 14:28:40 -0500 (EST) Date: Thu, 07 Mar 2002 14:28:40 -0500 From: Rob Austein To: ipng@sunroof.eng.sun.com Reply-To: ipng@sunroof.eng.sun.com Subject: Re: PPP and Global Addresses In-Reply-To: <4.3.2.7.2.20020307122231.00b74d78@funnel.cisco.com> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) References: <4.3.2.7.2.20020307122231.00b74d78@funnel.cisco.com> MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020307192840.8782E1C7D@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Replies intentionally redirected to mailing list by author -- I get way too much mail and really don't need duplicate copies from a list that generates as much traffic as this one. Thanks.] At Thu, 07 Mar 2002 12:26:09 -0500, Ralph Droms wrote: > > I do disagree with the DT conclusion - as do other WG member > who spoke up in SLC - but I'll let the rest of the > WG members make up their own minds about the various protocol > proposals. I agree with Ralph and disagree with the design team conclusion, for several reasons: 1) The portions of DHCP that are required for post-addr-conf (sorry, don't have a better name for this) are pretty minimal, and I'm pretty sure that one can write conforming DHCP clients and servers that only implement that part of the DHCP spec (more precisely, the only thing that such implementations would have to do with the complex part of the spec would be to ignore the messages without crashing). Ralph, please correct me if I'm wrong about this. 2) While I applaud the ingenuity and enthusiasm of all the people who have come up with interesting ways to configure things in the IPv6 universe without using DHCP, I have yet to see any proposals as simple as just using boring old DHCP for most of this stuff. We have a pretty good understanding of how DHCP works and what's required to support it (for some definition of "we" that may or may not include the members of this WG, a subject on which I decline to have a public opinion). Some of the proposals to replace DHCP, on the other hand, are pretty far out on either the research or kludge axes. While I am not in principle opposed to cool new stuff, I don't think it's sound engineering to do new stuff just for the sake of being different. 3) As I stated in my rant at the IESG plenary in Salt Lake, I think that the IPv6 WG has real work to do, and redesigning the entire Internet from the ground up isn't it. DHCP will do this job well enough, 'nuff said, can we please move on now? Since Ralph is much politer about this than I usually manage to be, I will now slink back under my rock. --Rob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 8 18:09:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g29294KL014627 for ; Fri, 8 Mar 2002 18:09:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g29293rL014626 for ipng-dist; Fri, 8 Mar 2002 18:09:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g29290KL014619 for ; Fri, 8 Mar 2002 18:09:00 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA21461 for ; Fri, 8 Mar 2002 18:09:00 -0800 (PST) From: Jonne.Soininen@nokia.com Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13972 for ; Fri, 8 Mar 2002 19:08:59 -0700 (MST) Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2929FG04640 for ; Fri, 8 Mar 2002 20:09:15 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 20:08:58 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 20:07:51 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Fri, 8 Mar 2002 18:07:50 -0800 Message-ID: <4D7B558499107545BB45044C63822DDEB2D931@mvebe001.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Making ND Optional [Was RE: draft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Thread-Index: AcHHDpGknJL9N7mJSGWKyz8YKWzqBAAACt3w To: , , , , , Cc: X-OriginalArrivalTime: 09 Mar 2002 02:07:51.0779 (UTC) FILETIME=[37CE5330:01C1C70F] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g29291KL014620 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Andrew, > => No. The GGSN is the default router. Nothing else > >is seen by the end host. So in this discussion > >we should be concerned with the Host (UE in 3GPP specs) > >and the default router (GGSN) for all link-local > >issues. > > Not true. > > The host sees GGSN only through PDP context pipe if PDP > context is set to IPv6/v4 type. > > Through control plane it is talking only to SGSN, which > handles entire call control and mobility management (distinct > from mobile IP). > I am sorry to say, but Hesham is totally right. GGSN is the default router. Everything else (Radio signaling, SM, and MM signaling) is 3GPP system dependent, and seen as part of layer 2 for IP. The IP host (Thus, layer 3 and up) does not see any other node from the 3GPP system. Thus, GGSN _is_ the default router... Cheers, Jonne. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 8 18:41:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g292fkKL014686 for ; Fri, 8 Mar 2002 18:41:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g292fj6F014685 for ipng-dist; Fri, 8 Mar 2002 18:41:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g292fgKL014678 for ; Fri, 8 Mar 2002 18:41:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA18235 for ; Fri, 8 Mar 2002 18:41:37 -0800 (PST) From: Jonne.Soininen@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA13854 for ; Fri, 8 Mar 2002 19:41:37 -0700 (MST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g292hlx12916 for ; Fri, 8 Mar 2002 20:43:47 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 8 Mar 2002 20:41:35 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 8 Mar 2002 20:29:43 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Date: Fri, 8 Mar 2002 18:29:42 -0800 Message-ID: <4D7B558499107545BB45044C63822DDE0A0781@mvebe001.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] Thread-Index: AcHHDo/Tl4sSk9i1RV2y7mleBMQcvQAAhlFQ To: , , , Cc: X-OriginalArrivalTime: 09 Mar 2002 02:29:43.0084 (UTC) FILETIME=[456796C0:01C1C712] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g292fhKL014679 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Andrew again, > This what is in current 3GPP specifications, is not > necessarily the "right thing". I think that what is in the 3GPP specs is the problem of 3GPP. Not us. Anyways, I rather would like to think that what 3GPP has is rather good, and (most important of all) it supports IPV6. That's enough for me. Cheers, Jonne. > -----Original Message----- > From: ext Delecki Andrew-Y10658 [mailto:AndrewDelecki@motorola.com] > Sent: Wednesday, March 06, 2002 4:11 PM > To: 'Hesham Soliman (ERA)'; Perkins Charles (IPRG); Karim > El-Malki (ERA) > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Should DAD be optional? > [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] > Importance: High > > > Dear Hesham, > > This what is in current 3GPP specifications, is not > necessarily the "right thing". > > Recommendation shall include the right network topology and > IPv6 mechanism, not deal with system, which is only "half" right. > > Andrew D. > > Motorola > > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Wednesday, March 06, 2002 3:24 PM > To: 'Charles E. Perkins'; Karim El-Malki (ERA) > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Should DAD be optional? > [Wasdraft-ietf-ipv6-cellular-host-00. txt -> wg last call?] > > > Hi Charlie > > I finally read the thread. > > > > I agree that it would be good to see some guidelines in an > > > informational doc. However I disagree on the title change to > > > IPv6 over cellular/3g. That is a different spec which we should > > > also work on. > > > > It is possible to design "cellular" systems where the > > 3GPP/PDP address assignment is completely replaced by > > localized, stateless methods. The way that addresses > > are assigned is not related to bandwidth, nor even to > > essential authorization issues. It's an artifact of > > near-compatibility with existing 2.5G layouts. GGSN > > does not NECESSARILY need to control this process. > > > > => That's fine, but we have to deal with what *is* > right now and not what *may come*. > There are people that want to roll out systems with > IPv6 support today, R&D will no doubt improve > things, but in this draft we need to deal with > the current specs. > > > Hesham > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sat Mar 9 00:08:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2988uKL014896 for ; Sat, 9 Mar 2002 00:08:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2988tfW014895 for ipng-dist; Sat, 9 Mar 2002 00:08:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2988qKL014888 for ; Sat, 9 Mar 2002 00:08:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA24575 for ; Sat, 9 Mar 2002 00:08:52 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA22447 for ; Sat, 9 Mar 2002 01:08:51 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2988oZc018421 for ; Sat, 9 Mar 2002 09:08:50 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sat Mar 09 09:09:02 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Sat, 9 Mar 2002 09:07:23 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AABF@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'ipng@sunroof.eng.sun.com'" Subject: RE: PPP and Global Addresses Date: Sat, 9 Mar 2002 03:27:36 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > 1) The portions of DHCP that are required for post-addr-conf (sorry, > don't have a better name for this) are pretty minimal, and I'm > pretty sure that one can write conforming DHCP clients > and servers > that only implement that part of the DHCP spec (more > precisely, the > only thing that such implementations would have to do with the > complex part of the spec would be to ignore the messages without > crashing). Ralph, please correct me if I'm wrong about this. > => I don't have a great knowledge of DHCP but wouldn't this simply message still require a relay agent? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 9 03:10:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g29BALKL015037 for ; Sat, 9 Mar 2002 03:10:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g29BALqs015036 for ipng-dist; Sat, 9 Mar 2002 03:10:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g29BAIKL015029 for ; Sat, 9 Mar 2002 03:10:18 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA18850 for ; Sat, 9 Mar 2002 03:10:17 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05363 for ; Sat, 9 Mar 2002 04:10:15 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g29BFFS02263; Sat, 9 Mar 2002 18:15:17 +0700 (ICT) From: Robert Elz To: "Hesham Soliman (ERA)" cc: ipng@sunroof.eng.sun.com Subject: Re: Cellular host draft - where we are and suggestions for moving for ward. In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AA9E@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053802C6AA9E@Esealnt861.al.sw.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 09 Mar 2002 18:15:15 +0700 Message-ID: <2261.1015672515@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 7 Mar 2002 19:53:30 +0100 From: "Hesham Soliman (ERA)" Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AA9E@Esealnt861.al.sw.ericsson.se> | => It means something like this: | | A B | GGSN ------- Host------- whatever you want tp put | | GGSNs MUST NOT use the /64 to configure addresses | on their own interfaces. This is exactly why there needs to be an IPv6 over whatever draft (in the IETF domain). Must of the (DAD related) part of this discussion has all been noise, as it has all been missing the point. In particular: | But no DAD is needed on link A. | | Makes sense? No, this is what is causing the confusion. It isn't that DAD isn't needed on A, it is that (as you are proposing) doing it there would simply be wrong, as no address is to be configured there. One never does DAD on a link other than the one where the address is to be configured - and your proposal is to have the A link above be unnumbered, with the prefix assigned to the host to use on its other link(s) (perhaps purely on its internal loopback interface, perhaps B if it exists). It is important to get the model right - if you even allow yourself to think that what the host is configuring the prefix on the 3GPP link, then it makes no sense at all to restrict the GGSN from also configuring an address on the link - the /64 has plenty of address in it, and if it is configured as a /64 (not two /65's or similar) then it really applies only to one link (joining it would be via a bridge). So, what's needed is an I-D that sets out exactly how the 3GPP link is to be used, and justifies that. Note that justifying the "MUST NOT" I quoted above from your message might not be easy - telling operators how they're to be permitted to configure their links is something the IETF does quite rarely. In particular, unnumbered links are liked by some, and hated by others, so you're going to need to have some very strong reasons to require that mode of operation as the only acceptable mode. If you do manage that, then you don't need to say that DAD isn't required, as doing DAD in the circumstances above would simply be crazy - it isn't a case of some kind of exception to the general DAD rule, it is a case where doing it would be completely contrary to the rest of the architecture. So this doesn't even get to reaching the case that has been discussed of some link types where it might be possible to assign addresses without DAD. On the other hand, there are still link local addresses to be assigned on link A, and there there's no possible justification for the GGSN not to assign itself one on the link, nor for the host (or whatever it turns out to be, "node" is a better word, many people believe that "host" excludes "router") either. Then the question of whether DAD is required for the link local addresses becomes relevant, and needs to be specified. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 9 08:53:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g29GroKL015217 for ; Sat, 9 Mar 2002 08:53:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g29GrnIp015216 for ipng-dist; Sat, 9 Mar 2002 08:53:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g29GrkKL015209 for ; Sat, 9 Mar 2002 08:53:46 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA14297 for ; Sat, 9 Mar 2002 08:53:47 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22794 for ; Sat, 9 Mar 2002 09:53:46 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g29GrjB12769 for ; Sat, 9 Mar 2002 17:53:45 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Sat Mar 09 17:53:44 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Sat, 9 Mar 2002 17:53:44 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AAC2@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Robert Elz'" , "Hesham Soliman (ERA)" Cc: ipng@sunroof.eng.sun.com Subject: RE: Cellular host draft - where we are and suggestions for moving for ward. Date: Sat, 9 Mar 2002 17:53:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | => It means something like this: > | > | A B > | GGSN ------- Host------- whatever you want tp put > | > | GGSNs MUST NOT use the /64 to configure addresses > | on their own interfaces. > > This is exactly why there needs to be an IPv6 over whatever draft > (in the IETF domain). Must of the (DAD related) part of this > discussion has all been noise, as it has all been missing the point. => No one disagreed with the need for splitting the I-D into two. But I disagree with your last statement, more below. > In particular: > > | But no DAD is needed on link A. > | > | Makes sense? > > No, this is what is causing the confusion. It isn't that DAD isn't > needed on A, it is that (as you are proposing) doing it there would > simply be wrong, as no address is to be configured there. => No, an address MUST be configured there, yes, only on the host side of the A link. > One never > does DAD on a link other than the one where the address is to be > configured - and your proposal is to have the A link above > be unnumbered, => No, the host configures an address and the GGSN doesn't. This is not _my_ proposal, this is how the 3GPP specs _are_. Have a look at the 3GPP advice draft, including the appendix. > > It is important to get the model right - if you even allow > yourself to > think that what the host is configuring the prefix on the 3GPP link, > then it makes no sense at all to restrict the GGSN from > also configuring > an address on the link - the /64 has plenty of address in > it, => Why doesn't it make sense ? Anyway, there is nothing _I_ can do about that, I'm describing an existing specification. and if it > is configured as a /64 (not two /65's or similar) then it > really applies only > to one link (joining it would be via a bridge). => Have you seen the Multi-link subnet draft? Or do you mean a L3 bridge as the MLSN draft suggests? > > So, what's needed is an I-D that sets out exactly how the > 3GPP link is to > be used, and justifies that. Note that justifying the > "MUST NOT" I quoted > above from your message might not be easy - telling > operators how they're to > be permitted to configure their links is something the IETF > does quite > rarely. In particular, unnumbered links are liked by > some, and hated by > others, so you're going to need to have some very strong > reasons to require > that mode of operation as the only acceptable mode. => I think you should consider it differently: 'we're not proposing a mechanism for 3GPP links, we're describing the host's behaviour based on the existing 3GPP specs'. > > On the other hand, there are still link local addresses to > be assigned on > link A, and there there's no possible justification for the > GGSN not to > assign itself one on the link, nor for the host (or > whatever it turns out to > be, "node" is a better word, many people believe that > "host" excludes > "router") either. Then the question of whether DAD is > required for the > link local addresses becomes relevant, and needs to be specified. => No. The link local address is negotiated before the reception of the RA, so it is impossile to have a collision between the host and GGSN. Just like PPP. Hesham > > kre > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 9 09:33:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g29HXnKL015261 for ; Sat, 9 Mar 2002 09:33:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g29HXn26015260 for ipng-dist; Sat, 9 Mar 2002 09:33:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g29HXkKL015253 for ; Sat, 9 Mar 2002 09:33:46 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24250 for ; Sat, 9 Mar 2002 09:33:47 -0800 (PST) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA21209 for ; Sat, 9 Mar 2002 09:33:46 -0800 (PST) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 886C51C7D for ; Sat, 9 Mar 2002 12:33:44 -0500 (EST) Date: Sat, 09 Mar 2002 12:33:44 -0500 From: Rob Austein To: ipng@sunroof.eng.sun.com Reply-To: ipng@sunroof.eng.sun.com Subject: Re: PPP and Global Addresses In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AABF@Esealnt861.al.sw.ericsson.se> References: <4DA6EA82906FD511BE2F00508BCF053802C6AABF@Esealnt861.al.sw.ericsson.se> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020309173344.886C51C7D@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At Sat, 9 Mar 2002 03:27:36 +0100, Hesham Soliman wrote: > > I don't have a great knowledge of DHCP but wouldn't this simply > message still require a relay agent? That's one way to do it. Another would be clever use of multicast. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 10 08:46:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2AGkYKL016139 for ; Sun, 10 Mar 2002 08:46:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2AGkY1v016138 for ipng-dist; Sun, 10 Mar 2002 08:46:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2AGkTKL016128 for ; Sun, 10 Mar 2002 08:46:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18264 for ; Sun, 10 Mar 2002 08:46:29 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA12919 for ; Sun, 10 Mar 2002 09:46:29 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 56D583443; Sun, 10 Mar 2002 11:46:28 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 10 Mar 2002 11:46:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Date: Sun, 10 Mar 2002 11:46:27 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711BDDE517@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00.txt -> wg last call?] Thread-Index: AcHGBKQ7VFEDO8nYTLaodWmrjRxa5gCPSW3g From: "Bound, Jim" To: "Hesham Soliman (ERA)" , "Charles E. Perkins" , "Karim El-Malki (ERA)" Cc: X-OriginalArrivalTime: 10 Mar 2002 16:46:28.0240 (UTC) FILETIME=[1FADA900:01C1C853] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2AGkUKL016129 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham and authors cellular hosts draft, I have to STRONGLY STRONGLY agree with Tony, Charlie, and Margaret, You MUST limit the scope of this title and work before you can get folks to agree on technical consensus. If you limit the scope the assumptions are limited (as Tony stated which I think Hesham missed in the dialogue I say objectively reading and parsing the debate). This work is driven by 3GPP for time-to-market. So I believe this work MUST be for 3GPP. We also need similar draft for 3GPP2 as Phil Roberts has stated and another point missed. I am against a General Hosts requirments document but I will say why when someone issues such a draft. I also think we need an 802.11 "use" document too. The bottom line is as my dead mother used to say "don't try to stuff 5 pounds of shit, in a 1 pound bag, it won't work and break the bag and stink". /jim > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Thursday, March 07, 2002 1:09 PM > To: 'Charles E. Perkins'; Karim El-Malki (ERA) > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Should DAD be optional? > [Wasdraft-ietf-ipv6-cellular-host-00.txt -> wg last call?] > > > > I have no problem with the words in your note, but then you > > have to rename the draft to be "IPv6-over-nearterm-3G", or > > better, "IPv6-over-3GPPr5-PDP". That gets the point across. > > > > If it's "IPv6-over-cellular", then you have to write > > the specification to apply to ALL cellular systems, current > > and future. That was the point in my note you quoted. > > > => Basically we're saying similar things in different > ways. My note (hasn't made it to the list yet) > said that we addressed both of the above in the > draft. The secions titled 'X function in 3GPP' > address the specifics. > It seems that there is some confusion about whether > cellular == 3GPP. That's certainly not the case > as it is explicitly stated in the draft. > So I do see the case for 2 documents, but the important > issue right now is to have some agreement on > the technical content, then decide if it should > be split into more than one document. > > Hesham > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sun Mar 10 08:46:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2AGkXKL016136 for ; Sun, 10 Mar 2002 08:46:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2AGkWgc016135 for ipng-dist; Sun, 10 Mar 2002 08:46:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2AGkSKL016121 for ; Sun, 10 Mar 2002 08:46:28 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19493 for ; Sun, 10 Mar 2002 08:46:27 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA01942 for ; Sun, 10 Mar 2002 09:46:27 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 96A305968; Sun, 10 Mar 2002 11:46:26 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 10 Mar 2002 11:46:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Updating draft-ietf-ipv6-cellular-host-00.txt? Date: Sun, 10 Mar 2002 11:46:26 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711BDDE516@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updating draft-ietf-ipv6-cellular-host-00.txt? Thread-Index: AcHF7P/xlkd9UnJcTu2J+JKvnnvhmQCU8vrw From: "Bound, Jim" To: "Jari Arkko" Cc: "Brian Haberman" , "Margaret Wasserman" , X-OriginalArrivalTime: 10 Mar 2002 16:46:26.0572 (UTC) FILETIME=[1EAF24C0:01C1C853] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2AGkSKL016122 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, I agree. But if we cannot get consensus quickly then its time to move on to the issues of use deployment elsewhere. /jim > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Thursday, March 07, 2002 7:30 AM > To: Bound, Jim > Cc: Brian Haberman; Margaret Wasserman; ipng@sunroof.eng.sun.com > Subject: Re: Updating draft-ietf-ipv6-cellular-host-00.txt? > > > Bound, Jim wrote: > > > > John et al. Bag this lets go build a cellular host consortia with > > vendors that want to ship and deploy IPv6 and build our use > requirements > > out of here. > > > > Or we will be hacking on this in January 2003. It was a > good thing to > > try but it might not work to do use / implementation reqs > in the IETF. > > Thats fine though. > > > Given that deployment starts this year and standards releases > are weeks > or at most months away, I'm sure decisions *will* be made as > to what goes to the > devices. The guestion is who will make the recommendations on what the > devices do. My strong preference though is that this WG makes > them, because > the expertise is here. > > Jari > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 10 09:04:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2AH42KL016191 for ; Sun, 10 Mar 2002 09:04:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2AH42YR016190 for ipng-dist; Sun, 10 Mar 2002 09:04:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2AH3xKL016183 for ; Sun, 10 Mar 2002 09:03:59 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13886 for ; Sun, 10 Mar 2002 09:03:59 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13607 for ; Sun, 10 Mar 2002 10:03:59 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 6610D3734; Sun, 10 Mar 2002 12:03:58 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 10 Mar 2002 12:03:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: PPP and Global Addresses Date: Sun, 10 Mar 2002 12:03:57 -0500 Message-ID: <56166EE9B83FD74B8613B160D65A481899300671@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP and Global Addresses Thread-Index: AcHF3YkkFE0rPDLiREKwUnb0KxNv4gCYpZ7w From: "Bound, Jim" To: "Francis Dupont" Cc: X-OriginalArrivalTime: 10 Mar 2002 17:03:58.0327 (UTC) FILETIME=[91943870:01C1C855] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2AH3xKL016184 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis, > In your previous mail you wrote: > > But I don't really care about your opinion or others on > what should be > used or not used from the work we do in the IETF. > > => I disagree: the resources of IETF are not infinite so waste is > a common concern. We are talking about use not a standard. Thats none of the IETFs business formally. We have enough work in the formal IETF charter work load, at least I do. Plus the only resources used for "use" are those who ship products and the network operators that use them. > > What I care about is if you find a technical hole or error in our > protocol specifications or interoperablity issues. > > => I'd like to see any of the security concerns of > draft-prigent-dhcpv6-threats-00.txt addressed, or > a proof that "the capability of automatic allocation of > reusable network addresses" has a meaning for IPv6 addresses > (note that we have 5 years of proof of the opposite). Differentiate the need for an Intranet vs an Internet. Most DHC is deployed on Intranets. Ralph has responded to you and I concur. /jim > > Regards > > Francis.Dupont@enst-bretagne.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 Sun Mar 10 09:39:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2AHdRKL016223 for ; Sun, 10 Mar 2002 09:39:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2AHdRUh016222 for ipng-dist; Sun, 10 Mar 2002 09:39:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2AHdOKL016215 for ; Sun, 10 Mar 2002 09:39:24 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21235 for ; Sun, 10 Mar 2002 09:39:24 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08554 for ; Sun, 10 Mar 2002 10:39:24 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 1B0425A7D for ; Sun, 10 Mar 2002 12:39:24 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 10 Mar 2002 12:39:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: PPP and Global Addresses Date: Sun, 10 Mar 2002 12:39:23 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0152082E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP and Global Addresses Thread-Index: AcHHlICEYtxG8IgKQSi0hvZoDqBKnQAxflvg From: "Bound, Jim" To: X-OriginalArrivalTime: 10 Mar 2002 17:39:24.0135 (UTC) FILETIME=[84A8C770:01C1C85A] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2AHdOKL016216 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk just as note for those that don't know dhcpv6 supports multicast too. /jim > -----Original Message----- > From: Rob Austein [mailto:sra+ipng@hactrn.net] > Sent: Saturday, March 09, 2002 12:34 PM > To: ipng@sunroof.eng.sun.com > Subject: Re: PPP and Global Addresses > > > At Sat, 9 Mar 2002 03:27:36 +0100, Hesham Soliman wrote: > > > > I don't have a great knowledge of DHCP but wouldn't this simply > > message still require a relay agent? > > That's one way to do it. Another would be clever use of multicast. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Sun Mar 10 10:35:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2AIZEKL016267 for ; Sun, 10 Mar 2002 10:35:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2AIZD0r016266 for ipng-dist; Sun, 10 Mar 2002 10:35:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2AIZAKL016259 for ; Sun, 10 Mar 2002 10:35:10 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27992 for ; Sun, 10 Mar 2002 10:35:09 -0800 (PST) Received: from smtp012.mail.yahoo.com (smtp012.mail.yahoo.com [216.136.173.32]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id LAA21504 for ; Sun, 10 Mar 2002 11:35:09 -0700 (MST) Received: from iching2101 (AUTH login) at 12-230-77-92.client.attbi.com (HELO ghostshell) (iching2101@12.230.77.92) by smtp.mail.vip.sc5.yahoo.com with SMTP; 10 Mar 2002 18:35:08 -0000 From: "Steve F. Smith, Jr" To: Subject: IE6 + v6? Date: Sun, 10 Mar 2002 10:36:20 -0800 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Does anyone know where I can find information regarding Internet Explorer 6 and Ipv6? I'm unable to get http working over v6 using IE6. I've checked Microsoft web site with no luck. If this is the wrong mailing list can someone point me in the right direction? Thanks, Steve Smith _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.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 Mar 11 05:19:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BDJIKL017981 for ; Mon, 11 Mar 2002 05:19:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2BDJIs4017980 for ipng-dist; Mon, 11 Mar 2002 05:19:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BDJFKL017973 for ; Mon, 11 Mar 2002 05:19:15 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01212 for ; Mon, 11 Mar 2002 05:19:16 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA29449 for ; Mon, 11 Mar 2002 05:19:14 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id PAA09503; Mon, 11 Mar 2002 15:19:05 +0200 Date: Mon, 11 Mar 2002 15:19:05 +0200 Message-Id: <200203111319.PAA09503@burp.tkv.asdf.org> From: Markku Savela To: narten@us.ibm.com CC: ipng@sunroof.eng.sun.com In-reply-to: <200203081910.g28JAH303376@cichlid.adsl.duke.edu> (message from Thomas Narten on Fri, 08 Mar 2002 14:10:17 -0500) Subject: Re: DAD and unique ID on link? References: <200203081910.g28JAH303376@cichlid.adsl.duke.edu> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Actually, I made a proposal in which one would not need to run DAD on > addresses other than link-local if the ids were globally unique (e.g., > generated from the EUI-64 identifier). One would still need to run DAD > on other addresses (e.g., temprorary addresses). I have some mild uneasines about solutions which require the IP layer to be aware of internal structure of the interface identifier (like whether it is EUI-64 or not). Of course, this leads into implementation logic, where the stack must always ask the network interface to give id (in case of EUI-64), and additionally, there would be need for API to ask random ID from interface. But, I prefer such solution, because then interface ID just always just a string of bits for the stack. Btw, amusingly I stumbled on draft-ietf-ipngwg-addr-arch-v3-07.txt, "2.5.1 Interface Identifiers": Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. They are required to be unique on that link. .... This sounds good to me, exactly what I need :-) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 11 06:00:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BE0aKL018036 for ; Mon, 11 Mar 2002 06:00:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2BE0aWZ018035 for ipng-dist; Mon, 11 Mar 2002 06:00:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BE0XKL018028 for ; Mon, 11 Mar 2002 06:00:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02602 for ; Mon, 11 Mar 2002 06:00:34 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27635 for ; Mon, 11 Mar 2002 07:00:33 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id QAA09564; Mon, 11 Mar 2002 16:00:32 +0200 Date: Mon, 11 Mar 2002 16:00:32 +0200 Message-Id: <200203111400.QAA09564@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipngwg-addr-arch-v3-07.txt and FF00::/16 and FF0F::/16? Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The scope value is [0..F], but 0 and F are marked as "reserved". Usually "reserved" values in protocols can be handled by "ignore on receive, zero on send". However, with scope and scoped addressing, I just can't ignore it on receive. What should I do with addresses starting with FF00::/16 FF0F::/16 a) when receiving a packet using those as destination. My first assumption: Drop it b) when application requests sending a packet to such address? My first assumption: reject with error Above logic will be hardcoded in all stacks, so anyone thinking later of redefining the meanings is severly limited. Just wanting to verify that I can do it in above way. Actually, only the value 0 is the problematic one (for 'F' I can just pretend that it is just another level above global, like universal :-). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 11 06:07:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BE7NKL018059 for ; Mon, 11 Mar 2002 06:07:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2BE7Nx6018058 for ipng-dist; Mon, 11 Mar 2002 06:07:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BE7KKL018051 for ; Mon, 11 Mar 2002 06:07:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05307 for ; Mon, 11 Mar 2002 06:07:21 -0800 (PST) Received: from mail3.noc.ntt.co.jp (mail3.noc.ntt.co.jp [210.163.32.58]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16916 for ; Mon, 11 Mar 2002 07:07:19 -0700 (MST) Received: from ms1-gw.noc.ntt.com (ms1-gw.noc.ntt.com) by mail3.noc.ntt.co.jp (8.9.3/NOC-MAIL3) id XAA00845; Mon, 11 Mar 2002 23:07:17 +0900 (JST) Received: from mr1-gw.noc.ntt.com by ms1-gw.noc.ntt.com (8.9.3/3.7W) id XAA01978; Mon, 11 Mar 2002 23:07:17 +0900 (JST) Received: from mail2.noc.ntt.com by mr1-gw.noc.ntt.com (8.9.3/3.7W) id XAA01974; Mon, 11 Mar 2002 23:07:16 +0900 (JST) Received: from r505r by mail2.noc.ntt.com (8.9.3/3.7W) id XAA03947; Mon, 11 Mar 2002 23:07:16 +0900 (JST) Message-ID: <01c001c1c905$cf940b90$30a0240a@local> From: "Yamasaki Toshi" To: "Bound, Jim" Cc: References: <56166EE9B83FD74B8613B160D65A481899300671@tayexc13.americas.cpqcorp.net> Subject: Re: PPP and Global Addresses Date: Mon, 11 Mar 2002 23:05:28 +0900 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim and all, > Differentiate the need for an Intranet vs an Internet. > Most DHC is deployed on Intranets. Ralph has responded to you and I > concur. I guess we are talking about "what is the best for ISP-to-Customer (PE-to-CPE) prefix delegation", correct? Then, there seems three proposals shown below for this purpose. What is your opinion for each proposed mechanism? (APD) draft-haberman-ipngwg-auto-prefix-02.txt (DHCPv6+PD option) draft-troan-dhcpv6-opt-prefix-delegation-00.txt (RA+PD option) draft-lutchann-ipv6-delegate-option-00.txt I believe everyone here agrees that zero-configuration environment is very important for the deployment of IPv6, because we know IPv6 should realize an world where not only technical people but also much more non-technical people can enjoy the global address and always-on environment. To achieve zero-configuration for "ISP-to-Customer (PE-to-CPE) prefix delegation", we had better have a global consensus about which mechanism is minimally required for this purpose. Many mechnisms for the same purpose will make it difficult to achieve zero-configuration enviroment, because CPE should know which to use before runnning an auto-configuration protocol among many choices. My opinion is: (APD) a good choice for a minimamlly required protocol for prefix delegation (DHCPv6+PD option) for those who want to more auto-configured parameters other than site-prefix (RA+PD option) can be used at only P-to-P enviroment and it is too restrictive P.S. Here is an ppt presentation about the "temporally" conclusion of IPv6 engineers mostly in Japan about this issue. http://www.apnic.net/meetings/13/sigs/docs/4.3_OSG_UNI.ppt It's a little old because there were no DHCPv6 nor RA proposals for prefix delegation when we discussed, but comments and opinions are very welcome. ---Toshi Yamasaki / NTT Communications -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 11 09:50:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BHo3KL018277 for ; Mon, 11 Mar 2002 09:50:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2BHo310018276 for ipng-dist; Mon, 11 Mar 2002 09:50:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BHo0KL018269 for ; Mon, 11 Mar 2002 09:50:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA05996 for ; Mon, 11 Mar 2002 09:50:01 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01444 for ; Mon, 11 Mar 2002 10:50:00 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 42CFF2E86; Mon, 11 Mar 2002 12:50:00 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Mon, 11 Mar 2002 12:50:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PPP and Global Addresses Date: Mon, 11 Mar 2002 12:49:59 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0152085D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP and Global Addresses Thread-Index: AcHJBhQsGHDb3jrCQ+ms6MILytm0rQAHNtOA From: "Bound, Jim" To: "Yamasaki Toshi" Cc: X-OriginalArrivalTime: 11 Mar 2002 17:50:00.0249 (UTC) FILETIME=[2A39D290:01C1C925] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2BHo0KL018270 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Toshi-san, > Jim and all, > > > Differentiate the need for an Intranet vs an Internet. > > Most DHC is deployed on Intranets. Ralph has responded to you and I > > concur. > > I guess we are talking about "what is the best for ISP-to-Customer > (PE-to-CPE) prefix delegation", correct? I believe solving this one first is wise. Then we can do what happens at leafs if required but my bias is that once we get a prefix to the edge router to a network then router renumbering should be used to propogate prefixes to routers. I also believe dhcpv6 servers should have routing interface to hear the router renumbering prefix announcements for use for the stateful address configuration of nodes. I do not believe that a coporate Intranet will use all stateless for a very long time. It will be mixed dhcpv6 and stateless. For the home user it should be stateless but that does not mean that dhcpv6 cannot be used at the PE. At least that is where I am at today. > > Then, there seems three proposals shown below for this > purpose. What is your > opinion for each proposed mechanism? OK. But I want to apply these to real deployment and can't do that on first read. So my responses at this point are an architectural view not an implementation view which I will have by the IETF meeting I hope. > > (APD) draft-haberman-ipngwg-auto-prefix-02.txt This could be useful for LINK or Subnet Prefix delegation but not useful to give prefixes across multiple subnets or lets say more than one link as it relys on ND. It could be useful also for Pt-to-Pt links as your slides below depict. > (DHCPv6+PD option) draft-troan-dhcpv6-opt-prefix-delegation-00.txt At this time in my view this is the most robust and most thought out draft of all of them. It also permits the use of giving the router additional parameters with future extensions to this draft. It also works across multiple links or over a network. This work also permits one to transition the way the addresses are given to CPE via xDSL at the DSLAM points of entry to the ISP-PE. The DHCPv6 server can perform many useful funcitons at the DSLAM location to kick-start IPv6 into the broadband market. I will stop there but can go into great detail. It also can be useful in a 3G (PP or P2) environment working in conjunction with AAA and HSS systems for location and authorization services. The bottom line is stateless is fine on a link but not across a network IMO. > (RA+PD option) draft-lutchann-ipv6-delegate-option-00.txt I think some of the features and methods of this draft should be merged with APD. So I can see having two approaches to solve the link or off line situations. But the DHCP6+PD is more robust and can be used in all situations. APD+RA+PD is the lightweight solution. > > I believe everyone here agrees that zero-configuration > environment is very > important for the deployment of IPv6, because we know IPv6 > should realize an > world where not only technical people but also much more non-technical > people can enjoy the global address and always-on environment. I agree. But do so with a pragmatic view. > > To achieve zero-configuration for "ISP-to-Customer (PE-to-CPE) prefix > delegation", we had better have a global consensus about > which mechanism is > minimally required for this purpose. Many mechnisms for the > same purpose > will make it difficult to achieve zero-configuration > enviroment, because CPE > should know which to use before runnning an > auto-configuration protocol > among many choices. I agree but I believe we can have a stateless and stateful solution for different needs. > > My opinion is: > > (APD) a good choice for a minimamlly required protocol for > prefix delegation I concur. > (DHCPv6+PD option) for those who want to more auto-configured > parameters > other than site-prefix I concur. > (RA+PD option) can be used at only P-to-P enviroment and it is too > restrictive Yes but merge its attributes with APD is my suggestion to the authors. > > P.S. > > Here is an ppt presentation about the "temporally" conclusion of IPv6 > engineers mostly in Japan about this issue. > http://www.apnic.net/meetings/13/sigs/docs/4.3_OSG_UNI.ppt > It's a little old because there were no DHCPv6 nor RA > proposals for prefix > delegation when we discussed, but comments and opinions are > very welcome. This was very very good presentation. I wish I had the time to do this for my work in the IETF in working groups it makes assumptions and ideas obvious. Thank You. Regards, /jim > > ---Toshi Yamasaki / NTT Communications > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 11 11:14:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BJEMKL018512 for ; Mon, 11 Mar 2002 11:14:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2BJEMnJ018511 for ipng-dist; Mon, 11 Mar 2002 11:14:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BJEJKL018504 for ; Mon, 11 Mar 2002 11:14:19 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA14755 for ; Mon, 11 Mar 2002 11:14:18 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA14396 for ; Mon, 11 Mar 2002 11:14:17 -0800 (PST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id MAA23401; Mon, 11 Mar 2002 12:14:15 -0700 (MST)] Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA06026; Mon, 11 Mar 2002 12:14:15 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id g2BJEBU06378; Mon, 11 Mar 2002 13:14:13 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 32F2A2EC83; Mon, 11 Mar 2002 20:14:08 +0100 (CET) To: "James Kempf" Cc: Subject: Re: Securing Neighbor Discovery References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> From: Alexandru Petrescu Date: 11 Mar 2002 20:14:08 +0100 In-Reply-To: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> Message-ID: Lines: 37 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "James Kempf" writes: > I've submitted a draft on securing neighbor discovery, > draft-kempf-secure-nd-00.txt. Hi James. Thanks for providing the tandem threat-solution for ND. As before, I'll make a case against using crypto as a total solution for a fine-grained problem. Please note that I think I understand some of the merits of the ABK crypto-system (I still miss some details). The threat document points out valid security concerns with ND. IMHO, some are easy to deal with and some other are harder, but in any case not all require total application of the ABK mechanism, noting that even if ABK's are applied some simple threats still hold. Threat 3.1. Malicious Last Hop Router fools the victim into using it as a default router. If the legitimate AR uses the ABK system then the attacker AR can also use a similar ABK system, right? It might be argued that the attacker AR can not communicate with the MN because it can't be authenticated by the MN with an attacker NAS, fair enough. But in that case, if the MN already shares a secret with the NAS, why not using the same secret to authenticate the ND, thus questioning the need for a more complex system. Threat 3.2 Good Router Goes Bad is probably less particular to ND. When good router goes bad it's too bad. Threat 3.5 Bogus On-Link Prefix can be addressed by a smart legitimate access router sending RA's with the attacker-prefix with lifetime 0. A smart MN could even detect too many RA sequences infinity-0-infinity-0 and consider that subnet unreliable. Threat 3.7 DAD seems to be solved by using an ABK system if the legitimate node will verify the authenticity of RS's. Threat 3.8 is not addressed by the ABK, I think. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 11 11:17:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BJHdKL018550 for ; Mon, 11 Mar 2002 11:17:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2BJHd3R018549 for ipng-dist; Mon, 11 Mar 2002 11:17:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BJHaKL018542 for ; Mon, 11 Mar 2002 11:17:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13291 for ; Mon, 11 Mar 2002 11:17:36 -0800 (PST) Received: from mg01.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05880 for ; Mon, 11 Mar 2002 12:17:35 -0700 (MST) Received: from austin.ibm.com (netmail.austin.ibm.com [9.3.7.137]) by mg01.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA23778 for ; Mon, 11 Mar 2002 13:17:36 -0600 Received: from porkchop.austin.ibm.com (porkchop.austin.ibm.com [9.53.151.169]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA25120 for ; Mon, 11 Mar 2002 13:17:33 -0600 Received: from localhost (lilianf@localhost) by porkchop.austin.ibm.com (AIX5.1/8.11.0/8.11.0-client1.01) with ESMTP id g2BJHY628908 for ; Mon, 11 Mar 2002 13:17:34 -0600 Date: Mon, 11 Mar 2002 13:16:13 -0600 (CST) From: Lilian Fernandes To: ipng@sunroof.eng.sun.com Subject: IPV6_JOIN_GROUP for v4 multicast Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have a question about the IPV6_JOIN_GROUP socket option from rfc2553bis-05. Is it intended that the user be able to use this socket option to join IPv4 multicast groups as well? The user could do this by specifying an IPv4-mapped IPv6 address for the IPv4 multicast address. The RFC does not deal with this case specifically....I have attached the relevant part of the rfc below: ------------------------------------------------------------------ IPV6_JOIN_GROUP Join a multicast group on a specified local interface. If the interface index is specified as 0, the kernel chooses the local interface. For example, some kernels look up the multicast group in the normal IPv6 routing table and use the resulting interface. Argument type: struct ipv6_mreq [deleted some stuff] The argument type of both of these options is the ipv6_mreq structure, defined as a result of including the header; struct ipv6_mreq { struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */ unsigned int ipv6mr_interface; /* interface index */ }; Thanks, _____________________________________________________________________ Lilian Fernandes AIX TCP/IP Development - IBM Austin Tel: 512-838-7966 Fax: 512-838-3509 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 11 12:19:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BKJFKL018707 for ; Mon, 11 Mar 2002 12:19:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2BKJFIP018706 for ipng-dist; Mon, 11 Mar 2002 12:19:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BKJCKL018699 for ; Mon, 11 Mar 2002 12:19:12 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA28073 for ; Mon, 11 Mar 2002 12:19:12 -0800 (PST) Received: from ensemada.lava.net (ensemada.lava.net [64.65.64.27]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA14501 for ; Mon, 11 Mar 2002 12:19:12 -0800 (PST) Received: from malasada.lava.net ([64.65.64.17]) (1433 bytes) by ensemada.lava.net; Mon, 11 Mar 2002 10:19:09 -1000 (HST) via sendmail [esmtp] id for Date: Mon, 11 Mar 2002 10:19:09 -1000 (HST) From: Antonio Querubin To: Lilian Fernandes cc: ipng@sunroof.eng.sun.com Subject: Re: IPV6_JOIN_GROUP for v4 multicast In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 11 Mar 2002, Lilian Fernandes wrote: > I have a question about the IPV6_JOIN_GROUP socket option from > rfc2553bis-05. Is it intended that the user be able to use this socket > option to join IPv4 multicast groups as well? The user could do this by > specifying an IPv4-mapped IPv6 address for the IPv4 multicast address. Unfortunately the RFCs don't specifically define an IPv4-mapped IPv6 equivalent for IPv4 multicast addresses. That section of the IPv6 address architecture RFC only pertains to mapping IPv4 unicast addresses. A suggestion was made last year to address this difference in behaviour at the basic sockets API level since the address architecture was pretty much fixed already. But that suggestion came a little too late and now it's been suggested that it be addressed instead in the advanced sockets API. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 11 12:33:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BKXxKL018729 for ; Mon, 11 Mar 2002 12:33:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2BKXxOv018728 for ipng-dist; Mon, 11 Mar 2002 12:33:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BKXuKL018721 for ; Mon, 11 Mar 2002 12:33:56 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA01735 for ; Mon, 11 Mar 2002 12:33:56 -0800 (PST) Received: from mg03.austin.ibm.com (mg03.austin.ibm.com [192.35.232.20]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA00291 for ; Mon, 11 Mar 2002 12:33:56 -0800 (PST) Received: from austin.ibm.com (netmail1.austin.ibm.com [9.3.7.138]) by mg03.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA26584; Mon, 11 Mar 2002 14:30:19 -0600 Received: from porkchop.austin.ibm.com (porkchop.austin.ibm.com [9.53.151.169]) by austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA35992; Mon, 11 Mar 2002 14:33:50 -0600 Received: from localhost (lilianf@localhost) by porkchop.austin.ibm.com (AIX5.1/8.11.0/8.11.0-client1.01) with ESMTP id g2BKXpI50494; Mon, 11 Mar 2002 14:33:51 -0600 Date: Mon, 11 Mar 2002 14:32:31 -0600 (CST) From: Lilian Fernandes To: Antonio Querubin cc: ipng@sunroof.eng.sun.com Subject: Re: IPV6_JOIN_GROUP for v4 multicast In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The advanced API does not address this yet....is there any way at all to currently join an IPv4 multicast group on an AF_INET6 socket? Or do applications need to open a separate AF_INET socket to join v4 groups? Thanks, Lilian On Mon, 11 Mar 2002, Antonio Querubin wrote: > On Mon, 11 Mar 2002, Lilian Fernandes wrote: > > > I have a question about the IPV6_JOIN_GROUP socket option from > > rfc2553bis-05. Is it intended that the user be able to use this socket > > option to join IPv4 multicast groups as well? The user could do this by > > specifying an IPv4-mapped IPv6 address for the IPv4 multicast address. > > Unfortunately the RFCs don't specifically define an IPv4-mapped IPv6 > equivalent for IPv4 multicast addresses. That section of the IPv6 address > architecture RFC only pertains to mapping IPv4 unicast addresses. > > A suggestion was made last year to address this difference in behaviour at > the basic sockets API level since the address architecture was pretty much > fixed already. But that suggestion came a little too late and now it's > been suggested that it be addressed instead in the advanced sockets API. > > _____________________________________________________________________ Lilian Fernandes AIX TCP/IP Development - IBM Austin Tel: 512-838-7966 Fax: 512-838-3509 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 11 13:03:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BL3qKL018836 for ; Mon, 11 Mar 2002 13:03:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2BL3qXh018835 for ipng-dist; Mon, 11 Mar 2002 13:03:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BL3nKL018828 for ; Mon, 11 Mar 2002 13:03:49 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11482 for ; Mon, 11 Mar 2002 13:03:49 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00944 for ; Mon, 11 Mar 2002 14:03:48 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id XAA09971; Mon, 11 Mar 2002 23:03:46 +0200 Date: Mon, 11 Mar 2002 23:03:46 +0200 Message-Id: <200203112103.XAA09971@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com In-reply-to: (message from Antonio Querubin on Mon, 11 Mar 2002 10:19:09 -1000 (HST)) Subject: Re: IPV6_JOIN_GROUP for v4 multicast References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Antonio Querubin > Unfortunately the RFCs don't specifically define an IPv4-mapped IPv6 > equivalent for IPv4 multicast addresses. That section of the IPv6 address > architecture RFC only pertains to mapping IPv4 unicast addresses. I don't see any problem here. IPv4-mapped format is just IPv4 address represented in IPv6 addres format. Makes no difference whether IPv4 address is "unicast", multicast or loopback net. Its 1:1 mapping. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 11 13:18:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BLINKL018890 for ; Mon, 11 Mar 2002 13:18:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2BLIMXN018889 for ipng-dist; Mon, 11 Mar 2002 13:18:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BLIHKL018882 for ; Mon, 11 Mar 2002 13:18:18 -0800 (PST) Received: from lillen (vpn-129-159-0-96.EMEA.Sun.COM [129.159.0.96]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2BLIDx04948; Mon, 11 Mar 2002 22:18:13 +0100 (MET) Date: Mon, 11 Mar 2002 22:12:57 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: IPV6_JOIN_GROUP for v4 multicast To: Lilian Fernandes Cc: Antonio Querubin , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The advanced API does not address this yet....is there any way at all to > currently join an IPv4 multicast group on an AF_INET6 socket? > Or do applications need to open a separate AF_INET socket to join v4 > groups? When working on porting the java.net classes to transparently support IPv6 we discovered that supporting IPv4-mapped addresses in IPV6_JOIN_GROUP (as well as supporting an ifindex for an interface with no IPv6 for IPV6_JOIN_GROUP and IPV6_MULTICAST_IF) was needed in order to get good transparency. Essentially when a java.net datagram socket is created it always corresponds an AF_INET6 socket in the kernel (if the kernel supports IPv6) and IPV6_JOIN_GROUP and sendto() handle IPv4-mapped addresses. 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 Mar 11 14:35:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BMZVKL019134 for ; Mon, 11 Mar 2002 14:35:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2BMZVhp019133 for ipng-dist; Mon, 11 Mar 2002 14:35:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2BMZSKL019126 for ; Mon, 11 Mar 2002 14:35:28 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11468 for ; Mon, 11 Mar 2002 14:35:23 -0800 (PST) Received: from gau.lava.net (gau.lava.net [64.65.64.28]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15767 for ; Mon, 11 Mar 2002 15:35:22 -0700 (MST) Received: from malasada.lava.net ([64.65.64.17]) (1240 bytes) by gau.lava.net; Mon, 11 Mar 2002 12:35:19 -1000 (HST) via sendmail [esmtp] id for Date: Mon, 11 Mar 2002 12:35:03 -1000 (HST) From: Antonio Querubin To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: IPV6_JOIN_GROUP for v4 multicast In-Reply-To: <200203112103.XAA09971@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 11 Mar 2002, Markku Savela wrote: > > From: Antonio Querubin > > > Unfortunately the RFCs don't specifically define an IPv4-mapped IPv6 > > equivalent for IPv4 multicast addresses. That section of the IPv6 address > > architecture RFC only pertains to mapping IPv4 unicast addresses. > > I don't see any problem here. IPv4-mapped format is just IPv4 address > represented in IPv6 addres format. Makes no difference whether IPv4 > address is "unicast", multicast or loopback net. Its 1:1 mapping. The RFC defines mapped addresses only for unicast addresses. There is no provision for dealing with mapped multicast addresses. Hence the problem... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 01:00:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2C90uKL019896 for ; Tue, 12 Mar 2002 01:00:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2C90uAS019895 for ipng-dist; Tue, 12 Mar 2002 01:00:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2C90oKL019888 for ; Tue, 12 Mar 2002 01:00:51 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2C90nx15003 for ; Tue, 12 Mar 2002 10:00:49 +0100 (MET) Date: Tue, 12 Mar 2002 09:55:33 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Next steps on Reserving bits in RFC 2473 Interface IDs? To: ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A while back I sent an email to the list talking about Reserving bits in RFC 2473 Interface IDs. Not much email has followed on this topic so it isn't clear whether people are having too much fun debating other topics, think it is a good/bad idea, or just don't care. I think our choices are: 1. Do nothing 2. Reserve a quarter of the IID space i.e. universal=1, group=1 becomes explicitly reserved. 3. Reserve half of the IID space i.e. all addresses with group=1 become explicitly reserved. It would be good to try to make progress on the mailing list on this question otherwise it's likely to appear on the agenda in the meetings next week :-) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 12 01:20:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2C9KHKL020010 for ; Tue, 12 Mar 2002 01:20:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2C9KHFa020009 for ipng-dist; Tue, 12 Mar 2002 01:20:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2C9KEKL020002 for ; Tue, 12 Mar 2002 01:20:14 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA09984 for ; Tue, 12 Mar 2002 01:20:14 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA02624 for ; Tue, 12 Mar 2002 01:20:13 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA10837; Tue, 12 Mar 2002 11:20:06 +0200 Date: Tue, 12 Mar 2002 11:20:06 +0200 Message-Id: <200203120920.LAA10837@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com In-reply-to: (message from Erik Nordmark on Tue, 12 Mar 2002 09:55:33 +0100 (CET)) Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Erik Nordmark > > A while back I sent an email to the list talking about > Reserving bits in RFC 2473 Interface IDs. rfc-2373 I presume... My opinion on this is: these ID related issues all belong to IP-over-foo documents. The rfc-2373 should only talk about (prefix=n, interface ID = 128-n), and not care at all what the ID bits are. Thus, all references to EUI-64 should be removed from 2373. I feel it would be cleaner specification that way, but if people want to keep EUI-64 and other bits, I'm not going to nag you too much. Just giving this "opinion" for the record. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 01:22:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2C9MFKL020027 for ; Tue, 12 Mar 2002 01:22:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2C9MF9h020026 for ipng-dist; Tue, 12 Mar 2002 01:22:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2C9MCKL020019 for ; Tue, 12 Mar 2002 01:22:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA14040; Tue, 12 Mar 2002 01:22:03 -0800 (PST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA17810; Tue, 12 Mar 2002 02:22:01 -0700 (MST) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g2C9LoG18741; Tue, 12 Mar 2002 10:21:50 +0100 (MET) Message-ID: <3C8DC8B1.AB205E41@inrialpes.fr> Date: Tue, 12 Mar 2002 10:21:53 +0100 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: ipng@sunroof.eng.sun.com Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: Content-Type: multipart/alternative; boundary="------------E74A69814C243CA391CF3802" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------E74A69814C243CA391CF3802 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Erik, I really think this is an important topic.... Considering the MobileIP mailing discussions it would make sense to have an IID space reserved for "RR-addresses". I also believe that an IID space should also be reserved for CGA (Crypto. Generated ) addresses... I would therefore vote for choice #3... Claude. Erik Nordmark wrote: > A while back I sent an email to the list talking about > Reserving bits in RFC 2473 Interface IDs. > > Not much email has followed on this topic so it isn't clear whether > people are having too much fun debating other topics, think it is > a good/bad idea, or just don't care. > > I think our choices are: > 1. Do nothing > 2. Reserve a quarter of the IID space i.e. universal=1, group=1 becomes > explicitly reserved. > 3. Reserve half of the IID space i.e. all addresses with group=1 become > explicitly reserved. > > It would be good to try to make progress on the mailing list on this question > otherwise it's likely to appear on the agenda in the meetings next week :-) > > 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 > -------------------------------------------------------------------- -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------E74A69814C243CA391CF3802 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Hello Erik,

I really think this is an important topic....
Considering the MobileIP mailing discussions it would make
sense to have an IID space reserved for "RR-addresses".
I also believe that an IID space should also be reserved for CGA
(Crypto. Generated ) addresses...
I would therefore vote for choice #3...

Claude.

Erik Nordmark wrote:

A while back I sent an email to the list talking about
Reserving bits in RFC 2473 Interface IDs.

Not much email has followed on this topic so it isn't clear whether
people are having too much fun debating other topics, think it is
a good/bad idea, or just don't care.

I think our choices are:
1. Do nothing
2. Reserve a quarter of the IID space i.e. universal=1, group=1 becomes
   explicitly reserved.
3. Reserve half of the IID space i.e. all addresses with group=1 become
   explicitly reserved.

It would be good to try to make progress on the mailing list on this question
otherwise it's likely to appear on the agenda in the meetings next week :-)

  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
--------------------------------------------------------------------

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------E74A69814C243CA391CF3802-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 02:06:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CA6NKL020108 for ; Tue, 12 Mar 2002 02:06:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CA6NwU020107 for ipng-dist; Tue, 12 Mar 2002 02:06:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CA6KKL020100 for ; Tue, 12 Mar 2002 02:06:20 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA22759 for ; Tue, 12 Mar 2002 02:06:16 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA18695 for ; Tue, 12 Mar 2002 02:06:19 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2CABi202619; Tue, 12 Mar 2002 17:11:47 +0700 (ICT) From: Robert Elz To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-Reply-To: <200203120920.LAA10837@burp.tkv.asdf.org> References: <200203120920.LAA10837@burp.tkv.asdf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Mar 2002 17:11:44 +0700 Message-ID: <2617.1015927904@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 12 Mar 2002 11:20:06 +0200 From: Markku Savela Message-ID: <200203120920.LAA10837@burp.tkv.asdf.org> | My opinion on this is: these ID related issues all belong to | IP-over-foo documents. The rfc-2373 should only talk about (prefix=n, | interface ID = 128-n), and not care at all what the ID bits are. I agree. | Thus, all references to EUI-64 should be removed from 2373. Yes. Exactly. 2373 should go no further than recommending that IPv6 over foo specs should use no more than 64 bits as the interface ID. The language that does that can be strong - but no matter how strong it can never be more than a recommendation, the authors of a later standard are always free to override an older one (assuming they can get rough consensus, ...) It needs to be made very very clear that no-one can ever take the low 64 bits of an IPv6 address, and attempt to make any sense out of them at all. The bits have meaning only within the scope of the prefix that assigns them, and can be interpreted only by knowing the assignment rules of whoever controls the prefix. Common sense rules like "set (the inverted) u=1 when autoconfiguring" make sense - they make it easy to mix & match assignment styles within a prefix - but no-one other than the owner of the prefix in question should be relying upon such a rule being applied. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 12 02:15:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CAFjKL020178 for ; Tue, 12 Mar 2002 02:15:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CAFjbl020177 for ipng-dist; Tue, 12 Mar 2002 02:15:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CAFfKL020170 for ; Tue, 12 Mar 2002 02:15:41 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA18143 for ; Tue, 12 Mar 2002 02:15:32 -0800 (PST) Received: from mail2.noc.ntt.co.jp (mail2.noc.ntt.co.jp [210.163.32.54]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA17198 for ; Tue, 12 Mar 2002 02:15:31 -0800 (PST) Received: from ms2-gw.noc.ntt.com (ms2-gw.noc.ntt.com) by mail2.noc.ntt.co.jp (8.9.3/NOC-MAIL1) id TAA23392; Tue, 12 Mar 2002 19:15:30 +0900 (JST) Received: from mr2-gw.noc.ntt.com by ms2-gw.noc.ntt.com (8.9.3/3.7W) id TAA22204; Tue, 12 Mar 2002 19:15:30 +0900 (JST) Received: from mail2.noc.ntt.com by mr2-gw.noc.ntt.com (8.9.3/3.7W) id TAA22193; Tue, 12 Mar 2002 19:15:29 +0900 (JST) Received: from r505r by mail2.noc.ntt.com (8.9.3/3.7W) id TAA10077; Tue, 12 Mar 2002 19:15:28 +0900 (JST) Message-ID: <00b901c1c9ae$97887700$3c43320a@local> From: "Yamasaki Toshi" To: "Bound, Jim" Cc: References: <9C422444DE99BC46B3AD3C6EAFC9711B0152085D@tayexc13.americas.cpqcorp.net> Subject: Re: PPP and Global Addresses Date: Tue, 12 Mar 2002 19:08:48 +0900 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim-san, Thank you for your thoughtful opinions and advices. Again, I believe this "ISP-to-Customer site-configuration" is one of the most urgent issues for the WG, because no non-technical customers can join to IPv6 world unless we provide any solution. This positive discussion will help us to solve the issue. > > Then, there seems three proposals shown below for this > > purpose. What is your opinion for each proposed mechanism? > > OK. But I want to apply these to real deployment and can't do that on first read. So my responses at this point are an architectural view not an implementation view which I will have by the IETF meeting I hope. Understand. FYI, some ISPs will (or want to) start IPv6/DSL services hopefully in 2002, and we will see some working-in-commercial-services implementations soon. > So I can see having two approaches to solve the link or off line situations. But the DHCP6+PD is more robust and can be used in all situations. APD+RA+PD is the lightweight solution. I agree with your opinion that APD is the minimally required lightweight solution and DHCPv6 is the "FULL-SERVICE" solution. It's not clear to me how you think the RA+PD proposal be merged into APD. Could you kindly explain the details? > I agree but I believe we can have a stateless and stateful solution for different needs. Absolutely. --- Toshi Yamasaki / NTT Communications -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 02:47:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CAlnKL020240 for ; Tue, 12 Mar 2002 02:47:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CAln2L020239 for ipng-dist; Tue, 12 Mar 2002 02:47:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CAlkKL020232 for ; Tue, 12 Mar 2002 02:47:46 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA04934 for ; Tue, 12 Mar 2002 02:47:48 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA25036 for ; Tue, 12 Mar 2002 02:47:52 -0800 (PST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id DAA07736; Tue, 12 Mar 2002 03:47:43 -0700 (MST)] Received: [from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id DAA03729; Tue, 12 Mar 2002 03:47:43 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr04.mot.com (8.11.6/8.11.6) with ESMTP id g2CAlc909869; Tue, 12 Mar 2002 04:47:39 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 097312EC83; Tue, 12 Mar 2002 11:47:06 +0100 (CET) To: Francis Dupont Cc: Erik Nordmark, Subject: Re: Reserving bits in RFC 2473 Interface IDs? References: <200203060829.g268TXg12457@givry.rennes.enst-bretagne.fr> From: Alexandru Petrescu Date: 12 Mar 2002 11:47:05 +0100 In-Reply-To: <200203060829.g268TXg12457@givry.rennes.enst-bretagne.fr> Message-ID: Lines: 17 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > Have you read draft-dupont-ipv6-imei-00.txt? Hi Francis, thanks for putting the IMEI idea on paper, it's been long expected by many circles. I have a remark below, please correct me if I misunderstood the conversion. > The IMEI 330001 53 007826 gives the 0333:0001:5300:7826 (usually > written 333:1:5300:7826) interface identifier. Since IMEI is represented in decimal and addresses in hexa, by doing the above it effectively leads to impossibility of use of parts of address space. I mean, all IMEI's can be represented into an IPv6 Interface ID, but certain IPv6 Interface ID's will never have a correspondent IMEI. Maybe better can be done. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 02:59:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CAxsKL020277 for ; Tue, 12 Mar 2002 02:59:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CAxsFV020276 for ipng-dist; Tue, 12 Mar 2002 02:59:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CAxpKL020269 for ; Tue, 12 Mar 2002 02:59:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA25921 for ; Tue, 12 Mar 2002 02:59:52 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA26250 for ; Tue, 12 Mar 2002 03:59:52 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id DAA12584; Tue, 12 Mar 2002 03:57:45 -0700 (MST)] Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id DAA13564; Tue, 12 Mar 2002 03:57:44 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (8.11.6/8.11.6) with ESMTP id g2C9vdB24109; Tue, 12 Mar 2002 03:57:40 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id C326C2EC84; Tue, 12 Mar 2002 11:57:37 +0100 (CET) To: Robert Elz Cc: Markku Savela, Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: <200203120920.LAA10837@burp.tkv.asdf.org> <2617.1015927904@brandenburg.cs.mu.OZ.AU> From: Alexandru Petrescu Date: 12 Mar 2002 11:57:37 +0100 In-Reply-To: <2617.1015927904@brandenburg.cs.mu.OZ.AU> Message-ID: Lines: 8 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz writes: > 2373 should go no further than recommending that IPv6 over foo specs > should use no more than 64 bits as the interface ID. I'm very curious if the suggested recommendation is really "no more than 64" or is it "exactly 64"? Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 03:10:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CBAvKL020326 for ; Tue, 12 Mar 2002 03:10:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CBAvRR020325 for ipng-dist; Tue, 12 Mar 2002 03:10:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CBAsKL020318 for ; Tue, 12 Mar 2002 03:10:54 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA08260 for ; Tue, 12 Mar 2002 03:10:53 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA12019 for ; Tue, 12 Mar 2002 04:10:49 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id EAA13686; Tue, 12 Mar 2002 04:10:48 -0700 (MST)] Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id EAA13978; Tue, 12 Mar 2002 04:10:47 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (8.11.6/8.11.6) with ESMTP id g2CBAiA32521; Tue, 12 Mar 2002 05:10:44 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id A00CB2EC83; Tue, 12 Mar 2002 12:10:36 +0100 (CET) To: Erik Nordmark Cc: Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: From: Alexandru Petrescu Date: 12 Mar 2002 12:10:36 +0100 In-Reply-To: Message-ID: Lines: 25 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark writes: > I think our choices are: > 1. Do nothing > 2. Reserve a quarter of the IID space i.e. universal=1, group=1 becomes > explicitly reserved. > 3. Reserve half of the IID space i.e. all addresses with group=1 become > explicitly reserved. Hi Erik, I have a side remark with respect to the u/g bits, and this might be because of a not so solid understanding of why they're there. Since u and g have approximately the same semantics that can be found in the 8bit prefix of the addres I was believing that they're necessary only for Ethernet-derived environments, where they can be exploited by specific Ethernet optimizations for multicast, etc. When other than Ethernet link layers are involved, probably the functionality of the u/g bits can be derived from the 8bit prefix? Maybe it's the 8bit prefix that should be tweaked to obtain the reservations proposed? Please take this as an aside only, I might be completely wrong of the rationale behind the u/g. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 04:50:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CCoUKL020516 for ; Tue, 12 Mar 2002 04:50:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CCoU94020515 for ipng-dist; Tue, 12 Mar 2002 04:50:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CCoRKL020508 for ; Tue, 12 Mar 2002 04:50:27 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA29165 for ; Tue, 12 Mar 2002 04:50:27 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA14636 for ; Tue, 12 Mar 2002 04:50:26 -0800 (PST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-128.cisco.com [161.44.149.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA22848; Tue, 12 Mar 2002 07:46:46 -0500 (EST) Message-Id: <4.3.2.7.2.20020312074133.00ba8670@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Mar 2002 07:46:43 -0500 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: PPP and Global Addresses Cc: ipng@sunroof.eng.sun.com In-Reply-To: <20020307192840.8782E1C7D@thrintun.hactrn.net> References: <4.3.2.7.2.20020307122231.00b74d78@funnel.cisco.com> <4.3.2.7.2.20020307122231.00b74d78@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 02:28 PM 3/7/2002 -0500, Rob Austein wrote: >1) The portions of DHCP that are required for post-addr-conf (sorry, > don't have a better name for this) are pretty minimal, and I'm > pretty sure that one can write conforming DHCP clients and servers > that only implement that part of the DHCP spec (more precisely, the > only thing that such implementations would have to do with the > complex part of the spec would be to ignore the messages without > crashing). Ralph, please correct me if I'm wrong about this. Rob - yes, DHCP clients and servers that don't do address assignment can be implemented to discard other messages and options that are not of interest. For DNS configuration, clients and server would only need to implement the Information-Request and Reply messages, which are used in a two message exchange. - 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 Tue Mar 12 04:50:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CCoJKL020506 for ; Tue, 12 Mar 2002 04:50:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CCoJ1N020505 for ipng-dist; Tue, 12 Mar 2002 04:50:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CCoGKL020498 for ; Tue, 12 Mar 2002 04:50:16 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA29084 for ; Tue, 12 Mar 2002 04:50:16 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11808 for ; Tue, 12 Mar 2002 05:50:15 -0700 (MST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-128.cisco.com [161.44.149.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA22967; Tue, 12 Mar 2002 07:50:13 -0500 (EST) Message-Id: <4.3.2.7.2.20020312074702.00baaad8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Mar 2002 07:50:05 -0500 To: "Hesham Soliman (ERA)" From: Ralph Droms Subject: RE: PPP and Global Addresses Cc: "'ipng@sunroof.eng.sun.com'" In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AABF@Esealnt861.al.sw. ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The DHCPv6 spec defines a well-known site-scoped multicast address that all DHCP servers listen on. Assuming a DHCP client has an address of sufficient scope to which a DHCP server can reply, the client can send an Information-Request message to that multicast address to contact a DHCp server without requiring a relay agent. - Ralph At 03:27 AM 3/9/2002 +0100, Hesham Soliman (ERA) wrote: > > 1) The portions of DHCP that are required for post-addr-conf (sorry, > > don't have a better name for this) are pretty minimal, and I'm > > pretty sure that one can write conforming DHCP clients > > and servers > > that only implement that part of the DHCP spec (more > > precisely, the > > only thing that such implementations would have to do with the > > complex part of the spec would be to ignore the messages without > > crashing). Ralph, please correct me if I'm wrong about this. > > > >=> I don't have a great knowledge of DHCP but >wouldn't this simply message still require >a relay agent? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 05:21:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CDL7KL020587 for ; Tue, 12 Mar 2002 05:21:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CDL7oZ020586 for ipng-dist; Tue, 12 Mar 2002 05:21:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CDL4KL020579 for ; Tue, 12 Mar 2002 05:21:04 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA04960 for ; Tue, 12 Mar 2002 05:21:04 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA23301 for ; Tue, 12 Mar 2002 06:20:59 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2CDQF202907; Tue, 12 Mar 2002 20:26:16 +0700 (ICT) From: Robert Elz To: Alexandru Petrescu cc: Markku Savela , ipng@sunroof.eng.sun.com Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-Reply-To: References: <200203120920.LAA10837@burp.tkv.asdf.org> <2617.1015927904@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Mar 2002 20:26:15 +0700 Message-ID: <2905.1015939575@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: 12 Mar 2002 11:57:37 +0100 From: Alexandru Petrescu Message-ID: | I'm very curious if the suggested recommendation is really "no more | than 64" or is it "exactly 64"? It is currently probably exactly 64 - but there's no reason for that. A link layer that doesn't have a use for all 64 bits shouldn't be required to pad them for no reason (note: the "padding" done by the ethernet layer isn't for no reason - it allows for the possible bridging between IEEE nets that use EUI-48s and those that use EUI-64's, and while that seems most likely very distasteful to me, so is bridging FDDI to ethernet, and we know that's been done...) The "no more than 64" is to make sure that standard sized address allocations can work on all link layers. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 12 05:57:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CDvvKL020654 for ; Tue, 12 Mar 2002 05:57:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CDvv3r020653 for ipng-dist; Tue, 12 Mar 2002 05:57:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CDvsKL020646 for ; Tue, 12 Mar 2002 05:57:54 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA24846 for ; Tue, 12 Mar 2002 05:57:55 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id FAA10305 for ; Tue, 12 Mar 2002 05:57:53 -0800 (PST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Tue, 12 Mar 2002 14:41:12 +0100 Message-ID: <91A311FF6A85D3118DDF0060080C3D8202C95D2A@lat3721.rd.francetelecom.fr> From: NOISETTE Yoann FTRD/DMI/CAE To: "'Yamasaki Toshi'" , "Bound, Jim" Cc: ipng@sunroof.eng.sun.com Subject: RE: PPP and Global Addresses Date: Tue, 12 Mar 2002 14:41:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-bc9e368d-3588-11d6-ac22-00508b692753" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------=_NextPartTM-000-bc9e368d-3588-11d6-ac22-00508b692753 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C9CB.9A4D8440" ------_=_NextPart_001_01C1C9CB.9A4D8440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for the pointer, the slides are very interesting indeed... I totally agree this is an important topic which should be discussed on = this list. IMO, the three mechanisms have different approaches and assets = (for instance, APD takes routing into consideration, DHCPv6+PD can provide precious DNS information...), so it is perhaps better, instead of = choosing one mechanism or the other to reach a consensus on what we think is necessary to provide ISP-to-Customer(PE-to-CPE) prefix delegation = leading to a zeroconfiguration environment as pointed out by Toshi-san. Moreover, in this aim, both stateful and stateless solutions could be considered, as pointed out by Jim, and could be discussed as the needs = are indeed not the same.=20 To bring a little more to the discussion and lay stress on the fact = that prefix delegation is a important topic, here's another kind of prefix delegation we can encounter. Though this is outside this list's work, = I think it is interesting to point that, for instance, RFC 3053 about = "IPv6 tunnel broker" provides a way an ISP could use to delegate prefixes to = its IPv4-only-connected clients : Quick quote : "Moreover, if the client machine is an IPv6 router willing to provide connectivity to several IPv6 hosts, the client should be asked also to provide some information about the amount of IPv6 addresses required. This allows the TB to allocate the client an IPv6 prefix that fits its needs instead of a single IPv6 address." Yoann -----Message d'origine----- De : Yamasaki Toshi [mailto:t.yamasaki@ntt.com] Envoy=E9 : lundi 11 mars 2002 15:05 =C0 : Bound, Jim Cc : ipng@sunroof.eng.sun.com Objet : Re: PPP and Global Addresses=20 Jim and all, > Differentiate the need for an Intranet vs an Internet. > Most DHC is deployed on Intranets. Ralph has responded to you and I > concur. I guess we are talking about "what is the best for ISP-to-Customer (PE-to-CPE) prefix delegation", correct? Then, there seems three proposals shown below for this purpose. What is = your opinion for each proposed mechanism? (APD) draft-haberman-ipngwg-auto-prefix-02.txt (DHCPv6+PD option) draft-troan-dhcpv6-opt-prefix-delegation-00.txt (RA+PD option) draft-lutchann-ipv6-delegate-option-00.txt I believe everyone here agrees that zero-configuration environment is = very important for the deployment of IPv6, because we know IPv6 should = realize an world where not only technical people but also much more non-technical people can enjoy the global address and always-on environment. To achieve zero-configuration for "ISP-to-Customer (PE-to-CPE) prefix delegation", we had better have a global consensus about which = mechanism is minimally required for this purpose. Many mechnisms for the same = purpose will make it difficult to achieve zero-configuration enviroment, = because CPE should know which to use before runnning an auto-configuration protocol among many choices. My opinion is: (APD) a good choice for a minimamlly required protocol for prefix = delegation (DHCPv6+PD option) for those who want to more auto-configured = parameters other than site-prefix (RA+PD option) can be used at only P-to-P enviroment and it is too restrictive P.S. Here is an ppt presentation about the "temporally" conclusion of IPv6 engineers mostly in Japan about this issue. http://www.apnic.net/meetings/13/sigs/docs/4.3_OSG_UNI.ppt It's a little old because there were no DHCPv6 nor RA proposals for = prefix delegation when we discussed, but comments and opinions are very = welcome. ---Toshi Yamasaki / NTT Communications -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C1C9CB.9A4D8440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: PPP and Global Addresses

Thanks for the pointer, the slides are very = interesting indeed...

I totally agree this is an important topic which = should be discussed on this list. IMO, the three mechanisms have = different approaches and assets (for instance, APD takes routing into = consideration, DHCPv6+PD can provide precious DNS information...), so = it is perhaps better, instead of choosing one mechanism or the other to = reach a consensus on what we think is necessary to provide = ISP-to-Customer(PE-to-CPE) prefix delegation leading to a = zeroconfiguration environment as pointed out by Toshi-san.

Moreover, in this aim, both stateful and stateless = solutions could be considered, as pointed out by Jim, and could be = discussed as the needs are indeed not the same.

To bring a little more to the discussion and lay = stress on the fact that prefix delegation is a important topic, here's = another kind of prefix delegation we can encounter. Though this = is  outside this list's work, I think it is interesting to point = that, for instance, RFC 3053 about "IPv6 tunnel broker" = provides a way an ISP could use to delegate prefixes to its = IPv4-only-connected clients :

        Quick = quote : "Moreover, if the client machine is an IPv6 router willing = to provide
        connectivity = to several IPv6 hosts, the client should be asked also
        to provide = some information about the amount of IPv6 addresses
        = required.  This allows the TB to allocate the client an IPv6 = prefix
        that fits its = needs instead of a single IPv6 address."


Yoann


-----Message d'origine-----
De : Yamasaki Toshi [mailto:t.yamasaki@ntt.com]=
Envoy=E9 : lundi 11 mars 2002 15:05
=C0 : Bound, Jim
Cc : ipng@sunroof.eng.sun.com
Objet : Re: PPP and Global Addresses


Jim and all,

> Differentiate the need for an Intranet vs an = Internet.
> Most DHC is deployed on Intranets.  Ralph = has responded to you and I
> concur.

I guess we are talking about "what is the best = for ISP-to-Customer
(PE-to-CPE) prefix delegation", correct?

Then, there seems three proposals shown below for = this purpose. What is your
opinion for each proposed mechanism?

(APD) draft-haberman-ipngwg-auto-prefix-02.txt
(DHCPv6+PD option) = draft-troan-dhcpv6-opt-prefix-delegation-00.txt
(RA+PD option) = draft-lutchann-ipv6-delegate-option-00.txt

I believe everyone here agrees that = zero-configuration environment is very
important for the deployment of IPv6, because we = know IPv6 should realize an
world where not only technical people but also much = more non-technical
people can enjoy the global address and always-on = environment.

To achieve zero-configuration for = "ISP-to-Customer (PE-to-CPE) prefix
delegation", we had better have a global = consensus about which mechanism is
minimally required for this purpose. Many mechnisms = for the same purpose
will make it difficult to achieve zero-configuration = enviroment, because CPE
should know which to use before runnning an = auto-configuration protocol
among many choices.

My opinion is:

(APD) a good choice for a minimamlly required = protocol for prefix delegation
(DHCPv6+PD option) for those who want to more = auto-configured parameters
other than site-prefix
(RA+PD option) can be used at only P-to-P enviroment = and it is too
restrictive

P.S.

Here is an ppt presentation about the = "temporally" conclusion of IPv6
engineers mostly in Japan about this issue.
http://www.apnic.net/meetings/13/sigs/docs/4.3_OSG_UNI= .ppt
It's a little old because there were no DHCPv6 nor = RA proposals for prefix
delegation when we discussed, but comments and = opinions are very welcome.

---Toshi Yamasaki / NTT Communications

---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01C1C9CB.9A4D8440-- ------=_NextPartTM-000-bc9e368d-3588-11d6-ac22-00508b692753-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 06:22:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CEMlKL020756 for ; Tue, 12 Mar 2002 06:22:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CEMlk9020755 for ipng-dist; Tue, 12 Mar 2002 06:22:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CEMgKL020748 for ; Tue, 12 Mar 2002 06:22:43 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2CEMcx13185; Tue, 12 Mar 2002 15:22:38 +0100 (MET) Date: Tue, 12 Mar 2002 15:17:20 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? To: Alexandru Petrescu Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Since u and g have approximately the same semantics that can be found > in the 8bit prefix of the addres I was believing that they're > necessary only for Ethernet-derived environments, where they can be > exploited by specific Ethernet optimizations for multicast, etc. The universal bit is defined in 2373bis (addr-arch-v3) to apply to most of the address space, thus it is not tied to the link-layer being Ethernet. And IP-over-Ethernet spec doesn't do anything different as a function of the IID when transmitting packets on the Ethernet. > When other than Ethernet link layers are involved, probably the > functionality of the u/g bits can be derived from the 8bit prefix? > Maybe it's the 8bit prefix that should be tweaked to obtain the > reservations proposed? Do you have a concrete proposal? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 12 06:34:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CEYBKL020809 for ; Tue, 12 Mar 2002 06:34:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CEYB6r020808 for ipng-dist; Tue, 12 Mar 2002 06:34:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CEXtKL020801 for ; Tue, 12 Mar 2002 06:33:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11744 for ; Tue, 12 Mar 2002 06:33:56 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25390 for ; Tue, 12 Mar 2002 07:33:53 -0700 (MST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA04645; Tue, 12 Mar 2002 14:33:50 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: "Bound, Jim" Cc: "Yamasaki Toshi" , Subject: Re: PPP and Global Addresses References: <9C422444DE99BC46B3AD3C6EAFC9711B0152085D@tayexc13.americas.cpqcorp.net> From: Ole Troan Date: Tue, 12 Mar 2002 14:33:50 +0000 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0152085D@tayexc13.americas.cpqcorp.net> ("Bound, Jim"'s message of "Mon, 11 Mar 2002 12:49:59 -0500") Message-ID: <7t5sn753lf5.fsf@mrwint.cisco.com> Lines: 22 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim and all, [...] >> To achieve zero-configuration for "ISP-to-Customer (PE-to-CPE) >> prefix delegation", we had better have a global consensus about >> which mechanism is minimally required for this purpose. Many >> mechnisms for the same purpose will make it difficult to achieve >> zero-configuration enviroment, because CPE should know which to use >> before runnning an auto-configuration protocol among many choices. > > I agree but I believe we can have a stateless and stateful solution > for different needs. I think prefix delegation is inherently stateful. both DHCP PD and ICMP PD are as such stateful protocols. that is, the delegating party has to keep track of which prefixes are assigned where. if anyone disagrees, please explain where the statelessness comes into the picture. /ot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 07:04:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CF4nKL020985 for ; Tue, 12 Mar 2002 07:04:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CF4n3I020984 for ipng-dist; Tue, 12 Mar 2002 07:04:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CF4kKL020977 for ; Tue, 12 Mar 2002 07:04:46 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21727; Tue, 12 Mar 2002 07:04:45 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01109; Tue, 12 Mar 2002 08:04:43 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2CFAR203334; Tue, 12 Mar 2002 22:10:30 +0700 (ICT) From: Robert Elz To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Mar 2002 22:10:27 +0700 Message-ID: <3332.1015945827@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 12 Mar 2002 15:17:20 +0100 (CET) From: Erik Nordmark Message-ID: | The universal bit is defined in 2373bis (addr-arch-v3) to | apply to most of the address space, thus it is not tied to the link-layer | being Ethernet. And should be deleted from there before that draft goes anywhere. Pretending that a bit in the middle of the address can have any useful function this way is simply foolish. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 12 07:59:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CFxaKL021226 for ; Tue, 12 Mar 2002 07:59:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CFxa9I021225 for ipng-dist; Tue, 12 Mar 2002 07:59:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CFxXKL021218 for ; Tue, 12 Mar 2002 07:59:33 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA29960 for ; Tue, 12 Mar 2002 07:59:33 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA21941 for ; Tue, 12 Mar 2002 07:59:31 -0800 (PST) content-class: urn:content-classes:message Subject: RE: Next steps on Reserving bits in RFC 2473 Interface IDs? MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 12 Mar 2002 07:59:23 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C409@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next steps on Reserving bits in RFC 2473 Interface IDs? Thread-Index: AcHJteZQxTgo9u8RRvCdezd7pPOUJgAKM+cg From: "Michel Py" To: "Alexandru Petrescu" , "Robert Elz" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2CFxXKL021219 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Alexandru Petrescu wrote: >> I'm very curious if the suggested recommendation is really >> "no more than 64" or is it "exactly 64"? > kre wrote: > It is currently probably exactly 64 - but there's no > reason for that. Actually, there are, but I will not get into that again. "more than 64" is not even debatable. "exactly 64" is today's status for most IPv6 addresses. "no more than 64" has some good arguments for it, mostly the following one: > A link layer that doesn't have a use for all 64 bits > shouldn't be required to pad them for no reason This is especially true with NBMA technologies such as frame relay, when using the MAC address of e0 on s0 is not always the best thing to do. My take on it is: IPv6 over ethernet: stick to exactly /64. Probably for TR and FDDI too. IPv6 over foo: it might be desirable to get a lower value (make it fit on a nibble or byte boundary) _if_ accompanied by RFC2373 modifications or new text that define a fixed aggregation boundary for routing purposes. Subneting below /64 must have defined boundaries just like above /64. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 08:12:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CGCSKL021265 for ; Tue, 12 Mar 2002 08:12:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CGCSwY021264 for ipng-dist; Tue, 12 Mar 2002 08:12:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CGCPKL021257 for ; Tue, 12 Mar 2002 08:12:25 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA27054 for ; Tue, 12 Mar 2002 08:12:25 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24842 for ; Tue, 12 Mar 2002 08:12:25 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA01433; Tue, 12 Mar 2002 09:12:23 -0700 (MST)] Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA11692; Tue, 12 Mar 2002 09:12:20 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (8.11.6/8.11.6) with ESMTP id g2CGCGk16371; Tue, 12 Mar 2002 10:12:17 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id C8EF22EC83; Tue, 12 Mar 2002 17:12:14 +0100 (CET) To: Erik Nordmark Cc: Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: From: Alexandru Petrescu Date: 12 Mar 2002 17:12:14 +0100 In-Reply-To: Message-ID: Lines: 37 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Erik, I'll pick the gauntlet, with great care :-) Erik Nordmark writes: > > When other than Ethernet link layers are involved, probably the > > functionality of the u/g bits can be derived from the 8bit prefix? > > Maybe it's the 8bit prefix that should be tweaked to obtain the > > reservations proposed? > > Do you have a concrete proposal? You seem to imply that the u/g bits are there not because of Ethernet, then I can observe that: universal bit =1 has similar meaning to Prefix =001 group bit =1 has similar meaning to Prefix =1111 1111 Many other prefixes are unassigned and as such can serve the purpose of about anything. For example, Prefix 010 could mean randomly generated Interface ID's. When doing this, I think it would be good to extract the commonalities of the usage scenarios of the current proposals, see how they fit the current Prefixes and what are the additional criteria needed to classify them. For example, how can one classify a randomly generated Interface ID and a Cryptographically Generated Address? Random IID serves privacy. CGA serves authentication of something. Both are security, BUT random IID also serves certain types of L2's, nothing to do with security. Both are global unicast and are not group. Since I find the classification difficult I think I'll refrain from proposing anything serious. What do you think? Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 08:29:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CGTZKL021337 for ; Tue, 12 Mar 2002 08:29:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CGTZdd021336 for ipng-dist; Tue, 12 Mar 2002 08:29:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CGTWKL021329 for ; Tue, 12 Mar 2002 08:29:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA05838 for ; Tue, 12 Mar 2002 08:29:32 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA15240 for ; Tue, 12 Mar 2002 09:29:31 -0700 (MST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id JAA23926; Tue, 12 Mar 2002 09:27:22 -0700 (MST)] Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA02660; Tue, 12 Mar 2002 09:27:21 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id g2CGRGU25112; Tue, 12 Mar 2002 10:27:17 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id E42242EC85; Tue, 12 Mar 2002 17:27:06 +0100 (CET) To: "Michel Py" Cc: "Robert Elz", Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: <2B81403386729140A3A899A8B39B046406C409@server2000.arneill-py.sacramento.ca.us> From: Alexandru Petrescu Date: 12 Mar 2002 17:27:06 +0100 In-Reply-To: <2B81403386729140A3A899A8B39B046406C409@server2000.arneill-py.sacramento.ca.us> Message-ID: Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Michel Py" writes: > IPv6 over ethernet: stick to exactly /64. Probably for TR and FDDI > too. > IPv6 over foo: it might be desirable to get a lower value (make it > fit on a nibble or byte boundary) _if_ accompanied by RFC2373 > modifications or new text that define a fixed aggregation boundary > for routing purposes. I like these, FWIW. This would imply changes in the meanings of Prefix 001 and Prefix 000. I doubt the intended meaning can be to have Ethernet under Prefix 001 and all other L2's under Prefix 000. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 09:03:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CH36KL021408 for ; Tue, 12 Mar 2002 09:03:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CH36a8021407 for ipng-dist; Tue, 12 Mar 2002 09:03:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CH33KL021400 for ; Tue, 12 Mar 2002 09:03:03 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA13001 for ; Tue, 12 Mar 2002 09:03:03 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02550 for ; Tue, 12 Mar 2002 10:03:01 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2CH1kI22162; Tue, 12 Mar 2002 09:01:46 -0800 (PST) Message-ID: <009d01c1c9e7$5e76d900$7e6015ac@T23KEMPF> From: "James Kempf" To: "Erik Nordmark" , References: Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? Date: Tue, 12 Mar 2002 09:00:10 -0800 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, I might have missed this point, but let me ask the question just in case it hasn't been asked. One of the purposes of reserving this bit is to avoid "bidding down" attacks in Mobile IPv6 binding update security, whereby an attacker requests a less secure method so it can mount an attack. One issue that comes to mind is that, by reducing the size of the address space, a reserved bit essentially makes it easier for an attacker to randomly seek through the address space for addresses that aren't protected by the bit. I've not actually gone through an in-depth analysis of this, so the statistics may still put such search in the category of a hard problem, but nevertheless I think it needs some consideration (if it hasn't already had some). Has this been considered? jak ----- Original Message ----- From: "Erik Nordmark" To: Sent: Tuesday, March 12, 2002 12:55 AM Subject: Next steps on Reserving bits in RFC 2473 Interface IDs? > > A while back I sent an email to the list talking about > Reserving bits in RFC 2473 Interface IDs. > > Not much email has followed on this topic so it isn't clear whether > people are having too much fun debating other topics, think it is > a good/bad idea, or just don't care. > > I think our choices are: > 1. Do nothing > 2. Reserve a quarter of the IID space i.e. universal=1, group=1 becomes > explicitly reserved. > 3. Reserve half of the IID space i.e. all addresses with group=1 become > explicitly reserved. > > It would be good to try to make progress on the mailing list on this question > otherwise it's likely to appear on the agenda in the meetings next week :-) > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 12:18:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CKIDKL021841 for ; Tue, 12 Mar 2002 12:18:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CKICwH021840 for ipng-dist; Tue, 12 Mar 2002 12:18:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CKI7KL021833 for ; Tue, 12 Mar 2002 12:18:08 -0800 (PST) Received: from lillen (vpn-129-159-0-106.EMEA.Sun.COM [129.159.0.106]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2CKI1x20485; Tue, 12 Mar 2002 21:18:01 +0100 (MET) Date: Tue, 12 Mar 2002 21:12:42 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? To: James Kempf Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <009d01c1c9e7$5e76d900$7e6015ac@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > One of the purposes of reserving this bit is to avoid "bidding down" > attacks in Mobile IPv6 binding update security, whereby an attacker > requests a less secure method so it can mount an attack. One issue that > comes to mind is that, by reducing the size of the address space, a > reserved bit essentially makes it easier for an attacker to randomly > seek through the address space for addresses that aren't protected by > the bit. I've not actually gone through an in-depth analysis of this, so > the statistics may still put such search in the category of a hard > problem, but nevertheless I think it needs some consideration (if it > hasn't already had some). Sorry, wrong topic. The purpose of *reserving* the bit(s) is to leave the door open to assign the bit(s) to something, hopefully useful, in the future. It is true that a possible *use* of the bits in the future is avoiding bidding down attacks in MIPv6. As part of developping a proposal for that would presumably require the type of analysis that you are pointing out. But, as pointed out in my original email on the subject, any such proposal for *using* the reserved bits for something, would need to go through the normal IETF standards track process. Reserving the bits just requires the analysis whether the cost of carving off the bits is worth the potential benefits of being able to use them for something in the future. Is that more clear? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 12 15:57:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CNvJKL022092 for ; Tue, 12 Mar 2002 15:57:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2CNvJLH022091 for ipng-dist; Tue, 12 Mar 2002 15:57:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2CNvGKL022084 for ; Tue, 12 Mar 2002 15:57:16 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA04391 for ; Tue, 12 Mar 2002 15:57:16 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11370 for ; Tue, 12 Mar 2002 16:57:16 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2CNvFd07993; Tue, 12 Mar 2002 15:57:15 -0800 (PST) Received: from [171.71.118.51] (beeman-ncd.cisco.com [171.71.118.51]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACZ54288; Tue, 12 Mar 2002 15:56:23 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <200203111400.QAA09564@burp.tkv.asdf.org> References: <200203111400.QAA09564@burp.tkv.asdf.org> Date: Tue, 12 Mar 2002 15:57:11 -0800 To: Markku Savela From: Steve Deering Subject: Re: draft-ietf-ipngwg-addr-arch-v3-07.txt and FF00::/16 and FF0F::/16? Cc: ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:00 PM +0200 3/11/02, Markku Savela wrote: >What should I do with addresses starting with > > FF00::/16 > FF0F::/16 You are correct that the spec is silent on that, and ought to say something. Given the implied ordering of scope levels, I think the following rules would be reasonable (basically agreeing with you): packets sent to FF*0::/16 should be discarded (silently?) at the source and discarded silently if received. packets sent to FF*F/16 should be treated the same as global multicasts. 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 Mar 12 16:23:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2D0NLKL022215 for ; Tue, 12 Mar 2002 16:23:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2D0NLJH022214 for ipng-dist; Tue, 12 Mar 2002 16:23:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2D0NHKL022207 for ; Tue, 12 Mar 2002 16:23:17 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10129 for ; Tue, 12 Mar 2002 16:23:18 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA29874 for ; Tue, 12 Mar 2002 16:23:23 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2D0NGI08337; Tue, 12 Mar 2002 16:23:17 -0800 (PST) Message-ID: <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> From: "James Kempf" To: "Alexandru Petrescu" Cc: References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> Subject: Re: Securing Neighbor Discovery Date: Tue, 12 Mar 2002 16:21:39 -0800 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alex, Sorry its taken so long to get back to you. > The threat document points out valid security concerns with ND. IMHO, > some are easy to deal with and some other are harder, but in any case > not all require total application of the ABK mechanism, noting that > even if ABK's are applied some simple threats still hold. > Certainly agree. > Threat 3.1. Malicious Last Hop Router fools the victim into using it > as a default router. If the legitimate AR uses the ABK system then > the attacker AR can also use a similar ABK system, right? It might be > argued that the attacker AR can not communicate with the MN because it > can't be authenticated by the MN with an attacker NAS, fair enough. > But in that case, if the MN already shares a secret with the NAS, why > not using the same secret to authenticate the ND, thus questioning the > need for a more complex system. > The draft discusses two possible ways to use ABKs. One is based on an authenticated exchange between the network and the host, whereby the host proves its identity to the network and the network does the same for the host, and the network gives the host a private ABK to use. I believe this is what you are referring to above. This could be accomplished some other way, by having a session key with the router for example, but the advantage of ID-crypto is that there is no secret key held by the router which must be known to other routers in the event the node is mobile, or which must be periodically regenerated by the network to avoid compromise. The host's private key acts as the session key. The cryptoparameters are public so there is no need to worry about compromise. Also, of course, standard public key could be used, but in this case, a cert authority would be required (for a full blown PKI) or, at the minimum, the host would require some way to obtain the router's public key. If the public key is the subnet id, there is no requirement for this, and particularly if the host is mobile, this is very convenient. The other way that identity is proved is that the host and the network participate in a roaming consortium which supplies them with preconfigured cryptoparameters and private key. In this case, there is no need for an authentication exchange between the host and network for purposes of securing ND (there may be a need for other reasons). > Threat 3.2 Good Router Goes Bad is probably less particular to ND. > When good router goes bad it's too bad. > Yup. Nothing to do but have the network operator be vigilant for attacks. Certainly, not requiring the routers to have globally routable addresses (as IPv6 does) will help keep attacks to a minimum. > Threat 3.5 Bogus On-Link Prefix can be addressed by a smart legitimate > access router sending RA's with the attacker-prefix with lifetime 0. > A smart MN could even detect too many RA sequences > infinity-0-infinity-0 and consider that subnet unreliable. > Sure, but this is a more complicated solution that solves a single threat. And like Return Routabliltiy in Mobile IP, there may be subtle ways around it. > Threat 3.8 is not addressed by the ABK, I think. > You are right. If someone starts pumping packets at you, there is little you can do, except maybe to shut down ND for a bit and maybe arrange to find the perpetrator (it may just be buggy software). Also, Francis Dupont pointed out that, if cryptographic techniques (any techniques, not just ABK) are used in ND, then the process of address resolution will suffer a performance hit (exactly how bad depends, of course, on the implementation) and an attacker might exploit this to mount a DOS attack. So I agree that there are some problems that ABKs solve and some not. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 12 23:12:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2D7CmKL022626 for ; Tue, 12 Mar 2002 23:12:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2D7Cm6U022625 for ipng-dist; Tue, 12 Mar 2002 23:12:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2D7CjKL022618 for ; Tue, 12 Mar 2002 23:12:45 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12974 for ; Tue, 12 Mar 2002 23:12:46 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA08823 for ; Wed, 13 Mar 2002 00:12:45 -0700 (MST) content-class: urn:content-classes:message Subject: RE: Next steps on Reserving bits in RFC 2473 Interface IDs? MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Mar 2002 23:12:44 -0800 Message-ID: <2B81403386729140A3A899A8B39B046405DF15@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next steps on Reserving bits in RFC 2473 Interface IDs? Thread-Index: AcHJ4zLikqaTHWIRSnq8QsxUjV39gwAerInQ From: "Michel Py" To: "Alexandru Petrescu" Cc: "Robert Elz" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2D7CkKL022619 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Michel Py wrote: >> IPv6 over ethernet: stick to exactly /64. Probably for TR and >> FDDI too. >> IPv6 over foo: it might be desirable to get a lower value >> (make it fit on a nibble or byte boundary) _if_ accompanied >> by RFC2373 modifications or new text that define a fixed >> aggregation boundary for routing purposes. > Alexandru Petrescu wrote: > I like these, FWIW. This would imply changes in the meanings > of Prefix 001 and Prefix 000. I doubt the intended meaning > can be to have Ethernet under Prefix 001 and all other L2's > under Prefix 000. I think that it is all under 001. Allocating another 1/8th of the v6 address space (000) to save pennies on the 001 does not make a lot of sense to me. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 00:59:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2D8xXKL022805 for ; Wed, 13 Mar 2002 00:59:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2D8xXeg022804 for ipng-dist; Wed, 13 Mar 2002 00:59:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2D8xUKL022797 for ; Wed, 13 Mar 2002 00:59:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA19163 for ; Wed, 13 Mar 2002 00:59:30 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA03944 for ; Wed, 13 Mar 2002 01:59:29 -0700 (MST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id BAA13325; Wed, 13 Mar 2002 01:48:23 -0700 (MST)] Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id BAA09922; Wed, 13 Mar 2002 01:59:24 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (8.11.6/8.11.6) with ESMTP id g2D8xGl06862; Wed, 13 Mar 2002 02:59:20 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id E68772EC84; Wed, 13 Mar 2002 09:59:10 +0100 (CET) To: "Michel Py" Cc: "Robert Elz", Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: <2B81403386729140A3A899A8B39B046405DF15@server2000.arneill-py.sacramento.ca.us> From: Alexandru Petrescu Date: 13 Mar 2002 09:59:10 +0100 In-Reply-To: <2B81403386729140A3A899A8B39B046405DF15@server2000.arneill-py.sacramento.ca.us> Message-ID: Lines: 38 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Michel Py" writes: > >> Michel Py wrote: > >> IPv6 over ethernet: stick to exactly /64. Probably for TR and > >> FDDI too. > >> IPv6 over foo: it might be desirable to get a lower value > >> (make it fit on a nibble or byte boundary) _if_ accompanied > >> by RFC2373 modifications or new text that define a fixed > >> aggregation boundary for routing purposes. > > > Alexandru Petrescu wrote: > > I like these, FWIW. This would imply changes in the meanings > > of Prefix 001 and Prefix 000. I doubt the intended meaning > > can be to have Ethernet under Prefix 001 and all other L2's > > under Prefix 000. > > I think that it is all under 001. Allocating another 1/8th of > the v6 address space (000) to save pennies on the 001 does not > make a lot of sense to me. Right, that reservation is not reasonable. My remark with the 000 prefix relies on the fact that this prefix is the only one today loosening the 64 bit Interface ID length: "Global unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field." This is made explicit in several places in the draft and I was guessing that it is so in order to allow for other Interface ID's than those derived from Ethernet (and not only to accomodate v4 addresses) under prefix 000. Probably it makes more sense to loosen all constraints on the size or structure of the Interface ID field of a 001 Glocal Unicast Address other that it should not exceed 64 bits in length. And leave the 000 addresses for v4 only. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 01:52:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2D9qTKL022913 for ; Wed, 13 Mar 2002 01:52:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2D9qTgU022912 for ipng-dist; Wed, 13 Mar 2002 01:52:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2D9qQKL022905 for ; Wed, 13 Mar 2002 01:52:26 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA29194 for ; Wed, 13 Mar 2002 01:52:27 -0800 (PST) Received: from qwerty.ssvl.kth.se (qwerty.ssvl.kth.se [192.16.125.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA20397 for ; Wed, 13 Mar 2002 02:52:25 -0700 (MST) Received: from localhost (qwerty.ssvl.kth.se [127.0.0.1]) by qwerty.ssvl.kth.se (8.11.2/8.11.2) with ESMTP id g2D9pj911220; Wed, 13 Mar 2002 10:51:45 +0100 Date: Wed, 13 Mar 2002 10:51:45 +0100 (CET) From: Alberto Escudero-Pascual X-X-Sender: To: Erik Nordmark cc: James Kempf , Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I agree of the potencial benefits of reserving bits in the IID for future "useful" use in the future, specialy in the mobility area. In that sense, i will like any references to EUI-64 based identifiers and the use of u/l bit being removed from 2473 as being already a proposal for making use of one "bit". So my suggestion is option 4: to reserve u and g bits (call them something else, pls) and follow the normal IETF standards track process to decide the (how to) use of them. I want to stick to the question of Erik but i argue why nodes for example that want to use a privacy extension (RFC3041) have to indicate that their IID is not EUI-64 based and hence the use of the privacy extension is observable. /aep -- -------------------------------------------------------------------------- That you are not paranoid, it doesn't mean that they are not watching you! http://www.it.kth.se/~aep > The purpose of *reserving* the bit(s) is to leave the door open > to assign the bit(s) to something, hopefully useful, in the future. > But, as pointed out in my original email on the subject, any such proposal > for *using* the reserved bits for something, would need to go through > the normal IETF standards track process. > Reserving the bits just requires the analysis whether the cost of > carving off the bits is worth the potential benefits of being able to > use them for something in the future. > > Is that more clear? > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 02:41:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DAfGKL022982 for ; Wed, 13 Mar 2002 02:41:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DAfGVk022981 for ipng-dist; Wed, 13 Mar 2002 02:41:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DAfCKL022974 for ; Wed, 13 Mar 2002 02:41:13 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA07411 for ; Wed, 13 Mar 2002 02:41:14 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA19314 for ; Wed, 13 Mar 2002 03:41:13 -0700 (MST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id DAA28795; Wed, 13 Mar 2002 03:41:12 -0700 (MST)] Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id DAA12951; Wed, 13 Mar 2002 03:29:19 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (8.11.6/8.11.6) with ESMTP id g2DAf9k21633; Wed, 13 Mar 2002 04:41:10 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 0228B2EC83; Wed, 13 Mar 2002 11:41:06 +0100 (CET) To: "James Kempf" Cc: Subject: Re: Securing Neighbor Discovery References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> From: Alexandru Petrescu Date: 13 Mar 2002 11:40:56 +0100 In-Reply-To: <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> Message-ID: Lines: 33 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi James, After your reply, my expectations confirm more and more that this is very much of AAA and PANA issue, and much less of securing the ND. Simple intuition tells me that if AAA and PANA can help authenticate the access, then ND is subsequently secured. If I were to work on securing ND, I would leave the key obtention behind (be it AAA, IKE/JFK/LBJ, ABK, CGA) and concentrate on how AH and ESP are applied to ND messages and see with that how to solve the threat draft. I might have a look into that, probably. "James Kempf" writes: > > Threat 3.5 Bogus On-Link Prefix can be addressed by a smart legitimate > > access router sending RA's with the attacker-prefix with lifetime 0. > > A smart MN could even detect too many RA sequences > > infinity-0-infinity-0 and consider that subnet unreliable. > > Sure, but this is a more complicated solution that solves a single > threat. Yes, but depends on what complex means. Mathematical complexity, implementation complexity, society institutions complexity. > So I agree that there are some problems that ABKs solve and some > not. I think the ABKs have an important merit in that they let the system configure the address the way it wants, doesn't impose bits and bytes anywhere in the address. I still need to understand how this is done, it looks like magic to me :-) Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 03:21:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DBLiKL023062 for ; Wed, 13 Mar 2002 03:21:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DBLibP023061 for ipng-dist; Wed, 13 Mar 2002 03:21:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DBLfKL023054 for ; Wed, 13 Mar 2002 03:21:41 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA19429 for ; Wed, 13 Mar 2002 03:21:41 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17205 for ; Wed, 13 Mar 2002 03:21:39 -0800 (PST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g2DBLOZc029764; Wed, 13 Mar 2002 12:21:30 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g2DBLOof021870; Wed, 13 Mar 2002 13:21:24 +0200 (EET) Message-ID: <3C8F3634.DE2E59F2@lmf.ericsson.se> Date: Wed, 13 Mar 2002 13:21:24 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: James Kempf , ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alexandru Petrescu wrote: > After your reply, my expectations confirm more and more that this is > very much of AAA and PANA issue, and much less of securing the ND. > Simple intuition tells me that if AAA and PANA can help authenticate > the access, then ND is subsequently secured. Well... while I'm an AAA guy myself, I really don't wish we need to get AAA everywhere just to secure our LAN control signaling. I'd like to concetrate also on infrastructureless methods. > If I were to work on securing ND, I would leave the key obtention > behind (be it AAA, IKE/JFK/LBJ, ABK, CGA) and concentrate on how AH > and ESP are applied to ND messages and see with that how to solve the > threat draft. I might have a look into that, probably. This on the other hand is an interesting issue. We may be able to separate the keying part from the protection part, even if the keying would take place without an infrastructure as in CGA. E.g., a router could use the host's public CGA key to encrypt a session key which it sends to the host, and the host uses this key in AH/ESP to protect actual signaling. But the modifications necessary before ESP works well enough for ND are pretty interesting. The basic problem we need to deal with manually keyed ESP is dst address as a pointer to the SA; this needs to change if manual keying is to be used. Another basic problem is inability to use *any* IP-based key management protocol (including IKE) due to chicken-and-egg effect. A third problem is that when the ND protection gets host specific - as it should - we need some way of indicating individual SAs. Also, the above discussion indicates that if we are to secure ND, we need a requirements document first. It isn't clear to me whether everyone agrees that we need infrastructureless, infrastructure-based, manually keyed etc. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 05:51:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DDpbKL023221 for ; Wed, 13 Mar 2002 05:51:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DDpaGm023220 for ipng-dist; Wed, 13 Mar 2002 05:51:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DDpXKL023213 for ; Wed, 13 Mar 2002 05:51:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA27995; Wed, 13 Mar 2002 05:50:04 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14882; Wed, 13 Mar 2002 06:50:04 -0700 (MST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id GAA15714; Wed, 13 Mar 2002 06:50:03 -0700 (MST)] Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id GAA22763; Wed, 13 Mar 2002 06:50:02 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (8.11.6/8.11.6) with ESMTP id g2DCnsR23299; Wed, 13 Mar 2002 06:49:55 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id DCF0E2EC83; Wed, 13 Mar 2002 14:49:52 +0100 (CET) To: Francis Dupont Cc: Erik Nordmark, Subject: Re: Reserving bits in RFC 2473 Interface IDs? References: <200203060829.g268TXg12457@givry.rennes.enst-bretagne.fr> From: Alexandru Petrescu Date: 13 Mar 2002 14:49:52 +0100 In-Reply-To: Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alexandru Petrescu writes: > Francis Dupont writes: > > Have you read draft-dupont-ipv6-imei-00.txt? > > Hi Francis, thanks for putting the IMEI idea on paper, it's been long > expected by many circles. I have a remark below, please correct me if > I misunderstood the conversion. > > > The IMEI 330001 53 007826 gives the 0333:0001:5300:7826 (usually > > written 333:1:5300:7826) interface identifier. > > Since IMEI is represented in decimal and addresses in hexa, by doing > the above it effectively leads to impossibility of use of parts of > address space. I mean, all IMEI's can be represented into an IPv6 > Interface ID, but certain IPv6 Interface ID's will never have a > correspondent IMEI. Maybe better can be done. ...I would suggest re-phrasing the following: "The IMEI 330001 53 007826 gives the 0333:0001:5300:7826 (usually written 333:1:5300:7826) interface identifier." into: "For example, the IMEI 330001 53 007826 gives the Interface ID 300:6072:9ed2. The maximum IMEI 999999 99 999999 is Interface ID 5af3:107a:3fff. The space in the Interface ID starting at 5af3:107a:4000 inclusive and up to ffff:ffff:ffff inclusive can not represent an Interface ID derived from an IMEI." Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 06:00:16 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DE0GKL023280 for ; Wed, 13 Mar 2002 06:00:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DE0GYp023279 for ipng-dist; Wed, 13 Mar 2002 06:00:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DE0CKL023272 for ; Wed, 13 Mar 2002 06:00:12 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16039 for ; Wed, 13 Mar 2002 06:00:13 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05167 for ; Wed, 13 Mar 2002 06:00:12 -0800 (PST) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2DE01o44806; Wed, 13 Mar 2002 23:00:02 +0900 (JST) Date: Wed, 13 Mar 2002 23:00:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: sra@hactrn.net Cc: ipng@sunroof.eng.sun.com Subject: Re: PPP and Global Addresses In-Reply-To: <20020307192840.8782E1C7D@thrintun.hactrn.net> References: <4.3.2.7.2.20020307122231.00b74d78@funnel.cisco.com> <20020307192840.8782E1C7D@thrintun.hactrn.net> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 43 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (We should probably change the subject...) >>>>> On Thu, 07 Mar 2002 14:28:40 -0500, >>>>> Rob Austein said: > 2) While I applaud the ingenuity and enthusiasm of all the people who > have come up with interesting ways to configure things in the IPv6 > universe without using DHCP, I have yet to see any proposals as > simple as just using boring old DHCP for most of this stuff. We > have a pretty good understanding of how DHCP works and what's > required to support it (for some definition of "we" that may or may > not include the members of this WG, a subject on which I decline to > have a public opinion). Some of the proposals to replace DHCP, on > the other hand, are pretty far out on either the research or kludge > axes. While I am not in principle opposed to cool new stuff, I > don't think it's sound engineering to do new stuff just for the > sake of being different. Could you be more specific about the "new stuff", please? I agree that the "level 2 compliance" described in draft-ietf-ipv6-dns-discovery-04 can be called a "new stuff", but the level 1 compliance, which is now the only main part of the draft, needs almost nothing new. In particular, if we use unicast well-known addresses with the level 1 compliance (this will work in a small network such as a home network or a SO-HO office), we do not need new implementation. It's just a matter of configuration. I admit that DHCPv6 only with information resources is also simple. However, in order to apply DHCPv6 in the real network, we'll need - a DHCPv6 relay agent (basically) in every subnet, or - multicast routing when we use a well-known multicast addresses for DHCP servers I believe both of two can be a problem to deploy DHCPv6 which is not easy to deal with. That's one of the key reasons why the design team preferred the current approach to DHCPv6. (correct me if I'm wrong > other team members.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 13 06:39:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DEdaKL023344 for ; Wed, 13 Mar 2002 06:39:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DEdavN023343 for ipng-dist; Wed, 13 Mar 2002 06:39:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DEdXKL023336 for ; Wed, 13 Mar 2002 06:39:33 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03787 for ; Wed, 13 Mar 2002 06:39:35 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA18113 for ; Wed, 13 Mar 2002 06:39:34 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA15441; Wed, 13 Mar 2002 07:39:32 -0700 (MST)] Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA25912; Wed, 13 Mar 2002 07:39:31 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id g2DEdPU21027; Wed, 13 Mar 2002 08:39:28 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 629FA2EC84; Wed, 13 Mar 2002 15:39:20 +0100 (CET) To: Jari Arkko Cc: James Kempf, Subject: Re: Securing Neighbor Discovery References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> <3C8F3634.DE2E59F2@lmf.ericsson.se> From: Alexandru Petrescu Date: 13 Mar 2002 15:39:19 +0100 In-Reply-To: <3C8F3634.DE2E59F2@lmf.ericsson.se> Message-ID: Lines: 71 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari Arkko writes: > Well... while I'm an AAA guy myself, I really don't wish we need to > get AAA everywhere just to secure our LAN control signaling. I'd > like to concetrate also on infrastructureless methods. Using Radius to escape 802.11b weaknesses is deployable for small LANs, I think. > > If I were to work on securing ND, I would leave the key obtention > > behind (be it AAA, IKE/JFK/LBJ, ABK, CGA) and concentrate on how AH > > and ESP are applied to ND messages and see with that how to solve the > > threat draft. I might have a look into that, probably. > > This on the other hand is an interesting issue. We may be > able to separate the keying part from the protection part, This is as natural as it gets. > even if the keying would take place without an infrastructure > as in CGA. E.g., a router could use the host's public CGA > key to encrypt a session key which it sends to the host, and > the host uses this key in AH/ESP to protect actual signaling. Two things here. One is that CGAs and address ownership were born out of very remote interactions, like in MN-CN across the whole network, while ND is happening on a link among neighbours; as such I think the infrastructure-less and infrastructure-based arguments apply a little less. The other is that I like a more equipotential perspective in ND, e.g. in your above keying procedure, swap 'host' with 'router'; after all, routers also act as neighbours. I would also like this activity to be only a little part of a greater "Securing Neighbour Discovery". For example, RFC 3041 is already securing the ND somehow: it provides privacy when Ethernet is used. > But the modifications necessary before ESP works well enough for ND > are pretty interesting. The basic problem we need to deal with > manually keyed ESP is dst address as a pointer to the SA; this needs > to change if manual keying is to be used. Aha, I was thinking that manual keying will create an SA similar to the ones created by automatic keying, but I might be wrong. > Another basic problem is inability to use *any* IP-based key > management protocol (including IKE) due to chicken-and-egg effect. Aha, this is interesting. This is why we should probably not address it. Allow someone else to solve it :-) > A third problem is that when the ND protection gets host specific - > as it should - we need some way of indicating individual SAs. Should it or shouldn't it? I would say that hosts should protect from routers and routers should protect from hosts. And hosts should protect from hosts, but we should not look into routers protecting from routers. > Also, the above discussion indicates that if we are to secure ND, we > need a requirements document first. Things are quite simple here, I think. Many of the requirements are in the threats draft. > It isn't clear to me whether everyone agrees that we need > infrastructureless, infrastructure-based, manually keyed etc. I don't know either who agrees and who doesn't. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 06:55:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DEtcKL023446 for ; Wed, 13 Mar 2002 06:55:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DEtceF023445 for ipng-dist; Wed, 13 Mar 2002 06:55:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DEtZKL023438 for ; Wed, 13 Mar 2002 06:55:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA06877 for ; Wed, 13 Mar 2002 06:55:35 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA21422 for ; Wed, 13 Mar 2002 06:55:34 -0800 (PST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g2DEtOZc020565; Wed, 13 Mar 2002 15:55:29 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g2DEtOof005932; Wed, 13 Mar 2002 16:55:24 +0200 (EET) Message-ID: <3C8F685C.65167ECA@lmf.ericsson.se> Date: Wed, 13 Mar 2002 16:55:24 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: James Kempf , ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> <3C8F3634.DE2E59F2@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alexandru Petrescu wrote: > Two things here. One is that CGAs and address ownership were born out > of very remote interactions, like in MN-CN across the whole network, > while ND is happening on a link among neighbours; as such I think the > infrastructure-less and infrastructure-based arguments apply a little > less. True (OTOH, other things being equal configuration-less and infrastructure-less is better). > > But the modifications necessary before ESP works well enough for ND > > are pretty interesting. The basic problem we need to deal with > > manually keyed ESP is dst address as a pointer to the SA; this needs > > to change if manual keying is to be used. > > Aha, I was thinking that manual keying will create an SA similar to > the ones created by automatic keying, but I might be wrong. They can be similar, but my point was that if you use manual keying you don't want to create a million SAs, while with dynamic keying you could in theory do that. > > A third problem is that when the ND protection gets host specific - > > as it should - we need some way of indicating individual SAs. > > Should it or shouldn't it? I would say that hosts should protect from > routers and routers should protect from hosts. And hosts should > protect from hosts, but we should not look into routers protecting > from routers. Yes... I meant that it isn't sufficient for the whole network to be secured with a single key. This would be possible with a small extension of IPsec (e.g. standardized SPI value for ND protection), but wouldn't work in public LANs. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 06:59:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DExvKL023478 for ; Wed, 13 Mar 2002 06:59:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DExvCN023477 for ipng-dist; Wed, 13 Mar 2002 06:59:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DExrKL023470 for ; Wed, 13 Mar 2002 06:59:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24935 for ; Wed, 13 Mar 2002 06:59:50 -0800 (PST) Received: from qwerty.ssvl.kth.se (qwerty.ssvl.kth.se [192.16.125.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA23766 for ; Wed, 13 Mar 2002 07:59:48 -0700 (MST) Received: from localhost (qwerty.ssvl.kth.se [127.0.0.1]) by qwerty.ssvl.kth.se (8.11.2/8.11.2) with ESMTP id g2DEsv913384; Wed, 13 Mar 2002 15:54:57 +0100 Date: Wed, 13 Mar 2002 15:54:57 +0100 (CET) From: Alberto Escudero-Pascual X-X-Sender: To: Alexandru Petrescu cc: Francis Dupont , Erik Nordmark , Subject: Re: Reserving bits in RFC 2473 Interface IDs? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As part of the IMEI the first two digits include the country of approval (33 for France for example) or the manufacturer. I will like to see alternatives that protect possible personal identifiable information. A message digest of the (IMEI, Nonce) will theoretically make use of all parts of space and will provide unlinkability between IPv6 global addresses and certain devices, what imho is highly recommendable. /aep 1.2 On 13 Mar 2002, Alexandru Petrescu wrote: > Alexandru Petrescu writes: > > Francis Dupont writes: > > > Have you read draft-dupont-ipv6-imei-00.txt? > > > > Hi Francis, thanks for putting the IMEI idea on paper, it's been long > > expected by many circles. I have a remark below, please correct me if > > I misunderstood the conversion. > > > > > The IMEI 330001 53 007826 gives the 0333:0001:5300:7826 (usually > > > written 333:1:5300:7826) interface identifier. > > > > Since IMEI is represented in decimal and addresses in hexa, by doing > > the above it effectively leads to impossibility of use of parts of > > address space. I mean, all IMEI's can be represented into an IPv6 > > Interface ID, but certain IPv6 Interface ID's will never have a > > correspondent IMEI. Maybe better can be done. > > ...I would suggest re-phrasing the following: > > "The IMEI 330001 53 007826 gives the 0333:0001:5300:7826 (usually > written 333:1:5300:7826) interface identifier." > > into: > > "For example, the IMEI 330001 53 007826 gives the Interface ID > 300:6072:9ed2. The maximum IMEI 999999 99 999999 is Interface ID > 5af3:107a:3fff. The space in the Interface ID starting at > 5af3:107a:4000 inclusive and up to ffff:ffff:ffff inclusive can > not represent an Interface ID derived from an IMEI." > > Alex > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- -------------------------------------------------------------------------- That you are not paranoid, it doesn't mean that they are not watching you! http://www.it.kth.se/~aep -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 07:00:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DF0JKL023488 for ; Wed, 13 Mar 2002 07:00:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DF0IHT023487 for ipng-dist; Wed, 13 Mar 2002 07:00:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DF0DKL023480 for ; Wed, 13 Mar 2002 07:00:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA14072 for ; Wed, 13 Mar 2002 07:00:01 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09267 for ; Wed, 13 Mar 2002 08:00:00 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2DExto45189; Wed, 13 Mar 2002 23:59:55 +0900 (JST) Date: Wed, 13 Mar 2002 23:59:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Lilian Fernandes Cc: ipng@sunroof.eng.sun.com Subject: Re: IPV6_JOIN_GROUP for v4 multicast In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 32 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 11 Mar 2002 14:32:31 -0600 (CST), >>>>> Lilian Fernandes said: > The advanced API does not address this yet....is there any way at all to > currently join an IPv4 multicast group on an AF_INET6 socket? There's no such a *standardized* way, as far as I know. > Or do applications need to open a separate AF_INET socket to join v4 > groups? If you want portability, I believe the answer is yes. I'm even not sure if we really should allow the usage of IPv4-mapped-multicast. We had a very heated discussion even for unicast addresses, and we were almost not able to reach consensus. At that time, one of main arguments to support the usage of IPv4-mapped addresses was existing implementations and easy-porting of widely-deployed unicast IPv4 applications. I don't believe the argument buys that much for multicast addresses/applications. In any case, I don't think the advanced API is a suitable place to define such a stuff. Since the basic API defines both IPV6_JOIN_GROUP and the usage of IPv4-mapped(-unicast) addresses, the appropriate document would also be the basic API spec, *if we'd ever need to standardize that*. We should not use the advanced API as a kitchen sink for arbitrary extensions. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 13 07:22:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DFM5KL023569 for ; Wed, 13 Mar 2002 07:22:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DFM5W8023568 for ipng-dist; Wed, 13 Mar 2002 07:22:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DFM1KL023561 for ; Wed, 13 Mar 2002 07:22:02 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA20358 for ; Wed, 13 Mar 2002 07:22:01 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA00511 for ; Wed, 13 Mar 2002 07:22:01 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA26805; Wed, 13 Mar 2002 08:21:55 -0700 (MST)] Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA29315; Wed, 13 Mar 2002 08:21:53 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id g2DFLQa21521; Wed, 13 Mar 2002 08:21:27 -0700 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id D254A2EC83; Wed, 13 Mar 2002 16:21:42 +0100 (CET) To: Alberto Escudero-Pascual Cc: Francis Dupont, Erik Nordmark, Subject: Re: Reserving bits in RFC 2473 Interface IDs? References: From: Alexandru Petrescu Date: 13 Mar 2002 16:21:42 +0100 In-Reply-To: Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alberto Escudero-Pascual writes: > As part of the IMEI the first two digits include the country of approval > (33 for France for example) or the manufacturer. Aha, that's bad. This 33 looks a lot like France's prefix, so I suppose US has 1, Luxembourg has 352. The question is: is the IMEI length variable? Adding new countries or manufacturers will exceed the IMEI one day? It's certainly not desirable to have this exceed the Interface ID derived from IMEIs. > I will like to see alternatives that protect possible personal > identifiable information. Let's come up with a first derivation that gives a fixed-length Interface ID from IMEI and then randomize it for those who desire privacy, what do you think? > A message digest of the (IMEI, Nonce) will theoretically make use of > all parts of space and will provide unlinkability between IPv6 > global addresses and certain devices, what imho is highly > recommendable. I think that what you propose does not give privacy. The hash you propose will stay un-changed and someone can identify that the same person that bought a CD yesterday, bought an MD today. So what. What do you think? Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 07:23:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DFNVKL023586 for ; Wed, 13 Mar 2002 07:23:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DFNVoD023585 for ipng-dist; Wed, 13 Mar 2002 07:23:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DFNSKL023578 for ; Wed, 13 Mar 2002 07:23:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA13403 for ; Wed, 13 Mar 2002 07:23:28 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA03127 for ; Wed, 13 Mar 2002 08:23:26 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA12510; Wed, 13 Mar 2002 17:23:08 +0200 Date: Wed, 13 Mar 2002 17:23:08 +0200 Message-Id: <200203131523.RAA12510@burp.tkv.asdf.org> From: Markku Savela To: Jari.Arkko@lmf.ericsson.se CC: petrescu@crm.mot.com, kempf@docomolabs-usa.com, ipng@sunroof.eng.sun.com In-reply-to: <3C8F685C.65167ECA@lmf.ericsson.se> (message from Jari Arkko on Wed, 13 Mar 2002 16:55:24 +0200) Subject: Re: Securing Neighbor Discovery References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> <3C8F3634.DE2E59F2@lmf.ericsson.se> <3C8F685C.65167ECA@lmf.ericsson.se> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Jari Arkko > > They can be similar, but my point was that if you use manual > keying you don't want to create a million SAs, while with > dynamic keying you could in theory do that. One could consider a special "helper" application/daemon, which would input from user (configuration) single manual key, and then would generate and install the necessary from SA's for the ND protection (I suspect this "daemon" would need to be constantly running, as SA's may be needed dynamically. Perhaps it could be an additional IPSEC key manager (which is at least possible with PF_KEY architecture, e.g. multiple key managements) One could have "secure virtual home WLAN" this way, as all ND would be protected by this key which is only configured to your own machines at home (or at any closed group wanting privacy over WLAN). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 07:32:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DFWEKL023629 for ; Wed, 13 Mar 2002 07:32:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DFWEoX023628 for ipng-dist; Wed, 13 Mar 2002 07:32:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DFWAKL023621 for ; Wed, 13 Mar 2002 07:32:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA16004 for ; Wed, 13 Mar 2002 07:32:11 -0800 (PST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07116 for ; Wed, 13 Mar 2002 08:32:10 -0700 (MST) Received: from inrialpes.fr (glandon.inrialpes.fr [194.199.24.105]) by ebene.inrialpes.fr (8.11.6/8.11.6) with ESMTP id g2DFVaQ00592; Wed, 13 Mar 2002 16:31:36 +0100 (MET) Message-ID: <3C8F70D9.ADD71E6D@inrialpes.fr> Date: Wed, 13 Mar 2002 16:31:37 +0100 From: Claude Castelluccia X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.8 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Alexandru Petrescu CC: Alberto Escudero-Pascual , Francis Dupont , Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: Reserving bits in RFC 2473 Interface IDs? References: Content-Type: multipart/alternative; boundary="------------7C309261506E9B2FADD1AE89" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------7C309261506E9B2FADD1AE89 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote: > > > A message digest of the (IMEI, Nonce) will theoretically make use of > > all parts of space and will provide unlinkability between IPv6 > > global addresses and certain devices, what imho is highly > > recommendable. > > I think that what you propose does not give privacy. The hash you > propose will stay un-changed and someone can identify that the same > person that bought a CD yesterday, bought an MD today. So what. > > What do you think? > you should probably change your address periodically (as suggested in RFC3041) by using a different nonce.... Claude. > > Alex > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------7C309261506E9B2FADD1AE89 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Alexandru Petrescu wrote:
 
> A message digest of the (IMEI, Nonce) will theoretically make use of
> all parts of space and will provide unlinkability between IPv6
> global addresses and certain devices, what imho is highly
> recommendable.

I think that what you propose does not give privacy.  The hash you
propose will stay un-changed and someone can identify that the same
person that bought a CD yesterday, bought an MD today.  So what.

What do you think?
 

you should probably change your address periodically (as suggested in RFC3041)
by using a different nonce....

Claude.

 
Alex

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                     http://playground.sun.com/ipng
FTP archive:                     ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------7C309261506E9B2FADD1AE89-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 07:54:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DFsTKL023659 for ; Wed, 13 Mar 2002 07:54:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DFsTeo023658 for ipng-dist; Wed, 13 Mar 2002 07:54:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DFsQKL023651 for ; Wed, 13 Mar 2002 07:54:26 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA19627 for ; Wed, 13 Mar 2002 07:54:26 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26755 for ; Wed, 13 Mar 2002 08:54:26 -0700 (MST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA29380; Wed, 13 Mar 2002 08:54:17 -0700 (MST)] Received: [from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id IAA03033; Wed, 13 Mar 2002 08:54:15 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr03.mot.com (8.11.6/8.11.6) with ESMTP id g2DFs5A16113; Wed, 13 Mar 2002 09:54:05 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id F01BF2EC83; Wed, 13 Mar 2002 16:54:01 +0100 (CET) To: Claude Castelluccia Cc: Alberto Escudero-Pascual, Francis Dupont, Erik Nordmark, Subject: Re: Reserving bits in RFC 2473 Interface IDs? References: <3C8F70D9.ADD71E6D@inrialpes.fr> From: Alexandru Petrescu Date: 13 Mar 2002 16:54:01 +0100 In-Reply-To: <3C8F70D9.ADD71E6D@inrialpes.fr> Message-ID: Lines: 16 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Claude Castelluccia writes: > > > A message digest of the (IMEI, Nonce) will theoretically make use of > > > all parts of space and will provide unlinkability between IPv6 > > > global addresses and certain devices, what imho is highly > > > recommendable. > > > > I think that what you propose does not give privacy. The hash you > > propose will stay un-changed and someone can identify that the same > > person that bought a CD yesterday, bought an MD today. So what. > > you should probably change your address periodically (as suggested > in RFC3041) by using a different nonce.... Right, I missed the nonce meaning. I guess Alberto meant just that. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 10:15:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DIFLKL024015 for ; Wed, 13 Mar 2002 10:15:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DIFL6W024014 for ipng-dist; Wed, 13 Mar 2002 10:15:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DIFIKL024007 for ; Wed, 13 Mar 2002 10:15:18 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13306 for ; Wed, 13 Mar 2002 10:15:20 -0800 (PST) Received: from gau.lava.net (gau.lava.net [64.65.64.28]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02862 for ; Wed, 13 Mar 2002 10:15:24 -0800 (PST) Received: from malasada.lava.net ([64.65.64.17]) (3407 bytes) by gau.lava.net; Wed, 13 Mar 2002 08:15:15 -1000 (HST) via sendmail [esmtp] id for Date: Wed, 13 Mar 2002 08:15:14 -1000 (HST) From: Antonio Querubin To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Lilian Fernandes , Subject: Re: IPV6_JOIN_GROUP for v4 multicast In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 13 Mar 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >>>>> On Mon, 11 Mar 2002 14:32:31 -0600 (CST), > >>>>> Lilian Fernandes said: > > > The advanced API does not address this yet....is there any way at all to > > currently join an IPv4 multicast group on an AF_INET6 socket? > > There's no such a *standardized* way, as far as I know. This is correct and the lack of a standard for dealing with it is the problem. But as has been noted through practical experience by some, it would be extremely convenient if it were. A goal of the APIs was to make simpler the transition to IPv6 for existing programs. That seems to have worked for the unicast case but the lack of a similar standard works against multicast programmers. > > Or do applications need to open a separate AF_INET socket to join v4 > > groups? > > If you want portability, I believe the answer is yes. > > I'm even not sure if we really should allow the usage of > IPv4-mapped-multicast. We had a very heated discussion even for > unicast addresses, and we were almost not able to reach consensus. At > that time, one of main arguments to support the usage of IPv4-mapped > addresses was existing implementations and easy-porting of > widely-deployed unicast IPv4 applications. I don't believe the > argument buys that much for multicast addresses/applications. And I would suggest that the same arguments still apply to multicast addresses as well. Otherwise this topic would not keep reappearing. If as you say, the arguments don't buy much for multicast addresses/applications then wouldn't those same arguments also not buy much for unicast addresses? I think many programmers would agree that the API makes it relatively simple to enable IPv6 in their existing unicast applications. So I'm having a difficult time understanding why such arguments would inherently not apply to multicast as well or why multicast should be treated noticeably differently than unicast in the API. > In any case, I don't think the advanced API is a suitable place to > define such a stuff. Since the basic API defines both IPV6_JOIN_GROUP > and the usage of IPv4-mapped(-unicast) addresses, the appropriate > document would also be the basic API spec, *if we'd ever need to > standardize that*. We should not use the advanced API as a kitchen > sink for arbitrary extensions. I agree. However, when I proposed wording to include a provision for this in the updated basic API, I think it unfortunately came a little too late. So someone then suggested that this be handled in the advanced API instead. If you're suggesting that's no longer a good place for this then do you have an alternative suggestion? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 10:23:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DINmKL024058 for ; Wed, 13 Mar 2002 10:23:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DINmMY024057 for ipng-dist; Wed, 13 Mar 2002 10:23:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DINjKL024050 for ; Wed, 13 Mar 2002 10:23:45 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17452 for ; Wed, 13 Mar 2002 10:23:45 -0800 (PST) Received: from thrintun.hactrn.net (dsl092-066-067.bos1.dsl.speakeasy.net [66.92.66.67]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20483 for ; Wed, 13 Mar 2002 10:23:44 -0800 (PST) Received: from thrintun.hactrn.net (localhost [127.0.0.1]) by thrintun.hactrn.net (Postfix) with ESMTP id 7A23B1C7D for ; Wed, 13 Mar 2002 13:23:39 -0500 (EST) Date: Wed, 13 Mar 2002 13:23:39 -0500 From: Rob Austein To: ipng@sunroof.eng.sun.com Reply-To: ipng@sunroof.eng.sun.com Subject: Re: PPP and Global Addresses In-Reply-To: References: <4.3.2.7.2.20020307122231.00b74d78@funnel.cisco.com> <20020307192840.8782E1C7D@thrintun.hactrn.net> User-Agent: Wanderlust/2.4.1 (Stand By Me) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.7 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Message-Id: <20020313182339.7A23B1C7D@thrintun.hactrn.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The level 1 compliance stuff is only simple in the case of a single subnet. As soon as you have routers between the client and the server, you have to do something to get the packets across the router. I suppose we could have a discussion about whether magic unicast addresses (which are really a limited special case of anycast) are better or worse than multicast, but I doubt that such a discussion would change any minds. The place where I do see a real difference is that draft-ietf-ipv6-dns-discovery-04 tacks new functions (service discovery and configuration) onto DNS. DNS was not really designed for this, and while it's certainly possible (RFC-1925 2.(3)) I think it's better to use a protocol that was designed for these tasks, particularly if by doing so one also builds an infrastructure that makes it easier to solve other problems (eg, configuring NTP). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 10:35:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DIZdKL024161 for ; Wed, 13 Mar 2002 10:35:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DIZcX0024160 for ipng-dist; Wed, 13 Mar 2002 10:35:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DIZZKL024153 for ; Wed, 13 Mar 2002 10:35:35 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA08371 for ; Wed, 13 Mar 2002 10:35:35 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18905 for ; Wed, 13 Mar 2002 10:35:35 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DIZWI01029; Wed, 13 Mar 2002 10:35:32 -0800 (PST) Message-ID: <018501c1cabd$a228d820$7e6015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , "Alexandru Petrescu" Cc: References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> <3C8F3634.DE2E59F2@lmf.ericsson.se> Subject: Re: Securing Neighbor Discovery Date: Wed, 13 Mar 2002 10:33:55 -0800 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex/Jari > > After your reply, my expectations confirm more and more that this is > > very much of AAA and PANA issue, and much less of securing the ND. > > Simple intuition tells me that if AAA and PANA can help authenticate > > the access, then ND is subsequently secured. > Not necessarily. As the ND threats draft I believe mentions, a fully authenticated node might decide to start playing the trickster, snooping traffic, etc. Cryptographic security on ND messaging helps prevent that. All AAA does is authenticate at the time of network entry, that the host is authorized to use the network, and provide the host with whatever it needs to have access. It doesn't prevent subsequent misbehavior. > > If I were to work on securing ND, I would leave the key obtention > > behind (be it AAA, IKE/JFK/LBJ, ABK, CGA) and concentrate on how AH > > and ESP are applied to ND messages and see with that how to solve the > > threat draft. I might have a look into that, probably. > > This on the other hand is an interesting issue. We may be > able to separate the keying part from the protection part, > even if the keying would take place without an infrastructure > as in CGA. E.g., a router could use the host's public CGA > key to encrypt a session key which it sends to the host, and > the host uses this key in AH/ESP to protect actual signaling. > > But the modifications necessary before ESP works well > enough for ND are pretty interesting. The basic problem > we need to deal with manually keyed ESP is dst address > as a pointer to the SA; this needs to change if manual > keying is to be used. Another basic problem is inability > to use *any* IP-based key management protocol (including > IKE) due to chicken-and-egg effect. A third problem > is that when the ND protection gets host specific - > as it should - we need some way of indicating individual > SAs. > Right, these are all issues the ABK draft was written to help solve, and CGAs might work here as well. > Also, the above discussion indicates that if we are > to secure ND, we need a requirements document first. > It isn't clear to me whether everyone agrees that we > need infrastructureless, infrastructure-based, manually > keyed etc. > Good point. My intention here is fairly practical. Public access 802.11 networks today are very insecure on the last hop. If you look at Mobile Star's (an 802.11 public access network provider) page, they basically say you are on your own as far as security goes. For purposes of providing the kind of secure wireless ISP service that people expect, I think we need a solution to this problem, and fairly soon. So, while I want a good, scalable technical solution, I am not particularly religious about what form the solution takes. ABKs have a kind of technical elegance IMHO (as do CGAs in their own way), but if we can make things work with IPsec then I'm certainly not averse to doing it. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 10:43:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DIhaKL024196 for ; Wed, 13 Mar 2002 10:43:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DIhadK024195 for ipng-dist; Wed, 13 Mar 2002 10:43:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DIhWKL024188 for ; Wed, 13 Mar 2002 10:43:32 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23032 for ; Wed, 13 Mar 2002 10:43:33 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05711 for ; Wed, 13 Mar 2002 10:43:37 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DIhTI01321; Wed, 13 Mar 2002 10:43:29 -0800 (PST) Message-ID: <019101c1cabe$be972ce0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" , "Alexandru Petrescu" Cc: References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF><036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> <3C8F3634.DE2E59F2@lmf.ericsson.se> Subject: Re: Securing Neighbor Discovery Date: Wed, 13 Mar 2002 10:41:53 -0800 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alex/Jari, > I would also like this activity to be only a little part of a greater > "Securing Neighbour Discovery". For example, RFC 3041 is already > securing the ND somehow: it provides privacy when Ethernet is used. > RFC 3041 has a "security by obscurity" facet to it. It really isn't security, it's more address privacy. > > Another basic problem is inability to use *any* IP-based key > > management protocol (including IKE) due to chicken-and-egg effect. > > Aha, this is interesting. This is why we should probably not address > it. Allow someone else to solve it :-) > Well, this is where L2 AAA might come in. Or the use of preconfigured keys via a roaming agreement. Things get easier if you build on existing business relationships and technical infrastructure between ISPs. > > A third problem is that when the ND protection gets host specific - > > as it should - we need some way of indicating individual SAs. > > Should it or shouldn't it? I would say that hosts should protect from > routers and routers should protect from hosts. And hosts should > protect from hosts, but we should not look into routers protecting > from routers. > Isn't the issue here the same as in the CN/MN SA problem with BUs? Why should two hosts on a link have to establish an IPsec SA in order to secure their ND signaling? > > It isn't clear to me whether everyone agrees that we need > > infrastructureless, infrastructure-based, manually keyed etc. > Well, I do care in so far as I want the solution to work within the existing ISP infrastructure as much as possible. I'm primarily concerned with trying to secure soon-to-be deployed wireless public access networks. There are existing trust relationships that can be leveraged to make solving the problem alot easier than those involved in the MIP BU security problem. In that case, there is no a priori trust relationship between the players to leverage. So while an infrastructureless solution is certainly not without its attractions, I think the constraints on the problem are such that it might not be necessary. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 10:43:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DIhmKL024206 for ; Wed, 13 Mar 2002 10:43:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DIhlUv024205 for ipng-dist; Wed, 13 Mar 2002 10:43:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DIhiKL024198 for ; Wed, 13 Mar 2002 10:43:44 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA10642 for ; Wed, 13 Mar 2002 10:43:44 -0800 (PST) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA28441 for ; Wed, 13 Mar 2002 10:43:43 -0800 (PST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g2DIhhd01483; Wed, 13 Mar 2002 10:43:43 -0800 (PST) Received: from [10.34.255.54] ([10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ACZ72036; Wed, 13 Mar 2002 10:42:50 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: References: Date: Wed, 13 Mar 2002 10:43:40 -0800 To: Alberto Escudero-Pascual From: Steve Deering Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? Cc: Erik Nordmark , Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:51 AM +0100 3/13/02, Alberto Escudero-Pascual wrote: >I want to stick to the question of Erik but i argue why nodes for example >that want to use a privacy extension (RFC3041) have to indicate that their >IID is not EUI-64 based and hence the use of the privacy extension is >observable. Alberto, The u bit in the current IID definition indicates whether or not the IID can be considered globally unique. The zero value (implying *not* globally unique) is used not only for randomly-generated ("privacy") IIDs but also for manually-assigned IIDs, and IIDs assigned via DHCP that are not derived from the node's IEEE-802 or EUI-64 address. In other words, u=0 does *not* mean randomly generated; it means not- globally-unique. 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 Mar 13 11:35:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DJZbKL024354 for ; Wed, 13 Mar 2002 11:35:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DJZbTI024353 for ipng-dist; Wed, 13 Mar 2002 11:35:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DJZWKL024343 for ; Wed, 13 Mar 2002 11:35:32 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA26863 for ; Wed, 13 Mar 2002 11:35:33 -0800 (PST) Received: from roll.mentat.com ([192.88.122.129]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24858 for ; Wed, 13 Mar 2002 11:35:37 -0800 (PST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA26111; Wed, 13 Mar 2002 11:35:44 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id LAA02173; Wed, 13 Mar 2002 11:35:44 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id LAA17665; Wed, 13 Mar 2002 11:37:53 -0800 (PST) Date: Wed, 13 Mar 2002 11:37:53 -0800 (PST) From: Tim Hartrick Message-Id: <200203131937.LAA17665@feller.mentat.com> To: lilianf@austin.ibm.com, jinmei@isl.rdc.toshiba.co.jp Subject: Re: IPV6_JOIN_GROUP for v4 multicast Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk All, > > In any case, I don't think the advanced API is a suitable place to > define such a stuff. Since the basic API defines both IPV6_JOIN_GROUP > and the usage of IPv4-mapped(-unicast) addresses, the appropriate > document would also be the basic API spec, *if we'd ever need to > standardize that*. We should not use the advanced API as a kitchen > sink for arbitrary extensions. > I agree with this last sentence. Both the API documents should be put to bed. If changes need to be made to them POSIX or X/Open or some other group should be tasked to handle it. If new features must be documented within this group then they should be put into a new document which does not obsolete the existing API documents but merely adds to or clarifies functionality. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 13 12:02:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DK2HKL024389 for ; Wed, 13 Mar 2002 12:02:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DK2Hq8024388 for ipng-dist; Wed, 13 Mar 2002 12:02:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DK2DKL024381 for ; Wed, 13 Mar 2002 12:02:13 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA24110 for ; Wed, 13 Mar 2002 12:02:14 -0800 (PST) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA01833 for ; Wed, 13 Mar 2002 12:02:17 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA00982; Wed, 13 Mar 2002 13:02:09 -0700 (MST)] Received: [from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id NAA25024; Wed, 13 Mar 2002 13:02:08 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr01.mot.com (8.11.6/8.11.6) with ESMTP id g2DJ22R19576; Wed, 13 Mar 2002 13:02:03 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id BAF132EC83; Wed, 13 Mar 2002 21:02:00 +0100 (CET) To: Steve Deering Cc: Alberto Escudero-Pascual, Erik Nordmark, Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: From: Alexandru Petrescu Date: 13 Mar 2002 21:02:00 +0100 In-Reply-To: Message-ID: Lines: 59 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering writes: > The u bit in the current IID definition indicates whether or not the > IID can be considered globally unique. I'm trying to fit the IMEI into one of: Links or Nodes with IEEE EUI-64 Identifiers Links or Nodes with IEEE 802 48 bit MAC's Links with Non-Global Identifiers Links without Identifiers and I can not fit into any, since it looks than an IMEI is global but is neither an EUI-64 identifier, nor an IEEE 802 48 MAC address. However, the link can not be considered as a link without identifiers[*]. IMEI being global I'm tempted to touch the u bit (universal/local). IMEI has nothing in it that could influence the g bit (individual/group), but further investigation is necessary probably. Alex [*] or can it? I guess that phones have IMEI's but their peers at the other end of the link (GSNS/SGNS) don't. When trying to code other identifiers into Modified EUI-64, I wonder whether the individial/group bit should also be set/reset, in addition to the universal/local bit. Also, why EUI-64 was adopted as basis and not any other? I understand that this easily covers 802 LAN's, but why not something more agnostic like If it was chosen as the preferred coding for Interface ID's for global unicast addresses, and as such as an umbrella for other identifiers, was I understand that Modified EUI-64 is to be used with all global unicast addresses The zero value (implying *not* > globally unique) is used not only for randomly-generated ("privacy") > IIDs but also for manually-assigned IIDs, and IIDs assigned via DHCP > that are not derived from the node's IEEE-802 or EUI-64 address. In > other words, u=0 does *not* mean randomly generated; it means not- > globally-unique. > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 12:57:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DKvMKL024484 for ; Wed, 13 Mar 2002 12:57:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DKvMh5024483 for ipng-dist; Wed, 13 Mar 2002 12:57:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DKvJKL024476 for ; Wed, 13 Mar 2002 12:57:19 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA19498 for ; Wed, 13 Mar 2002 12:57:20 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16833 for ; Wed, 13 Mar 2002 12:57:09 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id WAA12868; Wed, 13 Mar 2002 22:56:58 +0200 Date: Wed, 13 Mar 2002 22:56:58 +0200 Message-Id: <200203132056.WAA12868@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com In-reply-to: <200203131523.RAA12510@burp.tkv.asdf.org> (message from Markku Savela on Wed, 13 Mar 2002 17:23:08 +0200) Subject: Re: Securing Neighbor Discovery References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> <3C8F3634.DE2E59F2@lmf.ericsson.se> <3C8F685C.65167ECA@lmf.ericsson.se> <200203131523.RAA12510@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This might belong to IPSEC list, but just give a concrete idea about it, here is a solution sketch... Securing ND with existing IPSEC (kernel) only needs to agree on specific SPI to use and, assuming a special key management daemon, which would do the following tasks - inputs "lan key from as configuration". All generated SA's use this (or something derived from it deterministically) - automaticly installs following SA's 1) one SA for well known multicast addresses: spi=1 dst=ff02::1 src=any protocol=any spi=1 dst=ff02::2 src=any protocol=any 2) one SA for each own address and solicited node address: spi=1 dst=myaddress, src=any, protocol=any spi=1 dst=solicitednode, src=any, protocol=any - when kernel IPSEC asks a specific SA with dst= link local (unicast or multicast), src=any, protocol=any, it installs: spi=1 dst=requested-dst src=any protocol=any then the following security policy is sufficient to protect all ND discovery and all link local traffic for good measure. ff02/16 -> use ESP (src=any, protocol=any) fe80/10 -> use ESP (src=any, protocol=any) For example, when link comes up, system would need to send RS, thus it matches the multicast destination policy actually and the preinstalled SA spi=1 dst=ff02::2 src=any protocol=any Note, that the SA's with multicast dst can be used both incoming and outgoing. When kernel needs to send neighbor solicitation, the solicited node destination matches the policy and appropriate SA is requested from the special key management. At least it would work this way with my IPSEC :-). Only the "special key management" needs to be written. Doesn't look too difficult to me. The end result would be "multiple virtual lans" on the same physical media (ethernet, wlan). Only those nodes with same configured key would see each other. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 13:08:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DL8OKL024507 for ; Wed, 13 Mar 2002 13:08:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DL8OvL024506 for ipng-dist; Wed, 13 Mar 2002 13:08:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DL8KKL024499 for ; Wed, 13 Mar 2002 13:08:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19045 for ; Wed, 13 Mar 2002 13:08:22 -0800 (PST) Received: from qwerty.ssvl.kth.se (qwerty.ssvl.kth.se [192.16.125.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA05184 for ; Wed, 13 Mar 2002 14:08:20 -0700 (MST) Received: from localhost (qwerty.ssvl.kth.se [127.0.0.1]) by qwerty.ssvl.kth.se (8.11.2/8.11.2) with ESMTP id g2DL4Y914654; Wed, 13 Mar 2002 22:04:34 +0100 Date: Wed, 13 Mar 2002 22:04:34 +0100 (CET) From: Alberto Escudero-Pascual X-X-Sender: To: Steve Deering cc: Erik Nordmark , Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, Let me clarify my point: u=0 => RFC3041, Manual, DHCPv6 or RFC2472 (4.1) RFC3041 => u=0 What i am trying to say is that despite that u=0 doesn't necessary mean that RFC3041 is in use. In practice, it could be the case that a high number of those IID are using RFC3041 and hence the anonimity set is not going to be big enough. In an environment where it is known not to be DHCPv6 we end with P(u=0 => RFC3041) ~ 1. I still haven't seen a strong justification of why a IPv6 address should include a bit "claiming" its global uniqueness. I know it is a loooong time discussion but still i don't see that is justified. I rather prefer an approach that RFC3041 is the default for all the nodes and the nodes that want to "opt-in" to have a global unique IID are free to do it so. I want to stick to Erik's question and i agree in the value of having certain reserved bits in the IID but "how to use those bits" and "its collateral implications" (for privacy observability for example) should be discussed out of RFC2473. Agreed? /aep On Wed, 13 Mar 2002, Steve Deering wrote: > At 10:51 AM +0100 3/13/02, Alberto Escudero-Pascual wrote: > >I want to stick to the question of Erik but i argue why nodes for example > >that want to use a privacy extension (RFC3041) have to indicate that their > >IID is not EUI-64 based and hence the use of the privacy extension is > >observable. > > Alberto, > > The u bit in the current IID definition indicates whether or not the > IID can be considered globally unique. The zero value (implying *not* > globally unique) is used not only for randomly-generated ("privacy") > IIDs but also for manually-assigned IIDs, and IIDs assigned via DHCP > that are not derived from the node's IEEE-802 or EUI-64 address. In > other words, u=0 does *not* mean randomly generated; it means not- > globally-unique. > > Steve > -- -------------------------------------------------------------------------- That you are not paranoid, it doesn't mean that they are not watching you! http://www.it.kth.se/~aep -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 13:30:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DLUkKL024691 for ; Wed, 13 Mar 2002 13:30:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DLUkoC024690 for ipng-dist; Wed, 13 Mar 2002 13:30:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DLUgKL024683 for ; Wed, 13 Mar 2002 13:30:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25426 for ; Wed, 13 Mar 2002 13:30:44 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA11954 for ; Wed, 13 Mar 2002 14:30:44 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DLU9I06897; Wed, 13 Mar 2002 13:30:09 -0800 (PST) Message-ID: <009501c1cad6$069848a0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Markku Savela" , References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> <3C8F3634.DE2E59F2@lmf.ericsson.se> <3C8F685C.65167ECA@lmf.ericsson.se> <200203131523.RAA12510@burp.tkv.asdf.org> <200203132056.WAA12868@burp.tkv.asdf.org> Subject: Re: Securing Neighbor Discovery Date: Wed, 13 Mar 2002 13:28:32 -0800 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku, > This might belong to IPSEC list, but just give a concrete idea about > it, here is a solution sketch... > > Securing ND with existing IPSEC (kernel) only needs to agree on > specific SPI to use and, assuming a special key management daemon, > which would do the following tasks > > - inputs "lan key from as configuration". All generated SA's use this > (or something derived from it deterministically) > > - automaticly installs following SA's > > 1) one SA for well known multicast addresses: > > spi=1 dst=ff02::1 src=any protocol=any > spi=1 dst=ff02::2 src=any protocol=any > > 2) one SA for each own address and solicited node address: > > spi=1 dst=myaddress, src=any, protocol=any > spi=1 dst=solicitednode, src=any, protocol=any > Maybe I'm showing my ignorance here, but how does the host install this SA without doing ND? Use the multicast SA to bootstrap? Other than that, this looks interesting. Why don't you write a draft on it? jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 13:37:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DLbZKL024766 for ; Wed, 13 Mar 2002 13:37:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DLbZ5h024765 for ipng-dist; Wed, 13 Mar 2002 13:37:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DLbWKL024758 for ; Wed, 13 Mar 2002 13:37:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10882 for ; Wed, 13 Mar 2002 13:37:34 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA16406 for ; Wed, 13 Mar 2002 14:37:32 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id XAA13006; Wed, 13 Mar 2002 23:37:26 +0200 Date: Wed, 13 Mar 2002 23:37:26 +0200 Message-Id: <200203132137.XAA13006@burp.tkv.asdf.org> From: Markku Savela To: kempf@docomolabs-usa.com CC: ipng@sunroof.eng.sun.com In-reply-to: <009501c1cad6$069848a0$7e6015ac@T23KEMPF> Subject: Re: Securing Neighbor Discovery References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> <3C8F3634.DE2E59F2@lmf.ericsson.se> <3C8F685C.65167ECA@lmf.ericsson.se> <200203131523.RAA12510@burp.tkv.asdf.org> <200203132056.WAA12868@burp.tkv.asdf.org> <009501c1cad6$069848a0$7e6015ac@T23KEMPF> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Maybe I'm showing my ignorance here, but how does the host install this > SA without doing ND? Use the multicast SA to bootstrap? The "special ND key manager" generates the keys and installs the SA's directly. It does not communicate with other hosts at all. Of course, the key generation algorithm and SPI assignment logic must be the same on each host (this is what would need and RFC to get an agreement). As far as user is concerned, this would be no different than from configuring the "password" to the WLAN card of each host that wants to participate. Only, with IPSEC the crypto would be much stronger. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 14:21:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DMLRKL025012 for ; Wed, 13 Mar 2002 14:21:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DMLRH7025011 for ipng-dist; Wed, 13 Mar 2002 14:21:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DMLNKL025004 for ; Wed, 13 Mar 2002 14:21:24 -0800 (PST) Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.174.48]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA06570; Wed, 13 Mar 2002 17:21:23 -0500 (EST) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2DMLN2W000975; Wed, 13 Mar 2002 17:21:23 -0500 (EST) Received: (from danmcd@localhost) by kebe.east.sun.com (8.12.1+Sun/8.12.1/Submit) id g2DMLNUC000974; Wed, 13 Mar 2002 17:21:23 -0500 (EST) Message-Id: <200203132221.g2DMLNUC000974@kebe.east.sun.com> Subject: Re: Securing Neighbor Discovery In-Reply-To: <009501c1cad6$069848a0$7e6015ac@T23KEMPF> from James Kempf at "Mar 13, 2002 01:28:32 pm" To: James Kempf Date: Wed, 13 Mar 2002 17:21:23 -0500 (EST) CC: Markku Savela , ipng@sunroof.eng.sun.com From: Dan McDonald Organization: Sun Microsystems, Inc. - Solaris Internet Engineering X-Mailer: ELM [version 2.4ME+ PL66 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Maybe I'm showing my ignorance here, but how does the host install this > SA without doing ND? Use the multicast SA to bootstrap? I gave a talk about what Markku was proposing a few IETF's ago under the title "The Link-Shared Secret". Basically, you start with a shared-secret that all nodes on the link use. You then derive IPsec SAs based on this. > Other than that, this looks interesting. Why don't you write a draft on > it? It is interesting, until you factor in the famous Jeff Schiller problem: Your attacker is often a legitimate user of the link. A person who's trusted on the link can forge packets from any other user on the link... including the router, or any other neighbors. In a perfect world, ND would allow a host to only do host-type things, and then only on behalf of the host itself. You _might_ be able to separate out the router-advertising functions of ND by using an AH auth transform that is a digital signature, but processing this in interrupt context would be painful. Solve the aforementioned Jeff Schiller problem, and you probably can secure ND. If you can't, all such solutions will just limit your troublemakers to who is allowed on the LAN. To be fair, in some cases that's Good Enough (TM). Perhaps I should bring back link-shared secret from the dead. 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 Wed Mar 13 14:33:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DMXUKL025061 for ; Wed, 13 Mar 2002 14:33:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DMXU4C025060 for ipng-dist; Wed, 13 Mar 2002 14:33:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DMXPKL025053 for ; Wed, 13 Mar 2002 14:33:26 -0800 (PST) Received: from lillen (vpn-129-156-96-60.EMEA.Sun.COM [129.156.96.60]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2DMXMx10263; Wed, 13 Mar 2002 23:33:22 +0100 (MET) Date: Wed, 13 Mar 2002 14:32:36 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Securing Neighbor Discovery To: Markku Savela Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200203132056.WAA12868@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - inputs "lan key from as configuration". All generated SA's use this > (or something derived from it deterministically) Dan McDonald did a presentation in IPNG on such a scheme a few years back. I don't recall if there ever was an internet-draft. This is using all symmetric crypto, right? This means that if you allow a host on the network and let it authenticate the router advertisements it has secret necessary to pretend to be a router itself i.e. can redirect traffic arbitrarely. While that *might* be reasonable for e.g. a corporate LAN I don't think it is sufficient for a public access LAN. Inherently there seems to be a need to authenticate authorized routers without being able to pretend to be one. Thus different keying material must be used by the sender and receiver. 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 Wed Mar 13 15:28:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DNSRKL025143 for ; Wed, 13 Mar 2002 15:28:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DNSQFZ025142 for ipng-dist; Wed, 13 Mar 2002 15:28:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DNSNKL025135 for ; Wed, 13 Mar 2002 15:28:23 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05255 for ; Wed, 13 Mar 2002 15:28:25 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06170 for ; Wed, 13 Mar 2002 15:28:24 -0800 (PST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2DNRoI10064; Wed, 13 Mar 2002 15:27:50 -0800 (PST) Message-ID: <00b701c1cae6$77512520$7e6015ac@T23KEMPF> From: "James Kempf" To: "Markku Savela" Cc: References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> <3C8F3634.DE2E59F2@lmf.ericsson.se> <3C8F685C.65167ECA@lmf.ericsson.se> <200203131523.RAA12510@burp.tkv.asdf.org> <200203132056.WAA12868@burp.tkv.asdf.org> <009501c1cad6$069848a0$7e6015ac@T23KEMPF> <200203132137.XAA13006@burp.tkv.asdf.org> Subject: Re: Securing Neighbor Discovery Date: Wed, 13 Mar 2002 15:26:13 -0800 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > Maybe I'm showing my ignorance here, but how does the host install this > > SA without doing ND? Use the multicast SA to bootstrap? > > The "special ND key manager" generates the keys and installs the SA's > directly. It does not communicate with other hosts at all. Of course, > the key generation algorithm and SPI assignment logic must be the same > on each host (this is what would need and RFC to get an agreement). > > As far as user is concerned, this would be no different than from > configuring the "password" to the WLAN card of each host that wants to > participate. Only, with IPSEC the crypto would be much stronger. > We could leverge the roaming consortium or L2 AAA for this perhaps? Getting the user involved is not such a good option, as this has nothing at all to do with anything the user might be concerned about. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 15:37:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DNbdKL025171 for ; Wed, 13 Mar 2002 15:37:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DNbdUb025170 for ipng-dist; Wed, 13 Mar 2002 15:37:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DNbaKL025163 for ; Wed, 13 Mar 2002 15:37:36 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA16827 for ; Wed, 13 Mar 2002 15:37:36 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06258 for ; Wed, 13 Mar 2002 15:37:35 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5E9CF6A901; Thu, 14 Mar 2002 01:37:29 +0200 (EET) Message-ID: <3C8FE30E.1050500@kolumbus.fi> Date: Thu, 14 Mar 2002 01:38:54 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Markku Savela Cc: petrescu@crm.mot.com, kempf@docomolabs-usa.com, ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> <3C8F3634.DE2E59F2@lmf.ericsson.se> <3C8F685C.65167ECA@lmf.ericsson.se> <200203131523.RAA12510@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku Savela wrote: > One could consider a special "helper" application/daemon, which would > input from user (configuration) single manual key, and then would > generate and install the necessary from SA's for the ND protection (I > suspect this "daemon" would need to be constantly running, as SA's may > be needed dynamically. and then: > Securing ND with existing IPSEC (kernel) only needs to agree on > specific SPI to use and, assuming a special key management daemon, > which would do the following tasks True. (Both were listed a long time ago in Section 8 of [1] as one of the alternatives... I tried to do something about the issue at the IPsec WG but there weren't too many interested parties, maybe v6 wasn't interesting at that time, or something.) But as Erik pointed out the symmetric crypto may not be sufficient. Jari ---- [1] http://www.piuha.net/~jarkko/publications/draft-arkko-manual-icmpv6-sas-00.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 13 15:42:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DNgfKL025190 for ; Wed, 13 Mar 2002 15:42:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2DNgfm7025189 for ipng-dist; Wed, 13 Mar 2002 15:42:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2DNgcKL025182 for ; Wed, 13 Mar 2002 15:42:38 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12209 for ; Wed, 13 Mar 2002 15:42:39 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25051 for ; Wed, 13 Mar 2002 15:42:42 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 1B1C86A901; Thu, 14 Mar 2002 01:42:32 +0200 (EET) Message-ID: <3C8FE43D.20604@kolumbus.fi> Date: Thu, 14 Mar 2002 01:43:57 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: James Kempf Cc: Markku Savela , ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> <3C8F3634.DE2E59F2@lmf.ericsson.se> <3C8F685C.65167ECA@lmf.ericsson.se> <200203131523.RAA12510@burp.tkv.asdf.org> <200203132056.WAA12868@burp.tkv.asdf.org> <009501c1cad6$069848a0$7e6015ac@T23KEMPF> <200203132137.XAA13006@burp.tkv.asdf.org> <00b701c1cae6$77512520$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James Kempf wrote: >>As far as user is concerned, this would be no different than from >>configuring the "password" to the WLAN card of each host that wants to >>participate. Only, with IPSEC the crypto would be much stronger. > > We could leverge the roaming consortium or L2 AAA for this perhaps? > Getting the user involved is not such a good option, as this has nothing > at all to do with anything the user might be concerned about. Something like 802.1x EAP with an appropriate EAP submethod that generates session keys could be used here. Then you would get per-host session keys, and presumably all announcements coming from the router would have to be duplicated for all receivers, and there'd be no host-host communication. Perhaps that might be good in enough in some cases. Alternatively, AAA might give you the overall key for the network. In that case there'd be no limitations mentioned above, but you could spoof yourself as the router or the other hosts. Not sure there's increase in security compared to where we started, if unsuccessful network access authentication throws you out of the link. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 16:53:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E0r7KL025267 for ; Wed, 13 Mar 2002 16:53:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2E0r6c6025266 for ipng-dist; Wed, 13 Mar 2002 16:53:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E0r3KL025259 for ; Wed, 13 Mar 2002 16:53:03 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA28094 for ; Wed, 13 Mar 2002 16:53:05 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00626 for ; Wed, 13 Mar 2002 16:53:05 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA11053; Wed, 13 Mar 2002 16:53:04 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2E0r3m01728; Wed, 13 Mar 2002 16:53:03 -0800 X-mProtect:  Wed, 13 Mar 2002 16:53:03 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdwF1YLi; Wed, 13 Mar 2002 16:53:01 PST Message-Id: <4.3.2.7.2.20020313165036.03dcfe20@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 13 Mar 2002 16:51:41 -0800 To: IPng List From: Bob Hinden Subject: IPv6 working group agenda for Minneapolis IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The draft agenda is attached. When we put together the agenda we give priority to work the chairs and AD's thought was most important. There were a number of request for agenda slots that could not be honored. Suggest these topics be brought to the mailing list. Thanks, Bob Hinden & Steve Deering ------------------------------------------------------------------------- MONDAY, March 18, 2002, 1930-2200 Introduction, Steve Deering, 5 min. Review Agenda, Steve Deering, 5 min. Document Status, Bob Hinden, 15 min. Moving IPv6 Documents to Draft Standard, Margaret Wasserman, 30 min. IPv6 Node Requirements, John Loughney, 10 min. Default Address Selection for IPv6, Rich Draves, 0 min. Default Router Preferences and More-Specific Routes, Rich Draves, 15 min. DNS Discovery Update, Dave Thaler, 15 min. IPv6 Node Requirements, John Loughney, 5 min. Minimum IPv6 Functionality for a Cellular Host, Hesham Soliman, 30 min. Minimum Requirements of IPv6 for Low Cost Network Appliances, Atsushi Inoue, 10 min. THURSDAY, March 21, 2002 min. Prefix Delegation Intro, Steve Deering, 10 min. Automatic Prefix Delegation Protocol for IPV6, Brian Haberman , 10 min. DHCPv6 Prefix Delegation, Ralph Droms, 10 min. IPv6 Router Advertisement Prefix Delegation Option, Nathan Lutchansky, 10 min. Prefix Delegation Discussion, Steve Deering, 15 min. IPv6 Flow Label Specification, Jarno Rajahalme, 45 min. Reserving bits in RFC 2473 Interface IDs?, Erik Nordmark, 20 min. Make IMEI-based universal IPv6 interface IDs a w.g. Draft?, Francis Dupont, 5 min. Scoped Address Architecture Update, Tatuya Jinmei, 10 min. --------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 13 16:54:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E0sPKL025286 for ; Wed, 13 Mar 2002 16:54:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2E0sPHq025285 for ipng-dist; Wed, 13 Mar 2002 16:54:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E0sMKL025278 for ; Wed, 13 Mar 2002 16:54:22 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA01686 for ; Wed, 13 Mar 2002 16:54:24 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA23609; Wed, 13 Mar 2002 17:54:23 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2E0sMI12564; Wed, 13 Mar 2002 16:54:22 -0800 (PST) Message-ID: <00ec01c1caf2$8dbfacd0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Dan McDonald" Cc: "Markku Savela" , References: <200203132221.g2DMLNUC000974@kebe.east.sun.com> Subject: Re: Securing Neighbor Discovery Date: Wed, 13 Mar 2002 16:52:45 -0800 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Your attacker is often a legitimate user of the link. > Right, that's the point I was trying to bring up in my response to Alex. Just because someone has undergone AAA successfully doesn't mean that they won't disrupt the link. > A person who's trusted on the link can forge packets from any other > user on the link... including the router, or any other neighbors. > > In a perfect world, ND would allow a host to only do host-type things, and > then only on behalf of the host itself. > > You _might_ be able to separate out the router-advertising functions of ND by > using an AH auth transform that is a digital signature, but processing this > in interrupt context would be painful. > > Solve the aforementioned Jeff Schiller problem, and you probably can secure > ND. If you can't, all such solutions will just limit your troublemakers to > who is allowed on the LAN. > > To be fair, in some cases that's Good Enough (TM). Perhaps I should bring > back link-shared secret from the dead. > What we were trying to do in the ABK draft was provide a way that a node on the link could determine definitively that a particular ND/RA message came from the node/router possessing that identity. There main issue is some way to establish the right of the node to possess that identity beforehand, and we included sketches of a couple ways that seem consistent with current practice. We probably need to flesh these out some. That said, ABK is a new an largely unknown technology. In the security area, old and well trusted technologies are often easier to make work, because the holes are well known and can be patched around. So a solution based on IPsec, should it be possible to make it work and prove secure, would certainly be of interest. jak jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 17:49:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E1n6KL025349 for ; Wed, 13 Mar 2002 17:49:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2E1n6Jh025348 for ipng-dist; Wed, 13 Mar 2002 17:49:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E1n2KL025341 for ; Wed, 13 Mar 2002 17:49:02 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09971 for ; Wed, 13 Mar 2002 17:49:02 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA16654 for ; Wed, 13 Mar 2002 17:48:59 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2E1mso49483; Thu, 14 Mar 2002 10:48:54 +0900 (JST) Date: Thu, 14 Mar 2002 10:48:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: sra+ipng@hactrn.net Cc: ipng@sunroof.eng.sun.com Subject: Re: PPP and Global Addresses In-Reply-To: <20020313182339.7A23B1C7D@thrintun.hactrn.net> References: <4.3.2.7.2.20020307122231.00b74d78@funnel.cisco.com> <20020307192840.8782E1C7D@thrintun.hactrn.net> <20020313182339.7A23B1C7D@thrintun.hactrn.net> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 43 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 13 Mar 2002 13:23:39 -0500, >>>>> Rob Austein said: > The level 1 compliance stuff is only simple in the case of a single > subnet. As soon as you have routers between the client and the > server, you have to do something to get the packets across the router. Correct, and the "something" is to advertise the corresponding host route(s) in the site's routing system. I'm actually living with this configuration. > I suppose we could have a discussion about whether magic unicast > addresses (which are really a limited special case of anycast) are > better or worse than multicast, but I doubt that such a discussion > would change any minds. You're probably right, if we want to decide which is "better". However, I'm quite sure that the unicast/anycast approach is easier to deploy than the multicast one (whose scope is larger than link-local). (Again) the unicast/anycast approach has already run in my environment using a commercial routers. On the other hand, I don't know router products that officially supports IPv6 multicast routing. > The place where I do see a real difference is that > draft-ietf-ipv6-dns-discovery-04 tacks new functions (service > discovery and configuration) onto DNS. If you're talking about the level 2 compliance, I agree with you. The level 1 compliance does not need any new functions in DNS. > DNS was not really designed > for this, and while it's certainly possible (RFC-1925 2.(3)) I think > it's better to use a protocol that was designed for these tasks, > particularly if by doing so one also builds an infrastructure that > makes it easier to solve other problems (eg, configuring NTP). I agree here (thus I'm not so enthusiastic about the level 2 compliance.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 13 18:48:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E2mEKL025527 for ; Wed, 13 Mar 2002 18:48:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2E2mEaa025526 for ipng-dist; Wed, 13 Mar 2002 18:48:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E2mAKL025519 for ; Wed, 13 Mar 2002 18:48:10 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10261 for ; Wed, 13 Mar 2002 18:48:11 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02045 for ; Wed, 13 Mar 2002 18:48:07 -0800 (PST) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2E2lqo50010; Thu, 14 Mar 2002 11:47:52 +0900 (JST) Date: Thu, 14 Mar 2002 11:47:55 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Antonio Querubin Cc: Subject: Re: IPV6_JOIN_GROUP for v4 multicast In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 65 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 13 Mar 2002 08:15:14 -1000 (HST), >>>>> Antonio Querubin said: > And I would suggest that the same arguments still apply to multicast > addresses as well. Otherwise this topic would not keep reappearing. If > as you say, the arguments don't buy much for multicast > addresses/applications then wouldn't those same arguments also not buy > much for unicast addresses? I think many programmers would agree that the > API makes it relatively simple to enable IPv6 in their existing unicast > applications. So I'm having a difficult time understanding why such > arguments would inherently not apply to multicast as well or why multicast > should be treated noticeably differently than unicast in the API. In the unicast case, porting existing IPv4 applications (essentially) only needs some keyword replacements, such as s/AF_INET/AF_INET6/g s/sockaddr_in/sockaddr_in6/g In the multicast case, however, we'll also need to change semantical part of the existing application. For example: ip_mreq (for IPv4) takes in_addr to specify an interface while ipv6_mreq (for IPv6) takes an interface identifier. Thus, we'll (sometimes) need to change the syntax and/or semantics of command line arguments. This also means we need to introduce if_nametoindex() when porting. It also seems to me that people emphasize the useful part of mapped addresses tend to forget why some other people made objections to them in the old discussions about the unicast case; mapped addresses introduce additional complexity for address matching and access control, and the complexity can be a security hole. In my understanding, one of the reasons why we still go with mapped addresses in the unicast discussion was because there were already many existing (unicast) applications that relied on the usage of mapped addresses and because we could not ignore them. The situation is different in this case; we do not even have an official document that describes the usage of mapped-multicast addresses. So, in this case, we can/should concentrate on all the pros and cons. If the consensus is still for the usage of mapped addresses, I'll follow the result. BTW: I recall an old discussion about a protocol independent API for multicast applications that Dave Thaler (@Microsoft) proposed -if my memory is correct-. I'd rather prefer this approach. >> In any case, I don't think the advanced API is a suitable place to >> define such a stuff. Since the basic API defines both IPV6_JOIN_GROUP >> and the usage of IPv4-mapped(-unicast) addresses, the appropriate >> document would also be the basic API spec, *if we'd ever need to >> standardize that*. We should not use the advanced API as a kitchen >> sink for arbitrary extensions. > I agree. However, when I proposed wording to include a provision for this > in the updated basic API, I think it unfortunately came a little too late. > So someone then suggested that this be handled in the advanced API > instead. If you're suggesting that's no longer a good place for this then > do you have an alternative suggestion? As Tim pointed out, we'll go to an API community such as POSIX, or, if we still do some work in this group, we'll need a separate document. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 13 18:56:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E2uSKL025548 for ; Wed, 13 Mar 2002 18:56:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2E2uRxd025547 for ipng-dist; Wed, 13 Mar 2002 18:56:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E2uOKL025540 for ; Wed, 13 Mar 2002 18:56:24 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA23580 for ; Wed, 13 Mar 2002 18:56:09 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA02516 for ; Wed, 13 Mar 2002 18:56:10 -0800 (PST) Received: from AlperVAIO (dhcp68.docomolabs-usa.com [172.21.96.68]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2E2u4I15746; Wed, 13 Mar 2002 18:56:04 -0800 (PST) Message-ID: <02b801c1cb02$d5492bc0$446015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Jari Arkko" , "Alexandru Petrescu" Cc: "James Kempf" , References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> <3C8F3634.DE2E59F2@lmf.ericsson.se> Subject: Re: Securing Neighbor Discovery Date: Wed, 13 Mar 2002 18:49:16 -0800 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.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, > But the modifications necessary before ESP works well > enough for ND are pretty interesting. The basic problem > we need to deal with manually keyed ESP is dst address > as a pointer to the SA; this needs to change if manual > keying is to be used. Another basic problem is inability > to use *any* IP-based key management protocol (including > IKE) due to chicken-and-egg effect. A third problem Actually PANA should be able to work before IP address configuration, and most possibly (not a requirement) will distribute keys... > is that when the ND protection gets host specific - > as it should - we need some way of indicating individual > SAs. alper -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 19:19:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E3JNKL025662 for ; Wed, 13 Mar 2002 19:19:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2E3JN31025661 for ipng-dist; Wed, 13 Mar 2002 19:19:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E3JJKL025654 for ; Wed, 13 Mar 2002 19:19:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27074 for ; Wed, 13 Mar 2002 19:19:19 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA07886 for ; Wed, 13 Mar 2002 20:19:18 -0700 (MST) Received: from AlperVAIO (dhcp68.docomolabs-usa.com [172.21.96.68]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2E3IXI16174; Wed, 13 Mar 2002 19:18:33 -0800 (PST) Message-ID: <031a01c1cb05$f93416a0$446015ac@AlperVAIO> From: "Alper E. YEGIN" To: "Jari Arkko" , "James Kempf" Cc: "Markku Savela" , References: <01eb01c1c702$268384e0$7e6015ac@T23KEMPF> <036001c1ca25$0b5d2920$7e6015ac@T23KEMPF> <3C8F3634.DE2E59F2@lmf.ericsson.se> <3C8F685C.65167ECA@lmf.ericsson.se> <200203131523.RAA12510@burp.tkv.asdf.org> <200203132056.WAA12868@burp.tkv.asdf.org> <009501c1cad6$069848a0$7e6015ac@T23KEMPF> <200203132137.XAA13006@burp.tkv.asdf.org> <00b701c1cae6$77512520$7e6015ac@T23KEMPF> <3C8FE43D.20604@kolumbus.fi> Subject: Re: Securing Neighbor Discovery Date: Wed, 13 Mar 2002 19:11:45 -0800 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.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, > Something like 802.1x EAP with an appropriate EAP submethod that generates > session keys could be used here. Then you would get per-host session keys, > and presumably all announcements coming from the router would have to be > duplicated for all receivers, and there'd be no host-host communication. Perhaps > that might be good in enough in some cases. Actually, 802.1x also gives the host a multicast/broadcast key. alper > > Alternatively, AAA might give you the overall key for the network. In that > case there'd be no limitations mentioned above, but you could spoof yourself > as the router or the other hosts. Not sure there's increase in security > compared to where we started, if unsuccessful network access authentication > throws you out of the link. > > Jari > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 13 19:24:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E3O0KL025681 for ; Wed, 13 Mar 2002 19:24:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2E3O0YS025680 for ipng-dist; Wed, 13 Mar 2002 19:24:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E3NvKL025673 for ; Wed, 13 Mar 2002 19:23:57 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA26114 for ; Wed, 13 Mar 2002 19:23:58 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA07081 for ; Wed, 13 Mar 2002 19:24:01 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2E3NuZc021893 for ; Thu, 14 Mar 2002 04:23:57 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 14 04:23:56 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 04:14:01 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB0D@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , Markku Savela Cc: ipng@sunroof.eng.sun.com Subject: RE: Securing Neighbor Discovery Date: Thu, 14 Mar 2002 04:23:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > Maybe I'm showing my ignorance here, but how does the > host install > this > > > SA without doing ND? Use the multicast SA to bootstrap? > > > > The "special ND key manager" generates the keys and > installs the SA's > > directly. It does not communicate with other hosts at > all. Of course, > > the key generation algorithm and SPI assignment logic > must be the same > > on each host (this is what would need and RFC to get an > agreement). > > > > As far as user is concerned, this would be no different than from > > configuring the "password" to the WLAN card of each host > that wants to > > participate. Only, with IPSEC the crypto would be much stronger. > > > > We could leverge the roaming consortium or L2 AAA for this perhaps? > Getting the user involved is not such a good option, as > this has nothing > at all to do with anything the user might be concerned about. > James, I haven't read your draft yet, but regarding the AAA discussions, I prefer an infrastructureless solution, it's easy to deploy, more reliable, and all the other nice benefits of e2e are preserved. Since most of the ND security issues are about preventing address spoofing, I think CGAs would be a perfect fit for this. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 21:36:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E5a8KL025904 for ; Wed, 13 Mar 2002 21:36:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2E5a853025903 for ipng-dist; Wed, 13 Mar 2002 21:36:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E5a5KL025896 for ; Wed, 13 Mar 2002 21:36:05 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA12003 for ; Wed, 13 Mar 2002 21:36:05 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA16940 for ; Wed, 13 Mar 2002 22:36:04 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2E5Xt515123; Thu, 14 Mar 2002 07:33:55 +0200 Date: Thu, 14 Mar 2002 07:33:54 +0200 (EET) From: Pekka Savola To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Antonio Querubin , Subject: Re: IPV6_JOIN_GROUP for v4 multicast In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 14 Mar 2002, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >>>>> On Wed, 13 Mar 2002 08:15:14 -1000 (HST), > >>>>> Antonio Querubin said: > > > And I would suggest that the same arguments still apply to multicast > > addresses as well. Otherwise this topic would not keep reappearing. If > > as you say, the arguments don't buy much for multicast > > addresses/applications then wouldn't those same arguments also not buy > > much for unicast addresses? I think many programmers would agree that the > > API makes it relatively simple to enable IPv6 in their existing unicast > > applications. So I'm having a difficult time understanding why such > > arguments would inherently not apply to multicast as well or why multicast > > should be treated noticeably differently than unicast in the API. > > In the unicast case, porting existing IPv4 applications (essentially) > only needs some keyword replacements, such as > s/AF_INET/AF_INET6/g > s/sockaddr_in/sockaddr_in6/g Not in the real world. Who wants an application that can work _only_ with IPv6? Nobody. In the real world, sockaddr_storage and friends must be used and DNS lookup sections re-written with getaddrinfo and getnameinfo. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 13 23:11:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E7BOKL026026 for ; Wed, 13 Mar 2002 23:11:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2E7BOst026025 for ipng-dist; Wed, 13 Mar 2002 23:11:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2E7BKKL026018 for ; Wed, 13 Mar 2002 23:11:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA25002 for ; Wed, 13 Mar 2002 23:11:22 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA04943 for ; Thu, 14 Mar 2002 00:11:20 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 996987D; Thu, 14 Mar 2002 09:13:09 +0200 (EET) Message-ID: <3C904D23.4010805@nomadiclab.com> Date: Thu, 14 Mar 2002 09:11:31 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020307 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Kempf Cc: Dan McDonald , Markku Savela , ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery References: <200203132221.g2DMLNUC000974@kebe.east.sun.com> <00ec01c1caf2$8dbfacd0$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dan McDonald wrote: >> Your attacker is often a legitimate user of the link. James Kempf wrote: > Right, that's the point I was trying to bring up in my response to Alex. > Just because someone has undergone AAA successfully doesn't mean that > they won't disrupt the link. I completely agree. Additionally, I'd like to see an infrastructureless solution to be used anywhere possible. Why? Basically because an infrastructureless solution means that we can make it to work with zero configuration, while any infrastructure necessarily needs that either the initial credentials must be configured or that new nodes must learn the credentials of the infrastructure through "leap of faith". Dan McDonald wrote: >> In a perfect world, ND would allow a host to only do host-type things, >> and then only on behalf of the host itself. >> ... >> Solve the aforementioned Jeff Schiller problem, and you probably can >> secure ND. If you can't, all such solutions will just limit your >> troublemakers to who is allowed on the LAN. ... James Kempf wrote: > What we were trying to do in the ABK draft was provide a way that a node > on the link could determine definitively that a particular ND/RA message > came from the node/router possessing that identity. There main issue is > some way to establish the right of the node to possess that identity > beforehand, and we included sketches of a couple ways that seem > consistent with current practice. We probably need to flesh these out > some. > > That said, ABK is a new an largely unknown technology. In the security > area, old and well trusted technologies are often easier to make work, > because the holes are well known and can be patched around. So a > solution based on IPsec, should it be possible to make it work and prove > secure, would certainly be of interest. Already a year ago I tried to point out that CGA can be used to solve the ND security problem. Since CGA is able to securely bind a public key to a interface ID, you can use CGA to verify that the right party "speaks for" the interface ID. That seems to be sufficient to solve ND. However, it doesn't help much with router discovery. Personally, I think that ABK might have great potential for router discovery, since ABK can to convert even network prefixes into public keys. Now, if we just could figure out how we could use ABK to somehow express trust relationships between more covering prefixes (e.g. 3ff0::/16) and subprefixes (e.g. 3ff0:1::/20), then we would have something... Back then I also wrote an I-D, which describes one method how CGA can be used for ND. For various reasons that I-D never got published, but it has been available and is still available at http://www.tml.hut.fi/~pnr/publications/draft-nikander-ipng-pbk-addresses-00.txt The basic ideas are also described in Pekka Nikander, "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", presented at Cambridge Security Protocols Workshop 2001, April 25-27, 2001, Cambridge University. To be published in the workshop proceedings at the LNCS series. A pre-publication version of the paper is available at http://www.tml.hut.fi/~pnr/publications/cam2001.pdf --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 02:24:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EAO4KL026238 for ; Thu, 14 Mar 2002 02:24:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EAO4Sh026237 for ipng-dist; Thu, 14 Mar 2002 02:24:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EAO1KL026230 for ; Thu, 14 Mar 2002 02:24:01 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA29113 for ; Thu, 14 Mar 2002 02:24:03 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA03965 for ; Thu, 14 Mar 2002 03:24:01 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2EASkT02872; Thu, 14 Mar 2002 17:28:50 +0700 (ICT) From: Robert Elz To: Steve Deering cc: Alberto Escudero-Pascual , Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Mar 2002 17:28:46 +0700 Message-ID: <2870.1016101726@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 13 Mar 2002 10:43:40 -0800 From: Steve Deering Message-ID: | The u bit in the current IID definition indicates whether or not the | IID can be considered globally unique. If that were to be true, then we would require u==0 in all IPv6 addresses, as there's no possible way for anyone to know if their IID is globally unique or not. We don't even need to resort to postulating manufacturing errors (sloppiness, whatever) to see that the 'u' bit defined this way is useless. Though that is certainly part of the potential problem. The obvious case that breaks this is address reassignment. That is, I have some system or other, it has used autoconfig, and allocated itself an EUI-64 based address, and so, following the rules, has set u==1. Then the system's net interface breaks in some way (which might mean that the switch it is connected to breaks, not necessarily the hardware in the system). I desire my DNS advertised address to keep on working, so I assign that address to another interface in the system (or perhaps I install some new interface type, replace a 100baseTX with GigaE or something). As I want to avoid all service disruption, this interface gets the IPv6 address that the system has always had. The same IID. And because the address always had u==1 in the past, it has to keep u==1 now. Sometime later, my old interface card, with its burned in MAC addr, is plugged into some other system, connected most likely to some distant net (distant enough), it does its DAD, finds it can use the address based upon the EUI from the card, and does so, u==1. Now we have two systems both using IPv6 addresses with u==1, and both with the same IID. Thus, u==1 does not imply a globally unique IID, and cannot. The only way we could change that would be to refuse to allow an address to be used which didn't match the IEEE addr of the card, if it has u==1. That is, all stacks everywhere (including that in all those shipping XP's) would have to enforce that rule. Some hope (too late...). But I'd object to any attempt to do that in any case, even if it were feasible. There's no current use for globally unique IIDs - they're just a frill "it looks like we can get this for free, so let's define it". Adding mechanism for no purpose, and while doing so, prohibiting reassignment of addresses (which is useful functionality) would be absurd. Not only is there no use for globally unique IIDs currently, it is unlikely there ever will be one. No IPv6 address is required to have one of those, so nothing can ever depend on their existence (and with more and more people jumping on the "privacy address" band waggon - for reasons that aren't clear to me, but that's beside the point - it seems that less IPv6 addresses will have u==1 than might have initially seemed likely). Further, even if you find an address with u==1, there's no way to know if it really is globally unique - there's no testing mechanism - so it would be unreasonable to rely on its uniqueness for anything important. So, let's just end this pretence that u==1 has any special meaning, and revert to the earlier situation, where we no natural EUI-64 is going to have (the inverted) u==0, so we define things like randomly generated addresses to always set u==0, so that there's no chance that someone's randomly generated address is going to be occupying your EUI-64 address space on your link (the chance is tiny anyway, this removes it completely, and makes it reasonable for a system using autoconf of EUI-64 based addresses to simply give up and cry if its DAD fails, rather than requiring a recovery mechanism). Finally - if there were to be any kind of reasonable way to test an ID for uniqueness, then we'd be using EIDs now. Getting unique EIDs was the major problem that inhibited us from choosing a protocol that used them (8+8 being one of the contenders - the nearest to IPv6). And that was a problem when the EID would have been completely under our control, and so could have had any properties we desired, unlike EUI-64's, that we're just stuck with. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 14 03:09:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EB9CKL026286 for ; Thu, 14 Mar 2002 03:09:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EB9CnP026285 for ipng-dist; Thu, 14 Mar 2002 03:09:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EB99KL026278 for ; Thu, 14 Mar 2002 03:09:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA19013; Thu, 14 Mar 2002 03:09:09 -0800 (PST) Received: from qwerty.ssvl.kth.se (qwerty.ssvl.kth.se [192.16.125.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA13347; Thu, 14 Mar 2002 04:09:07 -0700 (MST) Received: from localhost (qwerty.ssvl.kth.se [127.0.0.1]) by qwerty.ssvl.kth.se (8.11.2/8.11.2) with ESMTP id g2EB2a922527; Thu, 14 Mar 2002 12:02:36 +0100 Date: Thu, 14 Mar 2002 12:02:36 +0100 (CET) From: Alberto Escudero-Pascual X-X-Sender: To: Robert Elz cc: Steve Deering , Erik Nordmark , Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-Reply-To: <2870.1016101726@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yesterday, i tried to estimate what is the probability of generating a random interface identifier that looks like a EUI-64 IID without using the 'u' bit at all calculating the worst of the cases. Let's take the worst of the cases, that all the EUI-64 based IPv6 current devices are in the same room. - Today there are 5692 company_id assigned by IEEE - Let's imagine that all of them are Ethernet devices - Let's imagine that the 5692*(2^24) IPv6 devices are in the same place running stalessadress autoconfiguration The probability of generating a random IID that "looks like a EUI-64" is P=1-[2^48-(5692*2^24)/2^48]=0.00034 I beleive that EUI-64 based, Random, Manual, DHCPv6 ... should not carry a bit "claiming" how they were generated to provide a "claim" of uniqueness. Is the porpouse of DaD to detect only the duplicate random interface identifiers then? There is a quantitative and qualitative difference in reserving one bit for RR or CryptoIID to enhance mobile security and even handover performance or to reserve one bit (u) to "CLAIM" uniqueness. PD. I funny plot of the distribution of the IEEE OUI is available at: http://www.it.kth.se/~aep/ieee-oui.ps /aep > So, let's just end this pretence that u==1 has any special meaning, and > revert to the earlier situation, where we no natural EUI-64 is going to > have (the inverted) u==0, so we define things like randomly generated > addresses to always set u==0, so that there's no chance that someone's > randomly generated address is going to be occupying your EUI-64 address > space on your link (the chance is tiny anyway, this removes it completely, > and makes it reasonable for a system using autoconf of EUI-64 based addresses > to simply give up and cry if its DAD fails, rather than requiring a recovery > mechanism). > > Finally - if there were to be any kind of reasonable way to test an ID for > uniqueness, then we'd be using EIDs now. Getting unique EIDs was the major > problem that inhibited us from choosing a protocol that used them (8+8 > being one of the contenders - the nearest to IPv6). And that was a problem > when the EID would have been completely under our control, and so could > have had any properties we desired, unlike EUI-64's, that we're just stuck > with. > > kre > -- -------------------------------------------------------------------------- That you are not paranoid, it doesn't mean that they are not watching you! http://www.it.kth.se/~aep -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 04:25:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2ECPEKL026347 for ; Thu, 14 Mar 2002 04:25:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2ECPDsD026346 for ipng-dist; Thu, 14 Mar 2002 04:25:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2ECPAKL026339 for ; Thu, 14 Mar 2002 04:25:10 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA16324 for ; Thu, 14 Mar 2002 04:25:11 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28430 for ; Thu, 14 Mar 2002 04:25:15 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id OAA13771; Thu, 14 Mar 2002 14:25:03 +0200 Date: Thu, 14 Mar 2002 14:25:03 +0200 Message-Id: <200203141225.OAA13771@burp.tkv.asdf.org> From: Markku Savela To: aep@it.kth.se CC: ipng@sunroof.eng.sun.com In-reply-to: (message from Alberto Escudero-Pascual on Thu, 14 Mar 2002 12:02:36 +0100 (CET)) Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: Alberto Escudero-Pascual > There is a quantitative and qualitative difference in reserving one > bit for RR or CryptoIID to enhance mobile security and even handover > performance or to reserve one bit (u) to "CLAIM" uniqueness. Uhh.. RR bit? I've not followed mobile-ip list too closely. But, if this bit is supposed to be reserved within "EUI-64 framework", I must protest! Because, ... ... it would limit home agents only to those hosts that have IPv6 address format that mandate EUI-64 interface id. Wouldn't this prevent using 6to4 address as home address? It would also exlude all future non-EUI-64 address formats (or force everyone to use EUI-64). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 05:02:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2ED2rKL026417 for ; Thu, 14 Mar 2002 05:02:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2ED2rOv026416 for ipng-dist; Thu, 14 Mar 2002 05:02:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2ED2nKL026409 for ; Thu, 14 Mar 2002 05:02:49 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA01263 for ; Thu, 14 Mar 2002 05:02:50 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17397 for ; Thu, 14 Mar 2002 06:02:49 -0700 (MST) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2ED2ho53586; Thu, 14 Mar 2002 22:02:43 +0900 (JST) Date: Thu, 14 Mar 2002 22:02:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Pekka Savola Cc: Subject: Re: IPV6_JOIN_GROUP for v4 multicast In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 40 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 14 Mar 2002 07:33:54 +0200 (EET), >>>>> Pekka Savola said: >> > And I would suggest that the same arguments still apply to multicast >> > addresses as well. Otherwise this topic would not keep reappearing. If >> > as you say, the arguments don't buy much for multicast >> > addresses/applications then wouldn't those same arguments also not buy >> > much for unicast addresses? I think many programmers would agree that the >> > API makes it relatively simple to enable IPv6 in their existing unicast >> > applications. So I'm having a difficult time understanding why such >> > arguments would inherently not apply to multicast as well or why multicast >> > should be treated noticeably differently than unicast in the API. >> >> In the unicast case, porting existing IPv4 applications (essentially) >> only needs some keyword replacements, such as >> s/AF_INET/AF_INET6/g >> s/sockaddr_in/sockaddr_in6/g > Not in the real world. Who wants an application that can work _only_ with > IPv6? Nobody. In the real world, sockaddr_storage and friends must be > used and DNS lookup sections re-written with getaddrinfo and getnameinfo. Though I admit that I may have oversimplified the description, you missed the point (or I failed to describe the point well). The point is, whether using IPv4-mapped addresses for multicast addresses is worth introducing or not. Secondly (this is far from the point of the discussion, though), I did not intend to say we can only consider applications that can work only with *IPv6*. What I meant was we can only use AF_INET6 sockets to support *both IPv4 and IPv6* with the usage of mapped addresses described in the basic API. And, some server side IPv4 applications can even be ported without sockaddr_storage, getaddrinfo(), or getnameinfo(). This was also an argument by supporters of mapped addresses. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 14 07:23:50 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EFNnKL026732 for ; Thu, 14 Mar 2002 07:23:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EFNn8L026731 for ipng-dist; Thu, 14 Mar 2002 07:23:49 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EFNkKL026724 for ; Thu, 14 Mar 2002 07:23:46 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10439 for ; Thu, 14 Mar 2002 07:23:47 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA05808 for ; Thu, 14 Mar 2002 07:23:51 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA20887; Thu, 14 Mar 2002 08:23:38 -0700 (MST)] Received: [from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA04599; Thu, 14 Mar 2002 08:23:29 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr04.mot.com (8.11.6/8.11.6) with ESMTP id g2EFNKr05558; Thu, 14 Mar 2002 09:23:21 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 266562EC85; Thu, 14 Mar 2002 16:23:17 +0100 (CET) To: "Charles E. Perkins" Cc: "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: Re: IPv6-support-for-what-exists-today (Was: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00.txt -> wg last call?]) References: <4DA6EA82906FD511BE2F00508BCF053802C6AA7C@Esealnt861.al.sw.ericsson.se> <3C86A7F3.6B783B24@iprg.nokia.com> From: Alexandru Petrescu Date: 14 Mar 2002 16:23:17 +0100 In-Reply-To: <3C86A7F3.6B783B24@iprg.nokia.com> Message-ID: Lines: 21 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Charles E. Perkins" writes: > That's exactly right, and I am suggesting that the draft > be renamed to be "IPv6-support-for-what-exists-today". Hi, appologies for a more than week old follow-up and this has probably been mentioned. Being confronted recently with the idea of using new unique ID's of new links for inducing some uniqueness properties into IPv6 addresses I think there's a need for more comfortable place within current IPv6 specs to accomodate those new things. For example, how about better separating IPv6-over-Ethernet rfc2464 from the current address architecture draft of rfc2373? My precise suggestion would be to move EUI-64 and Modified EUI-64 from the latter to the former. Of course, there are reasons for it be where it is, I'm just trying to understand why this is or is not possible. Thanks, Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 07:40:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EFegKL026774 for ; Thu, 14 Mar 2002 07:40:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EFegnO026773 for ipng-dist; Thu, 14 Mar 2002 07:40:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EFedKL026766 for ; Thu, 14 Mar 2002 07:40:39 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24043 for ; Thu, 14 Mar 2002 07:40:40 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16569 for ; Thu, 14 Mar 2002 07:40:42 -0800 (PST) Received: from tarski.cs.uni-bonn.de (tarski.cs.uni-bonn.de [131.220.4.200]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id QAA03162 for ; Thu, 14 Mar 2002 16:40:39 +0100 (MET) Received: (from ignatios@localhost) by tarski.cs.uni-bonn.de (8.9.1a/8.9.1) id QAA16355 for ipng@sunroof.eng.sun.com; Thu, 14 Mar 2002 16:39:54 +0100 (CET) Date: Thu, 14 Mar 2002 16:39:54 +0100 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: IPv6-support-for-what-exists-today (Was: Should DAD be optional? [Wasdraft-ietf-ipv6-cellular-host-00.txt -> wg last call?]) Message-ID: <20020314163954.A16189@tarski.cs.uni-bonn.de> References: <4DA6EA82906FD511BE2F00508BCF053802C6AA7C@Esealnt861.al.sw.ericsson.se> <3C86A7F3.6B783B24@iprg.nokia.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from petrescu@crm.mot.com on Thu, Mar 14, 2002 at 04:23:17PM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 14, 2002 at 04:23:17PM +0100, Alexandru Petrescu wrote: =20 > For example, how about better separating IPv6-over-Ethernet rfc2464 > from the current address architecture draft of rfc2373? My precise > suggestion would be to move EUI-64 and Modified EUI-64 from the latter > to the former. Of course, there are reasons for it be where it is, > I'm just trying to understand why this is or is not possible. The idea is to use the same 64bit Interface Identifier (especially if a globally unique, e.g., derived from the EUI-64 of the node, if available, or the EUI-64 of one of the Ethernet devices) also for an interface on=20 a different link that has no globally unique identifier itself. (E.g., on a serial point-to-point link, or Arcnet). This way, the probability of address collisions, which have to be sorted out somehow, is smaller. Regards, -is --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPJDERzCn4om+4LhpAQHdGwgAr6IPy2LuTxos6wi6573zbS9IOy4rEaCW wnIvV9BM2KFAwGFxGGXd7B0mTw6FM809uo2K4BU3IihjM9h2ij1538pYw0VVR7h1 RK2x3hZSx18szryQXRNaUMaxSQp7tGWrbeabpmBqOu/aFsQ5a4/4cjnejk1Wih/i 4kIYvDQ778QcAsyHDUrl5aNC2i9MYK2jxehG4kclOuf90MF0pjErj5Jm+ZPeqyh4 6n3v+Ckh1s4rINQu0HpOdyQRl0iISOPo3plFFFRaGF+x6GcQNBjC5pS/2gQr1O2w 5Jy88j/2cngZagqO2QoE1AaTyaFYEA70ZdScr7aglS9DYjxEkBY3Lg== =E0Wd -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 07:53:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EFrhKL026805 for ; Thu, 14 Mar 2002 07:53:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EFrhd7026804 for ipng-dist; Thu, 14 Mar 2002 07:53:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EFreKL026797 for ; Thu, 14 Mar 2002 07:53:40 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15976 for ; Thu, 14 Mar 2002 07:53:41 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA13180 for ; Thu, 14 Mar 2002 07:53:45 -0800 (PST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id IAA01628; Thu, 14 Mar 2002 08:53:40 -0700 (MST)] Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id IAA09745; Thu, 14 Mar 2002 08:41:46 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (8.11.6/8.11.6) with ESMTP id g2EFrao15662; Thu, 14 Mar 2002 09:53:37 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 9FFD32EC83; Thu, 14 Mar 2002 16:53:34 +0100 (CET) To: Ignatios Souvatzis Cc: Subject: Re: IPv6-support-for-what-exists-today References: <4DA6EA82906FD511BE2F00508BCF053802C6AA7C@Esealnt861.al.sw.ericsson.se> <3C86A7F3.6B783B24@iprg.nokia.com> <20020314163954.A16189@tarski.cs.uni-bonn.de> From: Alexandru Petrescu Date: 14 Mar 2002 16:53:34 +0100 In-Reply-To: <20020314163954.A16189@tarski.cs.uni-bonn.de> Message-ID: Lines: 13 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ignatios Souvatzis writes: > The idea is to use the same 64bit Interface Identifier (especially > if a globally unique, e.g., derived from the EUI-64 of the node, if > available, or the EUI-64 of one of the Ethernet devices) also for an > interface on a different link that has no globally unique identifier > itself. (E.g., on a serial point-to-point link, or Arcnet). Aha, so a device that has two interfaces one towards an IEEE LAN link and the other towards another type of link will inevitably prefer the IEEE LAN identifier as being "more unique" than the others, right? That's a cool idea, I would like to experiment with it. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 08:37:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EGbdKL026932 for ; Thu, 14 Mar 2002 08:37:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EGbd2Q026931 for ipng-dist; Thu, 14 Mar 2002 08:37:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EGbYKL026924 for ; Thu, 14 Mar 2002 08:37:34 -0800 (PST) Received: from lillen (vpn-129-156-96-17.EMEA.Sun.COM [129.156.96.17]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2EGbWx28137; Thu, 14 Mar 2002 17:37:32 +0100 (MET) Date: Thu, 14 Mar 2002 17:37:31 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? To: Markku Savela Cc: aep@it.kth.se, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200203141225.OAA13771@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > ... it would limit home agents only to those hosts that have IPv6 > address format that mandate EUI-64 interface id. Wouldn't this prevent > using 6to4 address as home address? It would also exlude all > future non-EUI-64 address formats (or force everyone to use EUI-64). Markku, 6to4 addresses have a 64 bit interface ID with the same semantics as other interface IDs. 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 Mar 14 08:53:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EGrXKL026957 for ; Thu, 14 Mar 2002 08:53:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EGrXX6026956 for ipng-dist; Thu, 14 Mar 2002 08:53:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EGrTKL026949 for ; Thu, 14 Mar 2002 08:53:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA09705 for ; Thu, 14 Mar 2002 08:53:31 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA24919 for ; Thu, 14 Mar 2002 09:53:30 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2EGqrI28825; Thu, 14 Mar 2002 08:52:53 -0800 (PST) Message-ID: <006001c1cb78$75c51990$7e6015ac@T23KEMPF> From: "James Kempf" To: "Pekka Nikander" Cc: "Dan McDonald" , "Markku Savela" , References: <200203132221.g2DMLNUC000974@kebe.east.sun.com> <00ec01c1caf2$8dbfacd0$7e6015ac@T23KEMPF> <3C904D23.4010805@nomadiclab.com> Subject: Re: Securing Neighbor Discovery Date: Thu, 14 Mar 2002 08:51:17 -0800 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, > I completely agree. Additionally, I'd like to see an > infrastructureless solution to be used anywhere possible. > Why? Basically because an infrastructureless solution means > that we can make it to work with zero configuration, while > any infrastructure necessarily needs that either the initial > credentials must be configured or that new nodes must learn > the credentials of the infrastructure through "leap of faith". > In general, if I am a network service provider, then I have a strong business interest in maintaining good service in my network. Since I am paying for the routers, wires, electricity, etc., and my customers are paying me for the service, I want to make sure I've got control over the quality of IP service that gets delivered, so I can deliever good service to my customers. This is not like the MIP BU security problem where there is no infrastructure for authenticating across the Internet. There is, in fact, an extensive infrastructure that is available, both technological (in NASes and AAA servers) and business/societal (in roaming agreements and billing reconciliation) for ensuring that the host that gets on the network is who they say they are, and that they pay for the service they use. This infrastructure is thus leveragable for authenticating that the host that gets on the network has the right to claim a particular identity. What's needed yet, and what we've proposed in ABKs, is a way for other hosts to validate that claim, and for a host to validate the claim of a router in that regard after the initial entry into the network. The note that Markku sent regarding use of IPsec seemed like it might have the same properties (but the details need to be worked out). So, the upshot of what I am saying is that I believe this is not a purely technical problem. There are sociological and business aspects of it that suggest a solution which leverages off the existing authentication/business infrastructure is likely to be more of interest to existing ISPs and future wireless ISPs. Now, that said, I agree that an infrastructureless solution may be of interest in some circumstances. It may even be of interest to ISPs, if the details are right. But I don't think there will ever be a case where an ISP will let a host on their network without requiring some kind of authentication as to the right of that host to use the network (unless, of course, the ISP is giving away the service). jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 09:03:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EH3uKL026980 for ; Thu, 14 Mar 2002 09:03:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EH3upU026979 for ipng-dist; Thu, 14 Mar 2002 09:03:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EH3rKL026972 for ; Thu, 14 Mar 2002 09:03:53 -0800 (PST) Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08998 for ; Thu, 14 Mar 2002 09:03:55 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA22175 for ; Thu, 14 Mar 2002 09:03:52 -0800 (PST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g2EH3JR08589; Thu, 14 Mar 2002 18:03:19 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g2EH3IUD024043; Thu, 14 Mar 2002 19:03:18 +0200 (EET) Message-ID: <3C90D7D6.A9925A9A@lmf.ericsson.se> Date: Thu, 14 Mar 2002 19:03:18 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf CC: Pekka Nikander , Dan McDonald , Markku Savela , ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery References: <200203132221.g2DMLNUC000974@kebe.east.sun.com> <00ec01c1caf2$8dbfacd0$7e6015ac@T23KEMPF> <3C904D23.4010805@nomadiclab.com> <006001c1cb78$75c51990$7e6015ac@T23KEMPF> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk James Kempf wrote: > The upshot of what I am saying is that I believe this is not a > purely > technical problem. There are sociological and business aspects > of it that suggest a solution which leverages off the existing > authentication/business infrastructure is likely to be more of interest > to > existing ISPs and future wireless ISPs. > > Now, that said, I agree that an infrastructureless solution may be of > interest in some circumstances. It may even be of interest to ISPs, > if the details are right. But I don't think there will ever be a case > where an ISP will let a host on their network without requiring > some kind of authentication as to the right of that host to use > the network (unless, of course, the ISP is giving away the > service). True. However, I wouldn't like to design the Internet _just_ for the ISPs and the commercial providers. If I'm a small business or a home, I want to set-up my networks without infrastructure, and I want it to "just work". For instance, I could lay a network in my home, expect IPv6 to work without major holes even if I might be using open wireless LANs, and I would also expect to use other types of infrastructureless technology, such SSH for my e-mail forwarding and telnetting needs. I don't want to set-up anything, unless we can prove that it is necessary. And it doesn't appear to be, based on proof by example i.e. some proposals that don't need infrastructure. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 10:00:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EI0OKL027055 for ; Thu, 14 Mar 2002 10:00:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EI0OSw027054 for ipng-dist; Thu, 14 Mar 2002 10:00:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EI0LKL027047 for ; Thu, 14 Mar 2002 10:00:21 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA21873 for ; Thu, 14 Mar 2002 10:00:23 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA01906 for ; Thu, 14 Mar 2002 11:00:23 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2EHxiI01055; Thu, 14 Mar 2002 09:59:44 -0800 (PST) Message-ID: <019d01c1cb81$cc2bb240$7e6015ac@T23KEMPF> From: "James Kempf" To: "Jari Arkko" Cc: "Pekka Nikander" , "Dan McDonald" , "Markku Savela" , References: <200203132221.g2DMLNUC000974@kebe.east.sun.com> <00ec01c1caf2$8dbfacd0$7e6015ac@T23KEMPF> <3C904D23.4010805@nomadiclab.com> <006001c1cb78$75c51990$7e6015ac@T23KEMPF> <3C90D7D6.A9925A9A@lmf.ericsson.se> Subject: Re: Securing Neighbor Discovery Date: Thu, 14 Mar 2002 09:58:07 -0800 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, So, this is getting a little off topic for this list, perhaps we should move the discussion elsewhere? Final comments below. > However, I wouldn't like to design the Internet _just_ for > the ISPs and the commercial providers. If I'm a small business > or a home, I want to set-up my networks without infrastructure, > and I want it to "just work". For instance, I could lay a > network in my home, expect IPv6 to work without major > holes even if I might be using open wireless LANs, and I > would also expect to use other types of infrastructureless > technology, such SSH for my e-mail forwarding and telnetting > needs. I don't want to set-up anything, unless we can > prove that it is necessary. And it doesn't appear to be, > based on proof by example i.e. some proposals that don't > need infrastructure. > I don't want to denigate the importance of SOHO and small networks. Small networks are OK, but designing something for the Internet based on an assumed small network configuration would be a mistake, IMHO. The 802.11 committee made this mistake, and now we are trying to get some attention to fixing it. What I'm concerned about specifically is the upcoming deployment of public access IPv6/802.11 networks that have no security on ND. This is a looming real problem, and I'd like to see the IETF develop some interoperability specs to address it before it happens instead of afterwards. So I'm not arguing from a theoretical or assumed future scenerio case, but from a problem that I see looming right now (NTT is deploying a prototype 802.11 network in Kyoto at the moment). I think the design needs to accommodate both small networks and large networks, i.e. it must be scalable. I think that can be achieved by providing space to leverage off the existing authentication infrastructure if it is there. If it isn't, then infrastructureless methods are, of course, appropriate. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 10:38:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EIcJKL027125 for ; Thu, 14 Mar 2002 10:38:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EIcJxO027124 for ipng-dist; Thu, 14 Mar 2002 10:38:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EIcFKL027117 for ; Thu, 14 Mar 2002 10:38:15 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02007 for ; Thu, 14 Mar 2002 10:38:16 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08080 for ; Thu, 14 Mar 2002 10:38:17 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2EIaht13799; Thu, 14 Mar 2002 13:36:45 -0500 (EST) Message-Id: <200203141836.g2EIaht13799@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Savola cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Antonio Querubin , ipng@sunroof.eng.sun.com Subject: Re: IPV6_JOIN_GROUP for v4 multicast In-reply-to: (Your message of "Thu, 14 Mar 2002 07:33:54 +0200.") Date: Thu, 14 Mar 2002 13:36:43 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Who wants an application that can work _only_ with IPv6? Nobody. strongly disagree. IPv6 provides capabilities that simply don't exist in IPv4 - among them the ability to provide large numbers of stable addresses. In other words, IPv6 enables applications that cannot be widely deployed under IPv4, and for that reason it's entirely reasonable to write applications for IPv6 only. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 11:33:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EJXwKL027239 for ; Thu, 14 Mar 2002 11:33:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EJXvBS027238 for ipng-dist; Thu, 14 Mar 2002 11:33:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EJXsKL027231 for ; Thu, 14 Mar 2002 11:33:54 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA17402 for ; Thu, 14 Mar 2002 11:33:56 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26297 for ; Thu, 14 Mar 2002 12:33:54 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2EJXUA21507; Thu, 14 Mar 2002 21:33:31 +0200 Date: Thu, 14 Mar 2002 21:33:30 +0200 (EET) From: Pekka Savola To: Keith Moore cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , Antonio Querubin , Subject: Re: IPV6_JOIN_GROUP for v4 multicast In-Reply-To: <200203141836.g2EIaht13799@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 14 Mar 2002, Keith Moore wrote: > > Who wants an application that can work _only_ with IPv6? Nobody. > > strongly disagree. IPv6 provides capabilities that simply don't > exist in IPv4 - among them the ability to provide large numbers of > stable addresses. In other words, IPv6 enables applications that > cannot be widely deployed under IPv4, and for that reason it's > entirely reasonable to write applications for IPv6 only. In this context, we're talking about an application that already existed for IPv4; entirely new kind of applications _might_ be written for IPv6 only at some point, but that's an entirely different issue. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 13:03:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EL3VKL027370 for ; Thu, 14 Mar 2002 13:03:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EL3UVi027369 for ipng-dist; Thu, 14 Mar 2002 13:03:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EL3OKL027362 for ; Thu, 14 Mar 2002 13:03:24 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10072 for ; Thu, 14 Mar 2002 13:03:23 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA08372 for ; Thu, 14 Mar 2002 14:03:22 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00730; Thu, 14 Mar 2002 16:03:18 -0500 (EST) Message-Id: <200203142103.QAA00730@ietf.org> To: IETF-Announce: ; cc: ipng@sunroof.eng.sun.com From: The IESG SUBJECT: Last Call: Default Address Selection for IPv6 to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 14 Mar 2002 16:03:18 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has received a request from the IP Version 6 Working Group Working Group to consider Default Address Selection for IPv6 as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by April 4, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipv6-default-addr-select-07.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 Thu Mar 14 14:29:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EMTUKL027634 for ; Thu, 14 Mar 2002 14:29:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EMTU1x027633 for ipng-dist; Thu, 14 Mar 2002 14:29:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EMTQKL027626 for ; Thu, 14 Mar 2002 14:29:26 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10715 for ; Thu, 14 Mar 2002 14:29:27 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08595 for ; Thu, 14 Mar 2002 15:29:10 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2EMT9R04889 for ; Thu, 14 Mar 2002 23:29:09 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 14 23:29:09 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 23:19:13 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB17@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'James Kempf'" , "Jari Arkko (LMF)" Cc: Pekka Nikander , Dan McDonald , Markku Savela , ipng@sunroof.eng.sun.com Subject: RE: Securing Neighbor Discovery Date: Thu, 14 Mar 2002 23:29:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [Sorry if this is not directly relevant to the list but it must be said...] > I think the design needs to accommodate both small networks and > large networks, i.e. it must be scalable. I think that can be > achieved by providing space to leverage off the existing > authentication => In fact, the most scalable solutions will be achieved using e2e and infrastructureless mechanisms. I know that a lot of network operators think that they will make more money or have 'control' if most functions are performed in the network. Overusing this philosophy will, IMHO, lead to detrimental results for these operators. Operators can certainly make money out of controlling some services, but it's only the ones that matter! Trying to control everything will only lead to more complexity and cost. In general, replacing control with creativity will lead to much better results IMHO. my 2 cents Hesham > infrastructure if it is there. If it isn't, then infrastructureless > methods > are, of course, appropriate. > > jak > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 14 14:49:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EMnkKL027660 for ; Thu, 14 Mar 2002 14:49:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EMnkjY027659 for ipng-dist; Thu, 14 Mar 2002 14:49:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EMngKL027652 for ; Thu, 14 Mar 2002 14:49:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA16702 for ; Thu, 14 Mar 2002 14:49:44 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18496 for ; Thu, 14 Mar 2002 15:49:43 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2EMn4I10909; Thu, 14 Mar 2002 14:49:04 -0800 (PST) Message-ID: <091d01c1cbaa$37a873f0$7e6015ac@T23KEMPF> From: "James Kempf" To: "Hesham Soliman \(ERA\)" , "Jari Arkko \(LMF\)" Cc: "Pekka Nikander" , "Dan McDonald" , "Markku Savela" , References: <4DA6EA82906FD511BE2F00508BCF053802C6AB17@Esealnt861.al.sw.ericsson.se> Subject: Re: Securing Neighbor Discovery Date: Thu, 14 Mar 2002 14:47:28 -0800 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, > > I think the design needs to accommodate both small networks and > > large networks, i.e. it must be scalable. I think that can be > > achieved by providing space to leverage off the existing > > authentication > > => In fact, the most scalable solutions will be > achieved using e2e and infrastructureless mechanisms. > I know that a lot of network operators think that > they will make more money or have 'control' if > most functions are performed in the network. > Overusing this philosophy will, IMHO, lead to > detrimental results for these operators. > Operators can certainly make money out of > controlling some services, but it's only the > ones that matter! Trying to control everything > will only lead to more complexity and cost. > In general, replacing control with creativity > will lead to much better results IMHO. > Let's take it to the new list to discuss securing ND. Or, we can talk about it in MN. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 14:51:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EMpFKL027677 for ; Thu, 14 Mar 2002 14:51:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2EMpEXJ027676 for ipng-dist; Thu, 14 Mar 2002 14:51:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EMpBKL027669 for ; Thu, 14 Mar 2002 14:51:11 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA22031 for ; Thu, 14 Mar 2002 14:51:12 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA13626 for ; Thu, 14 Mar 2002 15:51:11 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2EMpAR07378 for ; Thu, 14 Mar 2002 23:51:10 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 14 23:51:09 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 14 Mar 2002 23:41:13 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB1A@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: ipng@sunroof.eng.sun.com Subject: next steps for the cellular host draft Date: Thu, 14 Mar 2002 23:51:08 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Based on the discussions on the mailing list, some off-line discussions and new developments, the authors of the cellular host draft would like to suggest a possible way forward in this area. Basically the suggestion is: - The IPv6 WG will work a generic IPv6 Node Requirements draft. Work towards this shall be started in Minneapolis. This draft will be Standards Track. - A new IPv6 over Foo document will be produced. This is also Standards Track document. This work has started. - The current cellular host draft becomes an Informational and non-prescriptive document (possibly no keywords? to be discussed further in Minneapolis?) which is more like a document roadmap plus issues for hosts of certain category. The category is narrowly defined subset of the second and third generation cellular hosts. The second and third items are the most urgent ones for 3GPP. However, the authors of the cellular host draft are eager to contribute on all of the above work items. Additionally, we would like to note the following: - All current issues in the cellular host requirements document are resolved as per WG consensus. (An earlier e-mail had a suggestion for the resolutions.) - We'd like to name the Informational document "Implementation Guidelines for IPv6 in 2G and 3G Cellular Hosts". - The title of the IPv6 over Foo document needs thought. Potential candidates for Foo include PDP and UMTS but neither is exactly correct. Input is sought on this. Comments are welcome. Cheers, Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 16:53:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F0rAKL028041 for ; Thu, 14 Mar 2002 16:53:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F0rA70028040 for ipng-dist; Thu, 14 Mar 2002 16:53:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F0r5KL028033 for ; Thu, 14 Mar 2002 16:53:07 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA17967 for ; Thu, 14 Mar 2002 16:53:07 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA06568 for ; Thu, 14 Mar 2002 17:53:06 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA17206; Thu, 14 Mar 2002 16:53:05 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2F0r5Z01232; Thu, 14 Mar 2002 16:53:05 -0800 X-mProtect:  Thu, 14 Mar 2002 16:53:05 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpds1IT85; Thu, 14 Mar 2002 16:53:02 PST Message-Id: <4.3.2.7.2.20020314124616.024acbe0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Mar 2002 16:50:48 -0800 To: IPng List From: Bob Hinden Subject: Updated IPv6 working group agenda for Minneapolis IETF Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The updated agenda is attached. The changes were to remove the zero time slot for the address selection draft because an IETF last call has been started and to move the second IPv6 Node Requirements talk to Thursday as was originally intended. Bob ------------------------------------------------------------------------- MONDAY, March 18, 2002, 1930-2200 Introduction, Steve Deering, 5 min. Review Agenda, Steve Deering, 5 min. Document Status, Bob Hinden, 15 min. Moving IPv6 Documents to Draft Standard, Margaret Wasserman, 30 min. Default Router Preferences and More-Specific Routes, Rich Draves, 15 min. DNS Discovery Update, Dave Thaler, 15 min. IPv6 Node Requirements, John Loughney, 10 min. Minimum IPv6 Functionality for a Cellular Host, Hesham Soliman, 30 min. Minimum Requirements of IPv6 for Low Cost Network Appliances, Atsushi Inoue, 10 min. THURSDAY, March 21, 2002 min. IPv6 Node Requirements followup, John Loughney, 5 min. Prefix Delegation Intro, Steve Deering, 10 min. Automatic Prefix Delegation Protocol for IPV6, Brian Haberman , 10 min. DHCPv6 Prefix Delegation, Ralph Droms, 10 min. IPv6 Router Advertisement Prefix Delegation Option, Nathan Lutchansky, 10 min. Prefix Delegation Discussion, Steve Deering, 15 min. IPv6 Flow Label Specification, Jarno Rajahalme, 45 min. Reserving bits in RFC 2473 Interface IDs?, Erik Nordmark, 20 min. Make IMEI-based universal IPv6 interface IDs a w.g. Draft?, Francis Dupont, 5 min. Scoped Address Architecture Update, Tatuya Jinmei, 10 min. --------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 14 17:13:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F1DMKL028077 for ; Thu, 14 Mar 2002 17:13:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F1DMG8028076 for ipng-dist; Thu, 14 Mar 2002 17:13:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F1DJKL028069 for ; Thu, 14 Mar 2002 17:13:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09224 for ; Thu, 14 Mar 2002 17:13:22 -0800 (PST) Received: from dhcp185.64translator.com (82.180.32.202.ts.2iij.net [202.32.180.82]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA27574 for ; Thu, 14 Mar 2002 18:13:21 -0700 (MST) Received: from dhcp185.64translator.com (localhost [127.0.0.1]) by dhcp185.64translator.com (8.10.2/8.10.2) with ESMTP id g2F1DUk15785 for ; Fri, 15 Mar 2002 10:13:30 +0900 (JST) Date: Fri, 15 Mar 2002 10:13:29 +0900 Mime-Version: 1.0 (Apple Message framework v481) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: TAHI Test Event Report is available From: Hiroshi MIYATA To: ipng@sunroof.eng.sun.com Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.481) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, We had held "The 3rd TAHI IPv6 Interoperability test event" in january. 27 organizations had participated in this event. The report of this event is already available. Visit here. http://www.tahi.org/presentation/3rd-interop/ Regards, ..... Hiroshi MIYATA @ TAHI Project -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 14 17:51:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F1p2KL028168 for ; Thu, 14 Mar 2002 17:51:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F1p1Tl028167 for ipng-dist; Thu, 14 Mar 2002 17:51:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F1owKL028160 for ; Thu, 14 Mar 2002 17:50:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA28951 for ; Thu, 14 Mar 2002 17:50:58 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id SAA23754 for ; Thu, 14 Mar 2002 18:50:56 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 266894B24; Fri, 15 Mar 2002 10:50:53 +0900 (JST) To: "James Kempf" Cc: ipng@sunroof.eng.sun.com In-reply-to: kempf's message of Thu, 14 Mar 2002 09:58:07 PST. <019d01c1cb81$cc2bb240$7e6015ac@T23KEMPF> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Securing Neighbor Discovery From: itojun@iijlab.net Date: Fri, 15 Mar 2002 10:50:53 +0900 Message-ID: <20462.1016157053@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >So, this is getting a little off topic for this list, perhaps >we should move the discussion elsewhere? I guess so. >I don't want to denigate the importance of SOHO and small >networks. Small networks are OK, but designing >something for the Internet based on an assumed small network >configuration would be a mistake, IMHO. The 802.11 >committee made this mistake, and now we are trying >to get some attention to fixing it. > >What I'm concerned about specifically is the upcoming >deployment of public access IPv6/802.11 networks that >have no security on ND. This is a looming real problem, and >I'd like to see the IETF develop some interoperability >specs to address it before it happens instead of afterwards. >So I'm not arguing from a theoretical or assumed future >scenerio case, but from a problem that I see looming >right now (NTT is deploying a prototype 802.11 network in >Kyoto at the moment). one thing i don't understand is, why do you think it is not a problem for ARP, and is a problem for ND. 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 Thu Mar 14 17:53:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F1rhKL028185 for ; Thu, 14 Mar 2002 17:53:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F1rhUC028184 for ipng-dist; Thu, 14 Mar 2002 17:53:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F1reKL028177 for ; Thu, 14 Mar 2002 17:53:40 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18733 for ; Thu, 14 Mar 2002 17:53:41 -0800 (PST) From: Jonne.Soininen@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA13378 for ; Thu, 14 Mar 2002 18:53:40 -0700 (MST) Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2F1rnZ07653 for ; Fri, 15 Mar 2002 03:53:50 +0200 (EET) Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 14 Mar 2002 19:53:31 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 14 Mar 2002 19:53:15 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next steps on Reserving bits in RFC 2473 Interface IDs? Date: Thu, 14 Mar 2002 17:53:14 -0800 Message-ID: <4D7B558499107545BB45044C63822DDE0A0790@mvebe001.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next steps on Reserving bits in RFC 2473 Interface IDs? Thread-Index: AcHKyk7K9yFmZVrtQiCUlrFeM/Ud7AA+MUFw To: , Cc: , , X-OriginalArrivalTime: 15 Mar 2002 01:53:15.0503 (UTC) FILETIME=[2BFBB7F0:01C1CBC4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2F1reKL028178 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Alexandru, I would be a bit careful to use IMEI as Interface Identifier. I am not really sure if this is something you want to tell the whole world. (I know that Francis has a draft out on this topic, and no I have not read it, yet.) For instance, when the 3GPP mechanism of address allocation was designed in 3GPP, one of the criteria was not to show the IMEI. This is kind of confidential information from the end user point of view. In addition, it might not always be unique... Cheers, Jonne. > -----Original Message----- > From: ext Alexandru Petrescu [mailto:petrescu@crm.mot.com] > Sent: Wednesday, March 13, 2002 12:02 PM > To: Steve Deering > Cc: Alberto Escudero-Pascual; Erik Nordmark; ipng@sunroof.eng.sun.com > Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? > > > Steve Deering writes: > > The u bit in the current IID definition indicates whether or not the > > IID can be considered globally unique. > > I'm trying to fit the IMEI into one of: > > Links or Nodes with IEEE EUI-64 Identifiers > Links or Nodes with IEEE 802 48 bit MAC's > Links with Non-Global Identifiers > Links without Identifiers > > and I can not fit into any, since it looks than an IMEI is global but > is neither an EUI-64 identifier, nor an IEEE 802 48 MAC address. > However, the link can not be considered as a link without > identifiers[*]. > > IMEI being global I'm tempted to touch the u bit (universal/local). > > IMEI has nothing in it that could influence the g bit > (individual/group), but further investigation is necessary probably. > > Alex > > [*] or can it? I guess that phones have IMEI's but their peers at the > other end of the link (GSNS/SGNS) don't. > > > > When trying to > code other identifiers into Modified EUI-64, I wonder whether the > individial/group bit should also be set/reset, in addition to the > universal/local bit. > > Also, why EUI-64 was adopted as basis and not any other? I understand > that this easily covers 802 LAN's, but why not something more agnostic > like > > If it was chosen > as the preferred coding for Interface ID's for global unicast > addresses, and as such as an umbrella for other identifiers, was > > I understand that > Modified EUI-64 is to be used with all global unicast addresses > > The zero value (implying *not* > > globally unique) is used not only for randomly-generated ("privacy") > > IIDs but also for manually-assigned IIDs, and IIDs assigned via DHCP > > that are not derived from the node's IEEE-802 or EUI-64 address. In > > other words, u=0 does *not* mean randomly generated; it means not- > > globally-unique. > > > > 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 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 14 18:00:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F20RKL028215 for ; Thu, 14 Mar 2002 18:00:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F20QlU028214 for ipng-dist; Thu, 14 Mar 2002 18:00:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F20NKL028207 for ; Thu, 14 Mar 2002 18:00:23 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA00451; Thu, 14 Mar 2002 18:00:24 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA04185; Thu, 14 Mar 2002 18:00:26 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA21174; Thu, 14 Mar 2002 17:59:52 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2F1xpv23227; Thu, 14 Mar 2002 17:59:51 -0800 X-mProtect:  Thu, 14 Mar 2002 17:59:51 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdeVUyEZ; Thu, 14 Mar 2002 17:59:48 PST Message-Id: <4.3.2.7.2.20020314175238.02477b10@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Mar 2002 17:58:22 -0800 To: Erik.Nordmark@eng.sun.com, Thomas Narten From: Bob Hinden Subject: Request to Advance "Recommendations for IPv6 in 3GPP Standards" Cc: ipng@sunroof.eng.sun.com, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as an Informational RFC: Title : Recommendations for IPv6 in 3GPP Standards Author(s) : M. Wasserman Filename : draft-ietf-ipv6-3gpp-recommend-00.txt Pages : 22 Date : 22-Jan-02 A working group last call for this document was completed on March 11, 2002. Bob Hinden / Steve Deering IPv6 Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 14 23:19:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F7JYKL028818 for ; Thu, 14 Mar 2002 23:19:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F7JYLf028817 for ipng-dist; Thu, 14 Mar 2002 23:19:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F7JVKL028810 for ; Thu, 14 Mar 2002 23:19:31 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12560 for ; Thu, 14 Mar 2002 23:19:33 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA11139 for ; Fri, 15 Mar 2002 00:19:32 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2F7Iug31567; Fri, 15 Mar 2002 09:18:56 +0200 Date: Fri, 15 Mar 2002 09:18:56 +0200 (EET) From: Pekka Savola To: Hiroshi MIYATA cc: ipng@sunroof.eng.sun.com Subject: Re: TAHI Test Event Report is available In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 15 Mar 2002, Hiroshi MIYATA wrote: > We had held "The 3rd TAHI IPv6 Interoperability test event" in january. > 27 organizations had participated in this event. > > The report of this event is already available. > Visit here. > http://www.tahi.org/presentation/3rd-interop/ Where are the results? Not on that page, at least. (There are only a few pictures, list of participants and testing there.) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 14 23:47:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F7l8KL029029 for ; Thu, 14 Mar 2002 23:47:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F7l89B029028 for ipng-dist; Thu, 14 Mar 2002 23:47:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F7l5KL029018 for ; Thu, 14 Mar 2002 23:47:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA15326 for ; Thu, 14 Mar 2002 23:47:05 -0800 (PST) Received: from dhcp185.64translator.com (82.180.32.202.ts.2iij.net [202.32.180.82]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA01591 for ; Fri, 15 Mar 2002 00:47:02 -0700 (MST) Received: from dhcp185.64translator.com (localhost [127.0.0.1]) by dhcp185.64translator.com (8.10.2/8.10.2) with ESMTP id g2F7l9k17531; Fri, 15 Mar 2002 16:47:09 +0900 (JST) Date: Fri, 15 Mar 2002 16:47:09 +0900 Subject: Re: TAHI Test Event Report is available Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: ipng@sunroof.eng.sun.com To: Pekka Savola From: Hiroshi MIYATA In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry we can not disclose the test results because of NDA. On 2002.03.15, at 16:18, Pekka Savola wrote: > On Fri, 15 Mar 2002, Hiroshi MIYATA wrote: >> We had held "The 3rd TAHI IPv6 Interoperability test event" in january. >> 27 organizations had participated in this event. >> >> The report of this event is already available. >> Visit here. >> http://www.tahi.org/presentation/3rd-interop/ > > Where are the results? Not on that page, at least. (There are only a > few > pictures, list of participants and testing there.) > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Fri Mar 15 00:56:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F8uuKL029106 for ; Fri, 15 Mar 2002 00:56:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F8uukv029105 for ipng-dist; Fri, 15 Mar 2002 00:56:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F8urKL029098 for ; Fri, 15 Mar 2002 00:56:53 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA12462 for ; Fri, 15 Mar 2002 00:56:54 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA10738 for ; Fri, 15 Mar 2002 01:56:52 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2F8upf32230; Fri, 15 Mar 2002 10:56:51 +0200 Date: Fri, 15 Mar 2002 10:56:51 +0200 (EET) From: Pekka Savola To: IPng List cc: Bob Hinden Subject: Rh-hosts and 127-prefixlen [Re: IPv6 working group agenda for Minneapolis IETF] In-Reply-To: <4.3.2.7.2.20020313165036.03dcfe20@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 13 Mar 2002, Bob Hinden wrote: > The draft agenda is attached. When we put together the agenda we give > priority to work the chairs and AD's thought was most important. There > were a number of request for agenda slots that could not be > honored. Suggest these topics be brought to the mailing list. As there was unfortunately no time, I'd like to ask your feedback on: http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-hosts-00.txt http://www.ietf.org/internet-drafts/draft-savola-ipv6-127-prefixlen-01.txt Rh-hosts draft hasn't generated much of discussion since it left mobile-ip working group. I believe this will become unnecessary when host requirements includes similar discussion. But do we have to do something in the interim period? 127-prefixlen has genererated quite a lot of discussion, both back in Novermeber and now, and we seem to have reached some kind of a consensus on the contents. The most important question I stated for which there have replies is, what should be do with this? E.g.: 1) this is a non-issue, no need to do anything 2) wait for e.g. router requirements (could take a long time), what to do in the mean time? 3) push for individual informational 4) adapt as w.g. document, push for informational others? This is something I'd have liked to gauge in the w.g. meeting. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 15 01:50:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F9okKL029232 for ; Fri, 15 Mar 2002 01:50:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F9okJC029231 for ipng-dist; Fri, 15 Mar 2002 01:50:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F9ohKL029224 for ; Fri, 15 Mar 2002 01:50:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA28981 for ; Fri, 15 Mar 2002 01:50:44 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10666 for ; Fri, 15 Mar 2002 02:50:43 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3114C8F4D; Fri, 15 Mar 2002 04:50:43 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 15 Mar 2002 04:50:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: PPP and Global Addresses Date: Fri, 15 Mar 2002 04:50:42 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B371@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP and Global Addresses Thread-Index: AcHJrt6ZpJjf44hYR0qcPdf1yYuLgQCVs7rA From: "Bound, Jim" To: "Yamasaki Toshi" Cc: X-OriginalArrivalTime: 15 Mar 2002 09:50:43.0112 (UTC) FILETIME=[DF49F280:01C1CC06] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2F9ohKL029225 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Toshi-san, > Jim-san, > > Thank you for your thoughtful opinions and advices. Again, I > believe this thank you for your kind words. > "ISP-to-Customer site-configuration" is one of the most > urgent issues for > the WG, because no non-technical customers can join to IPv6 > world unless we > provide any solution. This positive discussion will help us > to solve the > issue. Very true and very important we need to make this clear to customers. > > > > Then, there seems three proposals shown below for this > > > purpose. What is your opinion for each proposed mechanism? > > > > OK. But I want to apply these to real deployment and can't > do that on > first read. So my responses at this point are an > architectural view not an > implementation view which I will have by the IETF meeting I hope. > > Understand. FYI, some ISPs will (or want to) start IPv6/DSL services > hopefully in 2002, and we will see some working-in-commercial-services > implementations soon. Yes and good point. Also Hitachi did a talk here about their routers (Madrid IPv6 Summit) and it appears the DSL business is real for sure. As I said there are some initial dhcpv6 implementations and we have lots of stateless addr conf. For 2002 I doubt in best case we can get working group consensus till at least the December IETF meeting in 2002 so we will need to do this with vendor products as custom solution for 2002. But lets not wait to deploy DSL with IPv6. I can get into this with you offline how one can proceed wearing my implementation hat for prefix delegation. > > > So I can see having two approaches to solve the link or off line > situations. But the DHCP6+PD is more robust and can be used in all > situations. APD+RA+PD is the lightweight solution. > > I agree with your opinion that APD is the minimally required > lightweight > solution and DHCPv6 is the "FULL-SERVICE" solution. > It's not clear to me how you think the RA+PD proposal be > merged into APD. > Could you kindly explain the details? I think Brian Haberman's draft -02 added pieces I thought were missing like lifetimes, and releases. So maybe that has already taken place. > > > I agree but I believe we can have a stateless and stateful > solution for > different needs. > > Absolutely. thank you, /jim > > --- Toshi Yamasaki / NTT Communications > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 15 01:53:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F9rSKL029249 for ; Fri, 15 Mar 2002 01:53:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2F9rSSc029248 for ipng-dist; Fri, 15 Mar 2002 01:53:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2F9rOKL029241 for ; Fri, 15 Mar 2002 01:53:24 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA24553 for ; Fri, 15 Mar 2002 01:53:26 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA14132 for ; Fri, 15 Mar 2002 02:53:25 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 93C6D8DF3; Fri, 15 Mar 2002 04:53:24 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 15 Mar 2002 04:53:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: PPP and Global Addresses Date: Fri, 15 Mar 2002 04:53:23 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520900@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PPP and Global Addresses Thread-Index: AcHJ0vicCgganNSXRwCvMDsgi7gsiQCNCsww From: "Bound, Jim" To: "Ole Troan" Cc: "Yamasaki Toshi" , X-OriginalArrivalTime: 15 Mar 2002 09:53:24.0580 (UTC) FILETIME=[3F880240:01C1CC07] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2F9rPKL029242 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ole, > > I agree but I believe we can have a stateless and stateful solution > > for different needs. > > I think prefix delegation is inherently stateful. both DHCP PD and > ICMP PD are as such stateful protocols. that is, the delegating party > has to keep track of which prefixes are assigned where. > > if anyone disagrees, please explain where the statelessness comes into > the picture. Good point........ /jim > > /ot > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 15 02:05:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FA5OKL029292 for ; Fri, 15 Mar 2002 02:05:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FA5OhQ029291 for ipng-dist; Fri, 15 Mar 2002 02:05:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FA5LKL029284 for ; Fri, 15 Mar 2002 02:05:21 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00613 for ; Fri, 15 Mar 2002 02:05:22 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA18125 for ; Fri, 15 Mar 2002 03:05:21 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id C9E755964; Fri, 15 Mar 2002 05:05:16 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 15 Mar 2002 05:05:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: next steps for the cellular host draft Date: Fri, 15 Mar 2002 05:05:16 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520902@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: next steps for the cellular host draft Thread-Index: AcHLqwIkFCGFTXFbQrm8LL1/X3QQmAAXc9rQ From: "Bound, Jim" To: "Hesham Soliman (ERA)" , X-OriginalArrivalTime: 15 Mar 2002 10:05:16.0801 (UTC) FILETIME=[E80C4F10:01C1CC08] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2FA5LKL029285 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk this sounds really good. congratulations working group............ /jim > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Thursday, March 14, 2002 5:51 PM > To: ipng@sunroof.eng.sun.com > Subject: next steps for the cellular host draft > > > > Based on the discussions on the mailing > list, some off-line discussions and > new developments, the authors of the > cellular host draft would like to > suggest a possible way forward in this > area. > > Basically the suggestion is: > > - The IPv6 WG will work a generic > IPv6 Node Requirements draft. > Work towards this shall be started > in Minneapolis. This draft will > be Standards Track. > > - A new IPv6 over Foo document will > be produced. This is also Standards > Track document. This work has started. > > - The current cellular host draft becomes > an Informational and non-prescriptive > document (possibly no keywords? to be > discussed further in Minneapolis?) > which is more like a document roadmap plus > issues for hosts of certain category. The > category is narrowly defined subset of the > second and third generation cellular hosts. > > The second and third items are the most urgent > ones for 3GPP. However, the authors of the cellular > host draft are eager to contribute on all of the > above work items. > > Additionally, we would like to note > the following: > > - All current issues in the cellular > host requirements document are resolved > as per WG consensus. (An earlier e-mail > had a suggestion for the resolutions.) > > - We'd like to name the Informational > document "Implementation Guidelines > for IPv6 in 2G and 3G Cellular Hosts". > > - The title of the IPv6 over Foo document > needs thought. Potential candidates > for Foo include PDP and UMTS but neither > is exactly correct. Input is sought on > this. > > Comments are welcome. > > Cheers, > Hesham > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Fri Mar 15 02:09:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FA9HKL029314 for ; Fri, 15 Mar 2002 02:09:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FA9HAY029313 for ipng-dist; Fri, 15 Mar 2002 02:09:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FA9EKL029306 for ; Fri, 15 Mar 2002 02:09:14 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA19588 for ; Fri, 15 Mar 2002 02:09:15 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA03593 for ; Fri, 15 Mar 2002 02:09:16 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 2BF442FD3; Fri, 15 Mar 2002 05:09:14 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 15 Mar 2002 05:09:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TAHI Test Event Report is available Date: Fri, 15 Mar 2002 05:09:13 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520904@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TAHI Test Event Report is available Thread-Index: AcHL9dtpsBJDIyimQ5id7YnvopqzdwAE1dTQ From: "Bound, Jim" To: "Hiroshi MIYATA" , "Pekka Savola" Cc: X-OriginalArrivalTime: 15 Mar 2002 10:09:14.0090 (UTC) FILETIME=[757BBCA0:01C1CC09] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2FA9EKL029307 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk same is true for ETSI and UNH test suites. The reason is that we want vendors to come to test events with AD work too or in process code. If they get blasted on web page that they are not compliant then they will not come. This is pretty standard and same at Connectathon last week which was quite wonderful I am hearing from reports of IPv6 and MObile IPv6 and IPsec interoperability. /jim > -----Original Message----- > From: Hiroshi MIYATA [mailto:H.Miyata@jp.yokogawa.com] > Sent: Friday, March 15, 2002 2:47 AM > To: Pekka Savola > Cc: ipng@sunroof.eng.sun.com > Subject: Re: TAHI Test Event Report is available > > > Sorry we can not disclose the test results because of NDA. > > > On 2002.03.15, at 16:18, Pekka Savola wrote: > > > On Fri, 15 Mar 2002, Hiroshi MIYATA wrote: > >> We had held "The 3rd TAHI IPv6 Interoperability test > event" in january. > >> 27 organizations had participated in this event. > >> > >> The report of this event is already available. > >> Visit here. > >> http://www.tahi.org/presentation/3rd-interop/ > > > > Where are the results? Not on that page, at least. (There > are only a > > few > > pictures, list of participants and testing there.) > > > > -- > > Pekka Savola "Tell me of difficulties surmounted, > > Netcore Oy not those you stumble over and fall" > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Fri Mar 15 02:20:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FAKHKL029375 for ; Fri, 15 Mar 2002 02:20:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FAKHnC029374 for ipng-dist; Fri, 15 Mar 2002 02:20:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FAKEKL029367 for ; Fri, 15 Mar 2002 02:20:14 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02117 for ; Fri, 15 Mar 2002 02:20:16 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05567 for ; Fri, 15 Mar 2002 02:20:17 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2FAJVK00404; Fri, 15 Mar 2002 12:19:31 +0200 Date: Fri, 15 Mar 2002 12:19:31 +0200 (EET) From: Pekka Savola To: "Bound, Jim" cc: Hiroshi MIYATA , Subject: RE: TAHI Test Event Report is available In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B01520904@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 15 Mar 2002, Bound, Jim wrote: > same is true for ETSI and UNH test suites. > > The reason is that we want vendors to come to test events with AD work > too or in process code. If they get blasted on web page that they are > not compliant then they will not come. > > This is pretty standard and same at Connectathon last week which was > quite wonderful I am hearing from reports of IPv6 and MObile IPv6 and > IPsec interoperability. Well, personally I was looking at least for some statistics (xx % passed/failed this test, etc.).. or use some other form of obfuscation (name them vendor 1, 2, ..., N). > > /jim > > > -----Original Message----- > > From: Hiroshi MIYATA [mailto:H.Miyata@jp.yokogawa.com] > > Sent: Friday, March 15, 2002 2:47 AM > > To: Pekka Savola > > Cc: ipng@sunroof.eng.sun.com > > Subject: Re: TAHI Test Event Report is available > > > > > > Sorry we can not disclose the test results because of NDA. > > > > > > On 2002.03.15, at 16:18, Pekka Savola wrote: > > > > > On Fri, 15 Mar 2002, Hiroshi MIYATA wrote: > > >> We had held "The 3rd TAHI IPv6 Interoperability test > > event" in january. > > >> 27 organizations had participated in this event. > > >> > > >> The report of this event is already available. > > >> Visit here. > > >> http://www.tahi.org/presentation/3rd-interop/ > > > > > > Where are the results? Not on that page, at least. (There > > are only a > > > few > > > pictures, list of participants and testing there.) > > > > > > -- > > > Pekka Savola "Tell me of difficulties surmounted, > > > Netcore Oy not those you stumble over and fall" > > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home 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 > > -------------------------------------------------------------------- > > > -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 15 03:21:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FBL0KL029451 for ; Fri, 15 Mar 2002 03:21:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FBL0In029450 for ipng-dist; Fri, 15 Mar 2002 03:21:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FBKvKL029443 for ; Fri, 15 Mar 2002 03:20:57 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA25784 for ; Fri, 15 Mar 2002 03:20:57 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17954 for ; Fri, 15 Mar 2002 03:20:58 -0800 (PST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1969F379F; Fri, 15 Mar 2002 06:20:56 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Fri, 15 Mar 2002 06:20:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TAHI Test Event Report is available Date: Fri, 15 Mar 2002 06:20:55 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520908@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TAHI Test Event Report is available Thread-Index: AcHMCuz47fC8qBsiQKmm1jGOVRvWSgACC8iw From: "Bound, Jim" To: "Pekka Savola" Cc: "Hiroshi MIYATA" , X-OriginalArrivalTime: 15 Mar 2002 11:20:55.0953 (UTC) FILETIME=[7997F010:01C1CC13] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2FBKvKL029444 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk yeah we used to do this for the unh stuff. that is probably ok to do. let me go ping all the testing folks and see if this can be done. the argument against it was as follows: if people bring their AD stuff and say fail 70% of the cases which may be good and ok as they are debugging next releases. If we say that in the press someone will take that out of context and say that the vendors shipping IPv6 will failed 705 of the tests :------------) but there is probably away around media paranoia which is valid paranoia for IPv6. /jim > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi] > Sent: Friday, March 15, 2002 5:20 AM > To: Bound, Jim > Cc: Hiroshi MIYATA; ipng@sunroof.eng.sun.com > Subject: RE: TAHI Test Event Report is available > > > On Fri, 15 Mar 2002, Bound, Jim wrote: > > same is true for ETSI and UNH test suites. > > > > The reason is that we want vendors to come to test events > with AD work > > too or in process code. If they get blasted on web page > that they are > > not compliant then they will not come. > > > > This is pretty standard and same at Connectathon last week which was > > quite wonderful I am hearing from reports of IPv6 and > MObile IPv6 and > > IPsec interoperability. > > Well, personally I was looking at least for some statistics (xx % > passed/failed this test, etc.).. or use some other form of > obfuscation > (name them vendor 1, 2, ..., N). > > > > > /jim > > > > > -----Original Message----- > > > From: Hiroshi MIYATA [mailto:H.Miyata@jp.yokogawa.com] > > > Sent: Friday, March 15, 2002 2:47 AM > > > To: Pekka Savola > > > Cc: ipng@sunroof.eng.sun.com > > > Subject: Re: TAHI Test Event Report is available > > > > > > > > > Sorry we can not disclose the test results because of NDA. > > > > > > > > > On 2002.03.15, at 16:18, Pekka Savola wrote: > > > > > > > On Fri, 15 Mar 2002, Hiroshi MIYATA wrote: > > > >> We had held "The 3rd TAHI IPv6 Interoperability test > > > event" in january. > > > >> 27 organizations had participated in this event. > > > >> > > > >> The report of this event is already available. > > > >> Visit here. > > > >> http://www.tahi.org/presentation/3rd-interop/ > > > > > > > > Where are the results? Not on that page, at least. (There > > > are only a > > > > few > > > > pictures, list of participants and testing there.) > > > > > > > > -- > > > > Pekka Savola "Tell me of difficulties > surmounted, > > > > Netcore Oy not those you stumble over > and fall" > > > > Systems. Networks. Security. -- Robert Jordan: A Crown > of Swords > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPng Working Group Mailing List > > > > IPng Home 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 > > > > -------------------------------------------------------------------- > > > > > > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 15 05:42:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FDgdKL029603 for ; Fri, 15 Mar 2002 05:42:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FDgd1S029602 for ipng-dist; Fri, 15 Mar 2002 05:42:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FDgaKL029595 for ; Fri, 15 Mar 2002 05:42:36 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07581 for ; Fri, 15 Mar 2002 05:42:37 -0800 (PST) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14382 for ; Fri, 15 Mar 2002 06:42:36 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id GAA23727; Fri, 15 Mar 2002 06:42:28 -0700 (MST)] Received: [from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id GAA18753; Fri, 15 Mar 2002 06:42:27 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr02.mot.com (8.11.6/8.11.6) with ESMTP id g2FDg6T06842; Fri, 15 Mar 2002 07:42:07 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 51EC52EC85; Fri, 15 Mar 2002 14:42:00 +0100 (CET) To: Cc: , , , Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: <4D7B558499107545BB45044C63822DDE0A0790@mvebe001.NOE.Nokia.com> From: Alexandru Petrescu Date: 15 Mar 2002 14:42:00 +0100 In-Reply-To: <4D7B558499107545BB45044C63822DDE0A0790@mvebe001.NOE.Nokia.com> Message-ID: Lines: 37 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jonne.Soininen@nokia.com writes: > I would be a bit careful to use IMEI as Interface Identifier. Hi Jonne, please let me assure you that I'm trying to be very careful in all this. If I speak out so frequently is just because I need to better understand how IPv6 and 3GPP/UMTS can be made to work together. If I'm diverging too much from the list's topic, please stop me. > I am not really sure if this is something you want to tell the whole > world. Ok, privacy, yes. Alberto mentioned that not necessarily the IMEI should be coded but a hash of it, periodically updated starting from a nonce. > This is kind of confidential information from the end user point of > view. Aha, confidential, then it's not to be put in IPv6 addresses that are not confidential. > In addition, it might not always be unique... IMEI not being unique? That's bad, again. Then it's probably true that some id's are more unique than other id's. So I try something else than IMEI: IMSI. As IMEI is for phones, IMSI is in the SIM cards. Is the IMSI private? Is it unique? What are the other identifiers in the GSM/3GPP/UMTS? Phone number? Would an IMT2000 identifier be better adapted, since it has a wider reach, more neutral. Thanks for any info, I need to cover them all, the id's :-) Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 15 10:16:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FIGAKL000103 for ; Fri, 15 Mar 2002 10:16:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FIGAuB000102 for ipng-dist; Fri, 15 Mar 2002 10:16:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FIG7KL000095 for ; Fri, 15 Mar 2002 10:16:07 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA20992 for ; Fri, 15 Mar 2002 10:16:09 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA25814 for ; Fri, 15 Mar 2002 11:16:05 -0700 (MST) Received: from T23KEMPF (dhcp126.docomolabs-usa.com [172.21.96.126]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2FIEUI05431; Fri, 15 Mar 2002 10:14:31 -0800 (PST) Message-ID: <003e01c1cc4d$078db4c0$7e6015ac@T23KEMPF> From: "James Kempf" To: Cc: References: <20462.1016157053@itojun.org> Subject: Re: Securing Neighbor Discovery Date: Fri, 15 Mar 2002 10:12:55 -0800 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > one thing i don't understand is, why do you think it is not a problem > for ARP, and is a problem for ND. > It is a problem for ARP. To be complete, we should have a solution there too. jak -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 15 13:23:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FLNYKL002309 for ; Fri, 15 Mar 2002 13:23:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FLNYB9002308 for ipng-dist; Fri, 15 Mar 2002 13:23:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FLNVKL002301 for ; Fri, 15 Mar 2002 13:23:31 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10459 for ; Fri, 15 Mar 2002 13:23:33 -0800 (PST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22720 for ; Fri, 15 Mar 2002 14:23:32 -0700 (MST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA57066 for ; Fri, 15 Mar 2002 15:17:59 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g2FLNUq175956 for ; Fri, 15 Mar 2002 16:23:30 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g2FLL3Z03035 for ; Fri, 15 Mar 2002 16:21:03 -0500 Message-Id: <200203152121.g2FLL3Z03035@rotala.raleigh.ibm.com> To: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipv6-flow-label-00.txt Date: Fri, 15 Mar 2002 16:21:03 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hmm. There was much discussion in SLC on the Flow Label. Quite a lot of mail in the weeks immediately after SLC. Then quiet. Then a new ID appears. More silence. Something like 45 minutes of agenda time has been allocated next week for the topic. Has no one had time to read the draft yet? :-) Here are some high-level comments for folks to think about. The scope of the document could be narrowed. I think its focus might better be just what a host and router MUST do in order to be compliant. There is a fair amount of additional text that talks about MAYs with regards to possible usages. It could say more about what a host is supposed to do. It says a host MAY set the flow label, for instance, rather than what it MUST do. I think it would be better for the document to say a HOST just sets it to 0. Or, if that is not right, what it SHOULD/MUST do. We want predictable behavior from the originating hosts. In fact, the document might just have too many MAYs. It seems like it is trying to not make it illegal for someone to experiment with the flow label. I'm OK with that, but that doesn't need to be put in the spec as MAYs. It should be clear what RFC-compliant implementations are supposed to do. Not sure it needs to say anything more. People are always free to experiment. There is perhaps too much wording about what signaling (and "methods") should do with the flow label. IMO, much (all?) of this is future work, and this document shouldn't constrain it in anyway. For example, there may well be too much wording about how one might use the flow label. For example, there is wording about allowing the receiver to tell the sender what flow label should be used. This seems premature. There is even wording that suggests classifiers need to handle wildcarding of the source and dest fields in the tuple. Not sure how much of that is appropriate. In summary, I think it would be good for this document to make it clear exactly what compliant hosts and routers MUST do. Trying to say anything more than that may tending towards speculation that is premature. Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 15 13:54:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FLsaKL002382 for ; Fri, 15 Mar 2002 13:54:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2FLsaCI002381 for ipng-dist; Fri, 15 Mar 2002 13:54:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FLsXKL002374 for ; Fri, 15 Mar 2002 13:54:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA19643 for ; Fri, 15 Mar 2002 13:54:34 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-177.evrtwa1.vz.dsl.gtei.net [4.60.69.177]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA15004 for ; Fri, 15 Mar 2002 14:54:33 -0700 (MST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Fri, 15 Mar 2002 13:54:32 -0800 From: "Tony Hain" To: "Thomas Narten" , Subject: RE: draft-ietf-ipv6-flow-label-00.txt Date: Fri, 15 Mar 2002 13:54:31 -0800 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200203152121.g2FLL3Z03035@rotala.raleigh.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Narten wrote: > Has no one had time to read > the draft yet? :-) No, but thanks for the reminder & comments. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 15 16:28:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2G0SsKL003349 for ; Fri, 15 Mar 2002 16:28:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2G0SsG2003348 for ipng-dist; Fri, 15 Mar 2002 16:28:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2G0SoKL003341 for ; Fri, 15 Mar 2002 16:28:51 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA10627 for ; Fri, 15 Mar 2002 16:28:52 -0800 (PST) From: Jonne.Soininen@nokia.com Received: from mgw-dax2.ext.nokia.com (mgw-dax2.ext.nokia.com [63.78.179.217]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03467 for ; Fri, 15 Mar 2002 17:28:51 -0700 (MST) Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85]) by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2G0V7x02019 for ; Fri, 15 Mar 2002 18:31:07 -0600 (CST) Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 15 Mar 2002 18:28:49 -0600 Received: from mvebe001.NOE.Nokia.com ([172.18.140.37]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Fri, 15 Mar 2002 18:27:32 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Next steps on Reserving bits in RFC 2473 Interface IDs? Date: Fri, 15 Mar 2002 16:27:31 -0800 Message-ID: <4D7B558499107545BB45044C63822DDE0A0794@mvebe001.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next steps on Reserving bits in RFC 2473 Interface IDs? Thread-Index: AcHMJ0ZKIs24em+WTbKDlg/Z+Y77EgAWGyhQ To: Cc: , , , X-OriginalArrivalTime: 16 Mar 2002 00:27:32.0936 (UTC) FILETIME=[5D300480:01C1CC81] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2G0SpKL003342 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, > -----Original Message----- > From: ext Alexandru Petrescu [mailto:petrescu@crm.mot.com] > Jonne.Soininen@nokia.com writes: > > I would be a bit careful to use IMEI as Interface Identifier. > > Hi Jonne, please let me assure you that I'm trying to be very careful > in all this. If I speak out so frequently is just because I need to > better understand how IPv6 and 3GPP/UMTS can be made to work together. > If I'm diverging too much from the list's topic, please stop me. JSo: I do not if this is outside the scope, but I think the issue of making 3GPP/UMTS to work with IPv6 has been rather thoroughly researched. There has been done work in 3GPP, and the functionality is specified in the 3GPP specs. I can provide you with pointers to the docs off-line, if you wish. In addition, we had the IPv6-3GPP design team working on this issue last year. You can see the results in http://search.ietf.org/internet-drafts/draft-ietf-ipv6-3gpp-recommend-00.txt. > > > I am not really sure if this is something you want to tell the whole > > world. > > Ok, privacy, yes. Alberto mentioned that not necessarily the IMEI > should be coded but a hash of it, periodically updated starting from a > nonce. > > > This is kind of confidential information from the end user point of > > view. > > Aha, confidential, then it's not to be put in IPv6 addresses that are > not confidential. > The problem with IMEIs are that they are used in GSM, GPRS, and UMTS networks to screen stolen handsets. This makes additional requirements for privacy, and confidentiality of the IMEI value. > > In addition, it might not always be unique... > > IMEI not being unique? That's bad, again. Then it's probably true > that some id's are more unique than other id's. I had phone once that for some reason had a different IMEI electronically than what was printed on the back of the phone. I am not sure if that was the mistake of the person putting the wrong label on the phone... (It was not from the manufacturer that I currently work for... ;) > > So I try something else than IMEI: IMSI. As IMEI is for phones, IMSI > is in the SIM cards. Is the IMSI private? Is it unique? IMSI is very unique, but alas very private. That should never be shown outside the mobile network. (IMSI=International Mobile Subscriber Identification, if I remember correctly.) > > What are the other identifiers in the GSM/3GPP/UMTS? Phone number? Would you like your phone number to be shown on your IP address if you are using your modem over a telephone line. With all those telemarketers around... ;) > > Would an IMT2000 identifier be better adapted, since it has a wider > reach, more neutral. I am not sure what you are referring to. Something standardized in ITU? -Jonne. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 15 16:44:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2G0ikKL003377 for ; Fri, 15 Mar 2002 16:44:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2G0ikfE003376 for ipng-dist; Fri, 15 Mar 2002 16:44:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2G0ihKL003369 for ; Fri, 15 Mar 2002 16:44:43 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA14399 for ; Fri, 15 Mar 2002 16:44:44 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12300 for ; Fri, 15 Mar 2002 16:44:44 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id g2G0igR09149 for ; Sat, 16 Mar 2002 01:44:43 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Sat Mar 16 01:44:42 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sat, 16 Mar 2002 01:34:45 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB42@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Jonne.Soininen@nokia.com'" , petrescu@crm.mot.com Cc: deering@cisco.com, aep@it.kth.se, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: RE: Next steps on Reserving bits in RFC 2473 Interface IDs? Date: Sat, 16 Mar 2002 01:44:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > So I try something else than IMEI: IMSI. As IMEI is for phones, IMSI > is in the SIM cards. Is the IMSI private? Is it unique? IMSI is very unique, but alas very private. That should never be shown outside the mobile network. (IMSI=International Mobile Subscriber Identification, if I remember correctly.) => Yeah, IMSI identifies users/subscribers, so it's definitely not a good idea to put it into the IP address. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 02:18:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HAIdKL006021 for ; Sun, 17 Mar 2002 02:18:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HAIddP006020 for ipng-dist; Sun, 17 Mar 2002 02:18:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HAIaKL006013 for ; Sun, 17 Mar 2002 02:18:36 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA15436 for ; Sun, 17 Mar 2002 02:18:37 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21694 for ; Sun, 17 Mar 2002 02:18:41 -0800 (PST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g2HAIVg22367; Sun, 17 Mar 2002 02:18:31 -0800 (PST) From: Bill Manning Message-Id: <200203171018.g2HAIVg22367@boreas.isi.edu> Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt In-Reply-To: <20020306.124107.112630528.nov@tahi.org> from OKABE Nobuo at "Mar 6, 2 12:41:07 pm" To: nov@tahi.org (OKABE Nobuo) Date: Sun, 17 Mar 2002 02:18:31 -0800 (PST) Cc: pekkas@netcore.fi, tiny@tahi.org, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk % If so, I think ID should refer RFC1886, then nibble-style, of cause. % % But I have a question. % What domain should be the right stuff, % ip6.int or ip6.arpa, or both? % Please tell us WG consensus. % Its not WG consensus but it is true that it appears unlikly that ICANN will ever fully populate the IP6.ARPA zone. It turns out to be a subset of what is in the IP6.INT zone. The IESG approved RFC 30xx (61,16, something like that) that instructs ICANN to only populate the IP6.ARPA zone with prefixes delegated by the RIRs. Since a good chunk of IPv6 space was delegated prior to the RIRs participation in IPv6, the rules the IESG has given to ICANN prevent ICANN from doing the "right" thing. So what do you think is the right thing to do? -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 05:22:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HDM3KL006386 for ; Sun, 17 Mar 2002 05:22:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HDM3Qh006385 for ipng-dist; Sun, 17 Mar 2002 05:22:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HDM0KL006378 for ; Sun, 17 Mar 2002 05:22:00 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA07199 for ; Sun, 17 Mar 2002 05:22:01 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11714 for ; Sun, 17 Mar 2002 05:22:04 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2HDLnI27204; Sun, 17 Mar 2002 15:21:50 +0200 Date: Sun, 17 Mar 2002 15:21:49 +0200 (EET) From: Pekka Savola To: ot@cisco.com cc: rdroms@cisco.com, Subject: DHCPv6 + prefix delegation comments. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, A few comments to the DHCPv6 + prefix delegation draft. --8<-- 5.1 IA Prefix option [...] The lease-duration is expressed in seconds. The prefix-length gives the number of bits in the prefix carried in this option. To reduce the number of octets used for this option, the IPv6 prefix is represented in ceiling(prefix-length/8) octets. ==> I think the ceiling function should be spelled out a bit differently for clarity. 5.2 IA Prefix Request option [...] prefix-length: Prefix length for the requested global-scope prefixes. A value of zero (0) indicates that the requesting router will accept any prefix length provided by the delegating router. ==> Don't site-locals have a prefix length at all? num-global: The number of global-scope prefixes requested. A value of 0 indicates that the requesting router is not requesting any prefixes. A value of -1 indicates that the requesting router does not indicate a preference. num-site: The number of site-scope prefixes requested. A value of 0 indicates that the requesting router is not requesting any prefixes. A value of -1 indicates that the requesting router does not indicate a preference. ==> What does -1 actually signify: how are the fields coded? I'm assuming they're unsigned numbers and -1 is just a shorthand notation for 255; if so, 255 should be used instead. ==> Would it be better to say, "A value of 255 means any number of prefixes will be accepted"? 7.2 Delegating router behavior [xxx] an ISP; dyanmic assignment from a pool of available prefixes; selection based on an external authority such as a RADIUS server. ==> s/dyanmic/dynamic/ 8. Requesting-router-initiated prefix delegation ==> Requesting router-initiated.. 8.1 Requesting router behavior [...] If the requesting router subnets a delegated prefix, it must assign additional bits to the prefix to generate unique, longer prefixes. For example, if the requesting router were delegated DEAD:BEEF:CAFE:0::/48, it might generate DEAD:BEEF:CAFE:0001::/64 and DEAD:BEEF:CAFE:0002::/64 for assignment to the two links in the subscriber network. ==> It would probably be better use prefixes from under 3FFE:FFFF. 8.2 Delegating Router Behavior [...] Upon the receipt of a valid Decline message, the delegating router examines the IA options and the IA Prefix options for validity. If the IAs in the message are in a binding for the requesting router and the prefixes in the IAs have been assigned by the delegating router to those IA, the delegating router deletes the prefix(es) from the IAs. The delegating router MAY choose to make a notification that prefixes were declined. ==> what kind of notification? 9. Delegating Router-initiated prefix delegation reconfiguration ==> s/Delegating // 9.1 Delegating Router behavior [...] 9.2 Requesting Router behvaior [...] ==> should operations which are recommended when renumbering like this be discussed (e.g. immediate sending of new router advertisements in the subnet)? 11. Security Considerations [...] An intruder requesting router may be able to mount a denial of service attack by repeated requests for delegated prefixes that exhaust the delegating router's available prefixes. To guard against attacks through prefix delegation, requesting routers and delegating routers SHOULD use DHCP authentication as described in section "Authentication of DHCP messages" in the DHCP specification. ==> this gives only partial protection to the intruder problem above: or is it ok that theoretically authentic clients can exhaust the prefix pool or such too? ==> perhaps accidental delegation of site-prefixes outside of the site could be a problem here too -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 05:38:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HDcTKL006476 for ; Sun, 17 Mar 2002 05:38:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HDcTl1006475 for ipng-dist; Sun, 17 Mar 2002 05:38:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HDcQKL006468 for ; Sun, 17 Mar 2002 05:38:26 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA26302 for ; Sun, 17 Mar 2002 05:38:27 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA14474 for ; Sun, 17 Mar 2002 05:38:26 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2HDcNh27320; Sun, 17 Mar 2002 15:38:24 +0200 Date: Sun, 17 Mar 2002 15:38:23 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com cc: dthaler@microsoft.com, Subject: DNS discovery -04 comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Just two points: In the abstract, s/the stateful protocol/stateful protocols/ ? In 3.2, Host behaviour of looking up NS record from the reverse of site-locals may fail for a couple of reasons: e.g. the site could use multiple domain names, or if the site has no reverses for site-locals, they might be looked up from somewhere else (as recursion is desired).. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 06:24:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HEOkKL006583 for ; Sun, 17 Mar 2002 06:24:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HEOkO0006582 for ipng-dist; Sun, 17 Mar 2002 06:24:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HEOhKL006575 for ; Sun, 17 Mar 2002 06:24:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03389 for ; Sun, 17 Mar 2002 06:24:44 -0800 (PST) Received: from qwerty.ssvl.kth.se (qwerty.ssvl.kth.se [192.16.125.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22149 for ; Sun, 17 Mar 2002 07:24:43 -0700 (MST) Received: from localhost (qwerty.ssvl.kth.se [127.0.0.1]) by qwerty.ssvl.kth.se (8.11.2/8.11.2) with ESMTP id g2HEN7K15210 for ; Sun, 17 Mar 2002 15:23:07 +0100 Date: Sun, 17 Mar 2002 15:23:07 +0100 (CET) From: Alberto Escudero-Pascual X-X-Sender: cc: Subject: DHCPv6 and u/l bit In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (MUST, SHOULD) the (stateful) addresses provided by a DHCPv6 have the "u" bit to 0 as manual configuration? If i buy a 1000 Ethernet cards and keep them in a box under the table and set the u bit to 1 and provide those EUI-64 to my users? /aep -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 06:42:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HEgxKL006612 for ; Sun, 17 Mar 2002 06:42:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HEgwRc006611 for ipng-dist; Sun, 17 Mar 2002 06:42:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HEgtKL006604 for ; Sun, 17 Mar 2002 06:42:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17002 for ; Sun, 17 Mar 2002 06:42:55 -0800 (PST) Received: from cichlid.adsl.duke.edu ([166.63.189.230]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA14174 for ; Sun, 17 Mar 2002 07:42:55 -0700 (MST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g2HEf1703907; Sun, 17 Mar 2002 09:41:02 -0500 Message-Id: <200203171441.g2HEf1703907@cichlid.adsl.duke.edu> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: sra@hactrn.net, ipng@sunroof.eng.sun.com Subject: Deployability/Useability of Multicast [was: Re: PPP and Global Addresses ] In-Reply-To: Message from JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= of "Wed, 13 Mar 2002 23:00:03 +0900." Date: Sun, 17 Mar 2002 09:41:01 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= writes: > I admit that DHCPv6 only with information resources is also simple. > However, in order to apply DHCPv6 in the real network, we'll need > - a DHCPv6 relay agent (basically) in every subnet, or Not really a problem, as all routers today have relay agent support. In DHCPv4, the issue is configuring them. With DHCPv6, they don't need configuring, they use multicast to find the servers. > - multicast routing when we use a well-known multicast addresses for > DHCP servers I'd like the WG to think about this point very carefully. In hallway discussions in SLC, it was asserted to me that the existance of IP multicast, in home or enterprise networks (as opposed to WANs and backbones) was not something that IPv6 could depend on. For example, I was told by one individual that SLP wasn't a viable solution for service discovery because it relies in multicast. Hence, DNS Discovery couldn't just use SLP. The implications of this assertion are very significant. If site-wide multicast cannot be assumed, it means basic infrastrcuture protocols (like DHCP, SLP, etc.), *where* they depend on multicast, won't work, and we may need to invent protocols (or extensions) that don't have these shortcomings. On the other hand, extending an existing protocol or inventing a new one also has a cost associated with it - perhaps higher than the cost of getting multicast into a state where it can be relied upon. So, I'd like to ask the WG: 1) Do people think that the existance of multicast within a site (e.g., home, enterprise, etc.) can be assumed? Note: I'm assuming link-local multicast will always work, the question is whether wider scope (beyond neighboring routers) multicast is available. 2) If the answer is "can't assume multicast is present", what should be done about it. e.g., - What are the barriers that are preventing multicast from being an assumed part of the infrastructure? What is needed to remove those barriers? - Which infrastructure protocols does IPv6 rely on that assume the existance of multicast, and how are they limited if multicast is not available? Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 07:19:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HFJ3KL006665 for ; Sun, 17 Mar 2002 07:19:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HFJ3Oi006664 for ipng-dist; Sun, 17 Mar 2002 07:19:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HFJ0KL006657 for ; Sun, 17 Mar 2002 07:19:00 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21081 for ; Sun, 17 Mar 2002 07:19:01 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19325 for ; Sun, 17 Mar 2002 08:18:59 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2HFOnv01809; Sun, 17 Mar 2002 22:24:50 +0700 (ICT) From: Robert Elz To: Alberto Escudero-Pascual cc: ipng@sunroof.eng.sun.com Subject: Re: DHCPv6 and u/l bit In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 17 Mar 2002 22:24:49 +0700 Message-ID: <1807.1016378689@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 17 Mar 2002 15:23:07 +0100 (CET) From: Alberto Escudero-Pascual Message-ID: | (MUST, SHOULD) the (stateful) addresses provided by a DHCPv6 have the "u" | bit to 0 as manual configuration? They MAY (SHOULD is perhaps reasonable as a default setting). | If i buy a 1000 Ethernet cards and keep | them in a box under the table and set the u bit to 1 and provide those | EUI-64 to my users? It would be cheaper to buy an OUI from IEEE - you get lots more EUI's for a much lower price... I see no reason why you couldn't do that. But IPv6 addreses are delegated by a registry, or by someone delegated a bigger block than you need, making sub-delegations. They give you a /n. What you do with the 128-n bits inside that delegation is entirely your business, and you don't have to take the slightest bit of notice of anything anyone else claims that you should do. Of course, you should be aware of the consequences of your decisions, but whether you are or not, it is your address space for as long as the assignment of the prefix to you remains valiue, you decide how it gets apportioned. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 08:10:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HGAAKL006709 for ; Sun, 17 Mar 2002 08:10:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HGAAj2006708 for ipng-dist; Sun, 17 Mar 2002 08:10:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HGA7KL006701 for ; Sun, 17 Mar 2002 08:10:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA16179 for ; Sun, 17 Mar 2002 08:10:07 -0800 (PST) Received: from qwerty.ssvl.kth.se (qwerty.ssvl.kth.se [192.16.125.203]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA13085 for ; Sun, 17 Mar 2002 09:10:06 -0700 (MST) Received: from localhost (qwerty.ssvl.kth.se [127.0.0.1]) by qwerty.ssvl.kth.se (8.11.2/8.11.2) with ESMTP id g2HG4BK15531; Sun, 17 Mar 2002 17:04:11 +0100 Date: Sun, 17 Mar 2002 17:04:10 +0100 (CET) From: Alberto Escudero-Pascual X-X-Sender: To: Robert Elz cc: Subject: Re: DHCPv6 and u/l bit In-Reply-To: <1807.1016378689@brandenburg.cs.mu.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert, Is this your opinion or is stated somewhere? > > They MAY (SHOULD is perhaps reasonable as a default setting). > -- -------------------------------------------------------------------------- That you are not paranoid, it doesn't mean that they are not watching you! http://www.it.kth.se/~aep -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 08:16:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HGG9KL006751 for ; Sun, 17 Mar 2002 08:16:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HGG8aM006750 for ipng-dist; Sun, 17 Mar 2002 08:16:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HGG5KL006743 for ; Sun, 17 Mar 2002 08:16:05 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04444 for ; Sun, 17 Mar 2002 08:16:06 -0800 (PST) Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA27138 for ; Sun, 17 Mar 2002 09:16:05 -0700 (MST) Received: from dumbo.gmd.de (dumbo [193.175.132.239]) by mailhub.fokus.gmd.de (8.11.6/8.11.6) with SMTP id g2HGG2t28813; Sun, 17 Mar 2002 17:16:03 +0100 (MET) Received: by dumbo.gmd.de (SMI-8.6/SMI-SVR4) id RAA22020; Sun, 17 Mar 2002 17:07:00 +0100 Date: Sun, 17 Mar 2002 17:07:00 +0100 From: smirnow@fokus.gmd.de (Michael Smirnov) Message-Id: <200203171607.RAA22020@dumbo.gmd.de> To: jinmei@isl.rdc.toshiba.co.jp, narten@us.ibm.com Subject: Re: Deployability/Useability of Multicast [was: Re: PPP and Global Addresses ] Cc: sra@hactrn.net, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun Mar 17 15:44:36 2002 Thomas Narten wrote: <...> > So, I'd like to ask the WG: > > 1) Do people think that the existance of multicast within a site > (e.g., home, enterprise, etc.) can be assumed? > > Note: I'm assuming link-local multicast will always work, the > question is whether wider scope (beyond neighboring routers) > multicast is available. strong YES, however, imo it's always good to design a protocol with separation of concerns in mind. If, say, a service discovery needs multicast, that for some reason is not available, then there should be an option to use [e.g. manually configured] anycast instead. I believe that the question deserves to be discussed IETF-wide cheers Michael -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 08:55:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HGtbKL006877 for ; Sun, 17 Mar 2002 08:55:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HGtbIC006876 for ipng-dist; Sun, 17 Mar 2002 08:55:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HGtYKL006869 for ; Sun, 17 Mar 2002 08:55:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22141 for ; Sun, 17 Mar 2002 08:55:35 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA10670 for ; Sun, 17 Mar 2002 08:55:34 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2HH1lv02243; Mon, 18 Mar 2002 00:01:47 +0700 (ICT) From: Robert Elz To: Alberto Escudero-Pascual cc: ipng@sunroof.eng.sun.com Subject: Re: DHCPv6 and u/l bit In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Mar 2002 00:01:47 +0700 Message-ID: <2241.1016384507@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 17 Mar 2002 17:04:10 +0100 (CET) From: Alberto Escudero-Pascual Message-ID: | Is this your opinion or is stated somewhere? It is my opinion, and it should be stated somewhere... It is also a fact of life, there's nothing anyone can possibly do to control the way you use the addresses in a prefix delegated to you. It doesn't matter what the standards say, you still get to do what you like. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 09:07:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HH7JKL006897 for ; Sun, 17 Mar 2002 09:07:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HH7JsJ006896 for ipng-dist; Sun, 17 Mar 2002 09:07:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HH7GKL006889 for ; Sun, 17 Mar 2002 09:07:16 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07418 for ; Sun, 17 Mar 2002 09:07:17 -0800 (PST) Received: from tndh.net (evrtwa1-ar8-4-60-069-145.evrtwa1.vz.dsl.gtei.net [4.60.69.145]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05604 for ; Sun, 17 Mar 2002 09:07:16 -0800 (PST) Received: from eagleswings (127.0.0.1) by tndh.net (127.0.0.1) with [XMail 1.3 (Win32/Ix86) ESMTP Server] id for from ; Sun, 17 Mar 2002 09:07:18 -0800 From: "Tony Hain" To: "Robert Elz" , "Alberto Escudero-Pascual" Cc: Subject: RE: DHCPv6 and u/l bit Date: Sun, 17 Mar 2002 09:07:07 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <2241.1016384507@brandenburg.cs.mu.OZ.AU> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > Date: Sun, 17 Mar 2002 17:04:10 +0100 (CET) > From: Alberto Escudero-Pascual > Message-ID: > > > | Is this your opinion or is stated somewhere? > > It is my opinion, and it should be stated somewhere... It is also > a fact of life, there's nothing anyone can possibly do to control the > way you use the addresses in a prefix delegated to you. It doesn't > matter what the standards say, you still get to do what you like. > Yes this is a fact of life for the end user of the space, but the documents are targeted at various vendors supplying that end user. While the end user can choose to set the bits any way they like, their vendors are expected to follow a consistent set of rules so the end user knows what they are getting. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 09:32:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HHWaKL007004 for ; Sun, 17 Mar 2002 09:32:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HHWaUm007003 for ipng-dist; Sun, 17 Mar 2002 09:32:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HHWXKL006996 for ; Sun, 17 Mar 2002 09:32:33 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07273 for ; Sun, 17 Mar 2002 09:32:35 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23145 for ; Sun, 17 Mar 2002 10:32:33 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2HHcTv02382; Mon, 18 Mar 2002 00:38:35 +0700 (ICT) From: Robert Elz To: "Tony Hain" cc: "Alberto Escudero-Pascual" , ipng@sunroof.eng.sun.com Subject: Re: DHCPv6 and u/l bit In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Mar 2002 00:38:29 +0700 Message-ID: <2380.1016386709@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 17 Mar 2002 09:07:07 -0800 From: "Tony Hain" Message-ID: | Yes this is a fact of life for the end user of the space, but the | documents are targeted at various vendors supplying that end user. While | the end user can choose to set the bits any way they like, their vendors | are expected to follow a consistent set of rules so the end user knows | what they are getting. Wonderful. That's the right approach - can we all agree on that? First, that would answer Alberto's question the same way I did - he can config his DHCP server to return the u (& g) bits in any state he likes. Second, it will mean that the gibberish in 2373bis about u==1 implying a globally unique IID can go in the trash where it belongs, and we can keep the u bit the same as it was in 2373. That is, we tell the implementors what they're supposed to do, but not go on to ascribe some unrealisable meaning to the value of the bit if seen in an address. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 09:57:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HHvUKL007048 for ; Sun, 17 Mar 2002 09:57:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HHvUkc007047 for ipng-dist; Sun, 17 Mar 2002 09:57:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HHvRKL007040 for ; Sun, 17 Mar 2002 09:57:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA00762 for ; Sun, 17 Mar 2002 09:57:28 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA02551 for ; Sun, 17 Mar 2002 10:57:26 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id SAA197240; Sun, 17 Mar 2002 18:56:09 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2HHu4L54414; Sun, 17 Mar 2002 18:56:04 +0100 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA18684 from ; Sun, 17 Mar 2002 18:55:58 +0100 Message-Id: <3C94D89D.4E8E3029@hursley.ibm.com> Date: Sun, 17 Mar 2002 18:55:41 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Bill Manning Cc: OKABE Nobuo , pekkas@netcore.fi, tiny@tahi.org, ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt References: <200203171018.g2HAIVg22367@boreas.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Why wouldn't ICANN finish this job in the fullness of time? It's clear that the IETF decision is ip6.arpa so we just have to make it happen. Brian Bill Manning wrote: > > % If so, I think ID should refer RFC1886, then nibble-style, of cause. > % > % But I have a question. > % What domain should be the right stuff, > % ip6.int or ip6.arpa, or both? > % Please tell us WG consensus. > % > > Its not WG consensus but it is true that it appears unlikly that > ICANN will ever fully populate the IP6.ARPA zone. It turns out to > be a subset of what is in the IP6.INT zone. > > The IESG approved RFC 30xx (61,16, something like that) that > instructs ICANN to only populate the IP6.ARPA zone with prefixes > delegated by the RIRs. Since a good chunk of IPv6 space was > delegated prior to the RIRs participation in IPv6, the rules > the IESG has given to ICANN prevent ICANN from doing the "right" > thing. > > So what do you think is the right thing to do? > > -- > --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 10:03:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HI38KL007065 for ; Sun, 17 Mar 2002 10:03:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HI38Nt007064 for ipng-dist; Sun, 17 Mar 2002 10:03:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HI35KL007057 for ; Sun, 17 Mar 2002 10:03:05 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA02516 for ; Sun, 17 Mar 2002 10:03:07 -0800 (PST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05316 for ; Sun, 17 Mar 2002 10:03:05 -0800 (PST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id TAA72890 for ; Sun, 17 Mar 2002 19:02:49 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2HI2m922276 for ; Sun, 17 Mar 2002 19:02:49 +0100 Received: from gsine01.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA55150 from ; Sun, 17 Mar 2002 19:02:44 +0100 Message-Id: <3C94DA33.A8559924@hursley.ibm.com> Date: Sun, 17 Mar 2002 19:02:27 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-ietf-ipv6-flow-label-00.txt References: <200203152121.g2FLL3Z03035@rotala.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > It says a host > MAY set the flow label, for instance, rather than what it MUST do. I > think it would be better for the document to say a HOST just sets it > to 0. Or, if that is not right, what it SHOULD/MUST do. We want > predictable behavior from the originating hosts. But we can't do that realistically. A host may choose to set the flow label on no traffic at all, on particular types of traffic that it cares about, or on all traffic (unlikely). This will be a matter of local policy configuration, and/or the level of QOS support available in that particular version of that particular operating system. What this document attempts to say is what should happen in cases where hosts *choose* to activate the flow label. So the whole document is inevitably a MAY. Perhaps it would be better if that was explicit - an applicability statement written as a MAY, but SHOULDs in the body of the text to define the desired behaviour. Thanks for reading it anyway! Brian Thomas Narten wrote: > > Hmm. There was much discussion in SLC on the Flow Label. Quite a lot > of mail in the weeks immediately after SLC. Then quiet. Then a new ID > appears. More silence. Something like 45 minutes of agenda time has > been allocated next week for the topic. Has no one had time to read > the draft yet? :-) > > Here are some high-level comments for folks to think about. > > The scope of the document could be narrowed. I think its focus might > better be just what a host and router MUST do in order to be > compliant. There is a fair amount of additional text that talks about > MAYs with regards to possible usages. > > It could say more about what a host is supposed to do. It says a host > MAY set the flow label, for instance, rather than what it MUST do. I > think it would be better for the document to say a HOST just sets it > to 0. Or, if that is not right, what it SHOULD/MUST do. We want > predictable behavior from the originating hosts. > > In fact, the document might just have too many MAYs. It seems like it > is trying to not make it illegal for someone to experiment with the > flow label. I'm OK with that, but that doesn't need to be put in the > spec as MAYs. It should be clear what RFC-compliant implementations > are supposed to do. Not sure it needs to say anything more. People are > always free to experiment. > > There is perhaps too much wording about what signaling (and "methods") > should do with the flow label. IMO, much (all?) of this is future > work, and this document shouldn't constrain it in anyway. For example, > there may well be too much wording about how one might use the flow > label. For example, there is wording about allowing the receiver to > tell the sender what flow label should be used. This seems premature. > > There is even wording that suggests classifiers need to handle > wildcarding of the source and dest fields in the tuple. Not sure how > much of that is appropriate. > > In summary, I think it would be good for this document to make it > clear exactly what compliant hosts and routers MUST do. Trying to say > anything more than that may tending towards speculation that is > premature. > > Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 10:04:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HI4cKL007088 for ; Sun, 17 Mar 2002 10:04:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HI4bbw007087 for ipng-dist; Sun, 17 Mar 2002 10:04:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HI4YKL007080 for ; Sun, 17 Mar 2002 10:04:34 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11414 for ; Sun, 17 Mar 2002 10:04:36 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA20159 for ; Sun, 17 Mar 2002 10:04:35 -0800 (PST) Received: (from bmanning@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g2HI4QT01261; Sun, 17 Mar 2002 10:04:26 -0800 (PST) From: Bill Manning Message-Id: <200203171804.g2HI4QT01261@boreas.isi.edu> Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-01.txt In-Reply-To: <3C94D89D.4E8E3029@hursley.ibm.com> from Brian E Carpenter at "Mar 17, 2 06:55:41 pm" To: brian@hursley.ibm.com (Brian E Carpenter) Date: Sun, 17 Mar 2002 10:04:26 -0800 (PST) Cc: bmanning@ISI.EDU, nov@tahi.org, pekkas@netcore.fi, tiny@tahi.org, ipng@sunroof.eng.sun.com X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It can... as soon as all address delegations are handled by RIRs. All we have to do is not have any address delegations done through the IETF e.g. kill the 6bone or.... revise RFC 30xx to allow ICANN to update the zone based on IETF instruction. % Why wouldn't ICANN finish this job in the fullness of time? % % It's clear that the IETF decision is ip6.arpa so we just have to % make it happen. % % Brian % % Bill Manning wrote: % > % > % If so, I think ID should refer RFC1886, then nibble-style, of cause. % > % % > % But I have a question. % > % What domain should be the right stuff, % > % ip6.int or ip6.arpa, or both? % > % Please tell us WG consensus. % > % % > % > Its not WG consensus but it is true that it appears unlikly that % > ICANN will ever fully populate the IP6.ARPA zone. It turns out to % > be a subset of what is in the IP6.INT zone. % > % > The IESG approved RFC 30xx (61,16, something like that) that % > instructs ICANN to only populate the IP6.ARPA zone with prefixes % > delegated by the RIRs. Since a good chunk of IPv6 space was % > delegated prior to the RIRs participation in IPv6, the rules % > the IESG has given to ICANN prevent ICANN from doing the "right" % > thing. % > % > So what do you think is the right thing to do? % > % > -- % > --bill % -- --bill -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 11:33:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HJXDKL007174 for ; Sun, 17 Mar 2002 11:33:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HJXDUH007173 for ipng-dist; Sun, 17 Mar 2002 11:33:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HJXAKL007166 for ; Sun, 17 Mar 2002 11:33:10 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA23413 for ; Sun, 17 Mar 2002 11:33:11 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA11054 for ; Sun, 17 Mar 2002 12:33:10 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2HJX7T29913; Sun, 17 Mar 2002 21:33:08 +0200 Date: Sun, 17 Mar 2002 21:33:07 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com cc: richdr@microsoft.com Subject: router selection draft comments Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, A couple of comments on -01 draft. Most are just clarifications and similar. --8<-- Abstract This document describes an optional extension to Neighbor Discovery Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. ==> The preference values [...] could be removed IMO: this is being overly verbose detail for an abstract. 1. Introduction Neighbor Discovery [2] specifies a conceptual model for hosts that includes a Default Router List and a Prefix List. Hosts send Router Solicitation messages and receive from routers Router Advertisement messages. ==> s/receive from routers Router Advertisement messages/ receive Router Advertisement messages from routers/ Neighbor Discovery provides a Redirect message that routers can use to correct a host's choice of router. A router can send a Redirect message to a host, telling it to use a different router for a specific destination. However, the Redirect functionality is limited to a single link. A router on one link cannot redirect a host to a router on another link. Hence, Redirect messages do not help multi- homed hosts select an appropriate router. ==> Note about on-link redirecting. Usually, this is interpreted to mean: +- router1 -x - routerA --> host -| X +- router2 -x - routerB --> the only "trivial ones" are: traffic: host -> router1 -> router2 -> router{A,B}, router1 redirect -> router2 traffic: host -> router2 -> router1 -> router{A,B}, router2 redirect -> router1 One should note that on-link redirection _could_ theoretically be done for more complex scenarios (e.g. host -> router1 -> routerB, router1 send redirects to host for router2), but that would be difficult algorithmically. We use Router Advertisement messages, instead of some other protocol like RIP [5], is that Router Advertisements are an existing standard, stable protocol for router-to-host communication. ==> Because we use ... 2.2. Changes to Router Advertisement Message Format Prf (Default Router Preference) 2-bit signed integer. Indicates whether or not to prefer this router over other default routers. If Router Lifetime is zero, it MUST be initialized to zero by the sender and MUST be ignored by the receiver. If the Reserved (10) value is received, the receiver should treat the RA as having a zero Router Lifetime. ==> Is there a reason to specify any behaviour for 10 at this point? 2.3. Route Information Option Length 1, 2, or 3 depending on Prefix Length. If Prefix Length is greater than 64, then Length must be at least 3. If Prefix Length is greater than 0, then Length must be at least 2. If Prefix Length is zero, then Length may be 1. ==> Perhaps it would be best by defining that Length is the length of the option padded up to 8-byte blocks. 3.1. Conceptual Data Structures for Hosts Host B uses a Default Router List augmented with preference values. Host B does not have a routing table. Host B uses the Default Router Preference value in the Router Advertisement header. Host B ignores Route Information Options. ==> doesn't every host have a routing table of sorts..? Host C uses a Routing Table instead of a Default Router List. (The Routing Table may also subsume the Prefix List, but that is beyond the scope of this document.) Entries in the Routing Table have a prefix, prefix length, preference value, lifetime, and next-hop router. Host C uses both the Default Router Preference value in the Router Advertisement header and Route Information Options. ==> I think Routing Table shouldn't be capitalized, because it isn't an "official" term anywhere. When host C receives a Router Advertisement, it modifies its Routing Table as follows. If a route's lifetime is zero, the route is ==> s/If a route's/If the received route's/ prefix, prefix length, and next-hop router. When processing a Router Advertisment, host C first updates a ::/0 route based on the Router ==> Advertisement For example, suppose a host receives a Router Advertisement from router X with a Router Lifetime of 100 seconds and Default Router Preference of Medium. The body of the Router Advertisement contains a Route Information Option for ::/0 with a Route Lifetime of 200 seconds and a Route Preference of Low. After processing the Router Advertisement, host A will have an entry for router X in its Default Router List with lifetime 100 seconds. If host B receives the same Router Advertisement, it will have an entry in its Default Router List for router X with Medium preference and lifetime 100 seconds. Host C will have an entry in its Routing Table for ::/0 -> router X, with Low preference and lifetime 200 seconds. ==> Depending on the implementation, there may be a race condition if the implementation don't wait until the end of the processing of the whole message (first accept lifetime 100, pref=low for a very short time until the rest of the message is parsed). I'm not sure whether this is obvious or not.. 3.2. Conceptual Sending Algorithm for Hosts When host B does next-hop determination and consults its Default Router List, it first prefers reachable routers over non-reachable routers and second uses the router preference values. ==> first .. second sounds a bit awkward: "secondarily" would perhaps be a bit better, or via some rephrasing. If all default routers are not reachable, then it SHOULD round-robin among them all regardless of preference value. ==> s/not reachable/unreachable/ ==> Is this similar policy already used somewhere (e.g. RFC2461)? Some comparison with "old" mechanism in this case might be in order. If there are no routes matching the destination, then if host C has a single interface then it SHOULD assume the destination is on-link. If host C has multiple interfaces then it SHOULD discard the packet and report a Destination Unreachable / No Route To Destination error to the upper layer. ==> how does this relate to current mechanism? 3.4. Router Reachability Probing When a host avoids using a non-reachable router X and instead uses a reachable router Y, and the host would have used router X if router X were reachable, then the host SHOULD probe router XÆs reachability by sending a Neighbor Solicitation. These probes MUST be rate- limited to no more than one per minute per router. ==> ditto. 4. Router Configuration As one exception to this general rule, the administrator of a router that does not have a connection to the internet, or is connected through a firewall that blocks general traffic, may configure the router to advertise a Low Default Router Preference. ==> usually if there is such a policy in the firewall, it's there for a reason, and should not be tried to be avoided. Therefore, I think the firewall part of the above should be removed. Routers SHOULD NOT send more than 17 Route Information Options in Router Advertisements per link. ==> due to XXX? (MTU concerns?) 5.2. Multi-Homed Host and Isolated Network Here's another scenario: a multi-homed host is connected to the 6bone/internet via router X on one link and to an isolated network via router Y on another link. The multi-homed host might have a tunnel into a fire-walled corporate network, or it might be directly connected to an isolated test network. In this situation, a multi-homed host A (which has no default router preferences or more-specific routes) will have no way to choose between the two routers X and Y on its Default Router List. Users of the host will see unpredictable connectivity failures, depending on the destination address and the choice of router. ==> just a note: in this kind of scenario, there would be static routes in the nodes... -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 17 15:08:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HN8QKL007300 for ; Sun, 17 Mar 2002 15:08:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2HN8QTp007299 for ipng-dist; Sun, 17 Mar 2002 15:08:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2HN8NKL007292 for ; Sun, 17 Mar 2002 15:08:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA15609 for ; Sun, 17 Mar 2002 15:08:23 -0800 (PST) Received: from gate.alliedtelesyn.co.nz (gate.alliedtelesyn.co.nz [202.49.72.33]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA29958 for ; Sun, 17 Mar 2002 16:08:22 -0700 (MST) Received: (qmail 5739 invoked from network); 17 Mar 2002 23:08:21 -0000 Received: from aslan.alliedtelesyn.co.nz (HELO alliedtelesyn.co.nz) (202.49.74.92) by gate-int.alliedtelesyn.co.nz with SMTP; 17 Mar 2002 23:08:21 -0000 Received: from ASLAN/SpoolDir by alliedtelesyn.co.nz (Mercury 1.47); 18 Mar 02 11:08:20 +1300 Received: from SpoolDir by ASLAN (Mercury 1.47); 18 Mar 02 11:08:11 +1300 From: "Sean Lin" Organization: Allied Telesyn Research, Chch, NZ To: lutchann@litech.org, ipng@sunroof.eng.sun.com Date: Mon, 18 Mar 2002 11:08:09 +1300 (NZDST) MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: draft-lutchann-ipv6-delegate-option-00.txt Reply-to: sean.lin@alliedtelesyn.co.nz Message-ID: <3C95CA05.4598.3424E7B1@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Having read the above draft, i reckon that it is a very simple and effective mechanism for Prefix Delegation to implement. Also, in addition why not carry out the following prefix allocation in the diagram under Section 3.1. 1. Lb receives RA with prefix delegation option containing /56 prefix, e.g. aaaa:bbbb:cccc:dd::/56 2. If a bit in the prefix delegation option format is not set(stateless=0, stateful=1), then automatic assignment of /64 prefixes on Gx and Gy will be Gx <= aaaa:bbbb:cccc:dd01::/64 Gy <= aaaa:bbbb:cccc:dd02::/64 . . Gn <= aaaa:bbbb:cccc:ddff::/64 or depending on the site's requirements Lb <= /56 prefix Gx <= /58 prefix Gy <= /58 prefix and the length of the prefix to be allocated on the site link can be specified in the prefix delegation option format as well. Regards, Sean ------------------------------------------------------------- Sean Lin 27 Nazareth Avenue Software Engineer PO Box 8011 Allied Telesyn Research Christchurch phone +64 3 339 3000 New Zealand fax +64 3 339 3002 email: sean.lin@alliedtelesyn.co.nz web: http://www.alliedtelesyn.co.nz/ ------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 08:55:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IGteKL009182 for ; Mon, 18 Mar 2002 08:55:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IGteU4009181 for ipng-dist; Mon, 18 Mar 2002 08:55:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IGtbKL009174 for ; Mon, 18 Mar 2002 08:55:37 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA18045 for ; Mon, 18 Mar 2002 08:55:38 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA16547 for ; Mon, 18 Mar 2002 09:55:38 -0700 (MST) Received: from rdroms-w2k.cisco.com (sjc-vpn2-306.cisco.com [10.21.113.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA00592 for ; Mon, 18 Mar 2002 11:55:36 -0500 (EST) Message-Id: <4.3.2.7.2.20020318111334.00b4c278@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Mar 2002 11:55:32 -0500 To: IPng List From: Ralph Droms Subject: Re: IPv6 working group agenda for Minneapolis IETF In-Reply-To: <4.3.2.7.2.20020313165036.03dcfe20@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I read through RFC 2462 to find out the requirements level for host use of the 'O' flag field ("other stateful configuration") in RAs. The only text I found concerning the 'O' flag is" (section 4, Protocol Overview) Solicitations to the all-routers multicast group. Router Advertisements contain two flags indicating what type of stateful autoconfiguration (if any) should be performed. A "managed address configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain addresses. An "other stateful configuration" flag indicates whether hosts should use stateful autoconfiguration to obtain additional information (excluding addresses). (section 5.2, Autoconfiguration-Related Variables) OtherConfigFlag Copied from the O flag field (i.e., the "other stateful configuration" flag) of the most recently received Router Advertisement message. The flag indicates whether or not information other than addresses is to be obtained using the stateful autoconfiguration mechanism. It starts out in a FALSE state. In addition, when the value of the ManagedFlag is TRUE, the value of OtherConfigFlag is implicitly TRUE as well. It is not a valid configuration for a host to use stateful address autoconfiguration to request addresses only, without also accepting other configuration information. (section 5.5.3, Router Advertisement Processing) An advertisement's O flag field is processed in an analogous manner. A host copies the value of the O flag into OtherConfigFlag. If the value of OtherConfigFlag changes from FALSE to TRUE, the host should invoke the stateful autoconfiguration protocol, requesting information (excluding addresses if ManagedFlag is set to FALSE). If the value of the OtherConfigFlag changes from TRUE to FALSE, the host should continue running the stateful address autoconfiguration protocol, i.e., the change in the value of OtherConfigFlag has no effect. If the value of the flag stays unchanged, no special action takes place. In particular, a host MUST NOT reinvoke stateful configuration if it is already participating in the stateful protocol as a result of an earlier advertisement. So, RFC 2462 only uses RFC 2119 keywords to describe the behavior of a host when the value of the 'O' flag remains unchanged. The text in section 5.5.3 needs to be updated to: If the value of OtherConfigFlag changes from FALSE to TRUE, the host MUST invoke the stateful autoconfiguration protocol [...] If the value of the OtherConfigFlag changes from TRUE to FALSE, the host SHOULD continue running the stateful address autoconfiguration protocol [...] - 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 Mar 18 09:02:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IH2GKL009205 for ; Mon, 18 Mar 2002 09:02:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IH2G0N009204 for ipng-dist; Mon, 18 Mar 2002 09:02:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IH2DKL009197 for ; Mon, 18 Mar 2002 09:02:13 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA27677 for ; Mon, 18 Mar 2002 09:02:15 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA08396 for ; Mon, 18 Mar 2002 10:02:13 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2IH23i06902; Mon, 18 Mar 2002 19:02:03 +0200 Date: Mon, 18 Mar 2002 19:02:02 +0200 (EET) From: Pekka Savola To: Ralph Droms cc: IPng List Subject: Re: IPv6 working group agenda for Minneapolis IETF In-Reply-To: <4.3.2.7.2.20020318111334.00b4c278@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 18 Mar 2002, Ralph Droms wrote: > So, RFC 2462 only uses RFC 2119 keywords to describe the behavior of a host > when the value of the 'O' flag remains unchanged. The text in section > 5.5.3 needs to be updated to: > > If the value of OtherConfigFlag changes from FALSE to > TRUE, the host MUST invoke the stateful autoconfiguration > protocol [...] > > If the value of the OtherConfigFlag changes from TRUE > to FALSE, the host SHOULD continue running the stateful > address autoconfiguration protocol [...] Strongly disagree. This would make about every IPv6 implementation not supporting stateful protocols non-compliant. In my view 'O' is just a hint to the nodes that thay should try to use a stateful mechanism (as there is one in the specific network), if they have one. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 09:05:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IH5NKL009225 for ; Mon, 18 Mar 2002 09:05:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IH5NIY009224 for ipng-dist; Mon, 18 Mar 2002 09:05:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IH5JKL009217 for ; Mon, 18 Mar 2002 09:05:19 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18924 for ; Mon, 18 Mar 2002 09:05:20 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28944 for ; Mon, 18 Mar 2002 09:05:17 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 592334B23; Tue, 19 Mar 2002 02:05:17 +0900 (JST) To: Ralph Droms Cc: IPng List In-reply-to: rdroms's message of Mon, 18 Mar 2002 11:55:32 EST. <4.3.2.7.2.20020318111334.00b4c278@funnel.cisco.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IPv6 working group agenda for Minneapolis IETF From: itojun@iijlab.net Date: Tue, 19 Mar 2002 02:05:17 +0900 Message-ID: <24037.1016471117@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >So, RFC 2462 only uses RFC 2119 keywords to describe the behavior of a host >when the value of the 'O' flag remains unchanged. The text in section >5.5.3 needs to be updated to: > If the value of OtherConfigFlag changes from FALSE to > TRUE, the host MUST invoke the stateful autoconfiguration > protocol [...] you have changed "should" into "MUST". any reasons why? what happens if a host does not have stateful autoconfiguration protocol implementation? i think "SHOULD" is fine. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 18 09:08:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IH8jKL009245 for ; Mon, 18 Mar 2002 09:08:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IH8jYT009244 for ipng-dist; Mon, 18 Mar 2002 09:08:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IH8gKL009237 for ; Mon, 18 Mar 2002 09:08:42 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29831 for ; Mon, 18 Mar 2002 09:08:44 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00097 for ; Mon, 18 Mar 2002 09:08:41 -0800 (PST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2IH8gl03679 for ; Mon, 18 Mar 2002 11:08:43 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g2IH8gm03666 for ; Mon, 18 Mar 2002 11:08:42 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Mar 18 11:08:17 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 11:08:17 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4D0EE@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Pekka Savola'" , Ralph Droms Cc: IPng List Subject: RE: IPv6 working group agenda for Minneapolis IETF Date: Mon, 18 Mar 2002 11:08:16 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CE9F.7EA50370" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CE9F.7EA50370 Content-Type: text/plain; charset="iso-8859-1" So, change Ralph's text to SHOULD instead of MUST. The current text reads "should" and not "SHOULD". -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi] Sent: Monday, March 18, 2002 12:02 PM To: Ralph Droms Cc: IPng List Subject: Re: IPv6 working group agenda for Minneapolis IETF On Mon, 18 Mar 2002, Ralph Droms wrote: > So, RFC 2462 only uses RFC 2119 keywords to describe the behavior of a host > when the value of the 'O' flag remains unchanged. The text in section > 5.5.3 needs to be updated to: > > If the value of OtherConfigFlag changes from FALSE to > TRUE, the host MUST invoke the stateful autoconfiguration > protocol [...] > > If the value of the OtherConfigFlag changes from TRUE > to FALSE, the host SHOULD continue running the stateful > address autoconfiguration protocol [...] Strongly disagree. This would make about every IPv6 implementation not supporting stateful protocols non-compliant. In my view 'O' is just a hint to the nodes that thay should try to use a stateful mechanism (as there is one in the specific network), if they have one. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C1CE9F.7EA50370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: IPv6 working group agenda for Minneapolis IETF

So, change Ralph's text to SHOULD instead of MUST. = The current text reads "should" and not "SHOULD". =

-----Original Message-----
From: Pekka Savola [mailto:pekkas@netcore.fi]
Sent: Monday, March 18, 2002 12:02 PM
To: Ralph Droms
Cc: IPng List
Subject: Re: IPv6 working group agenda for = Minneapolis IETF


On Mon, 18 Mar 2002, Ralph Droms wrote:
> So, RFC 2462 only uses RFC 2119 keywords to = describe the behavior of a host
> when the value of the 'O' flag remains = unchanged.  The text in section
> 5.5.3 needs to be updated to:
>
>     If the value of = OtherConfigFlag changes from FALSE to
>     TRUE, the host MUST = invoke the stateful autoconfiguration
>     protocol [...]
>
>     If the value of the = OtherConfigFlag changes from TRUE
>     to FALSE, the host = SHOULD continue running the stateful
>     address = autoconfiguration protocol [...]

Strongly disagree.  This would make about every = IPv6 implementation not
supporting stateful protocols non-compliant.

In my view 'O' is just a hint to the nodes that thay = should try to use a
stateful mechanism (as there is one in the specific = network), if they have
one.

--
Pekka = Savola           =       "Tell me of difficulties = surmounted,
Netcore = Oy           &nbs= p;       not those you stumble over and = fall"
Systems. Networks. Security.  -- Robert Jordan: = A Crown of Swords

---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01C1CE9F.7EA50370-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 09:09:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IH9QKL009262 for ; Mon, 18 Mar 2002 09:09:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IH9QQR009261 for ipng-dist; Mon, 18 Mar 2002 09:09:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IH9NKL009254 for ; Mon, 18 Mar 2002 09:09:23 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29990 for ; Mon, 18 Mar 2002 09:09:25 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24594 for ; Mon, 18 Mar 2002 10:09:24 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2IH9Et06952; Mon, 18 Mar 2002 19:09:14 +0200 Date: Mon, 18 Mar 2002 19:09:14 +0200 (EET) From: Pekka Savola To: rdroms@cisco.com cc: ipng@sunroof.eng.sun.com Subject: Stateless DHCP and the DHCP draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Would it make sense to consider whether separating "stateless DHCPv6" and the stateful part (~address assignment) to separate drafts would make sense? I think a lot more people would be confortable with DHCPv6 if it was very simple and supported only the informational records most people would only use.. and stateful address and such specified in a separate draft? Just a thought... -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 09:13:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IHD9KL009302 for ; Mon, 18 Mar 2002 09:13:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IHD9UR009301 for ipng-dist; Mon, 18 Mar 2002 09:13:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IHD6KL009294 for ; Mon, 18 Mar 2002 09:13:06 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA01229 for ; Mon, 18 Mar 2002 09:13:07 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18003 for ; Mon, 18 Mar 2002 10:13:06 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2IHCsn07007; Mon, 18 Mar 2002 19:12:54 +0200 Date: Mon, 18 Mar 2002 19:12:54 +0200 (EET) From: Pekka Savola To: "Bernie Volz (EUD)" cc: Ralph Droms , IPng List Subject: RE: IPv6 working group agenda for Minneapolis IETF In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D0EE@EAMBUNT705> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 18 Mar 2002, Bernie Volz (EUD) wrote: > So, change Ralph's text to SHOULD instead of MUST. The current text > reads "should" and not "SHOULD". With SHOULD I agree only if there's further specification like: If the value of OtherConfigFlag changes from FALSE to TRUE, the host SHOULD invoke the stateful autoconfiguration protocol, if one is available, [...] .. I wouldn't make the support of stateful protocols even a SHOULD, but if there _is_ a supported stateful protocol, invoking it can be a SHOULD. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 09:21:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IHLsKL009328 for ; Mon, 18 Mar 2002 09:21:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IHLrQo009327 for ipng-dist; Mon, 18 Mar 2002 09:21:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IHLoKL009320 for ; Mon, 18 Mar 2002 09:21:50 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23910 for ; Mon, 18 Mar 2002 09:21:52 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA28008 for ; Mon, 18 Mar 2002 09:21:50 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2IHKlk14168; Mon, 18 Mar 2002 18:20:47 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA10775; Mon, 18 Mar 2002 18:20:47 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2IHKkg61868; Mon, 18 Mar 2002 18:20:46 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203181720.g2IHKkg61868@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: rdroms@cisco.com, ipng@sunroof.eng.sun.com Subject: Re: Stateless DHCP and the DHCP draft In-reply-to: Your message of Mon, 18 Mar 2002 19:09:14 +0200. Date: Mon, 18 Mar 2002 18:20:46 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Would it make sense to consider whether separating "stateless DHCPv6" and the stateful part (~address assignment) to separate drafts would make sense? => the stateful part is "dynamic address allocation", not "address assignment" (and this is not a detail, i.e. DHCP is not BOOTP). I think a lot more people would be confortable with DHCPv6 if it was very simple and supported only the informational records most people would only use.. and stateful address and such specified in a separate draft? => I fully agree and IMHO the "stateless DHCPv6" should be taken into account only when this will be done. Thanks Francis.Dupont@enst-bretagne.fr PS: of course the name (stateless DHCPv6) is the first thing to change (:-)! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 09:22:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IHMWKL009338 for ; Mon, 18 Mar 2002 09:22:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IHMVuQ009337 for ipng-dist; Mon, 18 Mar 2002 09:22:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IHMSKL009330 for ; Mon, 18 Mar 2002 09:22:28 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04503 for ; Mon, 18 Mar 2002 09:22:30 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18087 for ; Mon, 18 Mar 2002 10:22:24 -0700 (MST) Received: from rdroms-w2k.cisco.com (sjc-vpn2-306.cisco.com [10.21.113.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA02446 for ; Mon, 18 Mar 2002 12:22:23 -0500 (EST) Message-Id: <4.3.2.7.2.20020318120657.00b856e8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Mar 2002 12:22:18 -0500 To: IPng List From: Ralph Droms Subject: Requirements for 'O' flag (was Re: IPv6 working group agenda for Minneapolis IETF) In-Reply-To: <24037.1016471117@itojun.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OK, there are really several issues here: a. the text needs to be updated to use RFC 2119 keywords b. which keywords? c. what is "the stateful configuration protocol"? d. if the answer to "c" is DHCPv6, should RFC 2462 more explicitly reference the configuration-only version of DHCPv6 in the description of the 'O'flag? Without fixing a. RFC 2462 is underspecified in this area. I changed "should" into "MUST" because a network manager who wants hosts to use "the stateful configuration protocol" really expects those hosts to use it. It seemed like a good way to kick of the discussion. Now that the DHCPv6 spec is approaching completion, we ought to talk about c. and d. - Ralph At 02:05 AM 3/19/2002 +0900, itojun@iijlab.net wrote: > >So, RFC 2462 only uses RFC 2119 keywords to describe the behavior of a host > >when the value of the 'O' flag remains unchanged. The text in section > >5.5.3 needs to be updated to: > > If the value of OtherConfigFlag changes from FALSE to > > TRUE, the host MUST invoke the stateful autoconfiguration > > protocol [...] > > you have changed "should" into "MUST". any reasons why? what happens > if a host does not have stateful autoconfiguration protocol > implementation? > > i think "SHOULD" is fine. > >itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 18 09:26:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IHQcKL009373 for ; Mon, 18 Mar 2002 09:26:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IHQc8F009372 for ipng-dist; Mon, 18 Mar 2002 09:26:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IHQZKL009365 for ; Mon, 18 Mar 2002 09:26:35 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA24269 for ; Mon, 18 Mar 2002 09:26:37 -0800 (PST) Received: from fridge.docomolabs-usa.com (fridge.docomolabs-usa.com [216.98.102.228]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA05200 for ; Mon, 18 Mar 2002 09:26:34 -0800 (PST) Received: from T23KEMPF (dhcp27.docomolabs-usa.com [172.21.96.27]) by fridge.docomolabs-usa.com (8.11.3/8.11.3) with SMTP id g2IHQJI08375; Mon, 18 Mar 2002 09:26:19 -0800 (PST) Message-ID: <00c401c1cea1$cb66c110$566015ac@T23KEMPF> From: "James Kempf" To: "Pekka Savola" , Cc: References: Subject: Re: Stateless DHCP and the DHCP draft Date: Mon, 18 Mar 2002 09:24:43 -0800 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.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, I like the idea of stateless DHCP for defaults configuration. Maybe separating them would be the right thing, as long as it is clear that a combined addrconf + defaults conf implementation is possible so not to negatively impact near term deployment prospects. jak ----- Original Message ----- From: "Pekka Savola" To: Cc: Sent: Monday, March 18, 2002 9:09 AM Subject: Stateless DHCP and the DHCP draft > Hi, > > Would it make sense to consider whether separating "stateless DHCPv6" and > the stateful part (~address assignment) to separate drafts would make > sense? > > I think a lot more people would be confortable with DHCPv6 if it was very > simple and supported only the informational records most people would only > use.. and stateful address and such specified in a separate draft? > > Just a thought... > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 18 09:29:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IHTbKL009393 for ; Mon, 18 Mar 2002 09:29:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IHTbp8009392 for ipng-dist; Mon, 18 Mar 2002 09:29:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IHTYKL009385 for ; Mon, 18 Mar 2002 09:29:34 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25765 for ; Mon, 18 Mar 2002 09:29:36 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00197 for ; Mon, 18 Mar 2002 09:29:39 -0800 (PST) Received: from rdroms-w2k.cisco.com (sjc-vpn2-306.cisco.com [10.21.113.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA02995 for ; Mon, 18 Mar 2002 12:29:33 -0500 (EST) Message-Id: <4.3.2.7.2.20020318122338.00b4ce20@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Mar 2002 12:29:29 -0500 To: ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Re: Stateless DHCP and the DHCP draft In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, Thanks for the suggestion about separating the drafts. There is a need to more clearly specify what is required for "configuration-only" DHCP service. (There is also a need for a better name; suggestions, anyone?) I agree with Bernie that writing two separate specs wouldn't be a good idea; I think there would be a lot of overlap between the two specs. What about an "applicability statement" (in a separate doc) that describes in detail how a "configuration-only" client and server would operate? It might be as simple as "implement these sections of the DHCPv6 spec"? - Ralph At 07:09 PM 3/18/2002 +0200, Pekka Savola wrote: >Hi, > >Would it make sense to consider whether separating "stateless DHCPv6" and >the stateful part (~address assignment) to separate drafts would make >sense? > >I think a lot more people would be confortable with DHCPv6 if it was very >simple and supported only the informational records most people would only >use.. and stateful address and such specified in a separate draft? > >Just a thought... > >-- >Pekka Savola "Tell me of difficulties surmounted, >Netcore Oy not those you stumble over and fall" >Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Mar 18 09:37:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IHbfKL009431 for ; Mon, 18 Mar 2002 09:37:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IHbfEg009430 for ipng-dist; Mon, 18 Mar 2002 09:37:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IHbcKL009423 for ; Mon, 18 Mar 2002 09:37:38 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11170 for ; Mon, 18 Mar 2002 09:37:40 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08303 for ; Mon, 18 Mar 2002 09:37:37 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA08938; Mon, 18 Mar 2002 09:37:39 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2IHbcq07890; Mon, 18 Mar 2002 09:37:38 -0800 X-mProtect:  Mon, 18 Mar 2002 09:37:38 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (166.63.185.127, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdCqe1r3; Mon, 18 Mar 2002 09:37:35 PST Message-Id: <4.3.2.7.2.20020318092255.02732e60@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Mar 2002 09:36:09 -0800 To: Thomas Narten From: Bob Hinden Subject: Re: Deployability/Useability of Multicast [was: Re: PPP and Global Addresses ] Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200203171441.g2HEf1703907@cichlid.adsl.duke.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >1) Do people think that the existance of multicast within a site > (e.g., home, enterprise, etc.) can be assumed? > > Note: I'm assuming link-local multicast will always work, the > question is whether wider scope (beyond neighboring routers) > multicast is available. As much as I would like to see it otherwise, except for link (and maybe subnet) scoped multicast, I don't think we can assume multicast across a wider scope. I suspect it will be more the exception than the norm. >2) If the answer is "can't assume multicast is present", what should > be done about it. e.g., > > - What are the barriers that are preventing multicast from being an > assumed part of the infrastructure? What is needed to remove > those barriers? Don't we have a whole working group dealing with this (e.g., mboned)? It's a complicated mixture of routing protocol scaling, lack of agreement of inter-domain routing protocols, lack of interoperability between vendors of multicast routing protocols, few compelling applications that need multicast that can't be meet with unicast, etc. There are a few places where it is used (i.e., financial industry), but as far as I can tell it's not widely adopted much beyond that. > - Which infrastructure protocols does IPv6 rely on that assume the > existance of multicast, and how are they limited if multicast is > not available? Off the top of my head, DHCPv6 and Router Renumbering. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 18 09:57:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IHv0KL009608 for ; Mon, 18 Mar 2002 09:57:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IHv09I009607 for ipng-dist; Mon, 18 Mar 2002 09:57:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IHuvKL009600 for ; Mon, 18 Mar 2002 09:56:57 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA03474 for ; Mon, 18 Mar 2002 09:56:59 -0800 (PST) Received: from mail8.nc.rr.com (fe8.southeast.rr.com [24.93.67.55]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13321 for ; Mon, 18 Mar 2002 10:56:59 -0700 (MST) Received: from lorien.sc.innovationslab.net ([24.162.252.183]) by mail8.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Mon, 18 Mar 2002 12:56:45 -0500 Message-ID: <3C962A86.7C249B65@lorien.sc.innovationslab.net> Date: Mon, 18 Mar 2002 12:57:26 -0500 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Ralph Droms CC: IPng List Subject: Re: Requirements for 'O' flag (was Re: IPv6 working group agendafor Minneapolis IETF) References: <4.3.2.7.2.20020318120657.00b856e8@funnel.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Ralph, I agree the text should be updated. To address your points 'c' and 'd', it should be pointed out that 2462 was written so that there was no dependency upon a particular stateful configuration protocol. Operators would simply utilize their protocol of choice (DHCPv6 or foo) and 2462 would allow that to be advertised to the hosts. Brian Ralph Droms wrote: > > OK, there are really several issues here: > a. the text needs to be updated to use RFC 2119 keywords > b. which keywords? > c. what is "the stateful configuration protocol"? > d. if the answer to "c" is DHCPv6, should RFC 2462 more > explicitly reference the configuration-only version > of DHCPv6 in the description of the 'O'flag? > > Without fixing a. RFC 2462 is underspecified in this area. > > I changed "should" into "MUST" because a network manager who wants hosts to > use "the stateful configuration protocol" really expects those hosts to use > it. It seemed like a good way to kick of the discussion. > > Now that the DHCPv6 spec is approaching completion, we ought to talk about > c. and d. > > - Ralph > > At 02:05 AM 3/19/2002 +0900, itojun@iijlab.net wrote: > > >So, RFC 2462 only uses RFC 2119 keywords to describe the behavior of a host > > >when the value of the 'O' flag remains unchanged. The text in section > > >5.5.3 needs to be updated to: > > > If the value of OtherConfigFlag changes from FALSE to > > > TRUE, the host MUST invoke the stateful autoconfiguration > > > protocol [...] > > > > you have changed "should" into "MUST". any reasons why? what happens > > if a host does not have stateful autoconfiguration protocol > > implementation? > > > > i think "SHOULD" is fine. > > > >itojun > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 18 10:18:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IIIRKL009651 for ; Mon, 18 Mar 2002 10:18:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IIIRg3009650 for ipng-dist; Mon, 18 Mar 2002 10:18:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IIIOKL009643 for ; Mon, 18 Mar 2002 10:18:24 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27190 for ; Mon, 18 Mar 2002 10:18:26 -0800 (PST) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14739 for ; Mon, 18 Mar 2002 10:18:28 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 19 Mar 2002 00:05:45 +0530 Received: from murugankat (murugankat.future.futsoft.com [10.20.6.9]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g2III5H22257 for ; Mon, 18 Mar 2002 23:48:05 +0530 Reply-To: From: "Murugan KAT" To: "'IPng List'" Subject: RE: Requirements for 'O' flag (was Re: IPv6 working group agendafor Minneapolis IETF) Date: Tue, 19 Mar 2002 00:06:36 +0530 Message-Id: <000201c1ceab$d6811dc0$0906140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3C962A86.7C249B65@lorien.sc.innovationslab.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, Regarding Dual Stack Router implementation should a router maintain 2 routing tables, one for V4 and other for V6. What about the routing stacks? Should there be 2 instances of a routing protocol (BGP, OSPF etc.,) ? What is the general approach? Thanks, KAT -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 11:19:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IJJgKL009761 for ; Mon, 18 Mar 2002 11:19:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IJJgSC009760 for ipng-dist; Mon, 18 Mar 2002 11:19:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IJJdKL009753 for ; Mon, 18 Mar 2002 11:19:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA20778 for ; Mon, 18 Mar 2002 11:19:40 -0800 (PST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA13341 for ; Mon, 18 Mar 2002 12:19:39 -0700 (MST) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g2IJJcl21375 for ; Mon, 18 Mar 2002 13:19:38 -0600 (CST) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g2IJJc525881 for ; Mon, 18 Mar 2002 13:19:38 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Mar 18 13:19:37 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 18 Mar 2002 13:19:37 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4D0F0@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Bob Hinden'" , Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: RE: Deployability/Useability of Multicast [was: Re: PPP and Globa l Addresses ] Date: Mon, 18 Mar 2002 13:19:35 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CEB1.D7173480" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CEB1.D7173480 Content-Type: text/plain; charset="iso-8859-1" DHCPv6 only requires link-local multicast not site or global. From draft-ietf-dhc-dhcpv6-23: 7.1. Multicast Addresses DHCP makes use of the following multicast addresses: All_DHCP_Agents (FF02::1:2) This link-scoped multicast address is used by clients to communicate with the on-link agent(s) when they do not know the link-local address(es) for those agents. All agents (servers and relays) are members of this multicast group. All_DHCP_Servers (FF05::1:3) This site-scoped multicast address is used by clients or relays to communicate with server(s), either because they want to send messages to all servers or because they do not know the server(s) unicast address(es). Note that in order for a client to use this address, it must have an address of sufficient scope to be reachable by the server(s). All servers within the site are members of this multicast group. The All_DHCP_Servers is not a requirement to make the protocol work. It is usable in two cases: - For Information-Request messages to avoid the need for relays. But, the All_DHCP_Agents is usable with relays. - For auto-configuration of relays - if a relay doesn't have a configured DHCP server to forward packets to, it can forward them to the ALL_DHCP_Servers address. So, DHCPv6 MUST have link-local multicast. - Bernie Volz -----Original Message----- From: Bob Hinden [mailto:hinden@iprg.nokia.com] Sent: Monday, March 18, 2002 12:36 PM To: Thomas Narten Cc: ipng@sunroof.eng.sun.com Subject: Re: Deployability/Useability of Multicast [was: Re: PPP and Global Addresses ] Thomas, >1) Do people think that the existance of multicast within a site > (e.g., home, enterprise, etc.) can be assumed? > > Note: I'm assuming link-local multicast will always work, the > question is whether wider scope (beyond neighboring routers) > multicast is available. As much as I would like to see it otherwise, except for link (and maybe subnet) scoped multicast, I don't think we can assume multicast across a wider scope. I suspect it will be more the exception than the norm. >2) If the answer is "can't assume multicast is present", what should > be done about it. e.g., > > - What are the barriers that are preventing multicast from being an > assumed part of the infrastructure? What is needed to remove > those barriers? Don't we have a whole working group dealing with this (e.g., mboned)? It's a complicated mixture of routing protocol scaling, lack of agreement of inter-domain routing protocols, lack of interoperability between vendors of multicast routing protocols, few compelling applications that need multicast that can't be meet with unicast, etc. There are a few places where it is used (i.e., financial industry), but as far as I can tell it's not widely adopted much beyond that. > - Which infrastructure protocols does IPv6 rely on that assume the > existance of multicast, and how are they limited if multicast is > not available? Off the top of my head, DHCPv6 and Router Renumbering. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- ------_=_NextPart_001_01C1CEB1.D7173480 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Deployability/Useability of Multicast [was: Re: PPP and = Global Addresses ]

DHCPv6 only requires link-local multicast not site or = global. From draft-ietf-dhc-dhcpv6-23:

7.1. Multicast Addresses

   DHCP makes use of the following = multicast addresses:

      All_DHCP_Agents = (FF02::1:2) This link-scoped multicast address
          &nb= sp;           &nb= sp; is used by clients to communicate with the
          &nb= sp;           &nb= sp; on-link agent(s) when they do not know the
          &nb= sp;           &nb= sp; link-local address(es) for those agents.  All
          &nb= sp;           &nb= sp; agents (servers and relays) are members of this
          &nb= sp;           &nb= sp; multicast group.

      All_DHCP_Servers = (FF05::1:3) This site-scoped multicast address is
          &nb= sp;           &nb= sp; used by clients or relays to communicate with
          &nb= sp;           &nb= sp; server(s), either because they want to send
          &nb= sp;           &nb= sp; messages to all servers or because they do not
          &nb= sp;           &nb= sp; know the server(s) unicast address(es).  Note
          &nb= sp;           &nb= sp; that in order for a client to use this address,
          &nb= sp;           &nb= sp; it must have an address of sufficient scope to
          &nb= sp;           &nb= sp; be reachable by the server(s).  All servers
          &nb= sp;           &nb= sp; within the site are members of this multicast
          &nb= sp;           &nb= sp; group.

The All_DHCP_Servers is not a requirement to make the = protocol work. It is usable in two cases:
- For Information-Request messages to avoid the need = for relays. But, the All_DHCP_Agents is usable with relays.
- For auto-configuration of relays - if a relay = doesn't have a configured DHCP server to forward packets to, it can = forward them to the ALL_DHCP_Servers address.

So, DHCPv6 MUST have link-local multicast.

- Bernie Volz

-----Original Message-----
From: Bob Hinden [mailto:hinden@iprg.nokia.com]<= /FONT>
Sent: Monday, March 18, 2002 12:36 PM
To: Thomas Narten
Cc: ipng@sunroof.eng.sun.com
Subject: Re: Deployability/Useability of Multicast = [was: Re: PPP and
Global Addresses ]


Thomas,

>1) Do people think that the existance of = multicast within a site
>    (e.g., home, enterprise, = etc.) can be assumed?
>
>    Note: I'm assuming link-local = multicast will always work, the
>    question is whether wider = scope (beyond neighboring routers)
>    multicast is = available.

As much as I would like to see it otherwise, except = for link (and maybe
subnet) scoped multicast, I don't think we can = assume multicast across a
wider scope.  I suspect it will be more the = exception than the norm.

>2) If the answer is "can't assume multicast = is present", what should
>    be done about it. = e.g.,
>
>    - What are the barriers that = are preventing multicast from being an
>      assumed part of = the infrastructure? What is needed to remove
>      those = barriers?

Don't we have a whole working group dealing with this = (e.g., mboned)?

It's a complicated mixture of routing protocol = scaling, lack of agreement
of inter-domain routing protocols, lack of = interoperability between vendors
of multicast routing protocols, few compelling = applications that need
multicast that can't be meet with unicast, = etc.  There are a few places
where it is used (i.e., financial industry), but as = far as I can tell it's
not widely adopted much beyond that.

>    - Which infrastructure = protocols does IPv6 rely on that assume the
>      existance of = multicast, and how are they limited if multicast is
>      not = available?

Off the top of my head, DHCPv6 and Router = Renumbering.

Bob

---------------------------------------------------------------= -----
IETF IPng Working Group Mailing List
IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
Direct all administrative requests to = majordomo@sunroof.eng.sun.com
---------------------------------------------------------------= -----

------_=_NextPart_001_01C1CEB1.D7173480-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 11:29:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IJTAKL009813 for ; Mon, 18 Mar 2002 11:29:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IJTADW009812 for ipng-dist; Mon, 18 Mar 2002 11:29:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IJT7KL009805 for ; Mon, 18 Mar 2002 11:29:07 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27296 for ; Mon, 18 Mar 2002 11:29:08 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10692 for ; Mon, 18 Mar 2002 11:29:01 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2IJSNk30195; Mon, 18 Mar 2002 20:28:23 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA12883; Mon, 18 Mar 2002 20:28:23 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2IJSNg62330; Mon, 18 Mar 2002 20:28:23 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203181928.g2IJSNg62330@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alexandru Petrescu cc: Steve Deering , Alberto Escudero-Pascual , Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-reply-to: Your message of 13 Mar 2002 21:02:00 +0100. Date: Mon, 18 Mar 2002 20:28:23 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Steve Deering writes: > The u bit in the current IID definition indicates whether or not the > IID can be considered globally unique. => can I assume you didn't read draft-dupont-ipv6-imei-00.txt? (you should and I should have answered before :-) IMEI being global I'm tempted to touch the u bit (universal/local). IMEI has nothing in it that could influence the g bit (individual/group), but further investigation is necessary probably. => my proposal is to use u=1,g=1 for IMEIs. Obviously this collides with Erik's idea... Regards Francis.Dupont@enst-bretagne.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 Mon Mar 18 11:38:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IJcmKL009834 for ; Mon, 18 Mar 2002 11:38:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IJcmZa009833 for ipng-dist; Mon, 18 Mar 2002 11:38:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IJcjKL009826 for ; Mon, 18 Mar 2002 11:38:45 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA03409; Mon, 18 Mar 2002 11:38:45 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA21468; Mon, 18 Mar 2002 12:38:44 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2IJcOk31119; Mon, 18 Mar 2002 20:38:24 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA13039; Mon, 18 Mar 2002 20:38:24 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2IJcNg62370; Mon, 18 Mar 2002 20:38:24 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203181938.g2IJcNg62370@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jonne.Soininen@nokia.com cc: petrescu@crm.mot.com, deering@cisco.com, aep@it.kth.se, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-reply-to: Your message of Thu, 14 Mar 2002 17:53:14 PST. <4D7B558499107545BB45044C63822DDE0A0790@mvebe001.NOE.Nokia.com> Date: Mon, 18 Mar 2002 20:38:23 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I would be a bit careful to use IMEI as Interface Identifier. I am not really sure if this is something you want to tell the whole world. => there is such a concern for ESD (CDMA 32 bit hardware ID) but nothing about IMEI. In fact IMEI is sent in clear by the GSM protocol (as shown by our capture/decoding tool). (I know that Francis has a draft out on this topic, and no I have not read it, yet.) => no comment (:-). For instance, when the 3GPP mechanism of address allocation was designed in 3GPP, one of the criteria was not to show the IMEI. This is kind of confidential information from the end user point of view. In addition, it might not always be unique... => or you confuse IMEI and IMSI or you have access to 3GPP documents there are not on the 3GPP or ETSI sites. Can you give a pointer? Thanks Francis.Dupont@enst-bretagne.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 Mon Mar 18 11:58:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IJwZKL009899 for ; Mon, 18 Mar 2002 11:58:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IJwZgZ009898 for ipng-dist; Mon, 18 Mar 2002 11:58:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IJwWKL009891 for ; Mon, 18 Mar 2002 11:58:32 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA07565 for ; Mon, 18 Mar 2002 11:58:33 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11254 for ; Mon, 18 Mar 2002 11:58:35 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2IJw9k32616; Mon, 18 Mar 2002 20:58:09 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA13318; Mon, 18 Mar 2002 20:58:10 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2IJw9g62462; Mon, 18 Mar 2002 20:58:09 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203181958.g2IJw9g62462@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alexandru Petrescu cc: Jonne.Soininen@nokia.com, deering@cisco.com, aep@it.kth.se, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-reply-to: Your message of 15 Mar 2002 14:42:00 +0100. Date: Mon, 18 Mar 2002 20:58:09 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Jonne.Soininen@nokia.com writes: > I would be a bit careful to use IMEI as Interface Identifier. Hi Jonne, please let me assure you that I'm trying to be very careful in all this. If I speak out so frequently is just because I need to better understand how IPv6 and 3GPP/UMTS can be made to work together. If I'm diverging too much from the list's topic, please stop me. => the IMEI idea is terribly simple: GSM/UMTS terminals usually have no IEEE interface but have a globally unique ID, so use it exactly as we use IEEE IDs/MAC addresses. > I am not really sure if this is something you want to tell the whole > world. Ok, privacy, yes. => please read the last update of RFC 3041 before to get things from 3041 which are not in it... Alberto mentioned that not necessarily the IMEI should be coded but a hash of it, periodically updated starting from a nonce. => I can't see a reason to do that when RFC 3041 is supported. Or do you mean we can replace the MAC address by the IMEI for the seed? > In addition, it might not always be unique... IMEI not being unique? That's bad, again. Then it's probably true that some id's are more unique than other id's. => IMEI is unique according to 3GPP/ETSI standards. In the true world I am afraid it is not far more unique than MAC addresses... So I try something else than IMEI: IMSI. As IMEI is for phones, IMSI is in the SIM cards. Is the IMSI private? Is it unique? => IMSI is *private* and unique. What are the other identifiers in the GSM/3GPP/UMTS? Phone number? => none, the hardware ID is the IMEI. Others (IMSI/phone number) are private... Would an IMT2000 identifier be better adapted, since it has a wider reach, more neutral. => it seems the IMT2000 identifier would be the IMEI. Regards Francis.Dupont@enst-bretagne.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 Mon Mar 18 12:12:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IKCvKL009947 for ; Mon, 18 Mar 2002 12:12:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IKCvQr009946 for ipng-dist; Mon, 18 Mar 2002 12:12:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IKCsKL009939 for ; Mon, 18 Mar 2002 12:12:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA11266 for ; Mon, 18 Mar 2002 12:12:56 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA06769 for ; Mon, 18 Mar 2002 13:12:54 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2IKCRk01624; Mon, 18 Mar 2002 21:12:27 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA13507; Mon, 18 Mar 2002 21:12:28 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2IKCRg62514; Mon, 18 Mar 2002 21:12:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203182012.g2IKCRg62514@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jonne.Soininen@nokia.com cc: petrescu@crm.mot.com, deering@cisco.com, aep@it.kth.se, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-reply-to: Your message of Fri, 15 Mar 2002 16:27:31 PST. <4D7B558499107545BB45044C63822DDE0A0794@mvebe001.NOE.Nokia.com> Date: Mon, 18 Mar 2002 21:12:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: You can see the results in http://search.ietf.org/internet-drafts/draft-ietf-ipv6-3gpp-recommend-00.txt. => the 3GPP/IPv6 DT seems to ignore this ID issue... The problem with IMEIs are that they are used in GSM, GPRS, and UMTS networks to screen stolen handsets. This makes additional requirements for privacy, and confidentiality of the IMEI value. => I agree, the only usage of IMEI is to optionally look up the EIR for stolen terminals. I can't see any additional requirements for privacy and confidentiality? Can you explain? Do you afraid someone can declare his stolen phone has your phone IMEI (telcos are not so stupid, they check or are sued to death :-)? The only point is when you steal an handset you'd like to change the IMEI (so the IMEI should not easy to change :-). I had phone once that for some reason had a different IMEI electronically than what was printed on the back of the phone. I am not sure if that was the mistake of the person putting the wrong label on the phone... (It was not from the manufacturer that I currently work for... ;) => we have already this kind of stories about Ethernet NICs... > Would an IMT2000 identifier be better adapted, since it has a wider > reach, more neutral. I am not sure what you are referring to. Something standardized in ITU? => I found a reference to a project to extend IMEIs to the whole IMT2000 but I am not an ITU expert (you should ask my co-author). Regards Francis.Dupont@enst-bretagne.fr PS for Sun people: the MAC address is a part of the Serial Number of a Sun box (at least for old Sparcs). Is this a privacy/confidentiality issue? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 12:18:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IKIRKL010002 for ; Mon, 18 Mar 2002 12:18:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IKIQ6X010001 for ipng-dist; Mon, 18 Mar 2002 12:18:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IKINKL009991 for ; Mon, 18 Mar 2002 12:18:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14230; Mon, 18 Mar 2002 12:18:24 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA00735; Mon, 18 Mar 2002 13:18:21 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2IKIJk02462; Mon, 18 Mar 2002 21:18:19 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA13621; Mon, 18 Mar 2002 21:18:20 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2IKIJg62557; Mon, 18 Mar 2002 21:18:19 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203182018.g2IKIJg62557@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-reply-to: Your message of Tue, 12 Mar 2002 09:55:33 +0100. Date: Mon, 18 Mar 2002 21:18:19 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Not much email has followed on this topic so it isn't clear whether people are having too much fun debating other topics, think it is a good/bad idea, or just don't care. => what exactly do you mean by "reserve": - make them not available at all? - enforce some control/rules on availability? I think our choices are: 1. Do nothing 2. Reserve a quarter of the IID space i.e. universal=1, group=1 becomes explicitly reserved. 3. Reserve half of the IID space i.e. all addresses with group=1 become explicitly reserved. => if reserve is available following to be defined rules I am in favor of 3. It would be good to try to make progress on the mailing list on this question otherwise it's likely to appear on the agenda in the meetings next week :-) => so we'll get a hot (and not too long, please :-) discussion thursday morning. BTW I have an objection to the "IPv6 over foo" only way: this assumes there is a real link. With mobile IPv6 there are some scenarios where the home link is purely virtual, so there is no foo... Thanks Francis.Dupont@enst-bretagne.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 Mon Mar 18 12:52:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IKqMKL010092 for ; Mon, 18 Mar 2002 12:52:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IKqM0Y010091 for ipng-dist; Mon, 18 Mar 2002 12:52:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IKqIKL010084 for ; Mon, 18 Mar 2002 12:52:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA23624 for ; Mon, 18 Mar 2002 12:52:20 -0800 (PST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA24318 for ; Mon, 18 Mar 2002 13:52:19 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id g2IKqJT15497; Mon, 18 Mar 2002 12:52:19 -0800 (PST) Received: from [166.63.186.235] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ADB19374; Mon, 18 Mar 2002 12:51:25 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@127.0.0.1 Message-Id: In-Reply-To: <200203181928.g2IJSNg62330@givry.rennes.enst-bretagne.fr> References: <200203181928.g2IJSNg62330@givry.rennes.enst-bretagne.fr> Date: Mon, 18 Mar 2002 12:52:14 -0800 To: Francis Dupont From: Steve Deering Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? Cc: Alexandru Petrescu , Alberto Escudero-Pascual , Erik Nordmark , ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 8:28 PM +0100 3/18/02, Francis Dupont wrote: > In your previous mail you wrote: > > Steve Deering writes: > > The u bit in the current IID definition indicates whether or not the > > IID can be considered globally unique. > >=> can I assume you didn't read draft-dupont-ipv6-imei-00.txt? >(you should and I should have answered before :-) That's normally a safe assumption, but in this case I actually did read your draft. My statement, which you quoted above, is not in conflict with your proposal, so I don't understand what point you are making. >=> my proposal is to use u=1,g=1 for IMEIs. Obviously this collides >with Erik's idea... Yep. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 18 13:02:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IL25KL010122 for ; Mon, 18 Mar 2002 13:02:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IL25kX010121 for ipng-dist; Mon, 18 Mar 2002 13:02:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IL22KL010114 for ; Mon, 18 Mar 2002 13:02:02 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA22967; Mon, 18 Mar 2002 13:02:03 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04596; Mon, 18 Mar 2002 13:02:00 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2IL1gk05848; Mon, 18 Mar 2002 22:01:42 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA14280; Mon, 18 Mar 2002 22:01:43 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2IL1gg62706; Mon, 18 Mar 2002 22:01:42 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203182101.g2IL1gg62706@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Steve Deering cc: Alexandru Petrescu , Alberto Escudero-Pascual , Erik Nordmark , ipng@sunroof.eng.sun.com Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-reply-to: Your message of Mon, 18 Mar 2002 12:52:14 PST. Date: Mon, 18 Mar 2002 22:01:42 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: At 8:28 PM +0100 3/18/02, Francis Dupont wrote: > In your previous mail you wrote: > > Steve Deering writes: > > The u bit in the current IID definition indicates whether or not the > > IID can be considered globally unique. => I apologize because this is not clear: I answer to a mail from Alexandru who cited you. >=> can I assume you didn't read draft-dupont-ipv6-imei-00.txt? >(you should and I should have answered before :-) That's normally a safe assumption, but in this case I actually did read your draft. My statement, which you quoted above, is not in conflict with your proposal, so I don't understand what point you are making. => the question is addressed to Alexandru... Thanks Francis.Dupont@enst-bretagne.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 Mon Mar 18 13:03:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IL2vKL010139 for ; Mon, 18 Mar 2002 13:02:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IL2uIM010138 for ipng-dist; Mon, 18 Mar 2002 13:02:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IL2rKL010131 for ; Mon, 18 Mar 2002 13:02:53 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28305 for ; Mon, 18 Mar 2002 13:02:55 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17493 for ; Mon, 18 Mar 2002 14:02:54 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2IL2l323773; Mon, 18 Mar 2002 13:02:47 -0800 (PST) Received: from [166.63.186.235] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ADB19645; Mon, 18 Mar 2002 13:02:00 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@127.0.0.1 Message-Id: In-Reply-To: References: Date: Mon, 18 Mar 2002 13:02:49 -0800 To: Alberto Escudero-Pascual From: Steve Deering Subject: Re: DHCPv6 and u/l bit Cc: Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 3:23 PM +0100 3/17/02, Alberto Escudero-Pascual wrote: >(MUST, SHOULD) the (stateful) addresses provided by a DHCPv6 have the "u" >bit to 0 as manual configuration? If the address provided by the DHCP server contains the modified EUI-64 value generated from an IEEE 802 or EUI-64 address belonging to the requesting node, it should have the "u" bit set to one; otherwise, it should be set to zero. Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 18 13:13:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2ILDUKL010167 for ; Mon, 18 Mar 2002 13:13:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2ILDUwb010166 for ipng-dist; Mon, 18 Mar 2002 13:13:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2ILDRKL010159 for ; Mon, 18 Mar 2002 13:13:27 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA25269 for ; Mon, 18 Mar 2002 13:13:29 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26670 for ; Mon, 18 Mar 2002 14:13:27 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id XAA32488; Mon, 18 Mar 2002 23:13:26 +0200 Date: Mon, 18 Mar 2002 23:13:26 +0200 Message-Id: <200203182113.XAA32488@burp.tkv.asdf.org> From: Markku Savela To: ipng@sunroof.eng.sun.com In-reply-to: <200203182101.g2IL1gg62706@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Mon, 18 Mar 2002 22:01:42 +0100) Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: <200203182101.g2IL1gg62706@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'm somewhat puzzled by this thread... has it been decided that IPv6 address is 64+64, and that latter 64 is EUI-64 format interface ID for all current and future IPv6 addresses? If not, I cannot see what is the point of assigning these bits from EUI-64 and expect them to be valid for other ID formats? They can only be guideline for certain link layers, but have not meaning between end nodes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 13:33:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2ILX4KL010224 for ; Mon, 18 Mar 2002 13:33:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2ILX40L010223 for ipng-dist; Mon, 18 Mar 2002 13:33:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2ILX1KL010216 for ; Mon, 18 Mar 2002 13:33:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA08659 for ; Mon, 18 Mar 2002 13:33:03 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA13836 for ; Mon, 18 Mar 2002 14:33:02 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2ILWOk08943; Mon, 18 Mar 2002 22:32:24 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id WAA14790; Mon, 18 Mar 2002 22:32:24 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2ILWOg62821; Mon, 18 Mar 2002 22:32:24 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203182132.g2ILWOg62821@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: ipng@sunroof.eng.sun.com Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-reply-to: Your message of Mon, 18 Mar 2002 23:13:26 +0200. <200203182113.XAA32488@burp.tkv.asdf.org> Date: Mon, 18 Mar 2002 22:32:24 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I'm somewhat puzzled by this thread... has it been decided that IPv6 address is 64+64, and that latter 64 is EUI-64 format interface ID for all current and future IPv6 addresses? => this was decided for all unicast addresses which don't begin by 000 bits. Look at last RFC 2373 revision, aka addr-arch-v3: draft-ietf-ipngwg-addr-arch-v3-07.txt but it seems the decision is not yet very decided even if the draft has been in last call since months. Regards Francis.Dupont@enst-bretagne.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 Mon Mar 18 13:58:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2ILwlKL010353 for ; Mon, 18 Mar 2002 13:58:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2ILwlpw010352 for ipng-dist; Mon, 18 Mar 2002 13:58:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2ILwiKL010345 for ; Mon, 18 Mar 2002 13:58:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06686 for ; Mon, 18 Mar 2002 13:58:47 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA26033 for ; Mon, 18 Mar 2002 14:58:46 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA27517; Mon, 18 Mar 2002 13:58:45 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2ILwiw13984; Mon, 18 Mar 2002 13:58:44 -0800 X-mProtect:  Mon, 18 Mar 2002 13:58:44 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (166.63.189.94, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOOgtLT; Mon, 18 Mar 2002 13:58:41 PST Message-Id: <4.3.2.7.2.20020318134811.026ea818@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Mar 2002 13:57:16 -0800 To: Markku Savela From: Bob Hinden Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200203182113.XAA32488@burp.tkv.asdf.org> References: <200203182101.g2IL1gg62706@givry.rennes.enst-bretagne.fr> <200203182101.g2IL1gg62706@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku, >I'm somewhat puzzled by this thread... has it been decided that IPv6 >address is 64+64, and that latter 64 is EUI-64 format interface ID for >all current and future IPv6 addresses? Yes. The use of 64 bit interface ID's is defined for prefixes 001 through 111 ( except for multicast addresses), in RFC2373 "IP Version 6 Addressing Architecture" published July 1998. See section 2.4. The text regarding EUI-64 has been clarified in . Bob >If not, I cannot see what is the point of assigning these bits from >EUI-64 and expect them to be valid for other ID formats? They can only >be guideline for certain link layers, but have not meaning between end >nodes. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 14:16:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IMG8KL010387 for ; Mon, 18 Mar 2002 14:16:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IMG847010386 for ipng-dist; Mon, 18 Mar 2002 14:16:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IMG3KL010379 for ; Mon, 18 Mar 2002 14:16:04 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2IMFtx28217; Mon, 18 Mar 2002 23:15:57 +0100 (MET) Date: Mon, 18 Mar 2002 23:15:48 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? To: Francis Dupont Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200203182018.g2IKIJg62557@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > => what exactly do you mean by "reserve": > - make them not available at all? > - enforce some control/rules on availability? See my first email on the subject. The summary is: Reserve for future use; any future use requires an standards track RFC. > BTW I have an objection to the "IPv6 over foo" only way: this assumes > there is a real link. With mobile IPv6 there are some scenarios where > the home link is purely virtual, so there is no foo... What does IPv6 over foo have to do this subject? 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 Mar 18 14:22:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IMMCKL010448 for ; Mon, 18 Mar 2002 14:22:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IMMCCW010447 for ipng-dist; Mon, 18 Mar 2002 14:22:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IMM9KL010440 for ; Mon, 18 Mar 2002 14:22:09 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24181 for ; Mon, 18 Mar 2002 14:22:10 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA26440 for ; Mon, 18 Mar 2002 15:22:09 -0700 (MST) Received: from rdroms-w2k.cisco.com (sjc-vpn2-136.cisco.com [10.21.112.136]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA24151 for ; Mon, 18 Mar 2002 17:22:08 -0500 (EST) Message-Id: <4.3.2.7.2.20020318171946.03539b48@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Mar 2002 17:21:06 -0500 To: From: Ralph Droms Subject: Re: DHCPv6 and u/l bit In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Text specifying the appropriate behavior (as Steve describes) on the part of DHCP servers will be added to the next rev of the DHCPv6 spec... - Ralph At 01:02 PM 3/18/2002 -0800, Steve Deering wrote: >At 3:23 PM +0100 3/17/02, Alberto Escudero-Pascual wrote: > >(MUST, SHOULD) the (stateful) addresses provided by a DHCPv6 have the "u" > >bit to 0 as manual configuration? > >If the address provided by the DHCP server contains the modified EUI-64 >value generated from an IEEE 802 or EUI-64 address belonging to the >requesting node, it should have the "u" bit set to one; otherwise, >it should be set to zero. > >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 >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 14:27:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IMRnKL010477 for ; Mon, 18 Mar 2002 14:27:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IMRmht010476 for ipng-dist; Mon, 18 Mar 2002 14:27:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IMRjKL010469 for ; Mon, 18 Mar 2002 14:27:45 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12643 for ; Mon, 18 Mar 2002 14:27:46 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19410 for ; Mon, 18 Mar 2002 14:27:48 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id AAA32683; Tue, 19 Mar 2002 00:27:30 +0200 Date: Tue, 19 Mar 2002 00:27:30 +0200 Message-Id: <200203182227.AAA32683@burp.tkv.asdf.org> From: Markku Savela To: hinden@iprg.nokia.com CC: ipng@sunroof.eng.sun.com In-reply-to: <4.3.2.7.2.20020318134811.026ea818@mailhost.iprg.nokia.com> (message from Bob Hinden on Mon, 18 Mar 2002 13:57:16 -0800) Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: <200203182101.g2IL1gg62706@givry.rennes.enst-bretagne.fr> <200203182101.g2IL1gg62706@givry.rennes.enst-bretagne.fr> <4.3.2.7.2.20020318134811.026ea818@mailhost.iprg.nokia.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Yes. The use of 64 bit interface ID's is defined for prefixes 001 through > 111 ( except for multicast addresses), in RFC2373 "IP Version 6 Addressing > Architecture" published July 1998. See section 2.4. The text regarding > EUI-64 has been clarified in . Ooops... :-} I guess I read some older RFC first, and the change never registered on reading updates (and after implementing the first version). I have all the time falsely assumed that IPv6 address for a specific link layer was n-bit prefix and 128-n bit identifier, where n could be almost anything between 0 and 64. So, there is only those addresses starting with 000 where anything is possible. Thats lots of addresses still, so maybe I keep the implementation as it is :-) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 18 14:27:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IMRiKL010467 for ; Mon, 18 Mar 2002 14:27:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2IMRivM010466 for ipng-dist; Mon, 18 Mar 2002 14:27:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IMRfKL010459 for ; Mon, 18 Mar 2002 14:27:41 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA26333; Mon, 18 Mar 2002 14:27:42 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA28491; Mon, 18 Mar 2002 14:27:38 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2IMRdk13679; Mon, 18 Mar 2002 23:27:39 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id XAA15582; Mon, 18 Mar 2002 23:27:39 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2IMRdg63051; Mon, 18 Mar 2002 23:27:39 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203182227.g2IMRdg63051@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-reply-to: Your message of Mon, 18 Mar 2002 23:15:48 +0100. Date: Mon, 18 Mar 2002 23:27:39 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => what exactly do you mean by "reserve": > - make them not available at all? > - enforce some control/rules on availability? See my first email on the subject. The summary is: Reserve for future use; any future use requires an standards track RFC. => fine, we seem to be in violent agreement. > BTW I have an objection to the "IPv6 over foo" only way: this assumes > there is a real link. With mobile IPv6 there are some scenarios where > the home link is purely virtual, so there is no foo... What does IPv6 over foo have to do this subject? => there are some answers to your next step message arguing the whole stuff should be moved to "IPv6 over foo" documents. My point is this won't work when there is no foo... So I am in favor to keep the modified EUI-64 stuff in the RFC 2373 revision. Regards Francis.Dupont@enst-bretagne.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 Mon Mar 18 15:14:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2INEkKL010667 for ; Mon, 18 Mar 2002 15:14:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2INEkQs010666 for ipng-dist; Mon, 18 Mar 2002 15:14:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2INEdKL010652 for ; Mon, 18 Mar 2002 15:14:40 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12090 for ; Mon, 18 Mar 2002 15:14:41 -0800 (PST) Received: from host238.2alpha.com ([192.104.59.100]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA10942 for ; Mon, 18 Mar 2002 15:14:37 -0800 (PST) Received: from A30P ([192.104.59.110]) by host238.2alpha.com (8.11.3/8.11.0) with ESMTP id g2IN8Oa24248 for ; Mon, 18 Mar 2002 15:08:25 -0800 (PST) Reply-To: From: "Philip J. Nesser II" To: Subject: TCP checksums Date: Mon, 18 Mar 2002 17:14:35 -0600 Organization: Nesser & Nesser Consulting Message-ID: <001e01c1ced2$acfeac70$ea804b0c@A30P> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-reply-to: <200203182227.g2IMRdg63051@givry.rennes.enst-bretagne.fr> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk RFC 793 states in section 3.1 that: "The checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header. This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length." How are people calculating the checksums on IPv6/TCP packets in current implementations? I assume that it is being done uniformly since people seem to interoperate, but for the life of me I can't seem to find it written down in any RFC. Can someone please point me to the appropriate reference? Thanks, Phil -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 15:29:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2INTTKL010823 for ; Mon, 18 Mar 2002 15:29:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2INTTCA010822 for ipng-dist; Mon, 18 Mar 2002 15:29:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2INTPKL010815 for ; Mon, 18 Mar 2002 15:29:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA29935 for ; Mon, 18 Mar 2002 15:29:27 -0800 (PST) Received: from gate.alliedtelesyn.co.nz (gate.alliedtelesyn.co.nz [202.49.72.33]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id QAA24633 for ; Mon, 18 Mar 2002 16:29:25 -0700 (MST) Received: (qmail 19225 invoked from network); 18 Mar 2002 23:29:23 -0000 Received: from aslan.alliedtelesyn.co.nz (HELO alliedtelesyn.co.nz) (202.49.74.92) by gate-int.alliedtelesyn.co.nz with SMTP; 18 Mar 2002 23:29:23 -0000 Received: from ASLAN/SpoolDir by alliedtelesyn.co.nz (Mercury 1.47); 19 Mar 02 11:29:22 +1300 Received: from SpoolDir by ASLAN (Mercury 1.47); 19 Mar 02 11:29:17 +1300 From: "Sean Lin" Organization: Allied Telesyn Research, Chch, NZ To: Date: Tue, 19 Mar 2002 11:29:13 +1200 (NZST) MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: TCP checksums Reply-to: sean.lin@alliedtelesyn.co.nz CC: ipng@sunroof.eng.sun.com Message-ID: <3C972104.4279.4A48ACF@localhost> In-reply-to: <001e01c1ced2$acfeac70$ea804b0c@A30P> References: <200203182227.g2IMRdg63051@givry.rennes.enst-bretagne.fr> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Phillip, Basically the checksumming in IPv6 and IPV4 are pretty much the same; same method but different pseudo-header. The format of the ipv6 pseudo-header is in RFC2460. Regards, Sean > RFC 793 states in section 3.1 that: > > "The checksum also covers a 96 bit pseudo header conceptually prefixed to > the TCP header. This pseudo header contains the Source Address, the > Destination Address, the Protocol, and TCP length." > > How are people calculating the checksums on IPv6/TCP packets in current > implementations? I assume that it is being done uniformly since people > seem to interoperate, but for the life of me I can't seem to find it > written down in any RFC. Can someone please point me to the appropriate > reference? > > Thanks, > > Phil > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- ------------------------------------------------------------- Sean Lin 27 Nazareth Avenue Software Engineer PO Box 8011 Allied Telesyn Research Christchurch phone +64 3 339 3000 New Zealand fax +64 3 339 3002 email: sean.lin@alliedtelesyn.co.nz web: http://www.alliedtelesyn.co.nz/ ------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 16:30:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J0UcKL010999 for ; Mon, 18 Mar 2002 16:30:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J0UcPk010998 for ipng-dist; Mon, 18 Mar 2002 16:30:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J0UbKL010991 for ; Mon, 18 Mar 2002 16:30:37 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2J0TguX024959 for ; Mon, 18 Mar 2002 16:29:42 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g2J0TgZc024958 for ipng@sunroof.eng.sun.com; Mon, 18 Mar 2002 16:29:42 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2EELVKL026603 for ; Thu, 14 Mar 2002 06:21:31 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15748 for ; Thu, 14 Mar 2002 06:21:34 -0800 (PST) Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12290 for ; Thu, 14 Mar 2002 06:21:33 -0800 (PST) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp4.cluster.oleane.net with SMTP id g2EELVj18274 for ; Thu, 14 Mar 2002 15:21:32 +0100 (CET) Message-ID: <00a501c1cb63$70cbf4a0$1901a8c0@oleane.com> From: "Peter Lewis" To: Subject: IPCN 2002 (IP-based Cellular Networks) Date: Thu, 14 Mar 2002 15:20:48 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A2_01C1CB6B.D1B62940" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_00A2_01C1CB6B.D1B62940 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 One of the most interesting subjects of IPCN 2002 (IP-based Cellular = Networks) is the relationship between the licensed 2.5/3G services and = 802.11 hotspots. How can optimal use be made of both environments such = that a realistic business service is possible?=20 Carriers will bring answers next April 23-26 during the third edition of = IPCN (Intersection of Mobile WAN and WLAN).=20 All details at: http://www.upperside.fr/ipcn02/baipcn02intro.htm =20 ------=_NextPart_000_00A2_01C1CB6B.D1B62940 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 
One of the = most=20 interesting subjects of IPCN 2002 (IP-based Cellular Networks) is the=20 relationship between the licensed 2.5/3G services and 802.11 hotspots. = How can=20 optimal use be made of both environments such that a realistic business = service=20 is possible?
Carriers will bring answers next = April 23-26=20 during the third edition of IPCN (Intersection of Mobile WAN and = WLAN).
All details=20 at:
http://www.uppe= rside.fr/ipcn02/baipcn02intro.htm
 
 
------=_NextPart_000_00A2_01C1CB6B.D1B62940-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 16:31:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J0VJKL011009 for ; Mon, 18 Mar 2002 16:31:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J0VJFb011008 for ipng-dist; Mon, 18 Mar 2002 16:31:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J0VHKL011001 for ; Mon, 18 Mar 2002 16:31:17 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2J0UMuX024967 for ; Mon, 18 Mar 2002 16:30:23 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g2J0UMDR024966 for ipng@sunroof.eng.sun.com; Mon, 18 Mar 2002 16:30:22 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2FAqxKL029422 for ; Fri, 15 Mar 2002 02:52:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01474 for ; Fri, 15 Mar 2002 02:53:00 -0800 (PST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA00907 for ; Fri, 15 Mar 2002 03:52:59 -0700 (MST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id g2FAqwR24824; Fri, 15 Mar 2002 11:52:58 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id g2FAqqUD014369; Fri, 15 Mar 2002 12:52:53 +0200 (EET) Message-ID: <3C91D284.A97DBC2B@lmf.ericsson.se> Date: Fri, 15 Mar 2002 12:52:52 +0200 From: Jari Arkko Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: itojun@iijlab.net CC: James Kempf , ipng@sunroof.eng.sun.com Subject: Re: Securing Neighbor Discovery References: <20462.1016157053@itojun.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >So, this is getting a little off topic for this list, perhaps > >we should move the discussion elsewhere? > I guess so. I have set up a list. Send e-mail to ietf-send-request@standards.ericsson.net with the text "subscribe" in the body to join. (The name of the list is "SEND" for Secure Neighbour Discovery.) > one thing i don't understand is, why do you think it is not a problem > for ARP, and is a problem for ND. It is certainly an issue for ARP as well. There's a few issues though which make the issue more relevant for us to discuss in the IPv6 context: - IPv6 has somewhat more control functionality (router discovery etc). Yes, serious enough attacks can be already launched with ARP, but nevertheless. - The IETF doesn't control address resolution on different link technologies. We do, however, control neighbour discovery and ICMPv6. - You could make the argument that let's try to fix this in v6 and move to using it, rather than fixing it in all versions of IP. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 16:32:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J0W4KL011019 for ; Mon, 18 Mar 2002 16:32:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J0W4Lx011018 for ipng-dist; Mon, 18 Mar 2002 16:32:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J0W3KL011011 for ; Mon, 18 Mar 2002 16:32:03 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2J0V8uX024975 for ; Mon, 18 Mar 2002 16:31:08 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g2J0V8po024974 for ipng@sunroof.eng.sun.com; Mon, 18 Mar 2002 16:31:08 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2IFhMKL008905 for ; Mon, 18 Mar 2002 07:43:22 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA03184 for ; Mon, 18 Mar 2002 07:43:23 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA17216 for ; Mon, 18 Mar 2002 07:43:23 -0800 (PST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 18 Mar 2002 07:43:19 -0800 Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Mar 2002 07:43:22 -0800 Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Mar 2002 07:43:21 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Mar 2002 07:43:21 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Mon, 18 Mar 2002 07:40:16 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DNS discovery -04 comments Date: Mon, 18 Mar 2002 07:40:15 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102DB8011@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS discovery -04 comments thread-index: AcHNuJh78+TaD5k1SGOrLOl+TdclOgA2occQ From: "Dave Thaler" To: "Pekka Savola" , Cc: X-OriginalArrivalTime: 18 Mar 2002 15:40:16.0192 (UTC) FILETIME=[33753C00:01C1CE93] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2IFhNKL008906 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola writes: > In the abstract, s/the stateful protocol/stateful protocols/ ? Actually the "stateful" wording needs to be changed anyway, as Ralph Droms pointed out in SLC. > In 3.2, Host behaviour of looking up NS record from the reverse of > site-locals may fail for a couple of reasons: e.g. the site could use > multiple domain names, or if the site has no reverses for site-locals, > they might be looked up from somewhere else (as recursion is desired).. Agree, there is no perfect heuristic. The idea is only to suggest a MAY that is better than nothing in many cases. When the lookup fails for whatever reason, you're no worse off than before when you had nothing. Thanks for the comments, -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 18 19:32:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J3VxKL011947 for ; Mon, 18 Mar 2002 19:32:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J3Vx5T011946 for ipng-dist; Mon, 18 Mar 2002 19:31:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J3VtKL011939 for ; Mon, 18 Mar 2002 19:31:55 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA15826 for ; Mon, 18 Mar 2002 19:31:57 -0800 (PST) Received: from starfruit.itojun.org (wireless-dhcp-189-224.ietf53.cw.net [166.63.189.224]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA23070 for ; Mon, 18 Mar 2002 19:31:56 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by starfruit.itojun.org (Postfix) with ESMTP id D221A7B9; Tue, 19 Mar 2002 12:31:47 +0900 (JST) To: hesham.soliman@era.ericsson.se Cc: ipng@sunroof.eng.sun.com Subject: requirement for celllular IPv6 host draft 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: Tue, 19 Mar 2002 12:31:47 +0900 Message-Id: <20020319033147.D221A7B9@starfruit.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk regarding to "is IPsec mandatory" discussion for cellular. see RFC2460 page 7. > A full implementation of IPv6 includes implementation of the > following extension headers: > > Hop-by-Hop Options > Routing (Type 0) > Fragment > Destination Options > Authentication > Encapsulating Security Payload > > The first four are specified in this document; the last two are > specified in [RFC-2402] and [RFC-2406], respectively. my interpretation: if cellular host does not implement "a full implementation of IPv6", cellular host can omit AH and ESP. so, I believe it okay for cellular host to omit AH/ESP, if needed. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 18 19:49:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J3nZKL012016 for ; Mon, 18 Mar 2002 19:49:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J3nZmO012015 for ipng-dist; Mon, 18 Mar 2002 19:49:35 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J3nVKL012008 for ; Mon, 18 Mar 2002 19:49:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA27324 for ; Mon, 18 Mar 2002 19:49:33 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA03383 for ; Mon, 18 Mar 2002 20:49:28 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2J3kKk32635; Tue, 19 Mar 2002 04:46:20 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id EAA17772; Tue, 19 Mar 2002 04:46:19 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2J3kJg64649; Tue, 19 Mar 2002 04:46:19 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203190346.g2J3kJg64649@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jun-ichiro itojun Hagino cc: hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: Re: requirement for celllular IPv6 host draft In-reply-to: Your message of Tue, 19 Mar 2002 12:31:47 +0900. <20020319033147.D221A7B9@starfruit.itojun.org> Date: Tue, 19 Mar 2002 04:46:19 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > A full implementation of IPv6 includes implementation of the > following extension headers: => this wording is unfortunate: what is a partial implementation of IPv6? Regards Francis.Dupont@enst-bretagne.fr PS: we definitely *need* an IPv6 host requirement document! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 19:55:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J3tqKL012090 for ; Mon, 18 Mar 2002 19:55:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J3tqb6012089 for ipng-dist; Mon, 18 Mar 2002 19:55:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J3tnKL012082 for ; Mon, 18 Mar 2002 19:55:49 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA28385 for ; Mon, 18 Mar 2002 19:55:51 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA19297 for ; Mon, 18 Mar 2002 20:55:50 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2J3tnkY024683 for ; Tue, 19 Mar 2002 04:55:49 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Mar 19 04:55:48 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 04:55:48 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB48@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Francis Dupont'" , Jun-ichiro itojun Hagino Cc: "Hesham Soliman (ERA)" , ipng@sunroof.eng.sun.com Subject: RE: requirement for celllular IPv6 host draft Date: Tue, 19 Mar 2002 04:55:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A full implementation of IPv6 includes implementation of the > > following extension headers: > > => this wording is unfortunate: what is a partial implementation > of IPv6? > ' > PS: we definitely *need* an IPv6 host requirement document! => Yes ! Hesham > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 20:01:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J41bKL012130 for ; Mon, 18 Mar 2002 20:01:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J41aIH012129 for ipng-dist; Mon, 18 Mar 2002 20:01:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J41XKL012122 for ; Mon, 18 Mar 2002 20:01:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA25971 for ; Mon, 18 Mar 2002 20:01:35 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id VAA06302 for ; Mon, 18 Mar 2002 21:01:34 -0700 (MST) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id EAA20500; Tue, 19 Mar 2002 04:01:32 GMT Received: from login.ecs.soton.ac.uk (IDENT:tjc@login.ecs.soton.ac.uk [152.78.68.149]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id EAA15886; Tue, 19 Mar 2002 04:01:34 GMT Date: Tue, 19 Mar 2002 04:01:32 +0000 (GMT) From: Tim Chown To: Jun-ichiro itojun Hagino cc: hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com Subject: Re: requirement for celllular IPv6 host draft In-Reply-To: <20020319033147.D221A7B9@starfruit.itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 19 Mar 2002, Jun-ichiro itojun Hagino wrote: > my interpretation: if cellular host does not implement "a full > implementation of IPv6", cellular host can omit AH and ESP. > so, I believe it okay for cellular host to omit AH/ESP, if needed. Though section 10 of rfc2401 says: All IPv6 systems MUST comply with all requirements of the Security Architecture document. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Mar 18 20:02:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J42mKL012159 for ; Mon, 18 Mar 2002 20:02:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J42mkP012158 for ipng-dist; Mon, 18 Mar 2002 20:02:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J42jKL012151 for ; Mon, 18 Mar 2002 20:02:45 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA29763 for ; Mon, 18 Mar 2002 20:02:47 -0800 (PST) From: matthew.ford@bt.com Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA08718 for ; Mon, 18 Mar 2002 20:02:43 -0800 (PST) Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Tue, 19 Mar 2002 04:02:41 +0000 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2654.89) id ; Tue, 19 Mar 2002 04:02:32 -0000 Message-ID: To: ipng@sunroof.eng.sun.com Subject: IPv6 cellular hosts draft Date: Tue, 19 Mar 2002 04:02:31 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There seems to be a lot of overlap between this draft and both the proposed IPv6 node requirements draft, and the IPv6 over 3GPP PDP contexts draft. Is the working group willing to tolerate this for the sake of getting something done in time for the R5 deadline? I'm concerned that this will result in yet more confusion for the cellular network community. If we have a node requirements document and an IPv6 over 3GPP document, what is the purpose of the cellular hosts document? Mat. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 20:06:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J46lKL012226 for ; Mon, 18 Mar 2002 20:06:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J46lY7012225 for ipng-dist; Mon, 18 Mar 2002 20:06:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J46iKL012215 for ; Mon, 18 Mar 2002 20:06:44 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA20781 for ; Mon, 18 Mar 2002 20:06:46 -0800 (PST) Received: from byd.ocn.ad.jp (byd.ocn.ad.jp [203.139.162.147]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA22391 for ; Mon, 18 Mar 2002 21:06:45 -0700 (MST) Received: from r505r (byd.ocn.ad.jp [203.139.162.147]) by byd.ocn.ad.jp (8.8.8/3.6W) with SMTP id NAA25512; Tue, 19 Mar 2002 13:06:38 +0900 (JST) Message-ID: <008c01c1cefb$4047e050$45bb3fa6@local> From: "Yamasaki Toshi" To: Cc: Subject: Questions about draft-ietf-ipv6-cellular-host-00.txt Date: Tue, 19 Mar 2002 13:04:41 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Heshman, Allow me to ask questions on this ML, because I missed to ask the WG meeting on Monday. Q1) What is the main reason why you assume two PPPs when a customer has two IPv6 enabled terminals under one Cellular Phone working as a bridge? You could assume to use one PPP to the Cellular Phone (or other terminal conneted to it) working as a MSR or L3router. Q2) Why do you assign a /64 not /128 to each mobile terminal, while you are sure there is only ONE host connected to the PPP link? Q3) Is it a good privacy protection to use the privacy extention under a /64 while everyone knows that /64 is assigned to his/her Cellular Terminal? Actually I'm developing a model for IPv6/DSL services and IPv6 Hot Spot services. You can find an temporaly document at: http://www.apnic.net/meetings/13/sigs/docs/4.3_OSG_UNI.ppt Your model of IPv6 access services for Cellular terminals are similar to my models assigning a /64 per customer, and I had and still have the same issues that I'm asking you in those questions above. Thanks in advance. --- Toshi Yamasaki / NTT Communications -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 20:35:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J4Z8KL012332 for ; Mon, 18 Mar 2002 20:35:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J4Z897012331 for ipng-dist; Mon, 18 Mar 2002 20:35:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J4Z3KL012321 for ; Mon, 18 Mar 2002 20:35:03 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA23350 for ; Mon, 18 Mar 2002 20:35:05 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA04767 for ; Mon, 18 Mar 2002 20:35:09 -0800 (PST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 18 Mar 2002 20:34:57 -0800 Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Mar 2002 20:35:04 -0800 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Mar 2002 20:35:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: router selection draft comments Date: Mon, 18 Mar 2002 20:35:04 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA806444033@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: router selection draft comments thread-index: AcHN6pShrMgljNCSR32pUq/gyJiEawAwTUcQ From: "Richard Draves" To: "Pekka Savola" , X-OriginalArrivalTime: 19 Mar 2002 04:35:04.0314 (UTC) FILETIME=[7089B5A0:01C1CEFF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2J4Z3KL012322 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka, thanks for giving the draft a careful reading. If I don't respond to a comment below, that means I've incorporated your suggestion. > Abstract > > This document describes an optional extension to Neighbor Discovery > Router Advertisement messages for communicating default router > preferences and more-specific routes from routers to hosts. This > improves the ability of hosts to pick an appropriate router, > especially when the host is multi-homed and the routers are on > different links. The preference values and specific routes > advertised to hosts require administrative configuration; they are > not automatically derived from routing tables. > > ==> The preference values [...] could be removed IMO: this is > being overly > verbose detail for an abstract. I disagree - this is an important aspect of the proposal and it's appropriate to be clear about it up front. > Neighbor Discovery provides a Redirect message that routers can use > to correct a host's choice of router. A router can send a Redirect > message to a host, telling it to use a different router for a > specific destination. However, the Redirect functionality > is limited > to a single link. A router on one link cannot redirect a host to a > router on another link. Hence, Redirect messages do not help multi- > homed hosts select an appropriate router. > > ==> Note about on-link redirecting. Usually, this is > interpreted to mean: > > +- router1 -x - routerA --> > host -| X > +- router2 -x - routerB --> > > the only "trivial ones" are: > > traffic: host -> router1 -> router2 -> router{A,B}, router1 > redirect -> > router2 > traffic: host -> router2 -> router1 -> router{A,B}, router2 > redirect -> > router1 > > One should note that on-link redirection _could_ > theoretically be done for > more complex scenarios (e.g. host -> router1 -> routerB, router1 send > redirects to host for router2), but that would be difficult > algorithmically. This is true, but it is orthogonal to the point I was making. So I don't see a need to change the draft. > 2.2. Changes to Router Advertisement Message Format > > Prf (Default Router Preference) > 2-bit signed integer. Indicates whether or not > to prefer > this router over other default routers. If Router > Lifetime is zero, it MUST be initialized to zero by the > sender and MUST be ignored by the receiver. If the > Reserved (10) value is received, the receiver should > treat the RA as having a zero Router Lifetime. > > ==> Is there a reason to specify any behaviour for 10 at this point? There was an previous request from the WG to specify this behavior. I don't recall the reasoning behind the request, but maybe the rationale was that if implementations behave differently it will be more difficult to ever make use of the code point in the future, because an analysis of the impact on then-existing implementations will be more difficult. > 2.3. Route Information Option > Length 1, 2, or 3 depending on Prefix Length. If Prefix Length > is greater than 64, then Length must be at least 3. If > Prefix Length is greater than 0, then Length must be at > least 2. If Prefix Length is zero, then Length > may be 1. > > ==> Perhaps it would be best by defining that Length is the > length of the > option padded up to 8-byte blocks. I think the current formulation is more precisely prescriptive. In particular, I want to allow simplistic senders to always send 24 byte options while more sophisticated senders can optimize with 8 or 16 byte options. > 3.1. Conceptual Data Structures for Hosts > > Host B uses a Default Router List augmented with preference values. > Host B does not have a routing table. Host B uses the > Default Router > Preference value in the Router Advertisement header. Host B ignores > Route Information Options. > > ==> doesn't every host have a routing table of sorts..? No. For example, early versions of the Microsoft Research IPv6 implementation had a default router list and a prefix list but not a routing table. > Host C uses a Routing Table instead of a Default Router List. (The > Routing Table may also subsume the Prefix List, but that is beyond > the scope of this document.) Entries in the Routing Table have a > prefix, prefix length, preference value, lifetime, and next-hop > router. Host C uses both the Default Router Preference value in the > Router Advertisement header and Route Information Options. > > ==> I think Routing Table shouldn't be capitalized, because > it isn't an > "official" term anywhere. For the purposes of this draft, the term Routing Table refers to a conceptual data structure in the same way that the terms Default Router List and Prefix List do, so I think it also should be capitalized for consistency. > For example, suppose a host receives a Router Advertisement from > router X with a Router Lifetime of 100 seconds and Default Router > Preference of Medium. The body of the Router Advertisement contains > a Route Information Option for ::/0 with a Route Lifetime of 200 > seconds and a Route Preference of Low. After processing the Router > Advertisement, host A will have an entry for router X in > its Default > Router List with lifetime 100 seconds. If host B receives the same > Router Advertisement, it will have an entry in its Default Router > List for router X with Medium preference and lifetime 100 seconds. > Host C will have an entry in its Routing Table for ::/0 -> > router X, > with Low preference and lifetime 200 seconds. > > ==> Depending on the implementation, there may be a race > condition if the > implementation don't wait until the end of the processing of > the whole > message (first accept lifetime 100, pref=low for a very short > time until > the rest of the message is parsed). I'm not sure whether > this is obvious > or not.. I will clarify that it is OK for implementations to have this race condition. > If all default > routers are not reachable, then it SHOULD round-robin > among them all > regardless of preference value. > > ==> s/not reachable/unreachable/ > > ==> Is this similar policy already used somewhere (e.g. > RFC2461)? Some > comparison with "old" mechanism in this case might be in order. RFC 2461 says that when no default routers are known to be reachable or probably reachable, routers SHOULD be selected in a round-robin fashion. So the round-robin idea here does have precedent. > If there are no routes matching the destination, then if host C has > a single interface then it SHOULD assume the destination > is on-link. > If host C has multiple interfaces then it SHOULD discard the packet > and report a Destination Unreachable / No Route To > Destination error > to the upper layer. > > ==> how does this relate to current mechanism? RFC 2461 says that if there are no default routers, then the destination should be considered on-link. However RFC 2461 does not consider multiple interfaces - see Appendix A. > 3.4. Router Reachability Probing > > When a host avoids using a non-reachable router X and > instead uses a > reachable router Y, and the host would have used router X if router > X were reachable, then the host SHOULD probe router XÆs > reachability > by sending a Neighbor Solicitation. These probes MUST be rate- > limited to no more than one per minute per router. > > ==> ditto. This router-reachability probing is somewhat new. It's related to the round-robining specified in RFC 2461 when the default routers are all unreachable. The difference is our operational experience at Microsoft produced situations in which a preferred router was temporarily unreachable and so hosts stopped using it, but when connectivity was restored they did not resume using it because they had already failed over to a less-preferred but reachable router. The RFC 2461 round-robining didn't help so I added this router-reachability probing. With router-reachability probing, the RFC 2461 round-robining is not strictly necessary - if the host knows of several unreachable routers, it could just use one and let router-reachability probing check the rest, instead of having Next-Hop Determination round-robin among them. The only real difference is exactly how often you end up sending Neighbor Solicitations to the different routers. > 4. Router Configuration > As one exception to this general rule, the administrator > of a router > that does not have a connection to the internet, or is connected > through a firewall that blocks general traffic, may configure the > router to advertise a Low Default Router Preference. > > ==> usually if there is such a policy in the firewall, it's > there for a > reason, and should not be tried to be avoided. Therefore, I > think the > firewall part of the above should be removed. I don't understand. The point of having the firewall router advertise a Low preference is to let hosts know that it's not a good choice for general internet connectivity - respecting the firewall policy. > Routers SHOULD NOT send more than 17 Route Information Options in > Router Advertisements per link. > > ==> due to XXX? (MTU concerns?) Due to feedback from an IESG member, if I recall correctly :-). The idea is to further reinforce that this is not an appropriate mechanism for dumping lots of routes onto a host. > 5.2. Multi-Homed Host and Isolated Network > > Here's another scenario: a multi-homed host is connected to the > 6bone/internet via router X on one link and to an isolated network > via router Y on another link. The multi-homed host might have a > tunnel into a fire-walled corporate network, or it might > be directly > connected to an isolated test network. > > In this situation, a multi-homed host A (which has no > default router > preferences or more-specific routes) will have no way to choose > between the two routers X and Y on its Default Router > List. Users of > the host will see unpredictable connectivity failures, depending on > the destination address and the choice of router. > > ==> just a note: in this kind of scenario, there would be > static routes in > the nodes... That's the point - the idea is to make these scenarios work without hacking static routes into the hosts. 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 Mar 18 20:35:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J4Z7KL012329 for ; Mon, 18 Mar 2002 20:35:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J4Z71W012328 for ipng-dist; Mon, 18 Mar 2002 20:35:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J4Z1KL012314 for ; Mon, 18 Mar 2002 20:35:01 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA24274 for ; Mon, 18 Mar 2002 20:35:04 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA04761 for ; Mon, 18 Mar 2002 20:35:07 -0800 (PST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 18 Mar 2002 20:35:03 -0800 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 18 Mar 2002 20:35:03 -0800 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 18 Mar 2002 20:35:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: I-D ACTION:draft-ietf-ipv6-router-selection-01.txt Date: Mon, 18 Mar 2002 20:35:02 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA806444032@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-ipv6-router-selection-01.txt thread-index: AcHDMa6Nk3UYRh/zRD+yQG+eDO/mdwBKNcWwApQFiHA= From: "Richard Draves" To: "Michel Py" Cc: X-OriginalArrivalTime: 19 Mar 2002 04:35:02.0885 (UTC) FILETIME=[6FAFA950:01C1CEFF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2J4Z2KL012315 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, I think source-address-based routing is an interesting idea but out of scope for this draft. Thanks, Rich > -----Original Message----- > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > Sent: Tuesday, March 05, 2002 7:37 AM > To: Richard Draves > Cc: ipng@sunroof.eng.sun.com > Subject: RE: I-D ACTION:draft-ietf-ipv6-router-selection-01.txt > > > Richard, > > Preliminary comments: If I read it correctly, all the RA > extensions are based on destination IPv6 address. I can see > several situations where it might be useful to have some RA > extensions based on the source address as well, which would > create some kind of a policy routing in the hosts (decide > where to send traffic based on the source IP, not the > destination one). > > Michel. > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 21:14:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J5EgKL012517 for ; Mon, 18 Mar 2002 21:14:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J5EgUU012516 for ipng-dist; Mon, 18 Mar 2002 21:14:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J5EdKL012509 for ; Mon, 18 Mar 2002 21:14:39 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA10624 for ; Mon, 18 Mar 2002 21:14:42 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA13661 for ; Mon, 18 Mar 2002 21:14:41 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id HAA00644; Tue, 19 Mar 2002 07:14:24 +0200 Date: Tue, 19 Mar 2002 07:14:24 +0200 Message-Id: <200203190514.HAA00644@burp.tkv.asdf.org> From: Markku Savela To: sean.lin@alliedtelesyn.co.nz CC: phil@nesser.com, ipng@sunroof.eng.sun.com In-reply-to: <3C972104.4279.4A48ACF@localhost> (sean.lin@alliedtelesyn.co.nz) Subject: Re: TCP checksums References: <200203182227.g2IMRdg63051@givry.rennes.enst-bretagne.fr> <3C972104.4279.4A48ACF@localhost> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: "Sean Lin" > Basically the checksumming in IPv6 and IPV4 are pretty much the > same; same method but different pseudo-header. The format of the ipv6 > pseudo-header is in RFC2460. Minor additional tidbit... ...you can use IPv6 pseudoheader for BOTH IPv4 and IPv6, if you use IPv4 mapped addresses for IPv4. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 21:27:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J5RvKL012574 for ; Mon, 18 Mar 2002 21:27:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J5Rvu9012573 for ipng-dist; Mon, 18 Mar 2002 21:27:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J5RsKL012566 for ; Mon, 18 Mar 2002 21:27:54 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA17559 for ; Mon, 18 Mar 2002 21:27:55 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA21666 for ; Mon, 18 Mar 2002 21:27:51 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2J5RpD12905; Tue, 19 Mar 2002 07:27:51 +0200 Date: Tue, 19 Mar 2002 07:27:51 +0200 (EET) From: Pekka Savola To: Richard Draves cc: ipng@sunroof.eng.sun.com Subject: RE: router selection draft comments In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA806444033@red-msg-06.redmond.corp.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I'll just comment on just some issues. On Mon, 18 Mar 2002, Richard Draves wrote: > Pekka, thanks for giving the draft a careful reading. If I don't respond to a comment below, that means I've incorporated your suggestion. > > > Neighbor Discovery provides a Redirect message that routers can use > > to correct a host's choice of router. A router can send a Redirect > > message to a host, telling it to use a different router for a > > specific destination. However, the Redirect functionality > > is limited > > to a single link. A router on one link cannot redirect a host to a > > router on another link. Hence, Redirect messages do not help multi- > > homed hosts select an appropriate router. > > > > ==> Note about on-link redirecting. Usually, this is > > interpreted to mean: > > > > +- router1 -x - routerA --> > > host -| X > > +- router2 -x - routerB --> > > > > the only "trivial ones" are: > > > > traffic: host -> router1 -> router2 -> router{A,B}, router1 > > redirect -> > > router2 > > traffic: host -> router2 -> router1 -> router{A,B}, router2 > > redirect -> > > router1 > > > > One should note that on-link redirection _could_ > > theoretically be done for > > more complex scenarios (e.g. host -> router1 -> routerB, router1 send > > redirects to host for router2), but that would be difficult > > algorithmically. > > This is true, but it is orthogonal to the point I was making. So I don't > see a need to change the draft. I agree: what I was describing was a way of doing a part of single-link functionality in a different fashion; but as I think your mechanism is simpler, this was just pointing out an another capability of redirects. > > 2.3. Route Information Option > > Length 1, 2, or 3 depending on Prefix Length. If Prefix Length > > is greater than 64, then Length must be at least 3. If > > Prefix Length is greater than 0, then Length must be at > > least 2. If Prefix Length is zero, then Length > > may be 1. > > > > ==> Perhaps it would be best by defining that Length is the > > length of the > > option padded up to 8-byte blocks. > > I think the current formulation is more precisely prescriptive. In > particular, I want to allow simplistic senders to always send 24 byte > options while more sophisticated senders can optimize with 8 or 16 byte > options. Doesn't the rule I pointed above fill these requirements? Actually, I just wanted a short sentence, like [RFC2461]: Length 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 octets. Perhaps the first one is obvious; when you go straight to explaining values to be used, it may seem a bit out of context (this is a balance between being too terse and too verbose though) if you don't have very clear visual image how Length was encoded. > > Host C uses a Routing Table instead of a Default Router List. (The > > Routing Table may also subsume the Prefix List, but that is beyond > > the scope of this document.) Entries in the Routing Table have a > > prefix, prefix length, preference value, lifetime, and next-hop > > router. Host C uses both the Default Router Preference value in the > > Router Advertisement header and Route Information Options. > > > > ==> I think Routing Table shouldn't be capitalized, because > > it isn't an > > "official" term anywhere. > > For the purposes of this draft, the term Routing Table refers to a > conceptual data structure in the same way that the terms Default Router > List and Prefix List do, so I think it also should be capitalized for > consistency. I disagree: Prefix List and DRL are the terms (capitalized) also used by the normative reference RFC2461, while Routing Table (capitalized) is *not*. So I think it should be non-capitalized (or defined). > > For example, suppose a host receives a Router Advertisement from > > router X with a Router Lifetime of 100 seconds and Default Router > > Preference of Medium. The body of the Router Advertisement contains > > a Route Information Option for ::/0 with a Route Lifetime of 200 > > seconds and a Route Preference of Low. After processing the Router > > Advertisement, host A will have an entry for router X in > > its Default > > Router List with lifetime 100 seconds. If host B receives the same > > Router Advertisement, it will have an entry in its Default Router > > List for router X with Medium preference and lifetime 100 seconds. > > Host C will have an entry in its Routing Table for ::/0 -> > > router X, > > with Low preference and lifetime 200 seconds. > > > > ==> Depending on the implementation, there may be a race > > condition if the > > implementation don't wait until the end of the processing of > > the whole > > message (first accept lifetime 100, pref=low for a very short > > time until > > the rest of the message is parsed). I'm not sure whether > > this is obvious > > or not.. > > I will clarify that it is OK for implementations to have this race > condition. IMO, it would probably be better *not* to have that race condition (consider if implementation send out two RA's, first incorrect one, second good one, 100 us apart). Not sure if that's easier to describe though. > > 3.4. Router Reachability Probing > > > > When a host avoids using a non-reachable router X and > > instead uses a > > reachable router Y, and the host would have used router X if router > > X were reachable, then the host SHOULD probe router XÆs > > reachability > > by sending a Neighbor Solicitation. These probes MUST be rate- > > limited to no more than one per minute per router. > > > > ==> ditto. > > This router-reachability probing is somewhat new. It's related to the > round-robining specified in RFC 2461 when the default routers are all > unreachable. The difference is our operational experience at Microsoft > produced situations in which a preferred router was temporarily > unreachable and so hosts stopped using it, but when connectivity was > restored they did not resume using it because they had already failed > over to a less-preferred but reachable router. The RFC 2461 > round-robining didn't help so I added this router-reachability probing. > > With router-reachability probing, the RFC 2461 round-robining is not > strictly necessary - if the host knows of several unreachable routers, > it could just use one and let router-reachability probing check the > rest, instead of having Next-Hop Determination round-robin among them. > The only real difference is exactly how often you end up sending > Neighbor Solicitations to the different routers. Concerns were raised on the w.g. meeting, so I'll leave this here for now. > > 4. Router Configuration > > As one exception to this general rule, the administrator > > of a router > > that does not have a connection to the internet, or is connected > > through a firewall that blocks general traffic, may configure the > > router to advertise a Low Default Router Preference. > > > > ==> usually if there is such a policy in the firewall, it's > > there for a > > reason, and should not be tried to be avoided. Therefore, I > > think the > > firewall part of the above should be removed. > > I don't understand. The point of having the firewall router advertise a > Low preference is to let hosts know that it's not a good choice for > general internet connectivity - respecting the firewall policy. Most definitely not. The point of the firewall is protecting hosts. Hosts using some other router because of higher preference (and thus being at least partially unprotected) is exactly the opposite: Firewalls should advertize _high_ default priority. (However, more specific routes to some other routes might have a better priority than the firewall, as these could most often be considered "internal networks"). I think you're considering firewall a bad evil connection-blocker: I see it as a protector. I guess that comes from defining the firewall policies yourself.. :-) > > Routers SHOULD NOT send more than 17 Route Information Options in > > Router Advertisements per link. > > > > ==> due to XXX? (MTU concerns?) > > Due to feedback from an IESG member, if I recall correctly :-). The idea > is to further reinforce that this is not an appropriate mechanism for > dumping lots of routes onto a host. A valid concern: however, I just happen to dislike "magic numbers", but e.g. pre-RFC2460 had some reasoning behind the magic of maximum number of routing header intermediate hops (23): I was wondering if there is something similar here. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 21:46:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J5kkKL012655 for ; Mon, 18 Mar 2002 21:46:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J5kkQM012654 for ipng-dist; Mon, 18 Mar 2002 21:46:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J5khKL012647 for ; Mon, 18 Mar 2002 21:46:43 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA03544 for ; Mon, 18 Mar 2002 21:46:44 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA24788 for ; Mon, 18 Mar 2002 21:46:40 -0800 (PST) Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2J5lSi27618 for ; Tue, 19 Mar 2002 07:47:28 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Mar 2002 07:46:42 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 19 Mar 2002 07:46:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IPv6 cellular hosts draft Date: Tue, 19 Mar 2002 07:46:41 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64C76@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 cellular hosts draft Thread-Index: AcHO+06007knTNU8Qva8kUs4HLmnLwADfepg To: , X-OriginalArrivalTime: 19 Mar 2002 05:46:42.0053 (UTC) FILETIME=[7230A350:01C1CF09] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2J5khKL012648 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mat, > There seems to be a lot of overlap between this draft and > both the proposed > IPv6 node requirements draft, and the IPv6 over 3GPP PDP > contexts draft. Is > the working group willing to tolerate this for the sake of > getting something > done in time for the R5 deadline? I'm concerned that this > will result in yet > more confusion for the cellular network community. If we have a node > requirements document and an IPv6 over 3GPP document, what is > the purpose of the cellular hosts document? If at the time that there is a IPv6 over Foo document with RFC status and a IPv6 Node Requirements document that is an RFC, then the information document can be made obsolete. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 22:15:04 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J6F4KL012694 for ; Mon, 18 Mar 2002 22:15:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J6F4KD012693 for ipng-dist; Mon, 18 Mar 2002 22:15:04 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J6F1KL012686 for ; Mon, 18 Mar 2002 22:15:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA23557 for ; Mon, 18 Mar 2002 22:15:03 -0800 (PST) From: matthew.ford@bt.com Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA10432 for ; Mon, 18 Mar 2002 23:15:01 -0700 (MST) Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Tue, 19 Mar 2002 06:10:04 +0000 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2654.89) id ; Tue, 19 Mar 2002 06:09:56 -0000 Message-ID: To: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: RE: IPv6 cellular hosts draft Date: Tue, 19 Mar 2002 06:09:53 -0000 X-Mailer: Internet Mail Service (5.5.2654.89) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Well, I guess that's OK as long as 3GPP are happy referencing an obsolete (and superceded) document. What I mean is, will the reference to the Informational document still make sense when people come to implement this? Will they know where to look for the up-to-date information? Mat. -----Original Message----- From: john.loughney To: matthew.ford; ipng Sent: 19/03/02 05:46 Subject: RE: IPv6 cellular hosts draft Hi Mat, > There seems to be a lot of overlap between this draft and > both the proposed > IPv6 node requirements draft, and the IPv6 over 3GPP PDP > contexts draft. Is > the working group willing to tolerate this for the sake of > getting something > done in time for the R5 deadline? I'm concerned that this > will result in yet > more confusion for the cellular network community. If we have a node > requirements document and an IPv6 over 3GPP document, what is > the purpose of the cellular hosts document? If at the time that there is a IPv6 over Foo document with RFC status and a IPv6 Node Requirements document that is an RFC, then the information document can be made obsolete. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 18 22:56:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J6uJKL012746 for ; Mon, 18 Mar 2002 22:56:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J6uJ66012745 for ipng-dist; Mon, 18 Mar 2002 22:56:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J6uGKL012738 for ; Mon, 18 Mar 2002 22:56:16 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA01534 for ; Mon, 18 Mar 2002 22:56:18 -0800 (PST) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA01100 for ; Mon, 18 Mar 2002 22:56:19 -0800 (PST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 19 Mar 2002 12:43:38 +0530 Received: from murugankat (murugankat.future.futsoft.com [10.20.6.9]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g2J6txH20086 for ; Tue, 19 Mar 2002 12:25:59 +0530 Reply-To: From: "Murugan KAT" To: "'IPng List'" Subject: Dual stack routers Date: Tue, 19 Mar 2002 12:44:32 +0530 Message-Id: <001601c1cf15$b88a0380$0906140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000201c1ceab$d6811dc0$0906140a@future.futsoft.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Murugan KAT Sent: Tuesday, 19 March 2002 12:07 AM To: 'IPng List' Subject: RE: Requirements for 'O' flag (was Re: IPv6 working group agendafor Minneapolis IETF) Hi, Regarding Dual Stack Router implementation should a router maintain 2 routing tables, one for V4 and other for V6. What about the routing stacks? Should there be 2 instances of a routing protocol (BGP, OSPF etc.,) ? What is the general approach? Thanks, KAT -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Mar 18 23:24:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J7OXKL012890 for ; Mon, 18 Mar 2002 23:24:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J7OXQ6012889 for ipng-dist; Mon, 18 Mar 2002 23:24:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J7OUKL012882 for ; Mon, 18 Mar 2002 23:24:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA11363 for ; Mon, 18 Mar 2002 23:24:32 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA00335 for ; Tue, 19 Mar 2002 00:24:31 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id AE8B758B0; Tue, 19 Mar 2002 02:24:25 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Mar 2002 02:24:25 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: requirement for celllular IPv6 host draft Date: Tue, 19 Mar 2002 02:24:25 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520954@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: requirement for celllular IPv6 host draft Thread-Index: AcHO+i/f78g3jW7IS/amwl/hrxcq3QAHGtbQ From: "Bound, Jim" To: "Hesham Soliman (ERA)" , "Francis Dupont" , "Jun-ichiro itojun Hagino" Cc: X-OriginalArrivalTime: 19 Mar 2002 07:24:25.0614 (UTC) FILETIME=[19250AE0:01C1CF17] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2J7OUKL012883 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, I strongly disagree. What is an IPv6 Hosts document going to tell us that we don't already know as implementors for IPv6? If its new requirements then we should write a draft on those requirements? I always hated the 1122 and 1123 restated the obvious to kernel OS implementors. I would argue the spec was good but it did not work in the market. What made implementations interoperable were bake-offs and learning to make the general TCP/IP specs work. Now for new requirements thats fine. We are trying to reduce the work load in the IETF not increase it? I don't see the business or technical benefit of using up the working groups energy with such a document. Maybe someone should write up what it would do and we should discuss that? I feel like we are urinating in the wind here. thanks /jim > -----Original Message----- > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > Sent: Monday, March 18, 2002 10:56 PM > To: 'Francis Dupont'; Jun-ichiro itojun Hagino > Cc: Hesham Soliman (ERA); ipng@sunroof.eng.sun.com > Subject: RE: requirement for celllular IPv6 host draft > > > > A full implementation of IPv6 includes implementation of the > > > following extension headers: > > > > => this wording is unfortunate: what is a partial implementation > > of IPv6? > > > ' > PS: we definitely *need* an IPv6 host requirement document! > > => Yes ! > > Hesham > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 18 23:26:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J7QtKL012912 for ; Mon, 18 Mar 2002 23:26:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J7Qtje012911 for ipng-dist; Mon, 18 Mar 2002 23:26:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J7QqKL012904 for ; Mon, 18 Mar 2002 23:26:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA07646 for ; Mon, 18 Mar 2002 23:26:54 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA19108 for ; Tue, 19 Mar 2002 00:26:53 -0700 (MST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 7B46D3662; Tue, 19 Mar 2002 02:26:52 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Mar 2002 02:26:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: TCP checksums Date: Tue, 19 Mar 2002 02:26:51 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520955@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TCP checksums Thread-Index: AcHPBT2WGKwaK+IjSIijpm6d2L7+/gAEiIUA From: "Bound, Jim" To: "Markku Savela" , Cc: , X-OriginalArrivalTime: 19 Mar 2002 07:26:52.0396 (UTC) FILETIME=[70A232C0:01C1CF17] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2J7QqKL012905 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes you can and a wonderful thing it is to build ones implementation that way :---) /jim > -----Original Message----- > From: Markku Savela [mailto:msa@burp.tkv.asdf.org] > Sent: Tuesday, March 19, 2002 12:14 AM > To: sean.lin@alliedtelesyn.co.nz > Cc: phil@nesser.com; ipng@sunroof.eng.sun.com > Subject: Re: TCP checksums > > > > > From: "Sean Lin" > > > Basically the checksumming in IPv6 and IPV4 are pretty much the > > same; same method but different pseudo-header. The format > of the ipv6 > > pseudo-header is in RFC2460. > > Minor additional tidbit... > > ...you can use IPv6 pseudoheader for BOTH IPv4 and IPv6, if you use > IPv4 mapped addresses for IPv4. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 18 23:32:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J7WDKL012941 for ; Mon, 18 Mar 2002 23:32:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J7WDEd012940 for ipng-dist; Mon, 18 Mar 2002 23:32:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J7WAKL012933 for ; Mon, 18 Mar 2002 23:32:10 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13165 for ; Mon, 18 Mar 2002 23:32:10 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA07854 for ; Mon, 18 Mar 2002 23:32:13 -0800 (PST) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id EE37836C0; Tue, 19 Mar 2002 02:32:09 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Mar 2002 02:32:09 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Dual stack routers Date: Tue, 19 Mar 2002 02:32:09 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B37C@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dual stack routers Thread-Index: AcHPE1/dr4hNE6QJTXeab2RKRKgzugABCrhQ From: "Bound, Jim" To: , "IPng List" X-OriginalArrivalTime: 19 Mar 2002 07:32:09.0896 (UTC) FILETIME=[2DE0DA80:01C1CF18] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2J7WAKL012934 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Its really up to the engineering team for that implementation. I would integrate v4 and v6 and duplicate as little as possible. At least all data structures so the algorithm for update/replace/delete was the same function module and not duplicated once for tcp and once for udp and yet again for SCTP. Then there is the emerging RDMA the router might want to use for storage. Treating all addresses as 16bytes (v4 and v6) works and will perform. Also all the traffic shaping, classification, et al on hardware would make the hardware engineers job a lot easier and thats a performance win too to support both address types. regards, /jim > -----Original Message----- > From: Murugan KAT [mailto:murugankat@future.futsoft.com] > Sent: Tuesday, March 19, 2002 2:15 AM > To: 'IPng List' > Subject: Dual stack routers > > > > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Murugan KAT > Sent: Tuesday, 19 March 2002 12:07 AM > To: 'IPng List' > Subject: RE: Requirements for 'O' flag (was Re: IPv6 working group > agendafor Minneapolis IETF) > > > Hi, > > Regarding Dual Stack Router implementation should a router maintain 2 > routing tables, one for V4 and other for V6. What about the > routing stacks? > Should there be 2 instances of a routing protocol (BGP, OSPF etc.,) ? > > What is the general approach? > > > Thanks, > KAT > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 18 23:33:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J7XPKL012961 for ; Mon, 18 Mar 2002 23:33:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2J7XPIF012960 for ipng-dist; Mon, 18 Mar 2002 23:33:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2J7XLKL012953 for ; Mon, 18 Mar 2002 23:33:21 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18762 for ; Mon, 18 Mar 2002 23:33:22 -0800 (PST) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA15360 for ; Tue, 19 Mar 2002 00:33:21 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id D39533706; Tue, 19 Mar 2002 02:33:20 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Mar 2002 02:33:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: requirement for celllular IPv6 host draft Date: Tue, 19 Mar 2002 02:33:20 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B01520957@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: requirement for celllular IPv6 host draft Thread-Index: AcHO+i/f78g3jW7IS/amwl/hrxcq3QAHGtbQAABqd8A= From: "Bound, Jim" To: "Bound, Jim" , "Hesham Soliman (ERA)" , "Francis Dupont" , "Jun-ichiro itojun Hagino" Cc: X-OriginalArrivalTime: 19 Mar 2002 07:33:20.0756 (UTC) FILETIME=[581D3B40:01C1CF18] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2J7XMKL012954 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk but I do think we need the cellular hosts doc for 3GGP Rel 5 given its a use model. /jim > -----Original Message----- > From: Bound, Jim > Sent: Tuesday, March 19, 2002 2:24 AM > To: Hesham Soliman (ERA); Francis Dupont; Jun-ichiro itojun Hagino > Cc: ipng@sunroof.eng.sun.com > Subject: RE: requirement for celllular IPv6 host draft > > > Hesham, > > I strongly disagree. > > What is an IPv6 Hosts document going to tell us that we don't > already know as implementors for IPv6? > > If its new requirements then we should write a draft on those > requirements? > > I always hated the 1122 and 1123 restated the obvious to > kernel OS implementors. I would argue the spec was good but > it did not work in the market. What made implementations > interoperable were bake-offs and learning to make the general > TCP/IP specs work. Now for new requirements thats fine. > > We are trying to reduce the work load in the IETF not increase it? > > I don't see the business or technical benefit of using up the > working groups energy with such a document. > > Maybe someone should write up what it would do and we should > discuss that? I feel like we are urinating in the wind here. > > thanks > /jim > > > -----Original Message----- > > From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] > > Sent: Monday, March 18, 2002 10:56 PM > > To: 'Francis Dupont'; Jun-ichiro itojun Hagino > > Cc: Hesham Soliman (ERA); ipng@sunroof.eng.sun.com > > Subject: RE: requirement for celllular IPv6 host draft > > > > > > > A full implementation of IPv6 includes implementation of the > > > > following extension headers: > > > > > > => this wording is unfortunate: what is a partial implementation > > > of IPv6? > > > > > ' > PS: we definitely *need* an IPv6 host requirement document! > > > > => Yes ! > > > > Hesham > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Tue Mar 19 03:05:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JB5NKL013456 for ; Tue, 19 Mar 2002 03:05:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JB5NGH013455 for ipng-dist; Tue, 19 Mar 2002 03:05:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JB5JKL013448 for ; Tue, 19 Mar 2002 03:05:19 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA15082 for ; Tue, 19 Mar 2002 03:05:20 -0800 (PST) Received: from monza.eurecom.fr (monza.eurecom.fr [193.55.113.133]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA22195 for ; Tue, 19 Mar 2002 04:05:19 -0700 (MST) Received: from bizet (bizet.eurecom.fr [172.17.10.33]) by monza.eurecom.fr (Postfix) with SMTP id B47D757BE1; Tue, 19 Mar 2002 12:05:17 +0100 (MET) From: "Michelle Wetterwald" To: Cc: Subject: RE: Next steps on Reserving bits in RFC 2473 Interface IDs? Date: Tue, 19 Mar 2002 12:05:18 +0100 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4D7B558499107545BB45044C63822DDE0A0794@mvebe001.NOE.Nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk See below... > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of > Jonne.Soininen@nokia.com > Sent: Saturday, March 16, 2002 1:28 AM > To: petrescu@crm.mot.com > Cc: deering@cisco.com; aep@it.kth.se; Erik.Nordmark@eng.sun.com; > ipng@sunroof.eng.sun.com > Subject: RE: Next steps on Reserving bits in RFC 2473 Interface IDs? > > > Hello, > > > -----Original Message----- > > From: ext Alexandru Petrescu [mailto:petrescu@crm.mot.com] > > Jonne.Soininen@nokia.com writes: > > > I would be a bit careful to use IMEI as Interface Identifier. > > > > Hi Jonne, please let me assure you that I'm trying to be very careful > > in all this. If I speak out so frequently is just because I need to > > better understand how IPv6 and 3GPP/UMTS can be made to work together. > > If I'm diverging too much from the list's topic, please stop me. > > JSo: I do not if this is outside the scope, but I think the issue > of making 3GPP/UMTS to work with IPv6 has been rather thoroughly > researched. There has been done work in 3GPP, and the > functionality is specified in the 3GPP specs. I can provide you > with pointers to the docs off-line, if you wish. In addition, we > had the IPv6-3GPP design team working on this issue last year. > You can see the results in > http://search.ietf.org/internet-drafts/draft-ietf-ipv6-3gpp-recomm > end-00.txt. > > > > > > I am not really sure if this is something you want to tell the whole > > > world. > > > > Ok, privacy, yes. Alberto mentioned that not necessarily the IMEI > > should be coded but a hash of it, periodically updated starting from a > > nonce. > > > > > This is kind of confidential information from the end user point of > > > view. > > > > Aha, confidential, then it's not to be put in IPv6 addresses that are > > not confidential. > > > > The problem with IMEIs are that they are used in GSM, GPRS, and > UMTS networks to screen stolen handsets. This makes additional > requirements for privacy, and confidentiality of the IMEI value. > > > > In addition, it might not always be unique... > > > > IMEI not being unique? That's bad, again. Then it's probably true > > that some id's are more unique than other id's. > > I had phone once that for some reason had a different IMEI > electronically than what was printed on the back of the phone. I > am not sure if that was the mistake of the person putting the > wrong label on the phone... (It was not from the manufacturer > that I currently work for... ;) Actually, what is important is the IMEI inside the terminal, not really the one printed on the back of the phone or on its box. IMEI are supposed to be unique by construction. Could you (or anybody else) provide additional arguments to convince us that they are *really* not unique and could not be used in the same way as the MAC addresses? > > > > > So I try something else than IMEI: IMSI. As IMEI is for phones, IMSI > > is in the SIM cards. Is the IMSI private? Is it unique? > > IMSI is very unique, but alas very private. That should never be > shown outside the mobile network. (IMSI=International Mobile > Subscriber Identification, if I remember correctly.) > > > > > What are the other identifiers in the GSM/3GPP/UMTS? Phone number? > > Would you like your phone number to be shown on your IP address > if you are using your modem over a telephone line. With all those > telemarketers around... ;) > > > > > Would an IMT2000 identifier be better adapted, since it has a wider > > reach, more neutral. > > I am not sure what you are referring to. Something standardized in ITU? > > -Jonne. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- --------- Michelle WETTERWALD -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 19 03:23:40 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JBNeKL013546 for ; Tue, 19 Mar 2002 03:23:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JBNevE013545 for ipng-dist; Tue, 19 Mar 2002 03:23:40 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JBNbKL013538 for ; Tue, 19 Mar 2002 03:23:37 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA12807 for ; Tue, 19 Mar 2002 03:23:37 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA28406 for ; Tue, 19 Mar 2002 04:23:36 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id EAA03134; Tue, 19 Mar 2002 04:23:33 -0700 (MST)] Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id EAA07749; Tue, 19 Mar 2002 04:23:33 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (8.11.6/8.11.6) with ESMTP id g2JBNNk21519; Tue, 19 Mar 2002 05:23:24 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 046EE2EC83; Tue, 19 Mar 2002 12:23:21 +0100 (CET) To: Francis Dupont Cc: Steve Deering, Alberto Escudero-Pascual, Erik Nordmark, Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: <200203182101.g2IL1gg62706@givry.rennes.enst-bretagne.fr> From: Alexandru Petrescu Date: 19 Mar 2002 12:23:20 +0100 In-Reply-To: <200203182101.g2IL1gg62706@givry.rennes.enst-bretagne.fr> Message-ID: Lines: 39 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > >=> can I assume you didn't read draft-dupont-ipv6-imei-00.txt? > >(you should and I should have answered before :-) > => the question is addressed to Alexandru... I guess I have read it before I suggested an improvement on the coding of decimal IMEIs into hexa. There's an email very early in the thread, but much later than your original post, ah too many emails. After this long deviation, it would be nice if we could get back to this thread's original subject on reserving bits in Interface ID's, of RFC2373, updated by draft-ietf-ipngwg-addr-arch-v3-07.txt. Since the proposal involves so many unknowns (to me) I think it's good to be conservative, and if a new reservation happens, then reserve a quarter only. In my humble oppinion. Alex Erik: > A while back I sent an email to the list talking about > Reserving bits in RFC 2473 Interface IDs. > > Not much email has followed on this topic so it isn't clear whether > people are having too much fun debating other topics, think it is > a good/bad idea, or just don't care. > > I think our choices are: > 1. Do nothing > 2. Reserve a quarter of the IID space i.e. universal=1, group=1 becomes > explicitly reserved. > 3. Reserve half of the IID space i.e. all addresses with group=1 become > explicitly reserved. > > It would be good to try to make progress on the mailing list on this question > otherwise it's likely to appear on the agenda in the meetings next week :-) > > Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 19 04:08:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JC8cKL013643 for ; Tue, 19 Mar 2002 04:08:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JC8c4n013642 for ipng-dist; Tue, 19 Mar 2002 04:08:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JC8ZKL013635 for ; Tue, 19 Mar 2002 04:08:35 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA15556 for ; Tue, 19 Mar 2002 04:08:36 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA05390 for ; Tue, 19 Mar 2002 04:08:32 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 110936A906; Tue, 19 Mar 2002 14:08:21 +0200 (EET) Message-ID: <3C972A8A.9060507@kolumbus.fi> Date: Tue, 19 Mar 2002 14:09:46 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: matthew.ford@bt.com Cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: IPv6 cellular hosts draft References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk matthew.ford@bt.com wrote: > Well, I guess that's OK as long as 3GPP are happy referencing an obsolete > (and superceded) document. What I mean is, will the reference to the > Informational document still make sense when people come to implement this? > Will they know where to look for the up-to-date information? I believe both IETF and 3GPP have an obsoleted-by process. So, if a reference to the cellular host informational RFC is made from the next 3GPP release, a future release would reference over Foo and general node requirements document, if those are available at the time that this standards release is made. Same in IETF, an RFC can become obsoleted by a new RFC (or RFCs?). Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 19 04:23:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JCNUKL013688 for ; Tue, 19 Mar 2002 04:23:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JCNUO2013687 for ipng-dist; Tue, 19 Mar 2002 04:23:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JCNQKL013680 for ; Tue, 19 Mar 2002 04:23:26 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03355 for ; Tue, 19 Mar 2002 04:23:27 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA18427 for ; Tue, 19 Mar 2002 05:23:26 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2JCTVq03749; Tue, 19 Mar 2002 19:29:32 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net cc: Ralph Droms , IPng List Subject: Re: IPv6 working group agenda for Minneapolis IETF In-Reply-To: <24037.1016471117@itojun.org> References: <24037.1016471117@itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Mar 2002 19:29:31 +0700 Message-ID: <3747.1016540971@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 19 Mar 2002 02:05:17 +0900 From: itojun@iijlab.net Message-ID: <24037.1016471117@itojun.org> | what happens | if a host does not have stateful autoconfiguration protocol | implementation? I just wanted to respond to this sub-issue... If the network admin has specified stateful autoconfig, and the host doesn't implement it, then the host MUST fall back on manual configuration. It MUST NOT decide to just ignore the O bit and autoconfigure itself some other way. But as manual configuration always wins any argument, that's always an option for any host (and any that don't support any kind of manual config, and don't support stateful config, simply cannot function on a net where stateless autoconfig is disabled). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 19 04:30:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JCUTKL013721 for ; Tue, 19 Mar 2002 04:30:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JCUTYS013720 for ipng-dist; Tue, 19 Mar 2002 04:30:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JCUQKL013713 for ; Tue, 19 Mar 2002 04:30:26 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA04846 for ; Tue, 19 Mar 2002 04:30:27 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09521 for ; Tue, 19 Mar 2002 05:30:25 -0700 (MST) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2JCaYq03764; Tue, 19 Mar 2002 19:36:34 +0700 (ICT) From: Robert Elz To: Bob Hinden cc: Thomas Narten , ipng@sunroof.eng.sun.com Subject: Re: Deployability/Useability of Multicast [was: Re: PPP and Global Addresses ] In-Reply-To: <4.3.2.7.2.20020318092255.02732e60@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20020318092255.02732e60@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 Mar 2002 19:36:34 +0700 Message-ID: <3762.1016541394@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 18 Mar 2002 09:36:09 -0800 From: Bob Hinden Message-ID: <4.3.2.7.2.20020318092255.02732e60@mailhost.iprg.nokia.com> | As much as I would like to see it otherwise, except for link (and maybe | subnet) scoped multicast, I don't think we can assume multicast across a | wider scope. I suspect it will be more the exception than the norm. When I saw Thomas' question, I thought that too. In the intervening few days however, I happened to get asked by people back home why the "ghost" program (that does something or other with PCs) wasn't working through our routers - it worked fine with client & server on the same cable, but not otherwise. They suspected broadcast packets not being "helped" - I asked for a packet trace (I'm not there at the minute) and what appears is IP multicast. So, on my net more than link wide multicast didn't exist last week, and does exist this week... Of course, this is IPv4, not IPv6 - but I think it demonstrates the point. That is, that all it is going to take is for there to be an application that actually needs multicast, and multicast will appear (at least within the site scope, perhaps even more than that). It would be a mistake to start counting nets with multicast currently enabled (or where if you ask the admin they'd say "sure, I can enable that") and from the low number of responses, start avoiding requiring multicast for new protocols. Just require it, that itself will be enough to get it implemented & deployed. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 19 04:41:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JCfKKL013757 for ; Tue, 19 Mar 2002 04:41:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JCfKUE013756 for ipng-dist; Tue, 19 Mar 2002 04:41:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JCfHKL013749 for ; Tue, 19 Mar 2002 04:41:17 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA07862 for ; Tue, 19 Mar 2002 04:41:18 -0800 (PST) From: juha.wiljakka@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA11471 for ; Tue, 19 Mar 2002 04:41:09 -0800 (PST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id g2JCfMZ16120 for ; Tue, 19 Mar 2002 14:41:22 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 19 Mar 2002 14:41:10 +0200 Received: from esebe005.NOE.Nokia.com ([172.21.138.45]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Tue, 19 Mar 2002 14:41:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Questions about draft-ietf-ipv6-cellular-host-00.txt Date: Tue, 19 Mar 2002 14:41:10 +0200 Message-ID: <245DBCAEEC4F074CB77B3F984FF9834F785702@esebe005.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Questions about draft-ietf-ipv6-cellular-host-00.txt Thread-Index: AcHO+9T6simzc0PKTDOHx4Ij40eyYgARTurw To: , Cc: X-OriginalArrivalTime: 19 Mar 2002 12:41:10.0707 (UTC) FILETIME=[59101830:01C1CF43] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! Some comments from me to the questions below: -----Original Message----- From: ext Yamasaki Toshi [mailto:t.yamasaki@ntt.com] Sent: 19 March, 2002 06:05 Q1) What is the main reason why you assume two PPPs when a customer has two IPv6 enabled terminals under one Cellular Phone working as a bridge? You could assume to use one PPP to the Cellular Phone (or other terminal conneted to it) working as a MSR or L3router. JW: If we talk about 3GPP Rel99, Rel4 and Rel5 specifications, there is currently only one specified way to connect laptop to the mobile terminal. And that is a PPP(v6) link between the laptop and the mobile terminal. Separate PDP context(s) are activated for the mobile terminal 'internal applications' (e.g. a web browser in a mobile terminal) and a separate PDP context is used for the laptop connection. (in this context mobile terminal = cellular host) Q2) Why do you assign a /64 not /128 to each mobile terminal, while you are sure there is only ONE host connected to the PPP link? JW: This is based the IPv6 addressing mechanism specified in 3GPP Rel99, Rel4 and Rel5 (the IPv6 addressing architecture change has recently been made based on IPv6 wg 3GPP design team recommendations). Every (primary) PDP context is allocated a globally unique prefix. Q3) Is it a good privacy protection to use the privacy extention under a /64 while everyone knows that /64 is assigned to his/her Cellular Terminal? JW: This is a good comment. "Bad guys" could simply look at the first 64 bits... Actually I'm developing a model for IPv6/DSL services and IPv6 Hot Spot services. You can find an temporaly document at: http://www.apnic.net/meetings/13/sigs/docs/4.3_OSG_UNI.ppt JW: thanks for the interesting link - I will have a look at that. Your model of IPv6 access services for Cellular terminals are similar to my models assigning a /64 per customer, and I had and still have the same issues that I'm asking you in those questions above. Best Regards, Juha Wiljakka, Nokia Finland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 19 05:21:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JDLEKL013853 for ; Tue, 19 Mar 2002 05:21:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JDLEQt013852 for ipng-dist; Tue, 19 Mar 2002 05:21:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JDLAKL013845 for ; Tue, 19 Mar 2002 05:21:10 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA22536 for ; Tue, 19 Mar 2002 05:21:12 -0800 (PST) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA13624 for ; Tue, 19 Mar 2002 05:21:15 -0800 (PST) Received: from lorien.sc.innovationslab.net ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Tue, 19 Mar 2002 08:20:57 -0500 Message-ID: <3C973B65.CBABDC5D@lorien.sc.innovationslab.net> Date: Tue, 19 Mar 2002 08:21:42 -0500 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Bound, Jim" CC: murugankat@future.futsoft.com, IPng List Subject: Re: Dual stack routers References: <9C422444DE99BC46B3AD3C6EAFC9711B01A9B37C@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, I agree with your assessment. It is essentially the way I have integrated IPv6 into an IPv4 system. One point to keep in mind though is how to support site-scoped addresses in this model. The route table needs expansion in order to incorporate the zone IDs in the lookup. Regards, Brian "Bound, Jim" wrote: > > Its really up to the engineering team for that implementation. I would integrate v4 and v6 and duplicate as little as possible. At least all data structures so the algorithm for update/replace/delete was the same function module and not duplicated once for tcp and once for udp and yet again for SCTP. Then there is the emerging RDMA the router might want to use for storage. Treating all addresses as 16bytes (v4 and v6) works and will perform. Also all the traffic shaping, classification, et al on hardware would make the hardware engineers job a lot easier and thats a performance win too to support both address types. > > regards, > /jim > > > -----Original Message----- > > From: Murugan KAT [mailto:murugankat@future.futsoft.com] > > Sent: Tuesday, March 19, 2002 2:15 AM > > To: 'IPng List' > > Subject: Dual stack routers > > > > > > > > > > -----Original Message----- > > From: owner-ipng@sunroof.eng.sun.com > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Murugan KAT > > Sent: Tuesday, 19 March 2002 12:07 AM > > To: 'IPng List' > > Subject: RE: Requirements for 'O' flag (was Re: IPv6 working group > > agendafor Minneapolis IETF) > > > > > > Hi, > > > > Regarding Dual Stack Router implementation should a router maintain 2 > > routing tables, one for V4 and other for V6. What about the > > routing stacks? > > Should there be 2 instances of a routing protocol (BGP, OSPF etc.,) ? > > > > What is the general approach? > > > > > > Thanks, > > KAT > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 19 06:57:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JEvUKL014135 for ; Tue, 19 Mar 2002 06:57:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JEvUKv014134 for ipng-dist; Tue, 19 Mar 2002 06:57:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JEvRKL014127 for ; Tue, 19 Mar 2002 06:57:27 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA08765 for ; Tue, 19 Mar 2002 06:57:28 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA13562 for ; Tue, 19 Mar 2002 06:57:27 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA09493; Tue, 19 Mar 2002 07:57:11 -0700 (MST)] Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id HAA20406; Tue, 19 Mar 2002 07:57:10 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id g2JEuwl07320; Tue, 19 Mar 2002 08:57:04 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 8EA2A2EC86; Tue, 19 Mar 2002 15:56:54 +0100 (CET) To: Francis Dupont Cc: , , , , Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: <200203181958.g2IJw9g62462@givry.rennes.enst-bretagne.fr> From: Alexandru Petrescu Date: 19 Mar 2002 15:56:54 +0100 In-Reply-To: <200203181958.g2IJw9g62462@givry.rennes.enst-bretagne.fr> Message-ID: Lines: 63 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > petrescu@crm.mot.com: > Ok, privacy, yes. > > => please read the last update of RFC 3041 before to get things from > 3041 which are not in it... So I suppose there's draft, a pointer would help. Far from me any intention that you imply, sorry. > Alberto mentioned that not necessarily the IMEI should be coded > but a hash of it, periodically updated starting from a nonce. > > => I can't see a reason to do that when RFC 3041 is supported. > Or do you mean we can replace the MAC address by the IMEI for the > seed? No-no. > > In addition, it might not always be unique... > > IMEI not being unique? That's bad, again. Then it's probably true > that some id's are more unique than other id's. > > => IMEI is unique according to 3GPP/ETSI standards. Ok, fact is that those future wireless phones things have not yet agreed among themselves who uses what as unique ID. This narrows the option of coding IMEIs into addresses to in fact coding IMEIs for 3GPP of ETSI into addresses. > What are the other identifiers in the GSM/3GPP/UMTS? Phone number? > > => none, the hardware ID is the IMEI. Others (IMSI/phone number) are > private... Ok, how about TMSI dynamically assigned by a VLR. Like an RCoA in an HMIPv6 domain. I guess it would not fit because it changes when moving into another geographical region. Then how about MSISDN, whose correspondence with the IMSI is kept by the HLR. HLR is a sort of super-VLR, only one of them per operator (there are several VLRs per operator). MSISDN is not so private as IMSI, only HLR knows the correspondence. So one can consider it overcomes IMSI's limitations. I think there's also MSRN but know nothing about it more than it's used for MSC-MSC communication. And I don't know what MSC means. > Would an IMT2000 identifier be better adapted, since it has a wider > reach, more neutral. > > => it seems the IMT2000 identifier would be the IMEI. Ah, some agreement, finally. Note though another difference between 802 id's and all those discussed above: the above identifiers identify the terminal itself, but not the other end of the communication at L2. I mean a base station has neither IMEI/IMSI/etc, and if it's identified by something it's certainly not the same kind of id as the one for the phone. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 19 07:34:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JFYHKL014697 for ; Tue, 19 Mar 2002 07:34:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JFYGKs014696 for ipng-dist; Tue, 19 Mar 2002 07:34:16 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JFYDKL014689 for ; Tue, 19 Mar 2002 07:34:13 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15709 for ; Tue, 19 Mar 2002 07:34:14 -0800 (PST) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03983 for ; Tue, 19 Mar 2002 08:34:13 -0700 (MST) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 82BE05B2B; Tue, 19 Mar 2002 10:34:13 -0500 (EST) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Mar 2002 10:34:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Dual stack routers Date: Tue, 19 Mar 2002 10:34:13 -0500 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0152095D@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Dual stack routers Thread-Index: AcHPSO7jmzIIPGl1Tnuc7YJT6NJCHgAEn+KA From: "Bound, Jim" To: "Brian Haberman" Cc: , "IPng List" X-OriginalArrivalTime: 19 Mar 2002 15:34:13.0455 (UTC) FILETIME=[85A9B5F0:01C1CF5B] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2JFYEKL014690 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, Agree. The entire issue of scoping will need to be added to the infrastructure for sure. thanks /jim > -----Original Message----- > From: Brian Haberman [mailto:haberman@lorien.sc.innovationslab.net] > Sent: Tuesday, March 19, 2002 8:22 AM > To: Bound, Jim > Cc: murugankat@future.futsoft.com; IPng List > Subject: Re: Dual stack routers > > > Jim, > I agree with your assessment. It is essentially the way I have > integrated IPv6 into an IPv4 system. One point to keep in mind though > is how to support site-scoped addresses in this model. The > route table > needs expansion in order to incorporate the zone IDs in the lookup. > > Regards, > Brian > > "Bound, Jim" wrote: > > > > Its really up to the engineering team for that > implementation. I would integrate v4 and v6 and duplicate as > little as possible. At least all data structures so the > algorithm for update/replace/delete was the same function > module and not duplicated once for tcp and once for udp and > yet again for SCTP. Then there is the emerging RDMA the > router might want to use for storage. Treating all addresses > as 16bytes (v4 and v6) works and will perform. Also all the > traffic shaping, classification, et al on hardware would make > the hardware engineers job a lot easier and thats a > performance win too to support both address types. > > > > regards, > > /jim > > > > > -----Original Message----- > > > From: Murugan KAT [mailto:murugankat@future.futsoft.com] > > > Sent: Tuesday, March 19, 2002 2:15 AM > > > To: 'IPng List' > > > Subject: Dual stack routers > > > > > > > > > > > > > > > -----Original Message----- > > > From: owner-ipng@sunroof.eng.sun.com > > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Murugan KAT > > > Sent: Tuesday, 19 March 2002 12:07 AM > > > To: 'IPng List' > > > Subject: RE: Requirements for 'O' flag (was Re: IPv6 working group > > > agendafor Minneapolis IETF) > > > > > > > > > Hi, > > > > > > Regarding Dual Stack Router implementation should a > router maintain 2 > > > routing tables, one for V4 and other for V6. What about the > > > routing stacks? > > > Should there be 2 instances of a routing protocol (BGP, > OSPF etc.,) ? > > > > > > What is the general approach? > > > > > > > > > Thanks, > > > KAT > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home 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 > > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 19 08:42:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JGg8KL015155 for ; Tue, 19 Mar 2002 08:42:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JGg8jJ015154 for ipng-dist; Tue, 19 Mar 2002 08:42:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JGg4KL015147 for ; Tue, 19 Mar 2002 08:42:05 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA00786; Tue, 19 Mar 2002 08:42:02 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06463; Tue, 19 Mar 2002 08:42:05 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2JGfP223450; Tue, 19 Mar 2002 17:41:25 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA27536; Tue, 19 Mar 2002 17:41:26 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2JGfPg66599; Tue, 19 Mar 2002 17:41:25 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203191641.g2JGfPg66599@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Alexandru Petrescu cc: Jonne.Soininen@nokia.com, deering@cisco.com, aep@it.kth.se, Erik.Nordmark@eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? In-reply-to: Your message of 19 Mar 2002 15:56:54 +0100. Date: Tue, 19 Mar 2002 17:41:25 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > => please read the last update of RFC 3041 before to get things from > 3041 which are not in it... So I suppose there's draft, a pointer would help. Far from me any intention that you imply, sorry. => draft-ietf-ipngwg-temp-addresses-v2-00.txt > => IMEI is unique according to 3GPP/ETSI standards. Ok, fact is that those future wireless phones things have not yet agreed among themselves who uses what as unique ID. This narrows the option of coding IMEIs into addresses to in fact coding IMEIs for 3GPP of ETSI into addresses. => I am not the ITU so I can't solve the issues between the 3GPP and the 3GPP2. Do you propose to wait they have merged (:-)? For me, the 3GPP/ETSI base is already enough. Ok, how about TMSI dynamically assigned by a VLR. Like an RCoA in an HMIPv6 domain. I guess it would not fit because it changes when moving into another geographical region. => exactly. Then how about MSISDN, whose correspondence with the IMSI is kept by the HLR. HLR is a sort of super-VLR, only one of them per operator (there are several VLRs per operator). MSISDN is not so private as IMSI, only HLR knows the correspondence. So one can consider it overcomes IMSI's limitations. => MSISDN is too large and is not an hardware ID. I think there's also MSRN but know nothing about it more than it's used for MSC-MSC communication. And I don't know what MSC means. => be serious, please! (BTW MSC=Mobile Switching Center) > => it seems the IMT2000 identifier would be the IMEI. Ah, some agreement, finally. => as I've said I am not the ITU (:-). Note though another difference between 802 id's and all those discussed above: the above identifiers identify the terminal itself, but not the other end of the communication at L2. I mean a base station has neither IMEI/IMSI/etc, and if it's identified by something it's certainly not the same kind of id as the one for the phone. => a base station is not a Mobile Equipment, does this matter? Regards Francis.Dupont@enst-bretagne.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 Tue Mar 19 08:58:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JGwJKL015246 for ; Tue, 19 Mar 2002 08:58:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JGwIFp015245 for ipng-dist; Tue, 19 Mar 2002 08:58:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JGwFKL015238 for ; Tue, 19 Mar 2002 08:58:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04179 for ; Tue, 19 Mar 2002 08:58:17 -0800 (PST) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA04342 for ; Tue, 19 Mar 2002 09:58:16 -0700 (MST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id JAA21300; Tue, 19 Mar 2002 09:58:13 -0700 (MST)] Received: [from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id JAA22073; Tue, 19 Mar 2002 09:58:13 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr03.mot.com (8.11.6/8.11.6) with ESMTP id g2JGw3k15430; Tue, 19 Mar 2002 10:58:04 -0600 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 640482EC84; Tue, 19 Mar 2002 17:58:01 +0100 (CET) To: Francis Dupont Cc: , , , , Subject: Re: Next steps on Reserving bits in RFC 2473 Interface IDs? References: <200203191641.g2JGfPg66599@givry.rennes.enst-bretagne.fr> From: Alexandru Petrescu Date: 19 Mar 2002 17:58:01 +0100 In-Reply-To: <200203191641.g2JGfPg66599@givry.rennes.enst-bretagne.fr> Message-ID: Lines: 31 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont writes: > So I suppose there's draft, a pointer would help. Far from me any > intention that you imply, sorry. > > => draft-ietf-ipngwg-temp-addresses-v2-00.txt Thanks! > I think there's also MSRN but know nothing about it more than it's > used for MSC-MSC communication. And I don't know what MSC means. > > => be serious, please! (BTW MSC=Mobile Switching Center) That might have looked funny but I really didn't know what MSC meant. Now I know. And it removes it from the list of my tries of id's to be coded into Interface ID's. As I said, I was trying to cover them all. > Note though another difference between 802 id's and all those > discussed above: the above identifiers identify the terminal itself, > but not the other end of the communication at L2. I mean a base > station has neither IMEI/IMSI/etc, and if it's identified by something > it's certainly not the same kind of id as the one for the phone. > > => a base station is not a Mobile Equipment, does this matter? Ok, I think I agree with you. I might have a different view of how those id's are used, I mean different than yours; but exactly as you, I was motivated to find how a sort of unique ID that can be fit into an Interface ID. Alex -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 19 13:42:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JLg2KL016313 for ; Tue, 19 Mar 2002 13:42:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JLg1VV016312 for ipng-dist; Tue, 19 Mar 2002 13:42:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JLfvKL016305 for ; Tue, 19 Mar 2002 13:41:57 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA24193 for ; Tue, 19 Mar 2002 13:42:00 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA29528 for ; Tue, 19 Mar 2002 14:41:59 -0700 (MST) Received: from localhost ([2001:460:1:210:202:2dff:fe46:6808]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2JLfuo91978 for ; Wed, 20 Mar 2002 06:41:56 +0900 (JST) Date: Wed, 20 Mar 2002 06:42:05 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: poposed changes to the scoping architecture draft User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 58 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We have some updates on the draft draft-ietf-ipngwg-scoping-arch-03.txt, on which I will make a short presentation in the Thursday ipv6 wg meeting. Since we missed the deadline to publish a new ID and since I'm not sure if I will have an enough slot for the presentation, please let me post a digest of the changes. Comments to this message are, of course, welcome. There are two changes, both of which were based on inputs after the 03 draft: 1. revise the mobility section to clarify issues about using site-local addresses with mobile IPv6: + site-local home/care-of addresses can be used when the mobile node moves within its home site and communicate with nodes within the site. + in general, however, there are several issues. For example, if the care-of address is a site-local address, an off-site mobile node cannot communicate with the home agent to register the care-of address. Also, if the home address is a site-local address (without route optimization) and a correspondent node (CN) is in a different site from the mobile node's home site, the CN cannot send packets back to the mobile node unless it can use route optimization. + to deal with such issues, we'll need an ability for mobile nodes to tell whether a correspondent node or the home agent is in the same site as the mobile node. However, there is currently no standard way to implement the ability. + thus, we recommend to use global home/care-of addresses *whenever possible*. (note, however, this does not mean we prohibit mobile nodes from using site-local home/care-of addresses.) 2. revise the textual representation section in the form of
%, the part is now formatted as follows: . where is a decimal number from 0 to 15 to specify a scope type, which corresponds to the "scop" field values of multicast addresses, and is a decimal number to identify a zone. "." is a delimiter character to separate from . (the reason for the delimiter character "." is because it is used in the "normal" address representation so address parser should escape the character. And, "." is more intuitive and more readable than other characters (i.e. ":", "a-f0-9").) An example: a site-local address fec0::1 on the #2 site can represented as fec0::1%5.2 (where 5 means the site scope and 2 means the 2nd site) The previous "readable" representation like "link2" or "site10" were removed accordingly. The "unreadable" numerical representation like 1342177281 (= 0x50000001) were also removed. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 19 13:59:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JLxVKL016375 for ; Tue, 19 Mar 2002 13:59:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JLxVit016374 for ipng-dist; Tue, 19 Mar 2002 13:59:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JLxSKL016367 for ; Tue, 19 Mar 2002 13:59:28 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA07372 for ; Tue, 19 Mar 2002 13:59:31 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA11140 for ; Tue, 19 Mar 2002 13:59:29 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id XAA02075; Tue, 19 Mar 2002 23:59:01 +0200 Date: Tue, 19 Mar 2002 23:59:01 +0200 Message-Id: <200203192159.XAA02075@burp.tkv.asdf.org> From: Markku Savela To: jinmei@isl.rdc.toshiba.co.jp CC: ipng@sunroof.eng.sun.com In-reply-to: Subject: Re: poposed changes to the scoping architecture draft References: Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-2022-JP Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Some quick tiny comments... > From: JINMEI Tatuya / $B?@L@C#:H(B > An example: a site-local address fec0::1 on the #2 site can > represented as fec0::1%5.2 (where 5 means the site scope and 2 means > the 2nd site) But "fec0::1%2" is exactly same, the site scope (5) is implicit from the address? Can you give an example of case where the scope is not associated with address? If there is such case, then explicit is useful, but otherwise always unnecessary? Or, this allows then to write "fec0::1%2.2". Is this intended to be allowed or flagged as an error? Btw. what is the scope level of address "::"? = 0? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 19 14:21:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JMLaKL016450 for ; Tue, 19 Mar 2002 14:21:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JMLaNX016449 for ipng-dist; Tue, 19 Mar 2002 14:21:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JMLXKL016442 for ; Tue, 19 Mar 2002 14:21:33 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA01737 for ; Tue, 19 Mar 2002 14:21:34 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA23255 for ; Tue, 19 Mar 2002 14:21:36 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2JMLQ201391; Tue, 19 Mar 2002 23:21:27 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id XAA02505; Tue, 19 Mar 2002 23:21:27 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2JMLRg67744; Tue, 19 Mar 2002 23:21:27 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203192221.g2JMLRg67744@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-reply-to: Your message of Wed, 20 Mar 2002 06:42:05 +0900. Date: Tue, 19 Mar 2002 23:21:27 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: 1. revise the mobility section to clarify issues about using site-local addresses with mobile IPv6: => I disagree with your solution because it takes more than a few line to describe it (:-). IMHO site-local addresses in a mobile IPv6 work well if only a bidirectional tunnel is used between the mobile and its home agent. Note there should be no penalty because by definition communications in the same site are local, so the only difference with routing optimization is the encapsulaion overhead. Another important point is an equivalent way to describe this solution is to say the bidirectional tunnel belongs to the home site. + thus, we recommend to use global home/care-of addresses *whenever possible*. => I agree because this avoids to have a bi-sited node. (no further comment about multi-site support in some IPv6 stacks :-). 2. revise the textual representation section => I agree if you still allow names (not ambiguous and mapped to the pair type/id in a local config file). Regards Francis.Dupont@enst-bretagne.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 Tue Mar 19 14:39:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JMdwKL016516 for ; Tue, 19 Mar 2002 14:39:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JMdwr5016515 for ipng-dist; Tue, 19 Mar 2002 14:39:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JMdtKL016508 for ; Tue, 19 Mar 2002 14:39:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17567 for ; Tue, 19 Mar 2002 14:39:56 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA18457 for ; Tue, 19 Mar 2002 15:39:55 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2JMdG203939; Tue, 19 Mar 2002 23:39:16 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id XAA02724; Tue, 19 Mar 2002 23:39:16 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2JMdFg67822; Tue, 19 Mar 2002 23:39:16 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203192239.g2JMdFg67822@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-reply-to: Your message of Tue, 19 Mar 2002 23:59:01 +0200. <200203192159.XAA02075@burp.tkv.asdf.org> Date: Tue, 19 Mar 2002 23:39:15 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Btw. what is the scope level of address "::"? = 0? => it is in all zones so IMHO its scope level is global. But for its use it must not go through routers so it is link-local. Note :: is valid only as a source on the wire (*) even if the source address selection draft is not sound (again) about this topic, and is always used with a link-local multicast destination. (*) many kernels map unspecfied destination to an address of the local node. Regards Francis.Dupont@enst-bretagne.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 Tue Mar 19 15:24:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JNO6KL016717 for ; Tue, 19 Mar 2002 15:24:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2JNO5OZ016716 for ipng-dist; Tue, 19 Mar 2002 15:24:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2JNO2KL016709 for ; Tue, 19 Mar 2002 15:24:02 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA18343 for ; Tue, 19 Mar 2002 15:24:04 -0800 (PST) Received: from cisco.com (mrwint.cisco.com [198.135.0.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA09633 for ; Tue, 19 Mar 2002 16:24:03 -0700 (MST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id XAA22619; Tue, 19 Mar 2002 23:23:58 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: JINMEI Tatuya / =?iso-8859-1?q?=C0=C0=A3=C8?= Cc: ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft References: From: Ole Troan Date: Tue, 19 Mar 2002 23:23:58 +0000 In-Reply-To: (JINMEI Tatuya / =?iso-8859-1?q?=C0=C0=A3=C8's?= message of "Wed, 20 Mar 2002 06:42:05 +0900") Message-ID: <7t5adt4kupd.fsf@mrwint.cisco.com> Lines: 37 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [...] > 2. revise the textual representation section > in the form of
%, the part is now > formatted as follows: > . > where is a decimal number from 0 to 15 to specify a > scope type, which corresponds to the "scop" field values of multicast > addresses, and is a decimal number to identify a > zone. "." is a delimiter character to separate from > . > (the reason for the delimiter character "." is because it is used in > the "normal" address representation so address parser should escape > the character. And, "." is more intuitive and more readable than > other characters (i.e. ":", "a-f0-9").) > > An example: a site-local address fec0::1 on the #2 site can > represented as fec0::1%5.2 (where 5 means the site scope and 2 means > the 2nd site) what is the reasoning behind this change? I certainly hope you still allow for the original
% where is one of number, name or interface. while we're at it, I would suggest we change the prefix representation to: % e.g fec0:0:0:1::/64%site2 which allows the use of '/' within the zone_id. > The previous "readable" representation like "link2" or "site10" were > removed accordingly. The "unreadable" numerical representation like > 1342177281 (= 0x50000001) were also removed. good. how an implementation represents a zone with a numerical representation should be implementation specific. should suffice with a sentence saying that zones can be represented numerically. /ot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 19 16:14:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K0EEKL016864 for ; Tue, 19 Mar 2002 16:14:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K0EEBG016863 for ipng-dist; Tue, 19 Mar 2002 16:14:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K0EAKL016856 for ; Tue, 19 Mar 2002 16:14:10 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA26096 for ; Tue, 19 Mar 2002 16:14:12 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA07965 for ; Tue, 19 Mar 2002 17:14:10 -0700 (MST) Received: from localhost ([2001:460:1:210:202:2dff:fe46:6808]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2K0E2o92941; Wed, 20 Mar 2002 09:14:02 +0900 (JST) Date: Wed, 20 Mar 2002 09:14:12 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-Reply-To: <200203192221.g2JMLRg67744@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200203192221.g2JMLRg67744@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 29 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 19 Mar 2002 23:21:27 +0100, >>>>> Francis Dupont said: > 1. revise the mobility section to clarify issues about using > site-local addresses with mobile IPv6: > => I disagree with your solution because it takes more than a few line > to describe it (:-). > IMHO site-local addresses in a mobile IPv6 work well if only a > bidirectional tunnel is used between the mobile and its home agent. > Note there should be no penalty because by definition communications > in the same site are local, so the only difference with routing > optimization is the encapsulaion overhead. > Another important point is an equivalent way to describe this solution > is to say the bidirectional tunnel belongs to the home site. Okay, we'll need some consideration about bidirectional tunneling. > 2. revise the textual representation section > => I agree if you still allow names (not ambiguous and mapped to > the pair type/id in a local config file). We'll still allow (implementation-dependent) names, just like before. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 19 20:47:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K4lfKL017748 for ; Tue, 19 Mar 2002 20:47:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K4lfe2017747 for ipng-dist; Tue, 19 Mar 2002 20:47:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K4lcKL017740; Tue, 19 Mar 2002 20:47:38 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA13972; Tue, 19 Mar 2002 20:47:40 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA22577; Tue, 19 Mar 2002 21:47:39 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2K4lY206946; Wed, 20 Mar 2002 05:47:34 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id FAA07007; Wed, 20 Mar 2002 05:47:34 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2K4lXg69172; Wed, 20 Mar 2002 05:47:33 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203200447.g2K4lXg69172@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ngtrans@sunroof.eng.sun.com Cc: ipng@sunroof.eng.sun.com Subject: get rid of IPv4 compatibles? Date: Wed, 20 Mar 2002 05:47:33 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thursday is the last chance to phase out IPv4 compatible addresses and automatic tunnels. I propose to add this point to the discussion about RFC 2373 revision. Francis.Dupont@enst-bretagne.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 Tue Mar 19 20:48:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K4muKL017780 for ; Tue, 19 Mar 2002 20:48:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K4mu22017779 for ipng-dist; Tue, 19 Mar 2002 20:48:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K4mqKL017772 for ; Tue, 19 Mar 2002 20:48:52 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA00378 for ; Tue, 19 Mar 2002 20:48:55 -0800 (PST) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA22864 for ; Tue, 19 Mar 2002 21:48:53 -0700 (MST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Wed, 20 Mar 2002 10:35:32 +0530 Received: from murugankat (murugankat.future.futsoft.com [10.20.6.9]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g2K4lpH21825; Wed, 20 Mar 2002 10:17:51 +0530 Reply-To: From: "Murugan KAT" To: "'IPng List'" Cc: "'Brian Haberman'" , "'Bound, Jim'" Subject: RE: Dual stack routers Date: Wed, 20 Mar 2002 10:36:30 +0530 Message-Id: <000401c1cfcd$00197c00$0906140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0152095D@tayexc13.americas.cpqcorp.net> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-MS-TNEF-Correlator: 000000006B69F18EDA9ED1118FF900203543672FE4119C02 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0005_01C1CFFB.19D1B800" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1CFFB.19D1B800 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Jim, Let us think of a single RTM having for both V4 and V6. But to what extent this is valid from routing stacks.? Will it be valid to propogate V4 routing info. also to V6 domain.? Obviously the other way is not valid? Thanks KAT.Murugan -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@compaq.com] Sent: Tuesday, 19 March 2002 9:04 PM To: Brian Haberman Cc: murugankat@future.futsoft.com; IPng List Subject: RE: Dual stack routers Brian, Agree. The entire issue of scoping will need to be added to the infrastructure for sure. thanks /jim > -----Original Message----- > From: Brian Haberman [mailto:haberman@lorien.sc.innovationslab.net] > Sent: Tuesday, March 19, 2002 8:22 AM > To: Bound, Jim > Cc: murugankat@future.futsoft.com; IPng List > Subject: Re: Dual stack routers > > > Jim, > I agree with your assessment. It is essentially the way I have > integrated IPv6 into an IPv4 system. One point to keep in mind though > is how to support site-scoped addresses in this model. The > route table > needs expansion in order to incorporate the zone IDs in the lookup. > > Regards, > Brian > > "Bound, Jim" wrote: > > > > Its really up to the engineering team for that > implementation. I would integrate v4 and v6 and duplicate as > little as possible. At least all data structures so the > algorithm for update/replace/delete was the same function > module and not duplicated once for tcp and once for udp and > yet again for SCTP. Then there is the emerging RDMA the > router might want to use for storage. Treating all addresses > as 16bytes (v4 and v6) works and will perform. Also all the > traffic shaping, classification, et al on hardware would make > the hardware engineers job a lot easier and thats a > performance win too to support both address types. > > > > regards, > > /jim > > > > > -----Original Message----- > > > From: Murugan KAT [mailto:murugankat@future.futsoft.com] > > > Sent: Tuesday, March 19, 2002 2:15 AM > > > To: 'IPng List' > > > Subject: Dual stack routers > > > > > > > > > > > > > > > -----Original Message----- > > > From: owner-ipng@sunroof.eng.sun.com > > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Murugan KAT > > > Sent: Tuesday, 19 March 2002 12:07 AM > > > To: 'IPng List' > > > Subject: RE: Requirements for 'O' flag (was Re: IPv6 working group > > > agendafor Minneapolis IETF) > > > > > > > > > Hi, > > > > > > Regarding Dual Stack Router implementation should a > router maintain 2 > > > routing tables, one for V4 and other for V6. What about the > > > routing stacks? > > > Should there be 2 instances of a routing protocol (BGP, > OSPF etc.,) ? > > > > > > What is the general approach? > > > > > > > > > Thanks, > > > KAT > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home 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 > > -------------------------------------------------------------------- > *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** ------=_NextPart_000_0005_01C1CFFB.19D1B800 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+Ih8FAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAwAUAAoAJAAAAAMAIQEB A5AGAEQMAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADAC4AAAAAAAMANgAA AAAAHgBwAAEAAAATAAAARHVhbCBzdGFjayByb3V0ZXJzAAACAXEAAQAAABYAAAABwc/M/0ZqCfjE O+sR1rwmAFDakd0nAAACAR0MAQAAACMAAABTTVRQOk1VUlVHQU5LQVRARlVUVVJFLkZVVFNPRlQu Q09NAAALAAEOAAAAAEAABg4ArAbtzM/BAQIBCg4BAAAAGAAAAAAAAABrafGO2p7REY/5ACA1Q2cv woAAAAMAFA4BAAAACwAfDgEAAAACAQkQAQAAAEoIAABGCAAALxMAAExaRnW6Ig+qAwAKAHJjcGcx MjXiMgNDdGV4BUEBAwH3/wqAAqQD5AcTAoAP8wBQBFY/CFUHshElDlEDAQIAY2jhCsBzZXQyBgAG wxEl9jMERhO3MBIsETMI7wn3tjsYHw4wNREiDGBjAFAzCwkBZDM2FlALpiBKXQdwLAqiCoQKgEwU ICASdQQgdGgLgGsgbxBmIGEgAJBuZ2yiZQfwVE0gE+B2HyEeIAIQBcAG4B5gIFY0yR7gbmQgsDYu CuMKgIRCdQVAdG8gdxPgfwVADsEJ8CHxHnAEICMhdu0HQGkhEANSIANgIeAf8gJzAZBja3MuPyDW VwMQAyBpBUBiH2AjhMUiEXADYHBvZyJgH2C/IMEkNguAAhAhUAdAcyIgcyIRITAgZANxC4AlEU/G Yh/gCGBzbHkeUR9gsyCBEoF3YSnwIyFuIIC1I3Q/HTpUE+AekHMdNKBLQVQuTQhwdSbQqwuQHUkt LrJPBRBnC4CHB0AF0AeQc2FnZS6zxR00RgNhOiBCCGAhAFIsHOIgWykBbCIQOlUc8S4xE0AFoG0K sHF6LjLhXR00BmACMDDwVJkKUHNkKsAxYDE5BdArCsAT0CAB0DAUQDk68jAg0FBNLCUyIDEAByE9 A6BIAaAEkAOBHTRDY5Uw8G0tlGsiYEBmIeB5CHBlLjkBKFABgDNCO6ggSVAgAUwEAHQzlZh1YmoF kDQhUkUw8PxEdS9hJLMkIwSQLNUdOvs20x0rQQnCIVA0QCohIsH2aRggI0FzClAesgTwJqB3H/ID 8CVhbgngJjMlwWE+ZAEAJjMqER00J9FyYf8ksC2gO4A5MSAjQLA5QR06Mx5gLKgvagdwHTo+IP8u vy/NR8AwtTbrMbcT4DdU3kAXsQiQKTAE8C4LgCsgXyOAJGACICnQAaAuQfB0fzOFR8Az/TUUNOAx YDVzOPQ6MhRAQTYlR8A2kzEnv0dmOB85Lzo+TpE7R2U7778890fAWB4c+EfAWkNJHuD3CcJBkSCR eQhhHuAEEEjR9weAAjA/sUkFQCMhSNFAIv8HQCnlKrJaoB/BQ1VHwAuA3w6wCcAm4SEQOkB2KMBf EU8iIAORX8Eg0HN5JLBl2zJgP8BPQfAmcG9fESICemsJ4HAnwVMQC4AmMWj5CGBnaF6XBCBjIAfg IhG9QLBwJrAAIB8BDrAtQSJ/QhFCoRggW9JigiMDBGJs/z+1R2Y8sx5QAaAfUEdmQfL9XNF4CrAA gQIgYoIFsASBvyICC4AFoWTBJuIqEnoCIDkfYElEZlUfYBewb2u/ZKBFNVh4VrAm0Asgc1nH6zbT WB4iMRgiIjADYA6w/jpHZlh4R8BckAQgGCBdY/9koEL1QBFIYQngBRAgAQ6w/mEkECAyRgEFQV6m MwAfUN9cIk1TXGIiMAhgbCEQXxdvI3Ag1F/hIPJkZKAjoGP/JuJEAFiHI6ACQB9RenEmsO0EEGlo sT+xQQVAH1BEAf8oIQMgNJABkCShRDUEIChS+2eJB0BnTHEeYHWUZKB9QexlLxggC1FjgGBnERQg /13SHkIfYC/AB4AgIDEwO4D/aiJHZgRheBBCgSEBKyJ5138hEAIggNB1pA3wIOOE93X2ZIWkR2Z5 HgEv0AtxICPwU0NUUD+0bMNAY3RUDQeAckhhIBBSRE1B/35rPLRisWNQBUAqsGHkHjD/RJUiEEPw L+A/snORJGN9Aodl2H63BCAxNmJ5DrDVBCAoePcpd+FyJPAg49tBo2WQciAxYTJBKEJ9Avt+ekQg YQEgDeAfABPgQVL9MWBjC2B74ZSRTVMxYIei9wMgajET4WQqsEBhd/QAwD9iQJPIKiGW93SmBCBq b/5iHuEXsCJxRAASciDydfL/kbFYh5JlAHCFEQPwZoFtMO9kWiBzZdUeUHllkCUAch//coEYIG68 R8BGyHJ8R89I3/ejNDC0LYUgLUExt1MvVDoPTidyck6/T8syOjE111DZcnI2kic6RyepeztG/1b/ WAdycbCvsb+i76P/pQ9nMNJkMEHwci0FIB8wQO1AsG4DYB7ALnShTMAxMN8zQrNqMca277f7XWFw MQDqZRPgbB7QTx7Qplmpf+80TzVVDiA10DesX61vrn/zO8JWsHF1QFFcIgQgIDK4J08nICALYCAQ KIFyv1ayX8ORch/yCcAIYHCzav8v0SEAlHAFsk0Bc6AmsCOgwQQgSUVURimyv7MffEhpoUmzW26U H/Kvg1P/r+MIAIvDdsyUwXgDm9iLpv8LcQGQYpEOULN5JDZok27wv4ThRJQgxSpU1BMhQVciUv8B oCRBQyjSfCS0K7W91dAE/4k0JcEUQAuAJLGFAQQgHsMfJDYmgSIQF5GQoEJHUMMxYEdmT1NQRpZR TOD+LJFQ2CqzatWjiZXH4QSQ77TRlPAmgQDQaN2/4V8/0f8sosvKvT3kj7PER2vnb+h/X+mP6lqz askyOjRXxlVHf8bSNQEDEB/yVWpzEzpSSPsDcB9gUC/RMPDwH1pCR2ZBjEB0cDovLwtReffGwiEA uEYvumK1y4iQHuD9NTFpXnDwD/EcAYDyL/M09nA7QPOPREBRO4COlWLB/zqhX2H1EXOBw+AHkHNh IhHdgtdhmiALIANwb7qvuJ3/5q8AfwGPAp/q7+XP/68G3/8H7wj/6x/sL+0/7k/vXw9f//F/97/z n/SvD3/2z/ff+O//+f/7D/wf/S/+PwV/H08gX/8hbwm/5O0iLyWPJp8nr3K5/ws/DE8NWQ4vLU8t gRD/Eg//clQTnzIfFj8XT6JHGQ8aH/+dohvvHP8kPztvPH89j0k7BUZkfT/gAAAeAEIQAQAAAEkA AAA8OUM0MjI0NDRERTk5QkM0NkIzQUQzQzZFQUZDOTcxMUIwMTUyMDk1REB0YXlleGMxMy5hbWVy aWNhcy5jcHFjb3JwLm5ldD4AAAAAAwAJWQEAAAALAACACCAGAAAAAADAAAAAAAAARgAAAAADhQAA AAAAAAMAAoAIIAYAAAAAAMAAAAAAAABGAAAAABCFAAAAAAAAAwAFgAggBgAAAAAAwAAAAAAAAEYA AAAAUoUAAD9xAQAeACWACCAGAAAAAADAAAAAAAAARgAAAABUhQAAAQAAAAQAAAA5LjAAAwAmgAgg BgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAALAC+ACCAGAAAAAADAAAAAAAAARgAAAAAOhQAAAAAA AAMAMIAIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAygAggBgAAAAAAwAAAAAAAAEYAAAAA GIUAAAAAAAALAO2ACCAGAAAAAADAAAAAAAAARgAAAAAGhQAAAAAAAAIB+A8BAAAAEAAAAGtp8Y7a ntERj/kAIDVDZy8CAfoPAQAAABAAAABrafGO2p7REY/5ACA1Q2cvAgH7DwEAAABJAAAAAAAAADih uxAF5RAaobsIACsqVsIAAG1zcHN0LmRsbAAAAAAATklUQfm/uAEAqgA32W4AAABDOlxtYWlsXG91 dGxvb2sucHN0AAAAAAMA/g8FAAAAAwANNP03AAACAX8AAQAAADEAAAAwMDAwMDAwMDZCNjlGMThF REE5RUQxMTE4RkY5MDAyMDM1NDM2NzJGRTQxMTlDMDIAAAAAAwAGEGWGYRADAAcQdgsAAAMAEBAA AAAAAwAREAEAAAAeAAgQAQAAAGUAAABKSU0sTEVUVVNUSElOS09GQVNJTkdMRVJUTUhBVklOR0ZP UkJPVEhWNEFORFY2QlVUVE9XSEFURVhURU5UVEhJU0lTVkFMSURGUk9NUk9VVElOR1NUQUNLUz9X SUxMSVRCRVZBAAAAANzO ------=_NextPart_000_0005_01C1CFFB.19D1B800-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 19 20:54:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K4sMKL017889 for ; Tue, 19 Mar 2002 20:54:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K4sM9u017888 for ipng-dist; Tue, 19 Mar 2002 20:54:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K4sJKL017881 for ; Tue, 19 Mar 2002 20:54:19 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA01890 for ; Tue, 19 Mar 2002 20:54:17 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA18395 for ; Tue, 19 Mar 2002 20:54:20 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2K4rRH08584; Tue, 19 Mar 2002 22:53:28 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Mar 2002 22:53:30 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02AD31E6@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Francis Dupont , JINMEI Tatuya / ???? Cc: ipng@sunroof.eng.sun.com Subject: RE: poposed changes to the scoping architecture draft Date: Tue, 19 Mar 2002 22:53:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1CFCB.293A93A0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1CFCB.293A93A0 Content-Type: text/plain; charset="iso-8859-1" Maybe I'm just paranoid but does anyone think that it should be recommended that integrity protection of some sort be done when a mobile uses a site local address as source when a packet is tunneled to the home site? Regards, Glenn > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Tuesday, March 19, 2002 4:21 PM > To: JINMEI Tatuya / ???? > Cc: ipng@sunroof.eng.sun.com > Subject: Re: poposed changes to the scoping architecture draft > > > In your previous mail you wrote: > > 1. revise the mobility section to clarify issues about using > site-local addresses with mobile IPv6: > > => I disagree with your solution because it takes more than a few line > to describe it (:-). > IMHO site-local addresses in a mobile IPv6 work well if only a > bidirectional tunnel is used between the mobile and its home agent. > Note there should be no penalty because by definition communications > in the same site are local, so the only difference with routing > optimization is the encapsulaion overhead. > Another important point is an equivalent way to describe this solution > is to say the bidirectional tunnel belongs to the home site. > > + thus, we recommend to use global home/care-of > addresses *whenever > possible*. > > => I agree because this avoids to have a bi-sited node. > (no further comment about multi-site support in some IPv6 stacks :-). > > 2. revise the textual representation section > > => I agree if you still allow names (not ambiguous and mapped to > the pair type/id in a local config file). > > Regards > > Francis.Dupont@enst-bretagne.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 > -------------------------------------------------------------------- > ------_=_NextPart_001_01C1CFCB.293A93A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: poposed changes to the scoping architecture draft

Maybe I'm just paranoid but does anyone think that it = should be recommended that integrity protection of some sort be done = when a mobile uses a site local address as source when a packet is = tunneled to the home site?

Regards,

Glenn

> -----Original Message-----
> From: Francis Dupont [mailto:Francis.Dupont@en= st-bretagne.fr]
> Sent: Tuesday, March 19, 2002 4:21 PM
> To: JINMEI Tatuya / ????
> Cc: ipng@sunroof.eng.sun.com
> Subject: Re: poposed changes to the scoping = architecture draft
>
>
>  In your previous mail you wrote:
>
>    1. revise the mobility = section to clarify issues about using
>       site-local = addresses with mobile IPv6:
>
> =3D> I disagree with your solution because = it takes more than a few line
> to describe it (:-).
> IMHO site-local addresses in a mobile IPv6 work = well if only a
> bidirectional tunnel is used between the mobile = and its home agent.
> Note there should be no penalty because by = definition communications
> in the same site are local, so the only = difference with routing
> optimization is the encapsulaion = overhead.
> Another important point is an equivalent way to = describe this solution
> is to say the bidirectional tunnel belongs to = the home site.
>
>      + thus, we = recommend to use global home/care-of
> addresses *whenever
>        = possible*.
>
> =3D> I agree because this avoids to have a = bi-sited node.
> (no further comment about multi-site support in = some IPv6 stacks :-).
>   
>    2. revise the textual = representation section
>
> =3D> I agree if you still allow names (not = ambiguous and mapped to
> the pair type/id in a local config = file).
>   
> Regards
>
> Francis.Dupont@enst-bretagne.fr
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>

------_=_NextPart_001_01C1CFCB.293A93A0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 19 20:54:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K4sjKL017899 for ; Tue, 19 Mar 2002 20:54:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K4sjY6017898 for ipng-dist; Tue, 19 Mar 2002 20:54:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K4sdKL017891 for ; Tue, 19 Mar 2002 20:54:39 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA15123 for ; Tue, 19 Mar 2002 20:54:41 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA19074 for ; Tue, 19 Mar 2002 21:54:40 -0700 (MST) Received: from localhost ([2001:460:1:210:202:2dff:fe46:6808]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2K4sVo94300; Wed, 20 Mar 2002 13:54:32 +0900 (JST) Date: Wed, 20 Mar 2002 13:54:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ole Troan Cc: ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-Reply-To: <7t5adt4kupd.fsf@mrwint.cisco.com> References: <7t5adt4kupd.fsf@mrwint.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 55 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 19 Mar 2002 23:23:58 +0000, >>>>> Ole Troan said: >> An example: a site-local address fec0::1 on the #2 site can >> represented as fec0::1%5.2 (where 5 means the site scope and 2 means >> the 2nd site) > what is the reasoning behind this change? I certainly hope you still > allow for the original
% where is one of > number, name or interface. I intended to introduce the new format as a replacement of the previous "readable" format like "site2". Implementation dependent zone "names" (including interface names) are still allowed. As for "numbers", I'm not sure if it makes sense to keep them. Since the consensus is zone IDs must contain scope type in its representation, the form of . is a kind of "numeric" representation. Of course, the internal encoding of the representation can be a single integer, but it might just be complicated like 1342177281 (= 0x50000001) because it should contain both the scope type and the zone ID. Do we still need the (possibly complicated) "raw" numbers in the textual representation? > while we're at it, I would suggest we change the prefix representation > to: % e.g fec0:0:0:1::/64%site2 which allows the use > of '/' within the zone_id. The motivation of the ordering is described in the 03 draft: In this combination, it is important to place the zone index portion before the prefix length, when we consider parsing the format by a name-to-address library function [BASICAPI]. That is, we can first separate the address with the zone index from the prefix length, and just pass the former to the library function. Though the API issue might not apply to all platforms, I believe it is still reasonable enough. >> The previous "readable" representation like "link2" or "site10" were >> removed accordingly. The "unreadable" numerical representation like >> 1342177281 (= 0x50000001) were also removed. > good. how an implementation represents a zone with a numerical > representation should be implementation specific. should suffice with > a sentence saying that zones can be represented numerically. Okay, if the consensus is to keep the "raw" numeric numbers in the textual representation, we'll revise the text in a more generic manner. (currently I'm planning just to remove this part.) JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 19 21:04:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K54DKL017955 for ; Tue, 19 Mar 2002 21:04:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K54DAc017954 for ipng-dist; Tue, 19 Mar 2002 21:04:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K548KL017947 for ; Tue, 19 Mar 2002 21:04:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA04262 for ; Tue, 19 Mar 2002 21:04:11 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA03628 for ; Tue, 19 Mar 2002 22:04:09 -0700 (MST) Received: from localhost ([2001:460:1:210:202:2dff:fe46:6808]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2K53xo94395; Wed, 20 Mar 2002 14:04:00 +0900 (JST) Date: Wed, 20 Mar 2002 14:04:09 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela Cc: ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-Reply-To: <200203192159.XAA02075@burp.tkv.asdf.org> References: <200203192159.XAA02075@burp.tkv.asdf.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 41 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 19 Mar 2002 23:59:01 +0200, >>>>> Markku Savela said: >> An example: a site-local address fec0::1 on the #2 site can >> represented as fec0::1%5.2 (where 5 means the site scope and 2 means >> the 2nd site) > But "fec0::1%2" is exactly same, the site scope (5) is implicit from > the address? Yes. > Can you give an example of case where the scope is not associated with > address? If there is such case, then explicit is useful, > but otherwise always unnecessary? As described in the 03 draft, one possibility is a kind of MIB entry which only specifies a particular zone (of a particular scope type). Such a possibility is one of the reasons to adopt this type of format since the 03 version. > Or, this allows then to write "fec0::1%2.2". Is this intended to be > allowed or flagged as an error? This should be treated as an error, as described in the 03 draft. > Btw. what is the scope level of address "::"? = 0? Hmm, good question. I personally think "::" can be treated as a global scope with regards to the scope architecture, because it does not cause ambiguity about the "zone". And, in fact, our current implementation treats "::" as a global address for convenience, and it works without anomaly. Can we agree on this? Then we'll clarify this point in the next revision of the draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 19 21:21:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K5LrKL017992 for ; Tue, 19 Mar 2002 21:21:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K5LrXq017991 for ipng-dist; Tue, 19 Mar 2002 21:21:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K5LlKL017975; Tue, 19 Mar 2002 21:21:47 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA18577; Tue, 19 Mar 2002 21:21:48 -0800 (PST) Received: from babingka.lava.net (babingka.lava.net [64.65.64.26]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA26192; Tue, 19 Mar 2002 22:21:47 -0700 (MST) Received: from malasada.lava.net ([64.65.64.17]) (1861 bytes) by babingka.lava.net; Tue, 19 Mar 2002 19:21:42 -1000 (HST) via sendmail [esmtp] id for Date: Tue, 19 Mar 2002 19:21:41 -1000 (HST) From: Antonio Querubin To: Francis Dupont cc: ngtrans@sunroof.eng.sun.com, Subject: Re: get rid of IPv4 compatibles? In-Reply-To: <200203200447.g2K4lXg69172@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 20 Mar 2002, Francis Dupont wrote: > Date: Wed, 20 Mar 2002 05:47:33 +0100 > From: Francis Dupont > To: ngtrans@sunroof.eng.sun.com > Cc: ipng@sunroof.eng.sun.com > Subject: get rid of IPv4 compatibles? > > Thursday is the last chance to phase out IPv4 compatible addresses > and automatic tunnels. I propose to add this point to the discussion > about RFC 2373 revision. ??? Is the RFC-2373 revision still under discussion? If it is how about just defining mapped multicast addresses already? Similar to section 2.5.5 here's a new section 2.7.2 :) 2.7.2 IPv6 Addresses with Embedded IPv4 Multicast Group Addresses Another type of IPv4-mapped IPv6 address which holds an embedded IPv4 multicast address is defined. This address type is used to represent the addresses of IPv4 multicast groups as IPv6 addresses. This type of address has the format: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |0000..............................0000|FFFF|IPv4 multicast 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 Mar 19 21:52:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K5qAKL018065 for ; Tue, 19 Mar 2002 21:52:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K5qAfa018064 for ipng-dist; Tue, 19 Mar 2002 21:52:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K5q6KL018057 for ; Tue, 19 Mar 2002 21:52:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA05286 for ; Tue, 19 Mar 2002 21:52:08 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA08814 for ; Tue, 19 Mar 2002 22:52:07 -0700 (MST) Received: from localhost ([2001:460:1:210:202:2dff:fe46:6808]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2K5p5o94645; Wed, 20 Mar 2002 14:51:06 +0900 (JST) Date: Wed, 20 Mar 2002 14:51:14 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Brian Haberman Cc: IPng List Subject: Re: Requirements for 'O' flag (was Re: IPv6 working group agendafor Minneapolis IETF) In-Reply-To: <3C962A86.7C249B65@lorien.sc.innovationslab.net> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <3C962A86.7C249B65@lorien.sc.innovationslab.net> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 18 Mar 2002 12:57:26 -0500, >>>>> Brian Haberman said: > I agree the text should be updated. To address your points 'c' > and 'd', it should be pointed out that 2462 was written so that there > was no dependency upon a particular stateful configuration protocol. > Operators would simply utilize their protocol of choice (DHCPv6 or foo) > and 2462 would allow that to be advertised to the hosts. I agree. How much a spec should be specific is always a tradeoff (if it is too generic, implementors and operators will be confused against so many choices. if it is too specific, we'll kill future extensions), but in this case, I think it is overspecification to restrict the possibility to DHCPv6. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 19 22:35:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K6YxKL018124 for ; Tue, 19 Mar 2002 22:34:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K6YxXx018123 for ipng-dist; Tue, 19 Mar 2002 22:34:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K6YtKL018116 for ; Tue, 19 Mar 2002 22:34:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA27151 for ; Tue, 19 Mar 2002 22:34:57 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA14400 for ; Tue, 19 Mar 2002 23:34:56 -0700 (MST) Received: from localhost ([2001:460:1:210:202:2dff:fe46:6808]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2K6Yoo94874; Wed, 20 Mar 2002 15:34:50 +0900 (JST) Date: Wed, 20 Mar 2002 15:35:00 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz (EUD)" Cc: ipng@sunroof.eng.sun.com Subject: Re: Deployability/Useability of Multicast [was: Re: PPP and Globa l Addresses ] In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D0F0@EAMBUNT705> References: <66F66129A77AD411B76200508B65AC69B4D0F0@EAMBUNT705> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 18 Mar 2002 13:19:35 -0600, >>>>> "Bernie Volz (EUD)" said: > The All_DHCP_Servers is not a requirement to make the protocol > work. It is usable in two cases: > - For Information-Request messages to avoid the need for > relays. But, the All_DHCP_Agents is usable with relays. > - For auto-configuration of relays - if a relay doesn't have a > configured DHCP server to forward packets to, it can forward them > to the ALL_DHCP_Servers address. That's true. However, "relay does have a configured DHCP server" is a strong assumption (especially in a large scale network), DHCPv6 quite relies on multicast (whose scope is larger than multicast). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 19 22:39:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K6dsKL018178 for ; Tue, 19 Mar 2002 22:39:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K6dsXM018177 for ipng-dist; Tue, 19 Mar 2002 22:39:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K6dmKL018162; Tue, 19 Mar 2002 22:39:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA21944; Tue, 19 Mar 2002 22:39:50 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA29197; Tue, 19 Mar 2002 23:39:49 -0700 (MST) Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 19 Mar 2002 22:39:48 -0800 Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 19 Mar 2002 22:39:48 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Mar 2002 22:39:42 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 19 Mar 2002 22:39:47 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Tue, 19 Mar 2002 22:36:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: get rid of IPv4 compatibles? Date: Tue, 19 Mar 2002 22:36:39 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC1047CEBC1@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: get rid of IPv4 compatibles? thread-index: AcHPzx603blj6Y2oSAWrkF3KgIcxiQACp1vQ From: "Dave Thaler" To: "Antonio Querubin" Cc: , X-OriginalArrivalTime: 20 Mar 2002 06:36:40.0520 (UTC) FILETIME=[97D42480:01C1CFD9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2K6dmKL018163 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Antonio Querubin writes: > If it is how about just defining mapped multicast addresses already? [...] > | 80 bits | 16 | 32 bits | > +--------------------------------------+--------------------------+ > |0000..............................0000|FFFF|IPv4 multicast group | > +--------------------------------------+----+---------------------+ This has been discussed before, and the above format is illegal, since all multicast addresses must begin with 0xFF, not 0x00. I think someone did once propose a format which was out of the legal multicast space. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 19 23:29:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K7T1KL018336 for ; Tue, 19 Mar 2002 23:29:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K7T1q3018335 for ipng-dist; Tue, 19 Mar 2002 23:29:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K7SvKL018328 for ; Tue, 19 Mar 2002 23:28:57 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA01477 for ; Tue, 19 Mar 2002 23:28:58 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA13922 for ; Wed, 20 Mar 2002 00:28:57 -0700 (MST) Received: from localhost ([2001:460:1:210:202:2dff:fe46:6808]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2K7Slo95202; Wed, 20 Mar 2002 16:28:48 +0900 (JST) Date: Wed, 20 Mar 2002 16:28:57 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Glenn Morrow" Cc: ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-Reply-To: <933FADF5E673D411B8A30002A5608A0E02AD31E6@zrc2c012.us.nortel.com> References: <933FADF5E673D411B8A30002A5608A0E02AD31E6@zrc2c012.us.nortel.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 17 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 19 Mar 2002 22:53:22 -0600, >>>>> "Glenn Morrow" said: > Maybe I'm just paranoid but does anyone think that it should be recommended > that integrity protection of some sort be done when a mobile uses a site > local address as source when a packet is tunneled to the home site? This can be an issue, but this is the case for all type of tunneling, that is, this is not specific to mobile IPv6. At this moment I don't think we need an additional note on this issue, but if many other people want to note this issue explicitly, I think we can add a short note in the Security Considerations section. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 20 00:08:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K88rKL018440 for ; Wed, 20 Mar 2002 00:08:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K88rR7018439 for ipng-dist; Wed, 20 Mar 2002 00:08:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K88lKL018423; Wed, 20 Mar 2002 00:08:47 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA03017; Wed, 20 Mar 2002 00:08:47 -0800 (PST) Received: from ensemada.lava.net (ensemada.lava.net [64.65.64.27]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23486; Wed, 20 Mar 2002 00:08:49 -0800 (PST) Received: from malasada.lava.net ([64.65.64.17]) (1708 bytes) by ensemada.lava.net; Tue, 19 Mar 2002 22:08:46 -1000 (HST) via sendmail [esmtp] id for Date: Tue, 19 Mar 2002 22:08:45 -1000 (HST) From: Antonio Querubin To: Dave Thaler cc: ngtrans@sunroof.eng.sun.com, Subject: RE: get rid of IPv4 compatibles? In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC1047CEBC1@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 19 Mar 2002, Dave Thaler wrote: > Antonio Querubin writes: > > If it is how about just defining mapped multicast addresses already? > [...] > > | 80 bits | 16 | 32 bits | > > +--------------------------------------+--------------------------+ > > |0000..............................0000|FFFF|IPv4 multicast group | > > +--------------------------------------+----+---------------------+ > > This has been discussed before, and the above format is illegal, since > all multicast addresses must begin with 0xFF, not 0x00. You mean all IPv6 multicast addresses? But here we mean mapped representations of IPv4 addresses which in this case happen to be multicast. For implementation purposes I think it would be simpler to keep the /96 prefix identical for both IPv4 unicast and IPv4 multicast addresses. Otherwise, tests for address type become a little more complicated since we'd be adding yet another prefix to test for and another map classification. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 01:17:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K9HrKL018535 for ; Wed, 20 Mar 2002 01:17:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K9HrNb018534 for ipng-dist; Wed, 20 Mar 2002 01:17:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K9HoKL018527 for ; Wed, 20 Mar 2002 01:17:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA17255 for ; Wed, 20 Mar 2002 01:17:50 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24351 for ; Wed, 20 Mar 2002 01:17:44 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id LAA02830; Wed, 20 Mar 2002 11:17:38 +0200 Date: Wed, 20 Mar 2002 11:17:38 +0200 Message-Id: <200203200917.LAA02830@burp.tkv.asdf.org> From: Markku Savela To: jinmei@isl.rdc.toshiba.co.jp CC: ipng@sunroof.eng.sun.com In-reply-to: Subject: Re: poposed changes to the scoping architecture draft References: <200203192159.XAA02075@burp.tkv.asdf.org> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-2022-JP Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: JINMEI Tatuya / $B?@L@C#:H(B > As described in the 03 draft, one possibility is a kind of MIB entry > which only specifies a particular zone (of a particular scope type). > Such a possibility is one of the reasons to adopt this type of format > since the 03 version. Ahh, a nasty person might then ask: why are we burdening all other addresses with this
%. when they don't need it, and the only place where it would be needed (that MIB example), is not actually using address at all! But, of course I can guess why: the place where such notation occurs, is usually parsed as address, and it would be truly neat if it could handle the addressless zone id too. My proposal for a solution is as follows: 1)
% is the format. scope_type is always known from the
. 2) to allow an API to specify an ANY address limited to a specific scope, the following specic adresses are assigned for the purpose: fe80::% - ANY address in specified link local zone fec0::% - ANY address in specified site zone ::% - ANY address in specified global zone and just to be complete, for zone specific multicasts ff01::% ff02::% ff03::% ... ff0F::% I believe all (?) of above are sort of illegal in normal use, and could thus be dedicated for the purpose (MIB, limiting a listen socket to specific scopeid etc.). How does this kludge sound? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 01:46:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K9k2KL018573 for ; Wed, 20 Mar 2002 01:46:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2K9k2bg018572 for ipng-dist; Wed, 20 Mar 2002 01:46:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2K9juKL018565 for ; Wed, 20 Mar 2002 01:45:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA23651 for ; Wed, 20 Mar 2002 01:45:56 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA00284 for ; Wed, 20 Mar 2002 02:45:55 -0700 (MST) Received: from tarski.cs.uni-bonn.de (tarski.cs.uni-bonn.de [131.220.4.200]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id KAA04006 for ; Wed, 20 Mar 2002 10:45:53 +0100 (MET) Received: (from ignatios@localhost) by tarski.cs.uni-bonn.de (8.9.1a/8.9.1) id KAA25313 for ipng@sunroof.eng.sun.com; Wed, 20 Mar 2002 10:45:04 +0100 (CET) Date: Wed, 20 Mar 2002 10:45:04 +0100 From: Ignatios Souvatzis Cc: "'IPng List'" Subject: Re: Dual stack routers Message-ID: <20020320104504.A23653@tarski.cs.uni-bonn.de> References: <9C422444DE99BC46B3AD3C6EAFC9711B0152095D@tayexc13.americas.cpqcorp.net> <000401c1cfcd$00197c00$0906140a@future.futsoft.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000401c1cfcd$00197c00$0906140a@future.futsoft.com>; from murugankat@future.futsoft.com on Wed, Mar 20, 2002 at 10:36:30AM +0530 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2002 at 10:36:30AM +0530, Murugan KAT wrote: > Let us think of a single RTM having for both V4 and V6.=20 > But to what extent this is valid from routing stacks.? Will it be valid to > propogate V4 routing info. also to V6 domain.? Obviously the other way is > not valid? In a multi-protocol world, this might well be valid at least for "site"-loc= al routing. Think OSPF, which provides routing information primary for OSI=20 protocols, but propagates the topology information to other protocol modules (e.g., IPv4). Now, if you have a node that only speaks one of the protocols involved, it obviously can't do this - but we're speaking of multiprotocol capable nodes already, right? Regards -is --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPJhaFzCn4om+4LhpAQFSwQf/ZpZlDkfOM5mtwR1hImHljbrfm1M3TPuE S0tuaxXwe83Yqaob/HTvom45vtrWWwAn8kU4gvw8RBTMGzuTOW83r7Gbr3t2R8rm dhxclnGBfK0CboTmLxEQcFipOhDH27vqgUi5ZZxDgxVOT3ad/8rQzLAO3GxiESE6 07qT3zT+nieu/xOfjdOMEAICdNkVwIaHdqZaIYJdxaTDCGcuY+RFCfvqR3XAUcJx UAEUva8H03QVo/UVMZOHxtqmSkLBbCNhCCg22kOuM/kZfNmh0IXQ0M8xi4lWi7iP AhJW7yxsE4FihbSomD9ohAL11ybtvcP7MM2EI7mhIW7aIv7KrGqazA== =IKb5 -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 02:04:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KA4FKL018616 for ; Wed, 20 Mar 2002 02:04:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KA4EQV018615 for ipng-dist; Wed, 20 Mar 2002 02:04:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KA4BKL018608 for ; Wed, 20 Mar 2002 02:04:11 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA27874 for ; Wed, 20 Mar 2002 02:04:12 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA07929 for ; Wed, 20 Mar 2002 02:04:12 -0800 (PST) Received: from tarski.cs.uni-bonn.de (tarski.cs.uni-bonn.de [131.220.4.200]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id LAA04230; Wed, 20 Mar 2002 11:04:10 +0100 (MET) Received: (from ignatios@localhost) by tarski.cs.uni-bonn.de (8.9.1a/8.9.1) id LAA27283; Wed, 20 Mar 2002 11:03:21 +0100 (CET) Date: Wed, 20 Mar 2002 11:03:21 +0100 From: Ignatios Souvatzis To: Ignatios Souvatzis Cc: "'IPng List'" Subject: Re: Dual stack routers Message-ID: <20020320110321.B23653@tarski.cs.uni-bonn.de> References: <9C422444DE99BC46B3AD3C6EAFC9711B0152095D@tayexc13.americas.cpqcorp.net> <000401c1cfcd$00197c00$0906140a@future.futsoft.com> <20020320104504.A23653@tarski.cs.uni-bonn.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="DKU6Jbt7q3WqK7+M" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020320104504.A23653@tarski.cs.uni-bonn.de>; from ignatios@theory.cs.uni-bonn.de on Wed, Mar 20, 2002 at 10:45:04AM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --DKU6Jbt7q3WqK7+M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2002 at 10:45:04AM +0100, Ignatios Souvatzis wrote: > On Wed, Mar 20, 2002 at 10:36:30AM +0530, Murugan KAT wrote: >=20 > > Let us think of a single RTM having for both V4 and V6.=20 > > But to what extent this is valid from routing stacks.? Will it be valid= to > > propogate V4 routing info. also to V6 domain.? Obviously the other way = is > > not valid? >=20 > In a multi-protocol world, this might well be valid at least for "site"-l= ocal > routing. Think OSPF, which provides routing information primary for OSI= =20 > protocols, but propagates the topology information to other protocol modu= les > (e.g., IPv4). >=20 > Now, if you have a node that only speaks one of the protocols involved, > it obviously can't do this - but we're speaking of multiprotocol capable > nodes already, right? I forgot: obviously, you need some way to associate the, say, OSI address of a local net or node with it's IPv4 and IPv6 network address. Regards, -is --DKU6Jbt7q3WqK7+M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPJhdYzCn4om+4LhpAQFnygf9GPv+IkWTsC/YEURB7oalpkvlvsrx4Wdc T3HoKzfie2oL7ak5U9WLPf24sw6D9hvthMXy4BPdszdO7IfA9i/q0Q1ggI6jBbyq KeFXgUXY1GWuED6Wzr32lCIQe3KyJmb+kAwUcu68d66ng+iSjequXjKIqe2qffFM Ykq/ytdnkGSIc9nvw9r0AbFeThK3NKSSJZQooIjRyAVV1EOUYHaPx9lhRGmIe27j G9pedWX+DMJbQjII8f9Lzhk/kn1m4I+C8Wk3YB2hVV9yh5frjyn1xGpNFVIdOYMl ADnRVTV9dCRJI8HuXltDmCraKSw78TplhjJ4T1cszBq7EfrW08P+Jg== =eJJa -----END PGP SIGNATURE----- --DKU6Jbt7q3WqK7+M-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 08:45:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KGjXKL020008 for ; Wed, 20 Mar 2002 08:45:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KGjXlH020007 for ipng-dist; Wed, 20 Mar 2002 08:45:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KGjTKL020000 for ; Wed, 20 Mar 2002 08:45:29 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA23005 for ; Wed, 20 Mar 2002 08:45:27 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24919 for ; Wed, 20 Mar 2002 08:45:26 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2KGih229617; Wed, 20 Mar 2002 17:44:43 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA16674; Wed, 20 Mar 2002 17:44:43 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2KGihg70735; Wed, 20 Mar 2002 17:44:43 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203201644.g2KGihg70735@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Markku Savela , ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-reply-to: Your message of Wed, 20 Mar 2002 14:04:09 +0900. Date: Wed, 20 Mar 2002 17:44:43 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > Btw. what is the scope level of address "::"? = 0? Hmm, good question. I personally think "::" can be treated as a global scope with regards to the scope architecture, because it does not cause ambiguity about the "zone". And, in fact, our current implementation treats "::" as a global address for convenience, and it works without anomaly. Can we agree on this? Then we'll clarify this point in the next revision of the draft. => agree! Francis.Dupont@enst-bretagne.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 Wed Mar 20 08:47:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KGlpKL020037 for ; Wed, 20 Mar 2002 08:47:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KGlpUh020036 for ipng-dist; Wed, 20 Mar 2002 08:47:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KGlmKL020029 for ; Wed, 20 Mar 2002 08:47:48 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01241 for ; Wed, 20 Mar 2002 08:47:49 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07161 for ; Wed, 20 Mar 2002 09:47:48 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2KGlY229968; Wed, 20 Mar 2002 17:47:34 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA16729; Wed, 20 Mar 2002 17:47:35 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2KGlYg70761; Wed, 20 Mar 2002 17:47:34 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203201647.g2KGlYg70761@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: "Glenn Morrow" , ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-reply-to: Your message of Wed, 20 Mar 2002 16:28:57 +0900. Date: Wed, 20 Mar 2002 17:47:34 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: >>>>> On Tue, 19 Mar 2002 22:53:22 -0600, >>>>> "Glenn Morrow" said: > Maybe I'm just paranoid but does anyone think that it should be recommended > that integrity protection of some sort be done when a mobile uses a site > local address as source when a packet is tunneled to the home site? This can be an issue, but this is the case for all type of tunneling, that is, this is not specific to mobile IPv6. At this moment I don't think we need an additional note on this issue, but if many other people want to note this issue explicitly, I think we can add a short note in the Security Considerations section. => I agree. In fact I can't see a reason to recommend integrity protection only when the source is site-local (i.e tunnel == external). Regards Francis.Dupont@enst-bretagne.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 Wed Mar 20 08:53:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KGrsKL020075 for ; Wed, 20 Mar 2002 08:53:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KGrsSJ020074 for ipng-dist; Wed, 20 Mar 2002 08:53:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KGrpKL020067 for ; Wed, 20 Mar 2002 08:53:51 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07748 for ; Wed, 20 Mar 2002 08:53:52 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA27426 for ; Wed, 20 Mar 2002 08:53:54 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2KGrF230715; Wed, 20 Mar 2002 17:53:15 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id RAA16817; Wed, 20 Mar 2002 17:53:15 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2KGrFg70803; Wed, 20 Mar 2002 17:53:15 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203201653.g2KGrFg70803@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-reply-to: Your message of Wed, 20 Mar 2002 11:17:38 +0200. <200203200917.LAA02830@burp.tkv.asdf.org> Date: Wed, 20 Mar 2002 17:53:15 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Ahh, a nasty person might then ask: why are we burdening all other addresses with this
%. when they don't need it, and the only place where it would be needed (that MIB example), is not actually using address at all! => as my goal is to always use names I am neutral: to add scope types is not a real burden and this catches errors. But, of course I can guess why: the place where such notation occurs, is usually parsed as address, and it would be truly neat if it could handle the addressless zone id too. => this was the argument for the binary format. IMHO it is sound to reuse it for the textual format, so I am slightly in favor of initial Jinmei's proposal. Regards Francis.Dupont@enst-bretagne.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 Wed Mar 20 09:44:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KHiQKL020549 for ; Wed, 20 Mar 2002 09:44:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KHiQJ1020548 for ipng-dist; Wed, 20 Mar 2002 09:44:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KHiNKL020541 for ; Wed, 20 Mar 2002 09:44:23 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA22209 for ; Wed, 20 Mar 2002 09:44:25 -0800 (PST) Received: from theory.cs.uni-bonn.de (theory.cs.uni-bonn.de [131.220.4.211]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08561 for ; Wed, 20 Mar 2002 10:44:24 -0700 (MST) Received: from tarski.cs.uni-bonn.de (tarski.cs.uni-bonn.de [131.220.4.200]) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) with ESMTP id SAA11992; Wed, 20 Mar 2002 18:44:22 +0100 (MET) Received: (from ignatios@localhost) by tarski.cs.uni-bonn.de (8.9.1a/8.9.1) id SAA03438; Wed, 20 Mar 2002 18:43:34 +0100 (CET) Date: Wed, 20 Mar 2002 18:43:34 +0100 From: Ignatios Souvatzis To: Ignatios Souvatzis Cc: "'IPng List'" Subject: Re: Dual stack routers Message-ID: <20020320184334.A3133@tarski.cs.uni-bonn.de> References: <9C422444DE99BC46B3AD3C6EAFC9711B0152095D@tayexc13.americas.cpqcorp.net> <000401c1cfcd$00197c00$0906140a@future.futsoft.com> <20020320104504.A23653@tarski.cs.uni-bonn.de> <20020320110321.B23653@tarski.cs.uni-bonn.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020320110321.B23653@tarski.cs.uni-bonn.de>; from ignatios@theory.cs.uni-bonn.de on Wed, Mar 20, 2002 at 11:03:21AM +0100 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2002 at 11:03:21AM +0100, Ignatios Souvatzis wrote: > On Wed, Mar 20, 2002 at 10:45:04AM +0100, Ignatios Souvatzis wrote: > > On Wed, Mar 20, 2002 at 10:36:30AM +0530, Murugan KAT wrote: > >=20 > > > Let us think of a single RTM having for both V4 and V6.=20 > > > But to what extent this is valid from routing stacks.? Will it be val= id to > > > propogate V4 routing info. also to V6 domain.? Obviously the other wa= y is > > > not valid? > >=20 > > In a multi-protocol world, this might well be valid at least for "site"= -local > > routing. Think OSPF, which provides routing information primary for OSI= =20 > > protocols, but propagates the topology information to other protocol mo= dules > > (e.g., IPv4). > >=20 > > Now, if you have a node that only speaks one of the protocols involved, > > it obviously can't do this - but we're speaking of multiprotocol capable > > nodes already, right? >=20 > I forgot: obviously, you need some way to associate the, say, OSI address > of a local net or node with it's IPv4 and IPv6 network address. I was confused. ELOWCOFFEE. s/OSPF/IS-IS/g in the above. -is --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPJjGQDCn4om+4LhpAQHM3gf/XY8/ZxckuF+fVPd5DGiE9p4EEWn2A0fP ITlg5nPhaxX3CXqAv6oebtj5NISntmAbi05Xhxo2iMGAasxr9XYEw47V4LI9Smgd Umx0o+QEwWKb4cGRZYXitx3hecfxDEMBG9eNi5WtD/Xyigvd+K8vFaknZjIQWo6E XvDYXPrrvM08zlwgu+IR/Yds3zt4I+lXrz0tkFc4MZIzIrlXiKfbXCG1WA+D8t9/ XC7rVK15U5/h39KqnAbJYQYmAj/lsIGZeDbYII1luEXcEV4I5g2PlrM2K/MfFSOA W4R09IlCsQ+5Mbb7N4lG3pCgPn9p0/s92Gq6EMqZYVXqRnPK4CsyAg== =BNuc -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 10:44:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KIiOKL020707 for ; Wed, 20 Mar 2002 10:44:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KIiOC1020706 for ipng-dist; Wed, 20 Mar 2002 10:44:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KIiJKL020699 for ; Wed, 20 Mar 2002 10:44:20 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2KIiFx28379; Wed, 20 Mar 2002 19:44:16 +0100 (MET) Date: Wed, 20 Mar 2002 19:44:07 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: poposed changes to the scoping architecture draft To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > + to deal with such issues, we'll need an ability for mobile nodes > to tell whether a correspondent node or the home agent is in the > same site as the mobile node. However, there is currently no > standard way to implement the ability. I agree that the issues here needs to be pointed out. I wonder if we can give more explicit advice for the case when a MN has a global HoA and a site-local CoA . For instance, in that case it might make sense to only do bidirectional tunneling. Does the document look at the different cases here? 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 Wed Mar 20 11:00:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJ0qKL020746 for ; Wed, 20 Mar 2002 11:00:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KJ0qBD020745 for ipng-dist; Wed, 20 Mar 2002 11:00:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJ0lKL020738; Wed, 20 Mar 2002 11:00:48 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2KJ0hx29791; Wed, 20 Mar 2002 20:00:44 +0100 (MET) Date: Wed, 20 Mar 2002 20:00:25 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: (ngtrans) get rid of IPv4 compatibles? To: Francis Dupont Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <200203200447.g2K4lXg69172@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Thursday is the last chance to phase out IPv4 compatible addresses > and automatic tunnels. I propose to add this point to the discussion > about RFC 2373 revision. The plan in ngtrans has been to remove this by creating RFC1933ter = RFC2893bis without these pieces. I don't have a problem removing compatible addresses from the addressing architecture, but I also don't think it is required. Once RFC2893bis blows it away its gone whether or not the addressing architecture contains the defintion for compatible addresses. 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 Wed Mar 20 11:01:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJ1CKL020778 for ; Wed, 20 Mar 2002 11:01:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KJ1Clh020777 for ipng-dist; Wed, 20 Mar 2002 11:01:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJ18KL020770 for ; Wed, 20 Mar 2002 11:01:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27979 for ; Wed, 20 Mar 2002 11:01:08 -0800 (PST) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16159 for ; Wed, 20 Mar 2002 12:01:07 -0700 (MST) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 20 Mar 2002 11:00:56 -0800 Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 20 Mar 2002 11:01:04 -0800 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Mar 2002 11:00:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: poposed changes to the scoping architecture draft Date: Wed, 20 Mar 2002 11:01:02 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA8063CEBE6@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: poposed changes to the scoping architecture draft thread-index: AcHQLyN5WXrlPhEERSeEPmZuK2tVxgAEcpDw From: "Richard Draves" To: "Francis Dupont" , "JINMEI Tatuya / ????" Cc: "Markku Savela" , X-OriginalArrivalTime: 20 Mar 2002 19:00:39.0138 (UTC) FILETIME=[8684B420:01C1D041] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2KJ19KL020771 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Btw. what is the scope level of address "::"? = 0? > > Hmm, good question. I personally think "::" can be treated as a > global scope with regards to the scope architecture, > because it does > not cause ambiguity about the "zone". And, in fact, our current > implementation treats "::" as a global address for > convenience, and it > works without anomaly. I think the loopback address should be link-local scope (on a virtual loopback link). It is obviously not global scope, since it does not uniquely specify an interface. Note that draft-ietf-ipv6-default-addr-select-07.txt section 2.4 also refers to this issue. 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 Mar 20 11:14:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJEVKL020875 for ; Wed, 20 Mar 2002 11:14:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KJEVDM020874 for ipng-dist; Wed, 20 Mar 2002 11:14:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJESKL020867; Wed, 20 Mar 2002 11:14:28 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA08750; Wed, 20 Mar 2002 11:14:28 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26113; Wed, 20 Mar 2002 12:14:27 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2KJCUO30600; Wed, 20 Mar 2002 21:12:30 +0200 Date: Wed, 20 Mar 2002 21:12:29 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: Francis Dupont , , Subject: Re: (ngtrans) get rid of IPv4 compatibles? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 20 Mar 2002, Erik Nordmark wrote: > I don't have a problem removing compatible addresses from the addressing > architecture, but I also don't think it is required. > Once RFC2893bis blows it away its gone whether or not the addressing > architecture contains the defintion for compatible addresses. I suggested removing compat-addrs earlier, but it didn't get support from Bob.. perhaps now it's a better time. IMO, if the aim is to get rid of compats in RFC2893bis, talking about compatible addresses in new addrarch (which is draft standard, so it'll be around for a long time..) is just plain confusing. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 11:17:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJHsKL020922 for ; Wed, 20 Mar 2002 11:17:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KJHsS1020921 for ipng-dist; Wed, 20 Mar 2002 11:17:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJHpKL020914 for ; Wed, 20 Mar 2002 11:17:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA09815 for ; Wed, 20 Mar 2002 11:17:51 -0800 (PST) Received: from tuubi52.adsl.netsonic.fi (tuubi52.adsl.netsonic.fi [194.29.196.52]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA25334 for ; Wed, 20 Mar 2002 12:17:45 -0700 (MST) Received: from nomadiclab.com (localhost [127.0.0.1]) by tuubi52.adsl.netsonic.fi (8.11.6/8.11.6) with ESMTP id g2KJHZm06942 for ; Wed, 20 Mar 2002 21:17:36 +0200 (EET) (envelope-from Pekka.Nikander@nomadiclab.com) Message-ID: <3C98E099.5000901@nomadiclab.com> Date: Wed, 20 Mar 2002 13:18:49 -0600 From: Pekka Nikander User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020307 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Allocating a bit in the RFC2437 Interface Identifier Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As discussed at the mobile-ip WG meeting on Tuesday morning, in length at the mobile-ip mailing list, and in some length at the this mailing list, there has emerged a need to encode functional, security related semantics into IP addresses. The purpose of this short note is to try to describe the situation in general terms, thereby giving *background* to the discussion on Thursday at the ipv6 WG meeting. Note that the discussion on Thursday morning is about *reserving* space in the interface ID for possible future extensions. This note is about a possible *use* of part of that space. It makes sense keeping the discussion of whether or not to reserve space separate from the discussion about use. The situation ============= Consider two hosts, Alice and Bob, that do not know each other. For some reason, Alice wants to contact Bob. Thus, she goes to DNS (or whatever), learns Bob's address, and sends a packet (e.g. TCP SYN) to Bob. Bob receives the packet and starts processing it. Now, when Bob receives the packet sent by Alice, he has no other knowledge about Alice but the packet itself. In particular, the only information he has about Alice is the source IP address in the packet. However, there seem to be situations (I'll return to them in a moment) where he needs to learn a little bit more about Alice before he can answer in a proper way. Clearly, Bob has a few options how he can proceed and learn more about Alice: a) He can go to DNS, do a reverse lookup, and hope to learn something useful. However, this may be expensive in terms of time and number of packets, causing packets sent to the DNS server that serves the reverse map for Alice's address, and thereby somewhat dangerous from the Denial-of-Service point of view. Additionally, secure DNS is not widely deployed, and therefore he usually can't fully trust the results. Anyhow, this is the method that most hosts use today. b) He can try to use some other infrastructure, such as AAA, and try to get some information about Alice from there. However, this method requires that Alice participates in the same infrastructure, which, in general, is unlikely for a number of years to come. Secondly, this method has the same drawbacks as DNS lookups, generating delay and extra traffic. c) He can send a probe to Alice, checking that there indeed is somebody who answers in the said address. TCP SYN ACK is basically such a probe, and so are the new Mobile IPv6 RR packets (HoTI, CoTI, HoT, CoT). The drawback of this method is that doesn't *prove* anything else but that Alice (or somebody impersonating her) is really there (which is an important property, but orthogonal to the other the other pieces of information about Alice). d) He can have a look at the address, and try to deduce something from the address itself. Currently, he can learn whether Alice is using a link local, site local or global address, whether Alice's address is supposed to contain a globally unique interface ID, etc. Now, the whole need and idea is to extend d) so that Bob can learn more about Alice by just looking at the address. This would be very benefial for busy servers, and especially in situations where the server may be facing a resource exhausting denial-of-service attack. Note, however, that extending d) does not mean, in any way, that the other options could not or should not be used in the future. Security point of view ====================== Security is a very important issue here. Firstly, as will be discussed below, there are situations where the method must be resistant to resource consumption amplifying denial-of-service attacks, basically ruling out DNS and AAA/other infra in those situations. Secondly, there are situations where the information about Alice must be reliable, i.e. authentic and integral. Secure DNS and AAA could fulfil this latter need, but only at the expense of added delay & traffic, and possible DoS/reflection, as noted above. The need for reliable information is especially important for security protocols. Here we come to the so called "bindding down" argument. That is, let us assume that there exist some default security protocol that all IPv6 hosts are assumed to support. Furthermore, let us assume that there *does* exist some more secure protocols for the same purpose, but some hosts do not support these more secure protocols, for example, since the more secure protocols impose more computational requirements or are otherwise more costly. In this situation the hosts must be able to do a selection between the default, less secure protocol and the more secure protocols. That is, if Bob supports both the default protocol and (at least one) more secure protocol, he must be able to determine if Alice supports the more secure protocol so that he can take the more secure protocol into use. Furthermore, he cannot ask Alice, since an attacker impersonating as Alice would lie, and say that Alice supports only the default, less secure protocol. In other words, there must be a method, independent on Alice's actions, that securely gives Bob reliable information about the protocols Alice supports. If such a method does not exist, and there is an attacker that can break one of the protocols, the attacker can claim that Alice supports only the protocol that it is able to break, thereby making it impossible for Bob to use the other more secure protocols. This is the essense of the bidding down attack: an attacker that is able to break one of a number of security protocols can impersonate Alice to Bob unless Bob can learn, independent of Alice, what protocols Alice supports. See http://playground.sun.com/mobile-ip/WG-archive/frm05357.html and http://www.piuha.net/~jarkko/publications/mipv6/Bidding_down.txt for more details. Note that with respect to the bidding down attack the discussing about allowing Bob to determine, by looking at the address, whether Alice is satisfied with the default protocol or not. That allows Bob to continue quickly in the default case. What to do, in exact terms, in the non-default case (other than not using the default protocol) is beyond the scope of this note. Especially, we are *not* suggesting that there should be additional bit(s) reserved for specific needs. Specific needs ============== Currently there seems to be only one situation where we want to introduce a default, not-so-good-but-good-enough security protocol that anybody can use, with the anticipation that in the future there will be a number of better-and-more-secure variants. This is the Mobile IPv6 situation, where Return Routability (RR) will be the baseline security protocol. However, the situation is in no way specific to Mobile IP. There will clearly be other needs too, e.g., secure multicast or anycast might have the same need. In the case of Mobile IP, we definitely want to have a method where it is possible to tell whether a given Mobile Node wants to use RR or not. In this case, the most secure security protocol is to disallow the function completely, i.e., say that Mobile IP Route Optimization MUST NOT be used for this host. For example, stationary hosts most probably want to forbid Mobile IP Route Optimization. However, if we want universal deployment for Mobile IPv6, the default clearly cannot be to disallow Mobile IP. Instead, the default case clearly needs to be the lowest common denominator, Return Routability (RR), and it is up to each host to separately indicate when it wants to use some more secure protocol, including the no-RO at all choice. The suggestion ============== Now, Mobile IPv6 Security Design Team has discussed whether it would be possible to allocate a bit (or a bit pattern) on the IPv6 64 bit Interface Identifier field, with the intention of later defining a method that allows peer hosts to securely find out what security protocols, and perhaps other functional features, the host using the address supports. That is, if the bit is cleared, the host is happy to rely on the default security protocols and semantics, as defined in the base IPv6 RFCs. Thus, its peers are allowed to use the default semantics and protocols when dealing with this host. If the bit is set, on the other hand, the host instructs its peers that the host is not happy with the default semantics and protocols, and instructs the peers to look for more information. The exact way of how to look for this information is to be defined later. Note that an active attacker at the path between Alice and Bob is able to clear a set bit. However, that changes the address, and Alice is not going to answer to any possible replies sent by Bob. Thus, the bit prevents the attacker from impersonating as Alice and fooling Bob to use the less secure protocol. The immediate intention at the mobile-ip WG is to the define the Return Routabilility (RR) security method as the default Mobile IP Route Optimization methods, to be used by all hosts that have the said bit cleared. If the bit is set, the corresponding hosts must go to find out what Mobile IP security method the mobile node supports. If the corresponding node cannot find out this information securely, it MUST NOT use Return Routability. This effectively blocks the bidding down attack, as discussed above. --Pekka Nikander on the behalf of the MIPv6 Security Design Team -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 11:19:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJJsKL020959 for ; Wed, 20 Mar 2002 11:19:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KJJska020958 for ipng-dist; Wed, 20 Mar 2002 11:19:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJJoKL020951 for ; Wed, 20 Mar 2002 11:19:50 -0800 (PST) Received: from saturn.sun.com (saturn.EBay.Sun.COM [129.150.69.2]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27970 for ; Wed, 20 Mar 2002 11:19:50 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11457 for ; Wed, 20 Mar 2002 11:19:45 -0800 (PST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 20 Mar 2002 11:19:43 -0800 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 20 Mar 2002 11:19:43 -0800 Received: from red-msg-06.redmond.corp.microsoft.com ([157.54.12.71]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 20 Mar 2002 11:19:17 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: poposed changes to the scoping architecture draft Date: Wed, 20 Mar 2002 11:19:40 -0800 Message-ID: <7695E2F6903F7A41961F8CF888D87EA804BC48A7@red-msg-06.redmond.corp.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: poposed changes to the scoping architecture draft thread-index: AcHQLyN5WXrlPhEERSeEPmZuK2tVxgAEcpDwAADI+5A= From: "Richard Draves" To: "Francis Dupont" , "JINMEI Tatuya / ????" Cc: "Markku Savela" , X-OriginalArrivalTime: 20 Mar 2002 19:19:17.0966 (UTC) FILETIME=[21644EE0:01C1D044] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2KJJpKL020952 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sorry I wasn't reading correctly - obviously you were discussing the unspecified address not the loopback address!! It's not clear to me that the unspecified address has a well-defined scope level... > -----Original Message----- > From: Richard Draves [mailto:richdr@microsoft.com] > Sent: Wednesday, March 20, 2002 11:01 AM > To: Francis Dupont; JINMEI Tatuya / ???? > Cc: Markku Savela; ipng@sunroof.eng.sun.com > Subject: RE: poposed changes to the scoping architecture draft > > > > > Btw. what is the scope level of address "::"? = 0? > > > > Hmm, good question. I personally think "::" can be treated as a > > global scope with regards to the scope architecture, > > because it does > > not cause ambiguity about the "zone". And, in fact, our current > > implementation treats "::" as a global address for > > convenience, and it > > works without anomaly. > > I think the loopback address should be link-local scope (on a > virtual loopback link). It is obviously not global scope, > since it does not uniquely specify an interface. > > Note that draft-ietf-ipv6-default-addr-select-07.txt section > 2.4 also refers to this issue. > > 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 Wed Mar 20 11:30:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJUWKL021064 for ; Wed, 20 Mar 2002 11:30:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KJUWiu021063 for ipng-dist; Wed, 20 Mar 2002 11:30:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJUTKL021056 for ; Wed, 20 Mar 2002 11:30:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13274 for ; Wed, 20 Mar 2002 11:30:29 -0800 (PST) Received: from mail7.nc.rr.com (fe7.southeast.rr.com [24.93.67.54]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA05394 for ; Wed, 20 Mar 2002 12:30:29 -0700 (MST) Received: from lorien.sc.innovationslab.net ([24.162.252.183]) by mail7.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 20 Mar 2002 10:10:59 -0500 Message-ID: <3C98A6AD.5261EB14@lorien.sc.innovationslab.net> Date: Wed, 20 Mar 2002 10:11:41 -0500 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: murugankat@future.futsoft.com CC: "'IPng List'" , "'Bound, Jim'" Subject: Re: Dual stack routers References: <000401c1cfcd$00197c00$0906140a@future.futsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Actually, having a single RTM supporting IPv4, IPv6 (global-scoped or otherwise), and any other protocol requires some intelligence on the part of the routing protocol. In my prototype of IPv6 scoped routing, I maintained a single RTM without a problem. However, I had to implement a mechanism that would determine which entries could be advertised per interface. Regards, Brian Murugan KAT wrote: > > Jim, > > Let us think of a single RTM having for both V4 and V6. > But to what extent this is valid from routing stacks.? Will it be valid to > propogate V4 routing info. also to V6 domain.? Obviously the other way is > not valid? > > Thanks > KAT.Murugan > > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound@compaq.com] > Sent: Tuesday, 19 March 2002 9:04 PM > To: Brian Haberman > Cc: murugankat@future.futsoft.com; IPng List > Subject: RE: Dual stack routers > > Brian, > > Agree. The entire issue of scoping will need to be added to the > infrastructure for sure. > > thanks > /jim > > > -----Original Message----- > > From: Brian Haberman [mailto:haberman@lorien.sc.innovationslab.net] > > Sent: Tuesday, March 19, 2002 8:22 AM > > To: Bound, Jim > > Cc: murugankat@future.futsoft.com; IPng List > > Subject: Re: Dual stack routers > > > > > > Jim, > > I agree with your assessment. It is essentially the way I have > > integrated IPv6 into an IPv4 system. One point to keep in mind though > > is how to support site-scoped addresses in this model. The > > route table > > needs expansion in order to incorporate the zone IDs in the lookup. > > > > Regards, > > Brian > > > > "Bound, Jim" wrote: > > > > > > Its really up to the engineering team for that > > implementation. I would integrate v4 and v6 and duplicate as > > little as possible. At least all data structures so the > > algorithm for update/replace/delete was the same function > > module and not duplicated once for tcp and once for udp and > > yet again for SCTP. Then there is the emerging RDMA the > > router might want to use for storage. Treating all addresses > > as 16bytes (v4 and v6) works and will perform. Also all the > > traffic shaping, classification, et al on hardware would make > > the hardware engineers job a lot easier and thats a > > performance win too to support both address types. > > > > > > regards, > > > /jim > > > > > > > -----Original Message----- > > > > From: Murugan KAT [mailto:murugankat@future.futsoft.com] > > > > Sent: Tuesday, March 19, 2002 2:15 AM > > > > To: 'IPng List' > > > > Subject: Dual stack routers > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: owner-ipng@sunroof.eng.sun.com > > > > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Murugan KAT > > > > Sent: Tuesday, 19 March 2002 12:07 AM > > > > To: 'IPng List' > > > > Subject: RE: Requirements for 'O' flag (was Re: IPv6 working group > > > > agendafor Minneapolis IETF) > > > > > > > > > > > > Hi, > > > > > > > > Regarding Dual Stack Router implementation should a > > router maintain 2 > > > > routing tables, one for V4 and other for V6. What about the > > > > routing stacks? > > > > Should there be 2 instances of a routing protocol (BGP, > > OSPF etc.,) ? > > > > > > > > What is the general approach? > > > > > > > > > > > > Thanks, > > > > KAT > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPng Working Group Mailing List > > > > IPng Home 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 > > > -------------------------------------------------------------------- > > > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > > ------------------------------------------------------------------------ > Name: winmail.dat > winmail.dat Type: application/ms-tnef > Encoding: base64 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 11:56:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJuwKL021237 for ; Wed, 20 Mar 2002 11:56:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KJuwug021236 for ipng-dist; Wed, 20 Mar 2002 11:56:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KJurKL021229 for ; Wed, 20 Mar 2002 11:56:53 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19734 for ; Wed, 20 Mar 2002 11:56:55 -0800 (PST) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26486 for ; Wed, 20 Mar 2002 12:56:54 -0700 (MST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 9E88A2D36 for ; Wed, 20 Mar 2002 14:56:53 -0500 (EST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 792E612CD; Wed, 20 Mar 2002 11:56:52 -0800 (PST) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g2KJupR22995; Wed, 20 Mar 2002 14:56:51 -0500 (EST) Received: from compaq.com by yquarry.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g2KJupb16535; Wed, 20 Mar 2002 14:56:51 -0500 (EST) Message-ID: <3C98E983.8010903@compaq.com> Date: Wed, 20 Mar 2002 13:56:51 -0600 From: Vladislav Yasevich Reply-To: vlad@zk3.dec.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20011126 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 Cc: ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft References: <200203192159.XAA02075@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei JINMEI Tatuya wrote: > > As described in the 03 draft, one possibility is a kind of MIB entry > which only specifies a particular zone (of a particular scope type). > Such a possibility is one of the reasons to adopt this type of format > since the 03 version. > What would this zone mean to the client requesting the info? The zone-id is meaningless without the accompanying address. It only has meaning on the node it is defined with the address of given scope. The whole scope duplication (in zone-id and address) is dubiouse since we don't allow any more having scope mismatches between the zone-id and the address scope. > >>Btw. what is the scope level of address "::"? = 0? >> > > Hmm, good question. I personally think "::" can be treated as a > global scope with regards to the scope architecture, because it does > not cause ambiguity about the "zone". And, in fact, our current > implementation treats "::" as a global address for convenience, and it > works without anomaly. The scope of the wildcard is wildcard i.e. it belongs to all scopes. I might be limed by specified a zone-id if we want to allow it (I think Dave Thaler originally proposed this on the api list). -vlad -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 12:02:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KK2sKL021303 for ; Wed, 20 Mar 2002 12:02:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KK2sHx021302 for ipng-dist; Wed, 20 Mar 2002 12:02:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KK2pKL021295 for ; Wed, 20 Mar 2002 12:02:51 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA22375 for ; Wed, 20 Mar 2002 12:02:52 -0800 (PST) Received: from matell.enst-bretagne.fr (matell.enst-bretagne.fr [192.108.115.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA19626 for ; Wed, 20 Mar 2002 13:02:51 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by matell.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2KK2l905475; Wed, 20 Mar 2002 21:02:47 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA18818; Wed, 20 Mar 2002 21:02:48 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2KK2lg71548; Wed, 20 Mar 2002 21:02:47 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203202002.g2KK2lg71548@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander cc: ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2437 Interface Identifier In-reply-to: Your message of Wed, 20 Mar 2002 13:18:49 CST. <3C98E099.5000901@nomadiclab.com> Date: Wed, 20 Mar 2002 21:02:47 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Can you change the subject: RFC 2437 is PKCS #1 ??? Francis.Dupont@enst-bretagne.fr PS: IMHO we should serialize reservation and use, so I'll read your message just after Erik presentation+discussion tomorrow! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 12:12:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KKC3KL021358 for ; Wed, 20 Mar 2002 12:12:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KKC31U021357 for ipng-dist; Wed, 20 Mar 2002 12:12:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KKBxKL021350 for ; Wed, 20 Mar 2002 12:11:59 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18810 for ; Wed, 20 Mar 2002 12:12:00 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA02850 for ; Wed, 20 Mar 2002 12:11:53 -0800 (PST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2KKBdt26928; Wed, 20 Mar 2002 15:11:40 -0500 (EST) Message-Id: <200203202011.g2KKBdt26928@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Nikander cc: ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2437 Interface Identifier In-reply-to: (Your message of "Wed, 20 Mar 2002 13:18:49 CST.") <3C98E099.5000901@nomadiclab.com> Date: Wed, 20 Mar 2002 15:11:39 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > there has emerged a need to encode functional, security related > semantics into IP addresses I strongly disagree. there has been a longstanding need to encode functional security related semantics into IP packets. but the address is entirely the wrong place for these. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 12:31:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KKVPKL021543 for ; Wed, 20 Mar 2002 12:31:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KKVPq1021542 for ipng-dist; Wed, 20 Mar 2002 12:31:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KKVMKL021535 for ; Wed, 20 Mar 2002 12:31:22 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA02015 for ; Wed, 20 Mar 2002 12:31:19 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA04528 for ; Wed, 20 Mar 2002 12:31:22 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2KKTCY11613; Wed, 20 Mar 2002 14:29:16 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 14:29:13 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02B2D557@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Francis Dupont , JINMEI Tatuya / ???? Cc: ipng@sunroof.eng.sun.com Subject: RE: poposed changes to the scoping architecture draft Date: Wed, 20 Mar 2002 14:29:12 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D04D.E53B6A20" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D04D.E53B6A20 Content-Type: text/plain; charset="iso-8859-1" Yes, I agree, this probably is the wrong ID to make the note in. I'll see if such a note is in the current revision of the MIPv6 draft. That should be sufficient. > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Wednesday, March 20, 2002 10:48 AM > To: JINMEI Tatuya / ???? > Cc: Morrow, Glenn [RICH2:C330:EXCH]; ipng@sunroof.eng.sun.com > Subject: Re: poposed changes to the scoping architecture draft > > > In your previous mail you wrote: > > >>>>> On Tue, 19 Mar 2002 22:53:22 -0600, > >>>>> "Glenn Morrow" said: > > > Maybe I'm just paranoid but does anyone think that it > should be recommended > > that integrity protection of some sort be done when a > mobile uses a site > > local address as source when a packet is tunneled to the > home site? > > This can be an issue, but this is the case for all type of > tunneling, > that is, this is not specific to mobile IPv6. At this > moment I don't > think we need an additional note on this issue, but if many other > people want to note this issue explicitly, I think we can > add a short > note in the Security Considerations section. > > => I agree. In fact I can't see a reason to recommend > integrity protection > only when the source is site-local (i.e tunnel == external). > > Regards > > Francis.Dupont@enst-bretagne.fr > ------_=_NextPart_001_01C1D04D.E53B6A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: poposed changes to the scoping architecture draft

Yes,

I agree, this probably is the wrong ID to make the = note in. I'll see if  such a note is in the current revision of = the MIPv6 draft. That should be sufficient.

> -----Original Message-----
> From: Francis Dupont [mailto:Francis.Dupont@en= st-bretagne.fr]
> Sent: Wednesday, March 20, 2002 10:48 AM
> To: JINMEI Tatuya / ????
> Cc: Morrow, Glenn [RICH2:C330:EXCH]; = ipng@sunroof.eng.sun.com
> Subject: Re: poposed changes to the scoping = architecture draft
>
>
>  In your previous mail you wrote:
>
>    >>>>> On Tue, = 19 Mar 2002 22:53:22 -0600,
>    >>>>> = "Glenn Morrow" <gmorrow@nortelnetworks.com> = said:
>   
>    > Maybe I'm just paranoid = but does anyone think that it
> should be recommended
>    > that integrity = protection of some sort be done when a
> mobile uses a site
>    > local address as source = when a packet is tunneled to the
> home site?
>   
>    This can be an issue, but = this is the case for all type of
> tunneling,
>    that is, this is not specific = to mobile IPv6.  At this
> moment I don't
>    think we need an additional = note on this issue, but if many other
>    people want to note this = issue explicitly, I think we can
> add a short
>    note in the Security = Considerations section.
>   
> =3D> I agree. In fact I can't see a reason = to recommend
> integrity protection
> only when the source is site-local (i.e tunnel = =3D=3D external).
>
> Regards
>
> Francis.Dupont@enst-bretagne.fr
>

------_=_NextPart_001_01C1D04D.E53B6A20-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 13:57:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KLvLKL021873 for ; Wed, 20 Mar 2002 13:57:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KLvKJI021872 for ipng-dist; Wed, 20 Mar 2002 13:57:20 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KLvHKL021865 for ; Wed, 20 Mar 2002 13:57:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23287 for ; Wed, 20 Mar 2002 13:57:19 -0800 (PST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA23861 for ; Wed, 20 Mar 2002 14:57:18 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id WAA47586; Wed, 20 Mar 2002 22:57:07 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2KLv7W143646; Wed, 20 Mar 2002 22:57:07 +0100 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA75514 from ; Wed, 20 Mar 2002 22:57:04 +0100 Message-Id: <3C99059D.D59ACC2E@hursley.ibm.com> Date: Wed, 20 Mar 2002 22:56:45 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Keith Moore Cc: Pekka Nikander , ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2437 Interface Identifier References: <200203202011.g2KKBdt26928@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > > there has emerged a need to encode functional, security related > > semantics into IP addresses > > I strongly disagree. > > there has been a longstanding need to encode functional security > related semantics into IP packets. > > but the address is entirely the wrong place for these. > I must say I don't understand the reference to RFC2437... presumably you mean 2374, which will be obsoleted anyway. In which case, I violently agree with Keith. We've already overloaded IP addresses with two functions - locator and identifier. We've been rebuffing various suggestions for yet more overloading for years (the porno bit for example) and this is in the same category - not the right place to put a security hint. It's quite inappropriate to damage the opaqueness of a pure ID field in such a way. If a security hint is needed, it should be somewhere else. On a practical point, I don't see how this fits with the addressing architecture (draft-ietf-ipngwg-addr-arch-v3-07.txt) which requires that "For all unicast addresses, except those that start with binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." It also doesn't fit with the RFC 3041 privacy extensions. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 14:22:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KMMFKL021976 for ; Wed, 20 Mar 2002 14:22:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KMMFGQ021975 for ipng-dist; Wed, 20 Mar 2002 14:22:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KMMCKL021968 for ; Wed, 20 Mar 2002 14:22:12 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10190 for ; Wed, 20 Mar 2002 14:22:12 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA01135 for ; Wed, 20 Mar 2002 15:22:11 -0700 (MST) Received: from d2.nomadiclab.com (bastion [131.160.194.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 1A8F422E15; Thu, 21 Mar 2002 00:20:36 +0200 (EET) Received: from nomadiclab.com (localhost [127.0.0.1]) by d2.nomadiclab.com (Postfix) with ESMTP id BA7AABA03; Thu, 21 Mar 2002 00:22:03 +0200 (EET) Message-ID: <3C990BD8.6080105@nomadiclab.com> Date: Wed, 20 Mar 2002 16:23:20 -0600 From: Pekka Nikander User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020307 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter Cc: Keith Moore , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: <200203202011.g2KKBdt26928@astro.cs.utk.edu> <3C99059D.D59ACC2E@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > I must say I don't understand the reference to RFC2437... > presumably you mean 2374, which will be obsoleted anyway. 2437 was a mistake, pardon my poor sleep deprived brain. The subject line should now have the right reference. > In which case, I violently agree with Keith. We've already > overloaded IP addresses with two functions - locator and > identifier. We've been rebuffing various suggestions for > yet more overloading for years (the porno bit for example) and > this is in the same category - not the right place to put a security > hint. It's quite inappropriate to damage the opaqueness of a pure ID > field in such a way. If a security hint is needed, it should be somewhere > else. A security hint is needed. Please read the "bidding down" notes to see why. For reference, here are the URLs again: http://playground.sun.com/mobile-ip/WG-archive/frm05357.html http://www.piuha.net/~jarkko/publications/mipv6/Bidding_down.txt If you don't agree with the argumentation, please let us know, in detail, where you disagree. What comes to the method of passing the hint, I (and the whole design team) really wish the hint could be placed somewhere else. However, we just haven't been able to find such a way. We would be more than happy to use some other method, but we just haven't been able to find one, given the constraints. > On a practical point, I don't see how this fits with the addressing > architecture (draft-ietf-ipngwg-addr-arch-v3-07.txt) which requires > that "For all unicast addresses, except those that start with binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format." It also doesn't fit with > the RFC 3041 privacy extensions. I'll let Erik to address this one, my knowledge fails here. --Pekka -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 14:29:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KMTwKL022036 for ; Wed, 20 Mar 2002 14:29:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KMTwfD022035 for ipng-dist; Wed, 20 Mar 2002 14:29:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KMTtKL022028 for ; Wed, 20 Mar 2002 14:29:55 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA24482 for ; Wed, 20 Mar 2002 14:29:55 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA13897 for ; Wed, 20 Mar 2002 14:29:49 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2KMTmq32588; Thu, 21 Mar 2002 00:29:48 +0200 Date: Thu, 21 Mar 2002 00:29:47 +0200 (EET) From: Pekka Savola To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2437 Interface Identifier In-Reply-To: <3C99059D.D59ACC2E@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 20 Mar 2002, Brian E Carpenter wrote: [snip] > overloaded IP addresses with two functions - locator and > identifier. We've been rebuffing various suggestions for > yet more overloading for years (the porno bit for example) and [snip] Hmm.. interesting piece of history. Any references? :-) P.S. wouldn't at least 2 bits been necessary, for unrated, X, XX, and XXX-rated porn? :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 14:44:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KMiBKL022095 for ; Wed, 20 Mar 2002 14:44:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KMiBEw022094 for ipng-dist; Wed, 20 Mar 2002 14:44:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KMiAKL022087 for ; Wed, 20 Mar 2002 14:44:10 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2KMhCsl001836 for ; Wed, 20 Mar 2002 14:43:12 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g2KMhC4i001835 for ipng@sunroof.eng.sun.com; Wed, 20 Mar 2002 14:43:12 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KMcdKL022071 for ; Wed, 20 Mar 2002 14:38:39 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA03274 for ; Wed, 20 Mar 2002 14:38:40 -0800 (PST) Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09425 for ; Wed, 20 Mar 2002 15:38:39 -0700 (MST) Received: (from sob@localhost) by newdev.harvard.edu (8.10.2/8.10.2) id g2KMcS612720; Wed, 20 Mar 2002 17:38:28 -0500 (EST) Date: Wed, 20 Mar 2002 17:38:28 -0500 (EST) From: Scott Bradner Message-Id: <200203202238.g2KMcS612720@newdev.harvard.edu> To: brian@hursley.ibm.com, pekkas@netcore.fi Subject: Re: Allocating a bit in the RFC2437 Interface Identifier Cc: ipng@sunroof.eng.sun.com Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > yet more overloading for years (the porno bit for example) and > Hmm.. interesting piece of history. Any references? :-) one data point I was asked by some folk (who claimed to be technical) in the lobby of the court building where I was testifying in the communications decency act case to set aside a bit in the v6 address to indicate that the contents of the packet was unsuitable for someone under 18 Scott -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 20 15:18:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KNI0KL022269 for ; Wed, 20 Mar 2002 15:18:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KNI0Tp022268 for ipng-dist; Wed, 20 Mar 2002 15:18:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KNHsKL022261 for ; Wed, 20 Mar 2002 15:17:55 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2KNHlx21098; Thu, 21 Mar 2002 00:17:48 +0100 (MET) Date: Thu, 21 Mar 2002 00:17:39 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Allocating a bit in the RFC2437 Interface Identifier To: Brian E Carpenter Cc: Keith Moore , Pekka Nikander , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C99059D.D59ACC2E@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > In which case, I violently agree with Keith. We've already > overloaded IP addresses with two functions - locator and > identifier. We've been rebuffing various suggestions for > yet more overloading for years (the porno bit for example) and > this is in the same category - not the right place to put a security > hint. It's quite inappropriate to damage the opaqueness of a pure ID > field in such a way. If a security hint is needed, it should be somewhere > else. Three - not two. In addition to locator and identifier we also effectively encode how the interface ID part is allocated (by having the universal/local bit in there.) Pekka's proposal (that has been discussed in the mobile-ipv6 context) essentially extends the ability to encode how the interface ID has been allocated to carry additional information. Basically when the bit is set to say "don't use non-default semantics" it would involve some checks against the interface ID. It would be most useful if folks could read the URLs that Pekka pointed so that we can gain a better shared understanding of the security issues involved. > On a practical point, I don't see how this fits with the addressing > architecture (draft-ietf-ipngwg-addr-arch-v3-07.txt) which requires > that "For all unicast addresses, except those that start with binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format." It also doesn't fit with > the RFC 3041 privacy extensions. I sent an email to the ipng list on titled Reserving bits in RFC 2473 Interface IDs? on March 4th. Since the above comment seems to be about that email I'd appreciate if you could recast it as a comment against that email. 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 Wed Mar 20 15:19:56 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KNJtKL022325 for ; Wed, 20 Mar 2002 15:19:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KNJtqj022324 for ipng-dist; Wed, 20 Mar 2002 15:19:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KNJqKL022317 for ; Wed, 20 Mar 2002 15:19:52 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA01233 for ; Wed, 20 Mar 2002 15:19:53 -0800 (PST) Received: from keiichi01.osaka.iij.ad.jp (wireless-dhcp-186-126.ietf53.cw.net [166.63.186.126]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA02119 for ; Wed, 20 Mar 2002 16:19:52 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.6/8.11.6) with ESMTP id g2KNH7m00719; Thu, 21 Mar 2002 08:17:07 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Thu, 21 Mar 2002 08:17:06 +0900 (JST) Message-Id: <20020321.081706.552536904.keiichi@iij.ad.jp> To: Francis.Dupont@enst-bretagne.fr Cc: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <200203192221.g2JMLRg67744@givry.rennes.enst-bretagne.fr> References: <200203192221.g2JMLRg67744@givry.rennes.enst-bretagne.fr> X-Mailer: Mew version 3.0.55 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, From: Francis Dupont > > 1. revise the mobility section to clarify issues about using > site-local addresses with mobile IPv6: > > => I disagree with your solution because it takes more than a few line > to describe it (:-). > IMHO site-local addresses in a mobile IPv6 work well if only a > bidirectional tunnel is used between the mobile and its home agent. > Note there should be no penalty because by definition communications > in the same site are local, so the only difference with routing > optimization is the encapsulaion overhead. > Another important point is an equivalent way to describe this solution > is to say the bidirectional tunnel belongs to the home site. Are you saying that if we use a bi-directional tunneling, the off-site MN can comunicate with the CN that is in the home-site of the MN? If so, I disagree. Consider the following condition. site A (fec0:0:0:100::/64): a home site of the MN site B (fec0:0:0:100::/64): a foreign site. If the MN moves from the site A to site B, the MN cannot determine the direction to which it should send a packet destinated to fec0:0:0:100:1234:5678:9abc:def0. The destination address can be both on the site A and the site B. --- Keiichi SHIMA IIJ Research Laboratory 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 Wed Mar 20 15:39:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KNdQKL022396 for ; Wed, 20 Mar 2002 15:39:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KNdQ7T022395 for ipng-dist; Wed, 20 Mar 2002 15:39:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KNdNKL022388 for ; Wed, 20 Mar 2002 15:39:23 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA08053 for ; Wed, 20 Mar 2002 15:39:24 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29372 for ; Wed, 20 Mar 2002 15:39:26 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2KNdD227060; Thu, 21 Mar 2002 00:39:13 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id AAA20668; Thu, 21 Mar 2002 00:39:14 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2KNdDg72314; Thu, 21 Mar 2002 00:39:13 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203202339.g2KNdDg72314@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= cc: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-reply-to: Your message of Thu, 21 Mar 2002 08:17:06 +0900. <20020321.081706.552536904.keiichi@iij.ad.jp> Date: Thu, 21 Mar 2002 00:39:13 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Are you saying that if we use a bi-directional tunneling, the off-site MN can comunicate with the CN that is in the home-site of the MN? => exactly, this works as soon as the IPv6 stack supports multi-site as it should. If so, I disagree. Consider the following condition. site A (fec0:0:0:100::/64): a home site of the MN site B (fec0:0:0:100::/64): a foreign site. => please add zone IDs to scoped addresses. If the MN moves from the site A to site B, the MN cannot determine the direction to which it should send a packet destinated to fec0:0:0:100:1234:5678:9abc:def0. The destination address can be both on the site A and the site B. => Jinmei, can you explain the scoping architecture to your colleague? It seems I'll be impolite if I try to answer (:-). Regards Francis.Dupont@enst-bretagne.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 Wed Mar 20 15:51:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KNp7KL022427 for ; Wed, 20 Mar 2002 15:51:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2KNp7Pn022426 for ipng-dist; Wed, 20 Mar 2002 15:51:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2KNp3KL022419 for ; Wed, 20 Mar 2002 15:51:03 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12250 for ; Wed, 20 Mar 2002 15:51:05 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA15362 for ; Wed, 20 Mar 2002 16:51:04 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2KNowt27982; Wed, 20 Mar 2002 18:50:58 -0500 (EST) Message-Id: <200203202350.g2KNowt27982@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Nikander cc: Brian E Carpenter , Keith Moore , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier In-reply-to: (Your message of "Wed, 20 Mar 2002 16:23:20 CST.") <3C990BD8.6080105@nomadiclab.com> Date: Wed, 20 Mar 2002 18:50:58 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A security hint is needed. Please read the "bidding down" notes > to see why. For reference, here are the URLs again: > > http://playground.sun.com/mobile-ip/WG-archive/frm05357.html > http://www.piuha.net/~jarkko/publications/mipv6/Bidding_down.txt I'd have to have more background to be sure I understand what's being discussed. But the bidding down argument is familiar from other contexts - for instance, security negotiation in SMTP, security negotation by failing over from an SSL port to another port that doesn't use authentication, indicating security by using an "s" suffix on a URL type. From the results of those discussions, I'm highly doubtful that allocating an address bit fixes the problem. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 17:09:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L19kKL022729 for ; Wed, 20 Mar 2002 17:09:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2L19kPI022728 for ipng-dist; Wed, 20 Mar 2002 17:09:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L19hKL022721 for ; Wed, 20 Mar 2002 17:09:43 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA05358 for ; Wed, 20 Mar 2002 17:09:45 -0800 (PST) From: jarno.rajahalme@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA17866 for ; Wed, 20 Mar 2002 18:09:25 -0700 (MST) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2L19b114511 for ; Thu, 21 Mar 2002 03:09:37 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 21 Mar 2002 03:09:24 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 21 Mar 2002 03:09:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C1D075.0980937A" Subject: New WG flow label draft (-01) Date: Thu, 21 Mar 2002 03:09:23 +0200 Message-ID: <009CA59D1752DD448E07F8EB2F911757D30F1A@esebe004.NOE.Nokia.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: New WG flow label draft (-01) Thread-Index: AcHQdR5fvODmz/2PTSuE0zx6MyZQNg== To: Cc: X-OriginalArrivalTime: 21 Mar 2002 01:09:23.0631 (UTC) FILETIME=[09BE6BF0:01C1D075] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1D075.0980937A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We had some face-to-face time on Tuesday, which resulted into a new = revision of the flow label draft. The presentation on Thursday will be = based on this. Jarno <>=20 ------_=_NextPart_001_01C1D075.0980937A Content-Type: text/plain; name="draft-ietf-ipv6-flow-label-01.txt" Content-Transfer-Encoding: base64 Content-Description: draft-ietf-ipv6-flow-label-01.txt Content-Disposition: attachment; filename="draft-ietf-ipv6-flow-label-01.txt" SVB2NiBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgSi4gUmFqYWhhbG1lDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTm9raWENCjxkcmFmdC1pZXRmLWlwdjYtZmxvdy1s YWJlbC0wMS50eHQ+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBLiBDb250YQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBU cmFuc3dpdGNoDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBCLiBDYXJwZW50ZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElCTQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBEZWVy aW5nDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgQ2lzY28NCkV4cGlyZXM6IFNlcHRlbWJlciAyMDAyICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAwMg0KDQoNCiAgICAgICAgICAgICAg ICAgICAgIElQdjYgRmxvdyBMYWJlbCBTcGVjaWZpY2F0aW9uDQogICAgICAgICAgICAgICAgICAg ZHJhZnQtaWV0Zi1pcHY2LWZsb3ctbGFiZWwtMDEudHh0DQoNCg0KU3RhdHVzIG9mIHRoaXMgbWVt bw0KDQogICBUaGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBzdWJqZWN0 IHRvIGFsbCBwcm92aXNpb25zDQogICBvZiBTZWN0aW9uIDEwIG9mIFJGQzIwMjYuDQoNCiAgIElu dGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2lu ZWVyaW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcg Z3JvdXBzLiBOb3RlIHRoYXQgb3RoZXINCiAgIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIHdv cmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4NCg0KICAgSW50ZXJuZXQtRHJhZnRz IGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzDQog ICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9j dW1lbnRzIGF0IGFueQ0KICAgdGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJu ZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQ0KICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVy IHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIg0KDQogICBUaGUgbGlzdCBvZiBjdXJyZW50IElu dGVybmV0LURyYWZ0cyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv MWlkLWFic3RyYWN0cy5odG1sDQoNCiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRv dyBEaXJlY3RvcmllcyBjYW4gYmUgYWNjZXNzZWQgYXQNCiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcv c2hhZG93Lmh0bWwNCg0KDQpBYnN0cmFjdA0KDQogICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB0 aGUgdXNhZ2Ugb2YgdGhlIElQdjYgRmxvdyBMYWJlbCBmaWVsZCwgdGhlDQogICByZXF1aXJlbWVu dHMgZm9yIElQdjYgc291cmNlIG5vZGVzIGxhYmVsaW5nIGZsb3dzLCBhbmQgdGhlDQogICByZXF1 aXJlbWVudHMgZm9yIGZsb3cgc3RhdGUgZXN0YWJsaXNobWVudCBtZXRob2RzLg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpSYWphaGFsbWUsIGV0IGFsLiAgICAgICBFeHBpcmVzOiBT ZXB0ZW1iZXIgMjAwMiAgICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCklOVEVSTkVULURSQUZU ICAgICBkcmFmdC1pZXRmLWlwdjYtZmxvdy1sYWJlbC0wMS50eHQgICAgICAgICAgTWFyY2ggMjAw Mg0KDQoNCg0KMS4gIFRlcm1pbm9sb2d5IGFuZCBEZWZpbml0aW9ucw0KDQogICBDbGFzc2lmaWVy ICAgICAgICAgICAgIEFuIElQIGxheWVyIGVudGl0eSB0aGF0IHNlbGVjdHMgcGFja2V0cyBiYXNl ZA0KICAgICAgICAgICAgICAgICAgICAgICAgICBvbiB0aGUgY29udGVudCBvZiBwYWNrZXQgaGVh ZGVycyBhY2NvcmRpbmcgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAgZGVmaW5lZCBydWxl cy4NCg0KICAgRmxvdyAgICAgICAgICAgICAgICAgICBBIHNlcXVlbmNlIG9mIHJlbGF0ZWQgcGFj a2V0cyBzZW50IGZyb20gYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBzb3VyY2UgdG8gYSB1 bmljYXN0LCBhbnljYXN0LCBvciBtdWx0aWNhc3QNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ZGVzdGluYXRpb24uIEEgZmxvdyBjb3VsZCBjb25zaXN0IG9mIGFsbA0KICAgICAgICAgICAgICAg ICAgICAgICAgICBwYWNrZXRzIGluIGEgc3BlY2lmaWMgdHJhbnNwb3J0IGNvbm5lY3Rpb24sIG9y DQogICAgICAgICAgICAgICAgICAgICAgICAgIGEgbWVkaWEgc3RyZWFtLiBIb3dldmVyLCBhIGZs b3cgaXMgbm90DQogICAgICAgICAgICAgICAgICAgICAgICAgIG5lY2Vzc2FyaWx5IDE6MSBtYXBw ZWQgdG8gYSB0cmFuc3BvcnQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgY29ubmVjdGlvbi4N Cg0KICAgRmxvdyBzdGF0ZSAgICAgICAgICAgICBUaGUgaW5mb3JtYXRpb24gc3RvcmVkIGluIGFu IElQIG5vZGUgZHJpdmluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgZmxvdyBjbGFz c2lmaWNhdGlvbiBhbmQgdGhlIGZsb3ctc3BlY2lmaWMNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgdHJlYXRtZW50LiBUaGUgcmVxdWlyZWQgaW5mb3JtYXRpb24gaXMNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgc3BlY2lmaWVkIGJ5IHRoZSBtZXRob2QgZGVmaW5pbmcgdGhlIGZsb3ctDQog ICAgICAgICAgICAgICAgICAgICAgICAgIHNwZWNpZmljIHRyZWF0bWVudC4NCg0KICAgRmxvdyBz dGF0ZSAgICAgICAgICAgICBBIGNvbnRyb2wgbWVjaGFuaXNtIHVzZWQgdG8gc2V0IHVwIHRoZSBm bG93DQogICBlc3RhYmxpc2htZW50IG1ldGhvZCAgIHN0YXRlLiBBIGZsb3cgc3RhdGUgZXN0YWJs aXNobWVudCBtZXRob2QgY2FuDQogICAgICAgICAgICAgICAgICAgICAgICAgIGJlIGVpdGhlcg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAtIER5bmFtaWMsIHVuZGVyIHNvdXJjZSBub2RlIGNv bnRyb2wgKGUuZy4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgUlNWUCksDQogICAgICAgICAg ICAgICAgICAgICAgICAgIC0gUXVhc2ktZHluYW1pYywgdW5kZXIgbmV0d29yayBtYW5hZ2VtZW50 DQogICAgICAgICAgICAgICAgICAgICAgICAgIGNvbnRyb2wsIG9yDQogICAgICAgICAgICAgICAg ICAgICAgICAgIC0gU3RhdGljLCB0aHJvdWdoIG1hbnVhbCBjb25maWd1cmF0aW9uLg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAtIEFsZ29yaXRobWljIChlLmcuIGxvYWQtc3ByZWFkaW5nKQ0K DQoNCg0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJT SEFMTCIsICJTSEFMTCBOT1QiLA0KICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVO REVEIiwgIk1BWSIsIGFuZCAiT1BUSU9OQUwiIGluIHRoaXMNCiAgIGRvY3VtZW50IGFyZSB0byBi ZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDIDIxMTkuDQoNCg0KMi4gIEludHJvZHVj dGlvbg0KDQogICBBIGZsb3cgaXMgYSBzZXF1ZW5jZSBvZiByZWxhdGVkIHBhY2tldHMgc2VudCBm cm9tIGEgc291cmNlIHRvIGENCiAgIHVuaWNhc3QsIGFueWNhc3QsIG9yIG11bHRpY2FzdCBkZXN0 aW5hdGlvbi4gVG8gZW5hYmxlIHNwZWNpZmljDQogICBwcm9jZXNzaW5nIGZvciB0aGUgZmxvdywg ZmxvdyBzdGF0ZSBuZWVkcyB0byBiZSBlc3RhYmxpc2hlZCBvbiB0aGUNCiAgIG5vZGVzIHByb3Zp ZGluZyB0aGUgZmxvdy1zcGVjaWZpYyB0cmVhdG1lbnQuIFRoZSBmbG93IHN0YXRlIGRlZmluZXMN CiAgIHdoYXQga2luZCBvZiB0cmVhdG1lbnQgc2hvdWxkIGJlIHByb3ZpZGVkLCBhbmQgaG93IHRv IGNsYXNzaWZ5IHRoZQ0KICAgcGFja2V0cyB0byB0aGUgZmxvdy4NCg0KICAgVHJhZGl0aW9uYWxs eSwgZmxvdyBjbGFzc2lmaWVycyBoYXZlIGJlZW4gYmFzZWQgb24gdGhlIDUtdHVwbGUgb2YgdGhl DQogICBTb3VyY2UgYW5kIERlc3RpbmF0aW9uIEFkZHJlc3NlcywgcG9ydHMgYW5kIHRoZSB0cmFu c3BvcnQgcHJvdG9jb2wNCiAgIHR5cGUuIEhvd2V2ZXIsIHRoZXNlIGZpZWxkcyBtYXkgYmUgdW5h dmFpbGFibGUgZHVlIHRvIGVpdGhlcg0KICAgZnJhZ21lbnRhdGlvbiBvciBlbmNyeXB0aW9uLCBv ciBsb2NhdGluZyB0aGVtIHBhc3QgYSBjaGFpbiBvZiBJUHY2DQogICBvcHRpb24gaGVhZGVycyBt YXkgYmUgaW5lZmZpY2llbnQuIEFkZGl0aW9uYWxseSwgZGVwZW5kZW5jZSBvbiBoaWdoZXINCg0K DQpSYWphaGFsbWUsIGV0IGFsLiAgICAgICBFeHBpcmVzOiBTZXB0ZW1iZXIgMjAwMiAgICAgICAg ICAgICAgICAgW1BhZ2UgMl0NCgwNCklOVEVSTkVULURSQUZUICAgICBkcmFmdC1pZXRmLWlwdjYt Zmxvdy1sYWJlbC0wMS50eHQgICAgICAgICAgTWFyY2ggMjAwMg0KDQoNCiAgIGxheWVyIGhlYWRl cnMgYnkgdGhlIElQIGxheWVyIHJlcHJlc2VudHMgYSBsYXllciB2aW9sYXRpb24sIHBvc3NpYmx5 DQogICBoaW5kZXJpbmcgdGhlIGludHJvZHVjdGlvbiBvZiBuZXcgdHJhbnNwb3J0IHByb3RvY29s cy4NCg0KICAgVGhlIDMtdHVwbGUgb2YgdGhlIEZsb3cgTGFiZWwgYW5kIHRoZSBTb3VyY2UgYW5k IERlc3RpbmF0aW9uIEFkZHJlc3MNCiAgIGZpZWxkcyBlbmFibGVzIGVmZmljaWVudCBJUHY2IGZs b3cgY2xhc3NpZmljYXRpb24sIHdoZXJlIG9ubHkgSVB2Ng0KICAgbWFpbiBoZWFkZXIgZmllbGRz IGluIGZpeGVkIHBvc2l0aW9ucyBhcmUgdXNlZC4gVGhlIHNwZWNpZmljYXRpb24gb2YNCiAgIHRo ZSBJUHY2IEZsb3cgTGFiZWwgZmllbGQgaXMgZ2l2ZW4gaW4gc2VjdGlvbiAzIGJlbG93Lg0KDQog ICBUaGUgbWluaW11bSBsZXZlbCBvZiBJUHY2IGZsb3cgc3VwcG9ydCBjb25zaXN0cyBvZiBsYWJl bGluZyB0aGUNCiAgIGZsb3dzLiBJUHY2IHNvdXJjZSBub2RlcyBjYW4gbGFiZWwga25vd24gZmxv d3MgKGUuZy4gVENQIGNvbm5lY3Rpb25zLA0KICAgUlRQIHN0cmVhbXMpLCBldmVuIGlmIHRoZSBu b2RlIGl0c2VsZiB3b3VsZCBub3QgcmVxdWlyZSBhbnkgZmxvdy0NCiAgIHNwZWNpZmljIHRyZWF0 bWVudC4gRG9pbmcgdGhpcyBlbmFibGVzIGUuZy4gcmVjZWl2ZXIgb3JpZW50ZWQNCiAgIHJlc291 cmNlIHJlc2VydmF0aW9ucyBbUlNWUF0uIFJlcXVpcmVtZW50cyBmb3IgZmxvdyBsYWJlbGluZyBh cmUNCiAgIGdpdmVuIGluIHNlY3Rpb24gNC4NCg0KICAgU3BlY2lmaWMgZmxvdyBzdGF0ZSBlc3Rh Ymxpc2htZW50IG1ldGhvZHMgYW5kIHRoZSByZWxhdGVkIHNlcnZpY2UNCiAgIG1vZGVscyBhcmUg b3V0IG9mIHNjb3BlIGZvciB0aGlzIHNwZWNpZmljYXRpb24sIGJ1dCB0aGUgZ2VuZXJpYw0KICAg cmVxdWlyZW1lbnRzIGVuYWJsaW5nIGNvLWV4aXN0ZW5jZSBvZiBkaWZmZXJlbnQgbWV0aG9kcyBp biBJUHY2IG5vZGVzDQogICBhcmUgc2V0IGZvcnRoIGluIHNlY3Rpb24gNS4NCg0KDQozLiAgSVB2 NiBGbG93IExhYmVsIFNwZWNpZmljYXRpb24NCg0KICAgVGhlIDIwLWJpdCBGbG93IExhYmVsIGZp ZWxkIGluIHRoZSBJUHY2IGhlYWRlciBTSE9VTEQgYmUgdXNlZCBieSBhDQogICBzb3VyY2UgdG8g bGFiZWwgc2VxdWVuY2VzIG9mIHJlbGF0ZWQgcGFja2V0cyBzZW50IHRvIGEgc3BlY2lmaWMNCiAg IHVuaWNhc3QsIGFueWNhc3QsIG9yIG11bHRpY2FzdCBkZXN0aW5hdGlvbi4gQSBub24temVybyBG bG93IExhYmVsDQogICBpbmRpY2F0ZXMgdGhhdCB0aGUgSVB2NiBwYWNrZXQgaXMgbGFiZWxlZC4g SVB2NiBub2RlcyByZWNlaXZpbmcgYQ0KICAgbGFiZWxlZCBJUHY2IHBhY2tldCBjYW4gdXNlIHRo ZSBGbG93IExhYmVsLCBhbmQgU291cmNlIGFuZA0KICAgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVs ZHMgdG8gY2xhc3NpZnkgdGhlIHBhY2tldCB0byBhIGNlcnRhaW4gZmxvdy4NCiAgIFRoZSBwYWNr ZXQgTUFZIGJlIGdpdmVuIHNvbWUgZmxvdy1zcGVjaWZpYyB0cmVhdG1lbnQgYmFzZWQgb24gdGhl DQogICBmbG93IHN0YXRlIGVzdGFibGlzaGVkIG9uIGEgc2V0IG9mIElQdjYgbm9kZXMuIFRoZSBu YXR1cmUgb2YgdGhlDQogICBzcGVjaWZpYyB0cmVhdG1lbnQgYW5kIHRoZSBtZXRob2RzIGZvciB0 aGUgZmxvdyBzdGF0ZSBlc3RhYmxpc2htZW50DQogICBhcmUgb3V0IG9mIHNjb3BlIGZvciB0aGlz IHNwZWNpZmljYXRpb24uDQoNCiAgIFRoZSBJUHY2IG5vZGUgYXNzaWduaW5nIGEgRmxvdyBMYWJl bCB2YWx1ZSBNVVNUIGtlZXAgdHJhY2sgb2YgYWxsIHRoZQ0KICAgRmxvdyBMYWJlbCwgU291cmNl IEFkZHJlc3MsIGFuZCBEZXN0aW5hdGlvbiBBZGRyZXNzIHRyaXBsZXRzIGluIHVzZQ0KICAgdG8g YXZvaWQgY3JlYXRpbmcgY29uZmxpY3RpbmcgY2xhc3NpZmllcnMuDQoNCiAgIFRoZSBGbG93IExh YmVsIHZhbHVlIHNldCBieSB0aGUgc291cmNlIE1VU1QgYmUgZGVsaXZlcmVkIHVuY2hhbmdlZCB0 bw0KICAgdGhlIGRlc3RpbmF0aW9uKHMpLg0KDQogICBJUHY2IG5vZGVzIE1VU1QgTk9UIGFzc3Vt ZSBhbnkgc3BlY2lmaWMgcHJvcGVydHkgb24gdGhlIEZsb3cgTGFiZWwNCiAgIHZhbHVlcyBhc3Np Z25lZCBieSBzb3VyY2Ugbm9kZXMuIFJvdXRlciBwZXJmb3JtYW5jZSBTSE9VTEQgTk9UIGJlDQog ICBkZXBlbmRlbnQgb24gdGhlIGRpc3RyaWJ1dGlvbiBvZiB0aGUgRmxvdyBMYWJlbCB2YWx1ZXMu IEVzcGVjaWFsbHksDQogICB0aGUgRmxvdyBMYWJlbCBiaXRzIGFsb25lIG1ha2UgcG9vciBtYXRl cmlhbCBmb3IgYSBoYXNoIGtleS4NCg0KICAgSWYgYW4gSVB2NiBub2RlIGlzIG5vdCBwcm92aWRp bmcgZmxvdy1zcGVjaWZpYyB0cmVhdG1lbnQsIGl0IE1VU1QNCiAgIGlnbm9yZSB0aGUgZmllbGQg d2hlbiByZWNlaXZpbmcgb3IgZm9yd2FyZGluZyBhIHBhY2tldC4NCg0KDQoNCg0KDQoNClJhamFo YWxtZSwgZXQgYWwuICAgICAgIEV4cGlyZXM6IFNlcHRlbWJlciAyMDAyICAgICAgICAgICAgICAg ICBbUGFnZSAzXQ0KDA0KSU5URVJORVQtRFJBRlQgICAgIGRyYWZ0LWlldGYtaXB2Ni1mbG93LWxh YmVsLTAxLnR4dCAgICAgICAgICBNYXJjaCAyMDAyDQoNCg0KNC4gIEZsb3cgTGFiZWxpbmcgUmVx dWlyZW1lbnRzDQoNCiAgIFRvIHN1cHBvcnQgZS5nLiByZWNlaXZlciBvcmllbnRlZCBmbG93IHN0 YXRlIGVzdGFibGlzaG1lbnQsIElQdjYNCiAgIHNvdXJjZSBub2RlcyBTSE9VTEQgbGFiZWwga25v d24gZmxvd3MuIEtub3duIGZsb3dzIG1heSBpbmNsdWRlIGUuZy4NCiAgIHRyYW5zcG9ydCBjb25u ZWN0aW9ucywgb3IgbWVkaWEgc3RyZWFtcy4NCg0KICAgVGhlIElQdjYgc291cmNlIG5vZGUgTVVT VCBwcm92aWRlIGEgZmFjaWxpdHkgZm9yIHZlcmlmeWluZyBhbmQNCiAgIGFzc2lnbmluZyBuZXcg RmxvdyBMYWJlbCB2YWx1ZXMsIGFuZCBmb3Igc3RvcmluZyB0aGUgRmxvdyBMYWJlbCwNCiAgIFNv dXJjZSBBZGRyZXNzLCBEZXN0aW5hdGlvbiBBZGRyZXNzIHRyaXBsZXRzIGN1cnJlbnRseSBpbiB1 c2UuIFRoZQ0KICAgZmFjaWxpdHkgTVVTVCBiZSB1c2VkIHdoZW5ldmVyIGEgbGFiZWwgbmVlZHMg dG8gYmUgYXNzaWduZWQgZm9yIGEgbmV3DQogICBmbG93LiBUaGUgZmFjaWxpdHkgTVVTVCBwcm92 aWRlIGEgcHJvZ3JhbW1pbmcgaW50ZXJmYWNlIHdpdGggYXQgbGVhc3QNCiAgIHRocmVlIGZ1bmN0 aW9uczoNCg0KICAgMSkgdG8gYXNzaWduIGFueSBGbG93IExhYmVsIHZhbHVlIGZvciBhIG5ldyBm bG93DQoNCiAgIDIpIHRvIGFzc2lnbiBhIHNwZWNpZmljIEZsb3cgTGFiZWwgZm9yIGEgbmV3IGZs b3csIGFuZA0KDQogICAzKSB0byBmcmVlIHRoZSBGbG93IExhYmVsIHZhbHVlIG9mIGEgc3BlY2lm aWMgZmxvdy4NCg0KICAgVGhlIGludGVyZmFjZSBkZWZpbml0aW9uIGlzIGJleW9uZCB0aGUgc2Nv cGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgRmxvdyBMYWJlbCB2YWx1ZXMgZm9yIGZsb3dzIE1V U1QgYmUgaW5jbHVkZWQgYWxvbmcgd2l0aCB0aGUgU291cmNlDQogICBhbmQgRGVzdGluYXRpb24g YWRkcmVzc2VzIGFzIHBhcnQgb2YgYW55IGZsb3cgcmVsYXRlZCBzaWduYWxpbmcNCiAgIGRlYWxp bmcgd2l0aCB0aGUgZmxvdywgZS5nLiB0cmFuc3BvcnQgbGF5ZXIgY29ubmVjdGlvbiBzZXQgdXAs IFJTVlANCiAgIGZvciByZXNvdXJjZSByZXNlcnZhdGlvbiwgb3IgU0RQIGZvciBtZWRpYSBzZXNz aW9uIHBhcmFtZXRlcnMuDQoNCiAgIFdpdGggW1JTVlBdIG9yIFtTRFBdIGVpdGhlciB0aGUgc291 cmNlIG9yIHRoZSBkZXN0aW5hdGlvbiBvZiB0aGUgZmxvdw0KICAgY291bGQgaGF2ZSBhIHByZWZl cmVuY2UgZm9yIHRoZSBGbG93IExhYmVsIHZhbHVlIHRvIGJlIHVzZWQuIEZvcg0KICAgZXhhbXBs ZSwgYSBtdWx0aWNhc3QgZGVzdGluYXRpb24gY291bGQgcmVxdWlyZSBhbGwgdGhlIHNvdXJjZXMg dG8gdXNlDQogICB0aGUgc2FtZSBGbG93IExhYmVsIHZhbHVlIGluIG9yZGVyIHRvIGNvbGxhcHNl IHRoZSBjbGFzc2lmaWVyIHN0YXRlDQogICB0byBhIHNpbmdsZSBmbG93IHN0YXRlIGVudHJ5LCBp bnN0ZWFkIG9mIGhhdmluZyBzZXBhcmF0ZSBmbG93IHN0YXRlDQogICBmb3IgZWFjaCBzb3VyY2Ug KHJlZi4gdGhlIFdpbGRjYXJkLUZpbHRlciByZXNlcnZhdGlvbiBzdHlsZSBpbg0KICAgW1JTVlBd KS4gVGhlcmVmb3JlIHRoZSBzb3VyY2UgU0hPVUxEIGhvbm9yIHRoZSBkZXN0aW5hdGlvbidzIHJl cXVlc3QNCiAgIHRvIG1hcmsgdGhlIHBhY2tldHMgd2l0aCB0aGUgRmxvdyBMYWJlbCB2YWx1ZSBz cGVjaWZpZWQuDQoNCg0KNS4gIEZsb3cgU3RhdGUgRXN0YWJsaXNobWVudCBSZXF1aXJlbWVudHMN Cg0KICAgVG8gZW5hYmxlIGZsb3ctc3BlY2lmaWMgdHJlYXRtZW50LCBmbG93IHN0YXRlIG5lZWRz IHRvIGJlIGVzdGFibGlzaGVkDQogICBvbiBhbGwgb3IgYSBzdWJzZXQgb2YgdGhlIElQdjYgbm9k ZXMgb24gdGhlIHBhdGggZnJvbSB0aGUgc291cmNlIHRvDQogICB0aGUgZGVzdGluYXRpb24ocyku IFRoZSBtZXRob2RzIGZvciB0aGUgc3RhdGUgZXN0YWJsaXNobWVudCwgYXMgd2VsbA0KICAgYXMg dGhlIG1vZGVscyBmb3IgZmxvdy1zcGVjaWZpYyB0cmVhdG1lbnQgYXJlIGRlZmluZWQgaW4gc2Vw YXJhdGUNCiAgIHNwZWNpZmljYXRpb25zLg0KDQogICBUbyBlbmFibGUgY28tZXhpc3RlbmNlIG9m IGRpZmZlcmVudCBtZXRob2RzIGluIElQdjYgbm9kZXMsIHRoZQ0KICAgbWV0aG9kcyBNVVNUIG1l ZXQgdGhlIGZvbGxvd2luZyBiYXNpYyByZXF1aXJlbWVudHM6DQoNCiAgICgxKSAgQSBwYWNrZXQg aXMgY2xhc3NpZmllZCB1bmFtYmlndW91c2x5IHRvIGEgZmxvdyBvbiB0aGUgYmFzaXMgb2YNCiAg ICAgICAgdGhlIEZsb3cgTGFiZWwsIGFuZCB0aGUgU291cmNlIGFuZCBEZXN0aW5hdGlvbiBBZGRy ZXNzIGZpZWxkcy4NCiAgICAgICAgRGVwZW5kaW5nIG9uIHRoZSBtZXRob2Qgc2VtYW50aWNzLCBt dWx0aXBsZSBzdWNoIHRyaXBsZXRzIE1BWQ0KICAgICAgICBpZGVudGlmeSB0aGUgc2FtZSBmbG93 IHN0YXRlIChzZWUgdGhlIFJTVlAgV2lsZGNhcmQtRmlsdGVyDQogICAgICAgIGV4YW1wbGUgaW4g c2VjdGlvbiA0IGFib3ZlKS4gVXNhZ2Ugb2YgYW55IGFkZGl0aW9uYWwgaGVhZGVyDQoNCg0KUmFq YWhhbG1lLCBldCBhbC4gICAgICAgRXhwaXJlczogU2VwdGVtYmVyIDIwMDIgICAgICAgICAgICAg ICAgIFtQYWdlIDRdDQoMDQpJTlRFUk5FVC1EUkFGVCAgICAgZHJhZnQtaWV0Zi1pcHY2LWZsb3ct bGFiZWwtMDEudHh0ICAgICAgICAgIE1hcmNoIDIwMDINCg0KDQogICAgICAgIGZpZWxkcyBmb3Ig ZmxvdyBjbGFzc2lmaWNhdGlvbiBpcyBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoaXMNCiAgICAgICAg c3BlY2lmaWNhdGlvbi4NCg0KICAgKDIpICBUaGUgSVB2NiBub2RlIGZhY2lsaXR5IGtlZXBpbmcg dHJhY2sgb2YgdGhlIEZsb3cgTGFiZWwsIFNvdXJjZQ0KICAgICAgICBBZGRyZXNzLCBEZXN0aW5h dGlvbiBBZGRyZXNzIHRyaXBsZXRzIE1VU1QgYmUgdXRpbGl6ZWQgd2hlbg0KICAgICAgICBhc3Np Z25pbmcgRmxvdyBMYWJlbCB2YWx1ZXMgdG8gbmV3IGZsb3dzIChzZWUgc2VjdGlvbiA0IGFib3Zl KS4NCg0KICAgKDMpICBUaGUgRmxvdyBMYWJlbCB2YWx1ZSAwIGlzIHJlc2VydmVkIGZvciBub24t bGFiZWxlZCBwYWNrZXRzLg0KDQogICAoNCkgIFRoZSBtZXRob2QgTVVTVCBwcm92aWRlIHRoZSBt ZWFucyBmb3IgZmxvdyBzdGF0ZSBjbGVhbi11cCBmcm9tDQogICAgICAgIHRoZSBJUHY2IG5vZGVz IHByb3ZpZGluZyB0aGUgZmxvdy1zcGVjaWZpYyB0cmVhdG1lbnQuIEJvdGggc29mdC0NCiAgICAg ICAgYW5kIGhhcmQtc3RhdGUgbWV0aG9kcyBhcmUgcG9zc2libGUuDQoNCiAgICg1KSAgVGhlIG1l dGhvZCBNVVNUIHByb3ZpZGUgdGhlIG1lYW5zIGZvciBhbiBJUHY2IG5vZGUgdG8gcmV0dXJuIGFu DQogICAgICAgIGluZGljYXRpb24sIGlmIHRoZSByZXF1ZXN0ZWQgZmxvdyBzdGF0ZSBjYW5ub3Qg YmUgc3VwcG9ydGVkLg0KDQogICAoNikgIEZsb3cgc3RhdGUgZXN0YWJsaXNobWVudCBtZXRob2Rz IFNIT1VMRCBpbmNsdWRlIHRoZSBNb2JpbGUgSVANCiAgICAgICAgSG9tZSBBZGRyZXNzZXMgb2Yg dGhlIHNvdXJjZSBhbmQgdGhlIGRlc3RpbmF0aW9uIGluIHRoZSBzdGF0ZQ0KICAgICAgICBlc3Rh Ymxpc2htZW50IHByb2Nlc3MgaW4gYWRkaXRpb24gdG8gdGhlIENhcmUtb2YgQWRkcmVzc2VzLCBp Zg0KICAgICAgICBhdmFpbGFibGUuIFRoaXMgZW5hYmxlcyBhdm9pZGluZyBzdGF0ZSBkdXBsaWNh dGlvbiBvbiBmaXhlZA0KICAgICAgICBwb3J0aW9ucyBvZiB0aGUgcGF0aCB3aGVuIGVpdGhlciBl bmQgY2hhbmdlcyBpdHMgQ2FyZS1vZg0KICAgICAgICBBZGRyZXNzLg0KDQoNClNlY3VyaXR5IENv bnNpZGVyYXRpb25zDQoNCiAgIEFueXRoaW5nIHRoYXQgZmFjaWxpdGF0ZXMgZmxvdyBjbGFzc2lm aWNhdGlvbiBhbHNvIGluY3JlYXNlcyB0aGUNCiAgIHZ1bG5lcmFiaWxpdHkgdG8gdHJhZmZpYyBh bmFseXNpcy4NCg0KICAgVGhlIHVzZSBvZiB0aGUgRmxvdyBMYWJlbCBmaWVsZCBpbiBnZW5lcmFs IGVuYWJsZXMgZmxvdw0KICAgY2xhc3NpZmljYXRpb24gYWxzbyBpbiB0aGUgcHJlc2VuY2Ugb2Yg RVNQIGVuY3J5cHRpb24gb2YgSVB2Ng0KICAgcGF5bG9hZHMuIFRoaXMgYWxsb3dzIHRoZSB0cmFu c3BvcnQgaGVhZGVyIHZhbHVlcyB0byByZW1haW4NCiAgIGNvbmZpZGVudGlhbCwgd2hpY2ggbWF5 IGxlc3NlbiB0aGUgcG9zc2liaWxpdGllcyBmb3Igc29tZSBmb3JtcyBvZg0KICAgdHJhZmZpYyBh bmFseXNpcy4NCg0KDQpJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlv biBkb2VzIG5vdCBkZWZpbmUgYW55IHdlbGwta25vd24gdmFsdWVzLg0KDQoNCkFja25vd2xlZGdl bWVudHMNCg0KICAgVGhlIGRpc2N1c3Npb24gb24gdGhlIHRvcGljIGluIHRoZSBJUHY2IFdHIG1h aWxpbmcgbGlzdCBoYXMgYmVlbg0KICAgaW5zdHJ1bWVudGFsIGZvciB0aGUgZGVmaW5pdGlvbiBv ZiB0aGlzIHNwZWNpZmljYXRpb24uIFRoZSBhdXRob3JzDQogICB3YW50IHRvIHRoYW5rIFN0ZXZl IEJsYWtlLCBKaW0gQm91bmQsIEZyYW5jaXMgRHVwb250LCBSb2JlcnQgRWx6LA0KICAgVG9ueSBI YWluLCBCb2IgSGluZGVuLCBDaHJpc3RpYW4gSHVpdGVtYSwgRnJhbmsgS2FzdGVuaG9seiwgQ2hh cmxlcw0KICAgUGVya2lucywgSGVzaGFtIFNvbGltYW4sIE1pY2hhZWwgVGhvbWFzLCBhbmQgTWFy Z2FyZXQgV2Fzc2VybWFuIGZvcg0KICAgdGhlaXIgY29udHJpYnV0aW9ucy4NCg0KDQoNCg0KDQpS YWphaGFsbWUsIGV0IGFsLiAgICAgICBFeHBpcmVzOiBTZXB0ZW1iZXIgMjAwMiAgICAgICAgICAg ICAgICAgW1BhZ2UgNV0NCgwNCklOVEVSTkVULURSQUZUICAgICBkcmFmdC1pZXRmLWlwdjYtZmxv dy1sYWJlbC0wMS50eHQgICAgICAgICAgTWFyY2ggMjAwMg0KDQoNCk5vcm1hdGl2ZSBSZWZlcmVu Y2VzDQoNCiAgIFtJUHY2XSAgICAgIFMuIERlZXJpbmcsIFIuIEhpbmRlbiwgIkludGVybmV0IFBy b3RvY29sIFZlcnNpb24gNg0KICAgICAgICAgICAgICAgU3BlY2lmaWNhdGlvbiIsIFJGQyAyNDYw LCBEZWNlbWJlciAxOTk4Lg0KDQoNCkluZm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JhamFo YWxtZV0gSi4gUmFqYWhhbG1lLCBBLiBDb250YSwgIkFuIElQdjYgRmxvdyBMYWJlbCBTcGVjaWZp Y2F0aW9uDQogICAgICAgICAgICAgICBQcm9wb3NhbCIsIEludGVybmV0IERyYWZ0IDxkcmFmdC1y YWphaGFsbWUtaXB2Ni1mbG93LQ0KICAgICAgICAgICAgICAgbGFiZWwtMDAudHh0PiwgTm92ZW1i ZXIgMjAwMSwgZXhwaXJlcyBNYXkgMjAwMiwgV29yayBpbg0KICAgICAgICAgICAgICAgcHJvZ3Jl c3MuDQoNCiAgIFtSRkMxODA5XSAgIEMuIFBhcnRyaWRnZSwgIlVzaW5nIHRoZSBGbG93IExhYmVs IEZpZWxkIGluIElQdjYiLCBSRkMNCiAgICAgICAgICAgICAgIDE4MDksIEp1bmUgMTk5NS4NCg0K ICAgW1JTVlBdICAgICAgUi4gQnJhZGVuLCBMLiBaaGFuZywgUy4gQmVyc29uLCBTLiBIZXJ6b2cs IFMuIEphbWluLA0KICAgICAgICAgICAgICAgIlJlc291cmNlIFJlc2VydmF0aW9uIFByb3RvY29s IChSU1ZQKSBWZXJzaW9uIDENCiAgICAgICAgICAgICAgIEZ1bmN0aW9uYWwgU3BlY2lmaWNhdGlv biIsIFJGQyAyMjA1LCBTZXB0ZW1iZXIgMTk5Ny4NCg0KICAgW1NEUF0gICAgICAgTS4gSGFuZGxl eSwgVi4gSmFjb2Jzb24sICJTRFA6IFNlc3Npb24gRGVzY3JpcHRpb24NCiAgICAgICAgICAgICAg IFByb3RvY29sIiwgUkZDIDIzMjcsIEFwcmlsIDE5OTguDQoNCg0KQXV0aG9ycycgQWRkcmVzc2Vz DQoNCiAgIEphcm5vIFJhamFoYWxtZQ0KICAgTm9raWEgUmVzZWFyY2ggQ2VudGVyDQogICBQLk8u IEJveCA0MDcNCiAgIEZJTi0wMDA0NSBOT0tJQSBHUk9VUCwNCiAgIEZpbmxhbmQNCiAgIEUtbWFp bDogamFybm8ucmFqYWhhbG1lQG5va2lhLmNvbQ0KDQogICBBbGV4IENvbnRhDQogICBUcmFuc3dp dGNoIENvcnBvcmF0aW9uDQogICAzIEVudGVycHJpc2UgRHJpdmUNCiAgIFNoZWx0b24sIENUIDA2 NDg0DQogICBVU0ENCiAgIEVtYWlsOiBhY29udGFAdHhjLmNvbQ0KDQogICBCcmlhbiBFLiBDYXJw ZW50ZXINCiAgIElCTSBadXJpY2ggUmVzZWFyY2ggTGFib3JhdG9yeQ0KICAgU2FldW1lcnN0cmFz c2UgNCAvIFBvc3RmYWNoDQogICA4ODAzIFJ1ZXNjaGxpa29uDQogICBTd2l0emVybGFuZA0KICAg RW1haWw6IGJyaWFuQGh1cnNsZXkuaWJtLmNvbQ0KDQogICBTdGV2ZSBEZWVyaW5nDQogICBDaXNj byBTeXN0ZW1zLCBJbmMuDQogICAxNzAgV2VzdCBUYXNtYW4gRHJpdmUNCiAgIFNhbiBKb3NlLCBD QSA5NTEzNC0xNzA2DQogICBVU0ENCiAgIEVtYWlsOiBkZWVyaW5nQGNpc2NvLmNvbQ0KDQpSYWph aGFsbWUsIGV0IGFsLiAgICAgICBFeHBpcmVzOiBTZXB0ZW1iZXIgMjAwMiAgICAgICAgICAgICAg ICAgW1BhZ2UgNl0NCgwNCklOVEVSTkVULURSQUZUICAgICBkcmFmdC1pZXRmLWlwdjYtZmxvdy1s YWJlbC0wMS50eHQgICAgICAgICAgTWFyY2ggMjAwMg0KDQoNCkV4cGlyYXRpb24gRGF0ZQ0KDQog ICBUaGlzIG1lbW8gaXMgZmlsZWQgYXMgPGRyYWZ0LWlldGYtaXB2Ni1mbG93LWxhYmVsLTAxLnR4 dD4gYW5kIGV4cGlyZXMNCiAgIGluIFNlcHRlbWJlciAyMDAyLg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClJhamFoYWxtZSwgZXQgYWwuICAgICAgIEV4cGlyZXM6 IFNlcHRlbWJlciAyMDAyICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0K ------_=_NextPart_001_01C1D075.0980937A-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 17:48:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L1mWKL022795 for ; Wed, 20 Mar 2002 17:48:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2L1mWP2022794 for ipng-dist; Wed, 20 Mar 2002 17:48:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L1mTKL022787 for ; Wed, 20 Mar 2002 17:48:29 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA18098 for ; Wed, 20 Mar 2002 17:48:30 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA29583 for ; Wed, 20 Mar 2002 18:48:29 -0700 (MST) Received: from cisco.com (che-vpn1-34.cisco.com [10.86.240.34]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA05601 for ; Wed, 20 Mar 2002 20:48:26 -0500 (EST) Message-ID: <3C993BC8.8874CEFC@cisco.com> Date: Wed, 20 Mar 2002 20:47:52 -0500 From: Josh Littlefield Organization: Cisco Systems X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: IPng List Subject: Re: Requirements for 'O' flag (was Re: IPv6 working group agendaforMinneapolis IETF) References: <3C962A86.7C249B65@lorien.sc.innovationslab.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya / $B?@L@C#:H(B wrote: > > >>>>> On Mon, 18 Mar 2002 12:57:26 -0500, > >>>>> Brian Haberman said: > > > I agree the text should be updated. To address your points 'c' > > and 'd', it should be pointed out that 2462 was written so that there > > was no dependency upon a particular stateful configuration protocol. > > Operators would simply utilize their protocol of choice (DHCPv6 or foo) > > and 2462 would allow that to be advertised to the hosts. > > I agree. How much a spec should be specific is always a tradeoff (if > it is too generic, implementors and operators will be confused against > so many choices. if it is too specific, we'll kill future > extensions), but in this case, I think it is overspecification to > restrict the possibility to DHCPv6. That may be, but I don't understand how the host would know how to interpet the 'O' bit if it means "do what the operator has decided is correct." If the hosts must be preconfigured to make sense of the 'O' bit, or the 'M' bit for that matter, then I think we've lost quite a bit of utility. In any event, I read 2462 to imply that DHCPv6 is the intended protocol for stateful autoconfiguration of addresses and/or configuration information, by its reference in section 1, but it's certainly implicit, not explicit. The text, and client behavior, need to be clarified one way or the other. -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-497-8378 fax: same Chelmsford, MA 01824-3627 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 19:06:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L36YKL022879 for ; Wed, 20 Mar 2002 19:06:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2L36Ye6022878 for ipng-dist; Wed, 20 Mar 2002 19:06:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L36UKL022871 for ; Wed, 20 Mar 2002 19:06:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA02113 for ; Wed, 20 Mar 2002 19:06:31 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21845 for ; Wed, 20 Mar 2002 20:06:27 -0700 (MST) Received: from localhost (wireless-dhcp-189-167.ietf53.cw.net [166.63.189.167]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2L34Mo02468; Thu, 21 Mar 2002 12:04:22 +0900 (JST) Date: Thu, 21 Mar 2002 12:04:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-Reply-To: <200203201653.g2KGrFg70803@givry.rennes.enst-bretagne.fr> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <200203201653.g2KGrFg70803@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 20 Mar 2002 17:53:15 +0100, >>>>> Francis Dupont said: > Ahh, a nasty person might then ask: why are we burdening all other > addresses with this >
%. > when they don't need it, and the only place where it would be needed > (that MIB example), is not actually using address at all! > => as my goal is to always use names I am neutral: to add scope types > is not a real burden and this catches errors. I agree. We'll basically use the format with readable "names" or in a copy-and-paste manner, so this is not a real burden. > But, of course I can guess why: the place where such notation occurs, > is usually parsed as address, and it would be truly neat if it could > handle the addressless zone id too. > => this was the argument for the binary format. IMHO it is sound to > reuse it for the textual format, so I am slightly in favor of initial > Jinmei's proposal. I (of course) agree. However, I admit that the question that Markku raised can be an FAQ. So I'd propose to add a note in this section that - though it seems redundant to add scope type in when it is used with an
, it does practically not matter. - thus, we use the unified (generic) format everywhere rather than to allow "optimized" notation. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 20 19:26:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L3QDKL022909 for ; Wed, 20 Mar 2002 19:26:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2L3QCBI022908 for ipng-dist; Wed, 20 Mar 2002 19:26:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L3Q8KL022901 for ; Wed, 20 Mar 2002 19:26:09 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA04372; Wed, 20 Mar 2002 19:26:10 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA26204; Wed, 20 Mar 2002 19:26:03 -0800 (PST) Received: from localhost (wireless-dhcp-189-167.ietf53.cw.net [166.63.189.167]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2L3Q3o02594; Thu, 21 Mar 2002 12:26:03 +0900 (JST) Date: Thu, 21 Mar 2002 12:26:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 20 Mar 2002 19:44:07 +0100 (CET), >>>>> Erik Nordmark said: >> + to deal with such issues, we'll need an ability for mobile nodes >> to tell whether a correspondent node or the home agent is in the >> same site as the mobile node. However, there is currently no >> standard way to implement the ability. > I agree that the issues here needs to be pointed out. > I wonder if we can give more explicit advice for the case > when a MN has a global HoA and a site-local CoA . > For instance, in that case it might make sense to only do bidirectional > tunneling. > Does the document look at the different cases here? (I'm not sure if I understood the question correctly, but anyway...) My intention in this proposed change is to point out some issues when using site-local addresses with MIP6 and to recommend to use global addresses for safety. We can add some more issues to this section, but I don't think it possible to cover all such issues. Also, with the fact that MIP6 itself is a moving target, making too specific advises would not make much sense. We'll consider the bidirectional tunneling case anyway, but IMO the text will still follow the intention above (that is, describing some issues with a simple recommendation). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 20 19:30:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L3UHKL022929 for ; Wed, 20 Mar 2002 19:30:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2L3UH99022928 for ipng-dist; Wed, 20 Mar 2002 19:30:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L3UDKL022921 for ; Wed, 20 Mar 2002 19:30:13 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12358 for ; Wed, 20 Mar 2002 19:30:14 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA22033 for ; Wed, 20 Mar 2002 19:30:16 -0800 (PST) Received: from localhost (wireless-dhcp-189-167.ietf53.cw.net [166.63.189.167]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2L3U2o02627; Thu, 21 Mar 2002 12:30:04 +0900 (JST) Date: Thu, 21 Mar 2002 12:29:51 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Richard Draves" Cc: Subject: Re: poposed changes to the scoping architecture draft In-Reply-To: <7695E2F6903F7A41961F8CF888D87EA804BC48A7@red-msg-06.redmond.corp.microsoft.com> References: <7695E2F6903F7A41961F8CF888D87EA804BC48A7@red-msg-06.redmond.corp.microsoft.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 23 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 20 Mar 2002 11:19:40 -0800, >>>>> "Richard Draves" said: > Sorry I wasn't reading correctly - obviously you were discussing the > unspecified address not the loopback address!! Okay. > It's not clear to me that the unspecified address has a well-defined > scope level... Perhaps we have two choices: 1. treat :: as global 2. does (explicitly) not define the scope type (level) of :: Even the choice 2 will make the document clear, and it will not cause a problem in a practical point of view. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 20 20:03:22 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L43MKL022970 for ; Wed, 20 Mar 2002 20:03:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2L43Mso022969 for ipng-dist; Wed, 20 Mar 2002 20:03:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L43IKL022962 for ; Wed, 20 Mar 2002 20:03:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA09114 for ; Wed, 20 Mar 2002 20:03:20 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA09746 for ; Wed, 20 Mar 2002 21:03:07 -0700 (MST) Received: from localhost (wireless-dhcp-189-167.ietf53.cw.net [166.63.189.167]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2L42uo02792; Thu, 21 Mar 2002 13:02:56 +0900 (JST) Date: Thu, 21 Mar 2002 13:03:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= Cc: ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-Reply-To: <20020321.081706.552536904.keiichi@iij.ad.jp> References: <200203192221.g2JMLRg67744@givry.rennes.enst-bretagne.fr> <20020321.081706.552536904.keiichi@iij.ad.jp> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 70 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 21 Mar 2002 08:17:06 +0900 (JST), >>>>> Keiichi SHIMA said: >> 1. revise the mobility section to clarify issues about using >> site-local addresses with mobile IPv6: >> >> => I disagree with your solution because it takes more than a few line >> to describe it (:-). >> IMHO site-local addresses in a mobile IPv6 work well if only a >> bidirectional tunnel is used between the mobile and its home agent. >> Note there should be no penalty because by definition communications >> in the same site are local, so the only difference with routing >> optimization is the encapsulaion overhead. >> Another important point is an equivalent way to describe this solution >> is to say the bidirectional tunnel belongs to the home site. > Are you saying that if we use a bi-directional tunneling, the off-site > MN can comunicate with the CN that is in the home-site of the MN? > If so, I disagree. Consider the following condition. > site A (fec0:0:0:100::/64): a home site of the MN > site B (fec0:0:0:100::/64): a foreign site. > If the MN moves from the site A to site B, In this case, the mobile node is multi-sited. The following figure would depict the situation. +----------------------------------------+ | +=====tunnel link====================+ | + | +--------------------------------+| | \| / || | I1 +--------+| +--home site-----+ ---- MN ---foreign site--+ | HA | I2 | | | The MN has (conceptually) at least two interfaces; I1 and I2. The former (conceptually) belongs to the home site, and the latter of course belongs to the foreign site. The site-local home address belongs to I1 (or perhaps a different interface, but it should belong to the home site). Just like other (normal) multi-sited nodes, the MN should always disambiguate the site zone when sending a packet. This applies when the mobile node sends a packet to a node in the home site. So, > the MN cannot determine the > direction to which it should send a packet destinated to > fec0:0:0:100:1234:5678:9abc:def0. The destination address can be both > on the site A and the site B. this is true, but cannot be a counter argument to what Francis said. We should (and can) just disambiguate the site zone when sending. BTW: It's still true that this type of situation is problematic. For example, - there is no way for the mobile to detect if the site A and the site B are same or different site (as I said in my first message in this thread). - if the site A and the site B are different sites, the mobile node cannot communicate with a node in the site B using mobile IPv6. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 20 21:00:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L50iKL023031 for ; Wed, 20 Mar 2002 21:00:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2L50iS3023030 for ipng-dist; Wed, 20 Mar 2002 21:00:44 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L50eKL023023 for ; Wed, 20 Mar 2002 21:00:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA28922 for ; Wed, 20 Mar 2002 21:00:43 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA21131 for ; Wed, 20 Mar 2002 22:00:42 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2L50Cu11030; Wed, 20 Mar 2002 23:00:13 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 23:00:15 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02B2DB6D@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Cc: hinden@iprg.nokia.com Subject: RE: New WG flow label draft (-01) Date: Wed, 20 Mar 2002 23:00:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D095.493EEE10" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D095.493EEE10 Content-Type: text/plain; charset="iso-8859-1" This looks very good and informative. Thank You. > -----Original Message----- > From: jarno.rajahalme@nokia.com [mailto:jarno.rajahalme@nokia.com] > Sent: Wednesday, March 20, 2002 7:09 PM > To: ipng@sunroof.eng.sun.com > Cc: hinden@iprg.nokia.com > Subject: New WG flow label draft (-01) > > > Hi, > > We had some face-to-face time on Tuesday, which resulted into > a new revision of the flow label draft. The presentation on > Thursday will be based on this. > > Jarno > > <> > > ------_=_NextPart_001_01C1D095.493EEE10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: New WG flow label draft (-01)

This looks very good and informative. Thank = You.

> -----Original Message-----
> From: jarno.rajahalme@nokia.com [mailto:jarno.rajahalme@nokia.c= om]
> Sent: Wednesday, March 20, 2002 7:09 PM
> To: ipng@sunroof.eng.sun.com
> Cc: hinden@iprg.nokia.com
> Subject: New WG flow label draft (-01)
>
>
> Hi,
>
> We had some face-to-face time on Tuesday, which = resulted into
> a new revision of the flow label draft. The = presentation on
> Thursday will be based on this.
>
>       Jarno
>
>  = <<draft-ietf-ipv6-flow-label-01.txt>>
>
>

------_=_NextPart_001_01C1D095.493EEE10-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 21:16:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L5GjKL023087 for ; Wed, 20 Mar 2002 21:16:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2L5Gjs4023086 for ipng-dist; Wed, 20 Mar 2002 21:16:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L5GgKL023079 for ; Wed, 20 Mar 2002 21:16:42 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA01745 for ; Wed, 20 Mar 2002 21:16:45 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA15612 for ; Wed, 20 Mar 2002 21:16:39 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2L5GCW11804; Wed, 20 Mar 2002 23:16:12 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 20 Mar 2002 23:16:15 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02B2DB78@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Brian E Carpenter , Keith Moore Cc: Pekka Nikander , ipng@sunroof.eng.sun.com Subject: RE: Allocating a bit in the RFC2437 Interface Identifier Date: Wed, 20 Mar 2002 23:16:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D097.859247C0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D097.859247C0 Content-Type: text/plain; charset="iso-8859-1" > In which case, I violently agree with Keith. We've already > overloaded IP addresses with two functions - locator and > identifier. I would rather see the WG focus on the value of using a bit to specify whether the address is intended to be both a locator and identifier or just a locator. I personally believe this would be a far better use of real estate than the other proposal. I certainly wouldn't expect any dicision soon on either proposed use, though. ------_=_NextPart_001_01C1D097.859247C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Allocating a bit in the RFC2437 Interface Identifier

> In which case, I violently agree with Keith. = We've already
> overloaded IP addresses with two functions - = locator and
> identifier.

I would rather see the WG focus on the value of using = a bit to specify whether the address is intended to be both a locator = and identifier or just a locator. I personally believe this would be a = far better use of real estate than the other proposal. I certainly = wouldn't expect any dicision soon on either proposed use, = though.

------_=_NextPart_001_01C1D097.859247C0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 20 21:51:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L5p9KL023156 for ; Wed, 20 Mar 2002 21:51:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2L5p9En023155 for ipng-dist; Wed, 20 Mar 2002 21:51:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L5p6KL023148 for ; Wed, 20 Mar 2002 21:51:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA06470 for ; Wed, 20 Mar 2002 21:51:07 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA04787 for ; Wed, 20 Mar 2002 22:51:07 -0700 (MST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id g2L5p6h03643; Wed, 20 Mar 2002 21:51:06 -0800 (PST) Received: from [166.63.187.189] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ADB88356; Wed, 20 Mar 2002 21:50:12 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@127.0.0.1 Message-Id: In-Reply-To: References: <7695E2F6903F7A41961F8CF888D87EA804BC48A7@red-msg-06.redmond.corp.microsof t.com> Date: Wed, 20 Mar 2002 21:51:02 -0800 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Steve Deering Subject: Re: poposed changes to the scoping architecture draft Cc: "Richard Draves" , Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 12:29 PM +0900 3/21/02, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >Perhaps we have two choices: > >1. treat :: as global >2. does (explicitly) not define the scope type (level) of :: > >Even the choice 2 will make the document clear, and it will not cause >a problem in a practical point of view. I think of :: as indicating the absence of an address, in which case it doesn't have any scope. For those who feel the need to assign a scope value to ::, it's probably safest to treat it as link-local (for example, to ensure that a router receiving a packet with a source address of :: is not forwarded to another link). Steve -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed Mar 20 22:06:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L66XKL023179 for ; Wed, 20 Mar 2002 22:06:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2L66XaG023178 for ipng-dist; Wed, 20 Mar 2002 22:06:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L66UKL023171 for ; Wed, 20 Mar 2002 22:06:30 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA22618 for ; Wed, 20 Mar 2002 22:06:27 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA21103 for ; Wed, 20 Mar 2002 22:06:29 -0800 (PST) Received: from mira-sjcd-4.cisco.com (mira-sjcd-4.cisco.com [171.69.43.47]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id g2L66I321025; Wed, 20 Mar 2002 22:06:18 -0800 (PST) Received: from [166.63.187.189] (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ADB88552; Wed, 20 Mar 2002 22:05:27 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@127.0.0.1 Message-Id: In-Reply-To: <200203190346.g2J3kJg64649@givry.rennes.enst-bretagne.fr> References: <200203190346.g2J3kJg64649@givry.rennes.enst-bretagne.fr> Date: Wed, 20 Mar 2002 22:06:16 -0800 To: Francis Dupont From: Steve Deering Subject: Re: requirement for celllular IPv6 host draft Cc: Jun-ichiro itojun Hagino , hesham.soliman@era.ericsson.se, ipng@sunroof.eng.sun.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 4:46 AM +0100 3/19/02, Francis Dupont wrote: > In your previous mail you wrote: > > > A full implementation of IPv6 includes implementation of the > > following extension headers: > >=> this wording is unfortunate: what is a partial implementation >of IPv6? It is an incomplete implementation. 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 Mar 20 22:07:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L675KL023189 for ; Wed, 20 Mar 2002 22:07:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2L675xw023188 for ipng-dist; Wed, 20 Mar 2002 22:07:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L671KL023181; Wed, 20 Mar 2002 22:07:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA22669; Wed, 20 Mar 2002 22:07:02 -0800 (PST) Received: from Mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA14878; Wed, 20 Mar 2002 23:07:01 -0700 (MST) Received: from lorien.sc.innovationslab.net ([24.162.252.183]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Wed, 20 Mar 2002 10:14:35 -0500 Message-ID: <3C98A789.B23EE698@lorien.sc.innovationslab.net> Date: Wed, 20 Mar 2002 10:15:21 -0500 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Dave Thaler CC: Antonio Querubin , ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com Subject: Re: (ngtrans) RE: get rid of IPv4 compatibles? References: <2E33960095B58E40A4D3345AB9F65EC1047CEBC1@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dave Thaler wrote: > > Antonio Querubin writes: > > If it is how about just defining mapped multicast addresses already? > [...] > > | 80 bits | 16 | 32 bits | > > +--------------------------------------+--------------------------+ > > |0000..............................0000|FFFF|IPv4 multicast group | > > +--------------------------------------+----+---------------------+ > > This has been discussed before, and the above format is illegal, since > all multicast addresses must begin with 0xFF, not 0x00. > > I think someone did once propose a format which was out of the legal > multicast space. And one of the biggest issues we had with that proposal was that there was no easy way to map an IPv4 scoped multicast address into a corresponding IPv6 scoped multicast address. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 00:54:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L8sYKL023392 for ; Thu, 21 Mar 2002 00:54:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2L8sYqx023391 for ipng-dist; Thu, 21 Mar 2002 00:54:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2L8sVKL023384 for ; Thu, 21 Mar 2002 00:54:31 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA11128 for ; Thu, 21 Mar 2002 00:54:31 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA28028 for ; Thu, 21 Mar 2002 01:54:30 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id KAA04603; Thu, 21 Mar 2002 10:54:25 +0200 Date: Thu, 21 Mar 2002 10:54:25 +0200 Message-Id: <200203210854.KAA04603@burp.tkv.asdf.org> From: Markku Savela To: jinmei@isl.rdc.toshiba.co.jp CC: ipng@sunroof.eng.sun.com In-reply-to: Subject: Re: poposed changes to the scoping architecture draft References: <200203201653.g2KGrFg70803@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The
%. just does not feel right to me. I don't like notations which allow writing erroneous expressions, whenever it can be avoided. And, I'm not yet quite convinced, that this case needs such "error-allowing" notation. Thus I prefer
% and scope type is from address. And, then make sure every address has a definite scope designated (the ones for which scope is a bit unclear are/were :: and "::/3" (eg. those pesky IPv4 mappen and kind addresses). [note, currently I plan to use scope=16 internally for those IPv4 addresses, that is outside and above IPv6 scopes. One major use for this is to distinguish between different 10/8 networks, if they are connected to node at same time, directly or tunnels] I thought my proposal was nice for listen sockets, you don't need a special separate socket option to set the scope, if you want to limit your listen to any address of specificic scope. With definitions fe80::% - ANY address in specified link local zone fec0::% - ANY address in specified site zone and normal bind as before, the process seems very simple (how this is reflected in internal data structures of listen socket is different, implementation matter). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 04:51:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LCpWKL023758 for ; Thu, 21 Mar 2002 04:51:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LCpWK9023757 for ipng-dist; Thu, 21 Mar 2002 04:51:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LCpTKL023750 for ; Thu, 21 Mar 2002 04:51:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA00441 for ; Thu, 21 Mar 2002 04:51:30 -0800 (PST) Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA01950 for ; Thu, 21 Mar 2002 05:51:29 -0700 (MST) Received: from lorien.sc.innovationslab.net ([24.162.252.183]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Thu, 21 Mar 2002 07:50:50 -0500 Message-ID: <3C99D734.598BF83@lorien.sc.innovationslab.net> Date: Thu, 21 Mar 2002 07:51:01 -0500 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Deering CC: "jinmei@isl.rdc.toshiba.co.jp" , IPng Mailing List Subject: Re: poposed changes to the scoping architecture draft References: <7695E2F6903F7A41961F8CF888D87EA804BC48A7@red-msg-06.redmond.corp.microsof t.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve Deering wrote: > > At 12:29 PM +0900 3/21/02, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >Perhaps we have two choices: > > > >1. treat :: as global > >2. does (explicitly) not define the scope type (level) of :: > > > >Even the choice 2 will make the document clear, and it will not cause > >a problem in a practical point of view. > > I think of :: as indicating the absence of an address, in which case > it doesn't have any scope. For those who feel the need to assign a > scope value to ::, it's probably safest to treat it as link-local > (for example, to ensure that a router receiving a packet with a > source address of :: is not forwarded to another link). I agree with the concept of :: not having any scope. If I had to pick a scope for the unspecified address, it would appear to have more of the characteristics of the multicast interface-local scope. But since it is not a multicast address, link-local should suffice. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 05:15:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LDFHKL023793 for ; Thu, 21 Mar 2002 05:15:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LDFHdh023792 for ipng-dist; Thu, 21 Mar 2002 05:15:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LDFDKL023785 for ; Thu, 21 Mar 2002 05:15:13 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA08671 for ; Thu, 21 Mar 2002 05:15:15 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA10672 for ; Thu, 21 Mar 2002 06:15:15 -0700 (MST) Received: from kenawang ([192.168.1.71]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id FAA27577; Thu, 21 Mar 2002 05:12:09 -0800 (PST) Message-Id: <4.2.2.20020321080740.01ec9100@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 21 Mar 2002 08:13:44 -0500 To: Markku Savela From: Margaret Wasserman Subject: Re: poposed changes to the scoping architecture draft Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200203210854.KAA04603@burp.tkv.asdf.org> References: <200203201653.g2KGrFg70803@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Thus I prefer > >
% > >and scope type is from address. I also prefer this notation. It removes any ambiguity about what a node is supposed to do if the address and the scope number don't match. >And, then make sure every address has >a definite scope designated (the ones for which scope is a bit unclear >are/were :: and "::/3" (eg. those pesky IPv4 mappen and kind >addresses). Every address has to have a scope, anyway, because routers need to know when/if a packets should be forwarded. If an address should not be forwarded at all, it is link-local. If it should be constrained within a site, it is site-local. If it can be forwarded anywhere, it is global. If this information is undefined for one or more types of addresses, we need to define it. If an address is never meant to be used on the wire, it is effectively node-local. For a unicast addresses, I think that we should consider these addresses link-local. That way, mistakes won't be propagated across the network. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 06:04:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LE4XKL023882 for ; Thu, 21 Mar 2002 06:04:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LE4Xc9023881 for ipng-dist; Thu, 21 Mar 2002 06:04:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LE4UKL023874 for ; Thu, 21 Mar 2002 06:04:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA15942 for ; Thu, 21 Mar 2002 06:04:31 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA00420 for ; Thu, 21 Mar 2002 07:04:30 -0700 (MST) Received: from d2.nomadiclab.com (bastion [131.160.194.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 28D4122E15; Thu, 21 Mar 2002 16:02:53 +0200 (EET) Received: from nomadiclab.com (localhost [127.0.0.1]) by d2.nomadiclab.com (Postfix) with ESMTP id 3B5A7BA03; Thu, 21 Mar 2002 16:04:21 +0200 (EET) Message-ID: <3C99E8B1.40408@nomadiclab.com> Date: Thu, 21 Mar 2002 08:05:37 -0600 From: Pekka Nikander User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020307 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Glenn Morrow Cc: Brian E Carpenter , Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: <933FADF5E673D411B8A30002A5608A0E02B2DB78@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Glenn Morrow wrote: > > In which case, I violently agree with Keith. We've already > > overloaded IP addresses with two functions - locator and > > identifier. > > I would rather see the WG focus on the value of using a bit to specify > whether the address is intended to be both a locator and identifier or > just a locator. I personally believe this would be a far better use of > real estate than the other proposal. I certainly wouldn't expect any > dicision soon on either proposed use, though. Well, the original idea was to reserve a bit to indicate that the address is Cryptographically Generaged Address (CGA), basically meaning that if the bit is set, then interface id = low64(hash(PK, stuff)) & mask where PK is a public key to be used as an identifier for the host stuff is contains other parameters (see the earlier messages) hash is a cryptographic hash function, e.g. SHA1 low64 is a function that takes lowest 64 bits mask indicates that we have to clear/set some bits of the iid In essense, that would allow anyone to determine if a given public key belongs to a host, just inspecting the public key, the address, and the "stuff" above. See e.g. Michale Roe and Greg O'Shea, "Childproof authentication for MIPv6", Computer Communications Review, April 2001, http://www.research.microsoft.com/users/gregos/CAM-v9.pdf or Pekka Nikander, "Denial-of-Service, Address Ownership, and Early Authentication in the IPv6 World", Cambridge Protocols Workshop, April 2001, http://www.tml.hut.fi/~pnr/publications/cam2001.pdf for research papers touching the idea. There is also a number of internet drafts that describe in more detail how CGA could be used for a number of purposes, including but not limited to Mobile IPv6. Unfortunately, this method is encumbered by IPR claims from Microsoft and Ericsson, and therefore it received violent opposition at the mobile-ip working group. As a result, the MIPv6 Design Team resolved to the more modest proposal of just allocating the bits, in the hope that the IPR issues could be dealed in a way or another. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 06:16:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEGaKL023936 for ; Thu, 21 Mar 2002 06:16:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LEGaRr023935 for ipng-dist; Thu, 21 Mar 2002 06:16:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEGXKL023928 for ; Thu, 21 Mar 2002 06:16:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA11474; Thu, 21 Mar 2002 06:16:34 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA06771; Thu, 21 Mar 2002 07:16:33 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id PAA51990; Thu, 21 Mar 2002 15:16:24 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2LEGLF73130; Thu, 21 Mar 2002 15:16:21 +0100 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40898 from ; Thu, 21 Mar 2002 15:16:17 +0100 Message-Id: <3C99EB1E.C51A6A5A@hursley.ibm.com> Date: Thu, 21 Mar 2002 15:15:58 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Erik Nordmark Cc: Keith Moore , Pekka Nikander , ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2437 Interface Identifier References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, As I recall we didn't define the U/L bit ; the IEEE did, and we decided to invert it. And I thought the U/L bit was only part of the ID allocation mechanism more than anything else. It has an unfortunate side effect of appearing to add semantics to the identifier field, but I don't think it really does so. In your March 4 mail you wrote > RFC 2373 does not have any way > to introduce or identify new types of interface IDs that can be > identified syntactically by just looking at the interface ID. Correct, and this is exactly how an identifier field should be -opaque, no syntax, no semantics. That is my whole point. Brian Erik Nordmark wrote: > > Brian, > > > In which case, I violently agree with Keith. We've already > > overloaded IP addresses with two functions - locator and > > identifier. We've been rebuffing various suggestions for > > yet more overloading for years (the porno bit for example) and > > this is in the same category - not the right place to put a security > > hint. It's quite inappropriate to damage the opaqueness of a pure ID > > field in such a way. If a security hint is needed, it should be somewhere > > else. > > Three - not two. > In addition to locator and identifier we also effectively encode > how the interface ID part is allocated (by having the universal/local > bit in there.) > Pekka's proposal (that has been discussed in the mobile-ipv6 context) > essentially extends the ability to encode how the interface ID has > been allocated to carry additional information. > Basically when the bit is set to say "don't use non-default semantics" > it would involve some checks against the interface ID. > > It would be most useful if folks could read the URLs that Pekka pointed > so that we can gain a better shared understanding of the security issues > involved. > > > On a practical point, I don't see how this fits with the addressing > > architecture (draft-ietf-ipngwg-addr-arch-v3-07.txt) which requires > > that "For all unicast addresses, except those that start with binary > > value 000, Interface IDs are required to be 64 bits long and to be > > constructed in Modified EUI-64 format." It also doesn't fit with > > the RFC 3041 privacy extensions. > > I sent an email to the ipng list on titled > Reserving bits in RFC 2473 Interface IDs? > on March 4th. > Since the above comment seems to be about that email I'd appreciate if you > could recast it as a comment against that email. > > 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 Mar 21 06:16:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEGLKL023926 for ; Thu, 21 Mar 2002 06:16:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LEGLam023925 for ipng-dist; Thu, 21 Mar 2002 06:16:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEGIKL023917 for ; Thu, 21 Mar 2002 06:16:18 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA13181 for ; Thu, 21 Mar 2002 06:15:45 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA05496 for ; Thu, 21 Mar 2002 07:15:43 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2LEFfR07244 for ; Thu, 21 Mar 2002 16:15:41 +0200 Date: Thu, 21 Mar 2002 16:15:41 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2374 Interface Identifier In-Reply-To: <3C99E8B1.40408@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 21 Mar 2002, Pekka Nikander wrote: > Unfortunately, this method is encumbered by IPR claims from Microsoft > and Ericsson, and therefore it received violent opposition at the > mobile-ip working group. As a result, the MIPv6 Design Team resolved > to the more modest proposal of just allocating the bits, in the > hope that the IPR issues could be dealed in a way or another. "We (MIPv6) can't use it due to IPR, so we'll just move the problem to ipng and have them reserve bits in the address instead"...? Doesn't sound discouraging enough to me. We MUST NOT reserve bits in the address to support IPR'd mechanisms. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 06:26:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEQRKL024021 for ; Thu, 21 Mar 2002 06:26:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LEQRMM024018 for ipng-dist; Thu, 21 Mar 2002 06:26:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEQLKL024010 for ; Thu, 21 Mar 2002 06:26:22 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2LEQ8x20178; Thu, 21 Mar 2002 15:26:09 +0100 (MET) Date: Thu, 21 Mar 2002 15:25:58 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Allocating a bit in the RFC2437 Interface Identifier To: Brian E Carpenter Cc: Erik Nordmark , Keith Moore , Pekka Nikander , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3C99EB1E.C51A6A5A@hursley.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > As I recall we didn't define the U/L bit ; the IEEE did, and we decided > to invert it. And I thought the U/L bit was only part of the ID allocation > mechanism more than anything else. It has an unfortunate side effect of > appearing to add semantics to the identifier field, but I don't think it > really does so. Without going into history, the current state is that the U/L bit has semantics in the sense that we point out [somewhere] that e.g. future transport protocols might use the knowledge that the interface ID is globally unique when the U bit is set. > Correct, and this is exactly how an identifier field should be > -opaque, no syntax, no semantics. That is my whole point. FWIW we seem to, for whatever reasons, already have embarked on the path of having semantics associated with the interface ID. While I'm not advocating removing the U/L bit, it sure would be interesting to know whether we think assigning the globally unique semantics is a bad idea. If so perhaps we should make it clear that U=1 means "assigned by the IEEE according to EUI-64" and nothing more. My interpretation is that this is not the current state of things. 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 Mar 21 06:35:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEZRKL024065 for ; Thu, 21 Mar 2002 06:35:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LEZRrP024064 for ipng-dist; Thu, 21 Mar 2002 06:35:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEZNKL024057 for ; Thu, 21 Mar 2002 06:35:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA20730 for ; Thu, 21 Mar 2002 06:35:26 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA15623 for ; Thu, 21 Mar 2002 07:35:25 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id GAA21054 for ; Thu, 21 Mar 2002 06:35:25 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2LEZP005856; Thu, 21 Mar 2002 06:35:25 -0800 X-mProtect:  Thu, 21 Mar 2002 06:35:25 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (166.63.185.127, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdMkgPH0; Thu, 21 Mar 2002 06:35:22 PST Message-Id: <4.3.2.7.2.20020321063314.026f8e38@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Mar 2002 06:33:54 -0800 To: IPng List From: Bob Hinden Subject: New IPv6 Co-Chair Cc: hinden@iprg.nokia.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We would like to announce that Margaret Wasserman is becoming a co-chair of the IPv6 working group. This is effective now. Margaret has been involved in the IPv6 (aka IPng) working group since close to the beginning and will add valuable cycles to running and managing the working group. We hope you will join us in welcoming Margaret as an IPv6 w.g. co-chair. Bob Hinden & Steve Deering -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 06:36:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEaOKL024075 for ; Thu, 21 Mar 2002 06:36:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LEaO99024074 for ipng-dist; Thu, 21 Mar 2002 06:36:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEaKKL024067 for ; Thu, 21 Mar 2002 06:36:21 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17471 for ; Thu, 21 Mar 2002 06:36:22 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA14512 for ; Thu, 21 Mar 2002 06:36:20 -0800 (PST) Received: from d2.nomadiclab.com (bastion [131.160.194.2]) by n2.nomadiclab.com (Postfix) with ESMTP id DA76622E15; Thu, 21 Mar 2002 16:34:39 +0200 (EET) Received: from nomadiclab.com (localhost [127.0.0.1]) by d2.nomadiclab.com (Postfix) with ESMTP id B73E9BA03; Thu, 21 Mar 2002 16:36:09 +0200 (EET) Message-ID: <3C99F026.8020803@nomadiclab.com> Date: Thu, 21 Mar 2002 08:37:26 -0600 From: Pekka Nikander User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020307 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > We MUST NOT reserve bits in the address to support IPR'd mechanisms. Actually, the intention is just the reverse. The intention is to reserve a bit (or bit pattern) so that the IPR'd mechanims NEED NOT to be used for future better security protocols. CGA can be used independent on whether there are any bits reserved or not. The bit method would leave the door open to any future security mechanisms, including those based on AAA and CGA. But I think Erik is better in expressing the issue, he first proposed the bit method anyway. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 06:41:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEfhKL024104 for ; Thu, 21 Mar 2002 06:41:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LEfhWm024103 for ipng-dist; Thu, 21 Mar 2002 06:41:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEfeKL024096 for ; Thu, 21 Mar 2002 06:41:40 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA16993; Thu, 21 Mar 2002 06:41:40 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15997; Thu, 21 Mar 2002 06:41:41 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2LEfaQ07492; Thu, 21 Mar 2002 16:41:36 +0200 Date: Thu, 21 Mar 2002 16:41:36 +0200 (EET) From: Pekka Savola To: Pekka Nikander cc: ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier In-Reply-To: <3C99F026.8020803@nomadiclab.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 21 Mar 2002, Pekka Nikander wrote: > Pekka Savola wrote: > > We MUST NOT reserve bits in the address to support IPR'd mechanisms. > > Actually, the intention is just the reverse. The intention is to > reserve a bit (or bit pattern) so that the IPR'd mechanims NEED NOT > to be used for future better security protocols. CGA can be used > independent on whether there are any bits reserved or not. > > The bit method would leave the door open to any future security mechanisms, > including those based on AAA and CGA. Our assumptions are different: you assume CGA is used (except when signalled not to), I assume CGA will not be used (unless signalled to do so). In the latter case, I'm not sure if bits are necessary. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 06:56:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEuwKL024367 for ; Thu, 21 Mar 2002 06:56:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LEuwRV024366 for ipng-dist; Thu, 21 Mar 2002 06:56:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEusKL024359 for ; Thu, 21 Mar 2002 06:56:55 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA24360 for ; Thu, 21 Mar 2002 06:56:54 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA26104 for ; Thu, 21 Mar 2002 07:56:53 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 423016A901; Thu, 21 Mar 2002 16:56:07 +0200 (EET) Message-ID: <3C99F4D1.7010201@kolumbus.fi> Date: Thu, 21 Mar 2002 16:57:21 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > We MUST NOT reserve bits in the address to support IPR'd mechanisms. That wasn't the case. The proposal is: 1) Allocate the bit 2) Use the bit value 0 to signify "default parameters" for ANY use (not just MIP) 3) Reserve the bit value 1 for future purposes There's two important things here. One, point 2 is not just for MIP. Second, we *reserve* the possibility to do something else than the default use in point 3. We don't know what that something could be. It could be something else than what Pekka mentioned about the IPRd mip mechanisms. Just that it would be prudunt to not paint ourselves in the corner that we can never have anything else than the default behaviour. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 06:58:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEw2KL024387 for ; Thu, 21 Mar 2002 06:58:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LEw2Ec024386 for ipng-dist; Thu, 21 Mar 2002 06:58:02 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LEvwKL024379 for ; Thu, 21 Mar 2002 06:57:58 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23058 for ; Thu, 21 Mar 2002 06:57:59 -0800 (PST) Received: from keiichi01.osaka.iij.ad.jp (wireless-dhcp-186-126.ietf53.cw.net [166.63.186.126]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA18817 for ; Thu, 21 Mar 2002 07:57:58 -0700 (MST) Received: from localhost (localhost [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.6/8.11.6) with ESMTP id g2LEubb00261; Thu, 21 Mar 2002 23:56:53 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Thu, 21 Mar 2002 23:56:37 +0900 (JST) Message-Id: <20020321.235637.294112664.keiichi@iij.ad.jp> To: Francis.Dupont@enst-bretagne.fr Cc: jinmei@isl.rdc.toshiba.co.jp, ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft From: Keiichi SHIMA / =?iso-2022-jp?B?GyRCRWc3RDBsGyhC?= In-Reply-To: <200203202339.g2KNdDg72314@givry.rennes.enst-bretagne.fr> References: <20020321.081706.552536904.keiichi@iij.ad.jp> <200203202339.g2KNdDg72314@givry.rennes.enst-bretagne.fr> X-Mailer: Mew version 3.0.55 on XEmacs 21.1.14 (Cuyahoga Valley) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, From: Francis Dupont > > If the MN moves from the site A to site B, the MN cannot determine the > direction to which it should send a packet destinated to > fec0:0:0:100:1234:5678:9abc:def0. The destination address can be both > on the site A and the site B. > > => Jinmei, can you explain the scoping architecture to your colleague? > It seems I'll be impolite if I try to answer (:-). I have read a reply from jinmei-san. I understand my previous mail is not true. I should learn more about the scoped-architecture :-), and I should make my MIP6 implementation as multi-sited. --- Keiichi SHIMA IIJ Research Laboratory 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 Thu Mar 21 07:06:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LF6bKL024455 for ; Thu, 21 Mar 2002 07:06:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LF6bhX024454 for ipng-dist; Thu, 21 Mar 2002 07:06:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LF6VKL024447 for ; Thu, 21 Mar 2002 07:06:32 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2LF6Px25498; Thu, 21 Mar 2002 16:06:26 +0100 (MET) Date: Thu, 21 Mar 2002 16:06:16 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier To: Pekka Savola Cc: Pekka Nikander , ipng@sunroof.eng.sun.com, Erik Nordmark In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Our assumptions are different: you assume CGA is used (except when > signalled not to), I assume CGA will not be used (unless signalled to do > so). > > In the latter case, I'm not sure if bits are necessary. The bidding down issue has been discussed on the mobile IP mailing list and so far nobody has proposed an infrastructure-less way to avoid this attack short of the bit-methods. Doesn't mean that one doesn't exist - but I think it means that there aren't obvious easy alternatives. Awaiting your proposal (but not on this mailing list - MIP is a better mailing list for this part I think). Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 21 07:08:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LF87KL024522 for ; Thu, 21 Mar 2002 07:08:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LF87Z4024521 for ipng-dist; Thu, 21 Mar 2002 07:08:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LF84KL024514 for ; Thu, 21 Mar 2002 07:08:04 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26094; Thu, 21 Mar 2002 07:08:03 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA24310; Thu, 21 Mar 2002 08:08:01 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id QAA90418; Thu, 21 Mar 2002 16:07:58 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2LF7wF102490; Thu, 21 Mar 2002 16:07:58 +0100 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA67732 from ; Thu, 21 Mar 2002 16:07:55 +0100 Message-Id: <3C99F737.E8C9A3BA@hursley.ibm.com> Date: Thu, 21 Mar 2002 16:07:35 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Erik Nordmark Cc: Keith Moore , Pekka Nikander , ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2437 Interface Identifier References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik Nordmark wrote: ... > we point out [somewhere] > that e.g. future transport protocols might use the knowledge that > the interface ID is globally unique when the U bit is set I seem to recall some discussion that this was broken since the U bit is not totally trustworthy - this relates of course to the 8+8 debate. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 09:29:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LHTrKL025213 for ; Thu, 21 Mar 2002 09:29:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LHTr7h025212 for ipng-dist; Thu, 21 Mar 2002 09:29:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LHTnKL025205 for ; Thu, 21 Mar 2002 09:29:49 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA23451 for ; Thu, 21 Mar 2002 09:29:51 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19440 for ; Thu, 21 Mar 2002 10:29:50 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2LHTft06024; Thu, 21 Mar 2002 12:29:41 -0500 (EST) Message-Id: <200203211729.g2LHTft06024@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Pekka Nikander cc: Glenn Morrow , Brian E Carpenter , Keith Moore , ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2374 Interface Identifier In-reply-to: (Your message of "Thu, 21 Mar 2002 08:05:37 CST.") <3C99E8B1.40408@nomadiclab.com> Date: Thu, 21 Mar 2002 12:29:40 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Well, the original idea was to reserve a bit to indicate that the > address is Cryptographically Generaged Address (CGA), basically > meaning that > > if the bit is set, then > interface id = low64(hash(PK, stuff)) & mask > > where > PK is a public key to be used as an identifier for the host > stuff is contains other parameters (see the earlier messages) > hash is a cryptographic hash function, e.g. SHA1 > low64 is a function that takes lowest 64 bits > mask indicates that we have to clear/set some bits of the iid > > In essense, that would allow anyone to determine if a given public > key belongs to a host, just inspecting the public key, the address, > and the "stuff" above. See e.g. given that you need all of that "stuff" in order to verify the key anyway, why not make the CGA bit part of that "stuff" also? Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 09:42:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LHgkKL025241 for ; Thu, 21 Mar 2002 09:42:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LHgkbg025240 for ipng-dist; Thu, 21 Mar 2002 09:42:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LHghKL025233 for ; Thu, 21 Mar 2002 09:42:43 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA11721 for ; Thu, 21 Mar 2002 09:42:45 -0800 (PST) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA26445 for ; Thu, 21 Mar 2002 10:42:44 -0700 (MST) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 21 Mar 2002 09:42:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D0FF.CD463FE1" Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Thu, 21 Mar 2002 09:42:42 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF187@TNEXVS02.tahoenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Allocating a bit in the RFC2374 Interface Identifier Thread-Index: AcHQ5k6oWnRlAWrXTaC4HQ96TNXJ5gAGDpGA From: "Mohan Parthasarathy" To: "Pekka Nikander" , "Pekka Savola" Cc: , "Erik Nordmark" X-OriginalArrivalTime: 21 Mar 2002 17:42:43.0032 (UTC) FILETIME=[CDC14D80:01C1D0FF] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1D0FF.CD463FE1 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 >=20 >=20 > Pekka Savola wrote: > > We MUST NOT reserve bits in the address to support IPR'd mechanisms. >=20 > Actually, the intention is just the reverse. The intention=20 > is to reserve a bit (or bit pattern) so that the IPR'd=20 > mechanims NEED NOT to be used for future better security=20 > protocols. CGA can be used independent on whether there are=20 > any bits reserved or not. >=20 > The bit method would leave the door open to any future=20 > security mechanisms, including those based on AAA and CGA. >=20 It is not very clear as to why you have to reserve a bit in the address to express different security mechanisms being used. Why can't this be built into the protocol itself ? Is it because that the future security mechanisms will not use the same set of message exchanges as RR and hence you want a protocol independent way of indicating the method ? I would assume that any mechanism to establish the binding between home address and care of address would have a few message exchanges. Can you not "indicate" which mechanism is being used in the first message being sent as part of establishing the binding ? I am not sure whether I am missing the obvious here. In your note that you sent : "Now, when bob receives the packet sent by Alice, he has no other knowledge about Alice except the packet itself. In particular, the only information he has about Alice is the source IP address in the packet". I am missing something here. Isn't the packet carrying any other information at all ? -thanks mohan > But I think Erik is better in expressing the issue, he first=20 > proposed the bit method anyway. >=20 > --Pekka Nikander >=20 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- >=20 ------_=_NextPart_001_01C1D0FF.CD463FE1 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Allocating a bit in the RFC2374 Interface Identifier

 
>
>
> Pekka Savola wrote:
> > We MUST NOT reserve bits in the address to = support IPR'd mechanisms.
>
> Actually, the intention is just the = reverse.  The intention
> is to reserve a bit (or bit pattern) so that the = IPR'd
> mechanims NEED NOT to be used for future better = security
> protocols.  CGA can be used independent on = whether there are
> any bits reserved or not.
>
> The bit method would leave the door open to any = future
> security mechanisms, including those based on = AAA and CGA.
>
It is not very clear as to why you have to reserve a = bit in the
address to express different security mechanisms = being used. Why can't
this be built into the protocol itself ? Is it = because that the future
security mechanisms will not use the same set of = message exchanges as
RR and hence you want a protocol independent way of = indicating the method ?
I would assume that any mechanism to establish the = binding between home
address and care of address  would have a few = message exchanges. Can you not
"indicate" which mechanism is being used in = the first message being sent
as part of establishing the binding ? I am not sure = whether I am missing
the obvious here. In your note that you sent :

"Now, when bob receives the packet sent by Alice, = he has no other knowledge
about Alice except the packet itself. In particular, = the only information
he has about Alice is the source IP address in the = packet".

I am missing something here. Isn't the packet carrying = any other
information at all ?

-thanks
mohan

> But I think Erik is better in expressing the = issue, he first
> proposed the bit method anyway.
>
> --Pekka Nikander
>
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &n= bsp;          http://playground.sun.com/ipng
> FTP = archive:           = ;           ftp://playground.sun.com/pub/i= png
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>

------_=_NextPart_001_01C1D0FF.CD463FE1-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 10:28:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LISsKL025496 for ; Thu, 21 Mar 2002 10:28:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LISsDR025495 for ipng-dist; Thu, 21 Mar 2002 10:28:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LISoKL025488 for ; Thu, 21 Mar 2002 10:28:51 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA29385 for ; Thu, 21 Mar 2002 10:28:51 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06050 for ; Thu, 21 Mar 2002 10:28:54 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2LIShW22331; Thu, 21 Mar 2002 12:28:44 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 21 Mar 2002 12:28:44 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02B8657D@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: "Glenn Morrow", jarno.rajahalme@nokia.com, ipng@sunroof.eng.sun.com Cc: hinden@iprg.nokia.com Subject: RE: New WG flow label draft (-01) Date: Thu, 21 Mar 2002 12:28:41 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D106.39DABCD0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D106.39DABCD0 Content-Type: text/plain; charset="iso-8859-1" However, I still think the MUST not be changed statement may limit its future potential. For instance what if the signaling used explicitly indicated that the field could be changed or not changed en-route. This seems to handle the case when applications would want the label to change or not. -----Original Message----- From: Morrow, Glenn [RICH2:C330:EXCH] Sent: Wednesday, March 20, 2002 11:00 PM To: jarno.rajahalme@nokia.com; ipng@sunroof.eng.sun.com Cc: hinden@iprg.nokia.com Subject: RE: New WG flow label draft (-01) This looks very good and informative. Thank You. > -----Original Message----- > From: jarno.rajahalme@nokia.com [ mailto:jarno.rajahalme@nokia.com ] > Sent: Wednesday, March 20, 2002 7:09 PM > To: ipng@sunroof.eng.sun.com > Cc: hinden@iprg.nokia.com > Subject: New WG flow label draft (-01) > > > Hi, > > We had some face-to-face time on Tuesday, which resulted into > a new revision of the flow label draft. The presentation on > Thursday will be based on this. > > Jarno > > <> > > ------_=_NextPart_001_01C1D106.39DABCD0 Content-Type: text/html; charset="iso-8859-1" RE: New WG flow label draft (-01)
However, I still think the MUST not be changed statement may limit its future potential. For instance what if the signaling used explicitly indicated that the field could be changed or not changed en-route. This seems to handle the case when applications would want the label to change or not.
-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH]
Sent: Wednesday, March 20, 2002 11:00 PM
To: jarno.rajahalme@nokia.com; ipng@sunroof.eng.sun.com
Cc: hinden@iprg.nokia.com
Subject: RE: New WG flow label draft (-01)

This looks very good and informative. Thank You.

> -----Original Message-----
> From: jarno.rajahalme@nokia.com [mailto:jarno.rajahalme@nokia.com]
> Sent: Wednesday, March 20, 2002 7:09 PM
> To: ipng@sunroof.eng.sun.com
> Cc: hinden@iprg.nokia.com
> Subject: New WG flow label draft (-01)
>
>
> Hi,
>
> We had some face-to-face time on Tuesday, which resulted into
> a new revision of the flow label draft. The presentation on
> Thursday will be based on this.
>
>       Jarno
>
>  <<draft-ietf-ipv6-flow-label-01.txt>>
>
>

------_=_NextPart_001_01C1D106.39DABCD0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 11:59:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LJxbKL025849 for ; Thu, 21 Mar 2002 11:59:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LJxbe1025848 for ipng-dist; Thu, 21 Mar 2002 11:59:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LJxYKL025841 for ; Thu, 21 Mar 2002 11:59:34 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA06658 for ; Thu, 21 Mar 2002 11:59:36 -0800 (PST) From: john.loughney@nokia.com Received: from mgw-x2.nokia.com (mgw-x2.nokia.com [131.228.20.22]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12832 for ; Thu, 21 Mar 2002 12:59:35 -0700 (MST) Received: from esvir02nok.ntc.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34]) by mgw-x2.nokia.com (Switch-2.2.1/Switch-2.2.0) with ESMTP id g2LJxkt28726 for ; Thu, 21 Mar 2002 21:59:47 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir02nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 21 Mar 2002 21:59:33 +0200 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.3779); Thu, 21 Mar 2002 21:59:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Node Requirements team Date: Thu, 21 Mar 2002 21:59:32 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEFC64CA9@esebe004.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Allocating a bit in the RFC2374 Interface Identifier Thread-Index: AcHQ/mlyH/la8ibqSbqWXXz9mV5qoAAE32+A To: X-OriginalArrivalTime: 21 Mar 2002 19:59:33.0301 (UTC) FILETIME=[EB74EE50:01C1D112] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2LJxYKL025842 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I unintentially left Marc Blanchet off of the Node Requirements team on my presentation today. This was a mistake, so I wanted to appologize to Marc & let the WG know that he is part of the team. John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 12:18:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LKIlKL025909 for ; Thu, 21 Mar 2002 12:18:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LKIl54025908 for ipng-dist; Thu, 21 Mar 2002 12:18:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LKIiKL025901 for ; Thu, 21 Mar 2002 12:18:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20379 for ; Thu, 21 Mar 2002 12:18:46 -0800 (PST) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16768 for ; Thu, 21 Mar 2002 13:18:45 -0700 (MST) Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 21 Mar 2002 12:18:42 -0800 Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 21 Mar 2002 12:18:44 -0800 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 21 Mar 2002 12:18:44 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 21 Mar 2002 12:18:43 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Thu, 21 Mar 2002 12:15:32 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Thu, 21 Mar 2002 12:15:34 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102DB802A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Allocating a bit in the RFC2374 Interface Identifier thread-index: AcHQ/gZ6rPS8Ecz/QEijwqTkLe9M8gAFcysw From: "Dave Thaler" To: X-OriginalArrivalTime: 21 Mar 2002 20:15:32.0147 (UTC) FILETIME=[26F93830:01C1D115] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2LKIiKL025902 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore writes: > > Well, the original idea was to reserve a bit to indicate that the > > address is Cryptographically Generaged Address (CGA), basically > > meaning that > > > > if the bit is set, then > > interface id = low64(hash(PK, stuff)) & mask > > > > where > > PK is a public key to be used as an identifier for the host > > stuff is contains other parameters (see the earlier messages) > > hash is a cryptographic hash function, e.g. SHA1 > > low64 is a function that takes lowest 64 bits > > mask indicates that we have to clear/set some bits of the iid > > > > In essense, that would allow anyone to determine if a given public > > key belongs to a host, just inspecting the public key, the address, > > and the "stuff" above. See e.g. > > given that you need all of that "stuff" in order to verify the key > anyway, why not make the CGA bit part of that "stuff" also? Because that has a big security hole known as "bidding down". A node receiving a packet from a spoofer, who can put whatever they want in the packet, wants to verify one thing: that the packet was sent by an entity which really "owns" (i.e. has a private key corresponding to) the source address, with extremely high probability. For transition (and maybe other reasons), the receiving node wants to also be able to communicate with nodes which do not do the above, and hence needs to distinguish upon receipt of the packet in question whether it should drop the packet because the "owner" of the source address (which may or may not be reachable at that instant) would have always included the authentication data, or not. Since a spoofer can construct any packet they like, and NOT include any authentication data, a bit in the source address seems to be the only way for a receiver who cares, to know whether to drop it (because auth data is missing) or accept it (because it's a legacy insecure address). -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 21 12:27:27 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LKRQKL025958 for ; Thu, 21 Mar 2002 12:27:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LKRQm9025957 for ipng-dist; Thu, 21 Mar 2002 12:27:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LKRNKL025950 for ; Thu, 21 Mar 2002 12:27:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA12819 for ; Thu, 21 Mar 2002 12:27:25 -0800 (PST) Received: from n2.nomadiclab.com (n2.nomadiclab.com [131.160.193.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA09856 for ; Thu, 21 Mar 2002 13:27:24 -0700 (MST) Received: from d2.nomadiclab.com (bastion [131.160.194.2]) by n2.nomadiclab.com (Postfix) with ESMTP id 8AEE922E15; Thu, 21 Mar 2002 22:25:45 +0200 (EET) Received: from nomadiclab.com (localhost [127.0.0.1]) by d2.nomadiclab.com (Postfix) with ESMTP id 39362BA03; Thu, 21 Mar 2002 22:27:16 +0200 (EET) Message-ID: <3C9A4270.9000104@nomadiclab.com> Date: Thu, 21 Mar 2002 14:28:32 -0600 From: Pekka Nikander User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020307 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy Cc: Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF187@TNEXVS02.tahoenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mohan Parthasarathy wrote: > "Now, when bob receives the packet sent by Alice, he has no other knowledge > about Alice except the packet itself. In particular, the only information > he has about Alice is the source IP address in the packet". > > I am missing something here. Isn't the packet carrying any other > information at all ? An attacker can change any field in the packet. However, if the attacker changes the source address, the packet is not about Alice any more. Thus, the packet does carry information, but the only piece of information that can be _securely_ relied on is the address. I think others, like Dave Thaler, are saying this more clearly here, probably due to my shortcomings in handling the English language. --Pekka -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 12:40:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LKeBKL026031 for ; Thu, 21 Mar 2002 12:40:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LKeBWQ026030 for ipng-dist; Thu, 21 Mar 2002 12:40:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LKe8KL026023 for ; Thu, 21 Mar 2002 12:40:08 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA15744 for ; Thu, 21 Mar 2002 12:40:10 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA05634 for ; Thu, 21 Mar 2002 13:40:09 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 9C3116A901; Thu, 21 Mar 2002 22:39:52 +0200 (EET) Message-ID: <3C9A456C.1030004@kolumbus.fi> Date: Thu, 21 Mar 2002 22:41:16 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Mohan Parthasarathy Cc: Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF187@TNEXVS02.tahoenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mohan Parthasarathy wrote: > t very clear as to why you have to reserve a bit in the > address to express different security mechanisms being used. Why can't > this be built into the protocol itself ? Is it because that the future > security mechanisms will not use the same set of message exchanges as > RR and hence you want a protocol independent way of indicating the method ? > I would assume that any mechanism to establish the binding between home > address and care of address would have a few message exchanges. Can you Because the MitM attacker can change everything related to these messages, it doesn't help to put anything to the messages for the bidding down protection. Note that the MitM can also change the IP address, but if he does so, he is *not* attacking the original host, as the address is changed. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 12:51:33 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LKpXKL026133 for ; Thu, 21 Mar 2002 12:51:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LKpXKA026132 for ipng-dist; Thu, 21 Mar 2002 12:51:33 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LKpTKL026125 for ; Thu, 21 Mar 2002 12:51:30 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA26194 for ; Thu, 21 Mar 2002 12:51:32 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA01769 for ; Thu, 21 Mar 2002 13:51:30 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2LKpN713095; Thu, 21 Mar 2002 21:51:23 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id VAA03071; Thu, 21 Mar 2002 21:51:23 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2LKpMg75993; Thu, 21 Mar 2002 21:51:22 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203212051.g2LKpMg75993@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Dave Thaler" cc: ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2374 Interface Identifier In-reply-to: Your message of Thu, 21 Mar 2002 12:15:34 PST. <2E33960095B58E40A4D3345AB9F65EC102DB802A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 21 Mar 2002 21:51:22 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have three concerns about this CGA/KBA idea: - first this idea is about interface IDs, not addresses (so for Mobile IPv6 we need Return Routability too). Kempf's I-D about neighbor discovery is about real addresses and ABK (address based keys) which has not this and the last concerns. - second the verification implies an expensive crypto operation (typically a signature check) so the scheme is subject to trival DoS attack, especially if each packet has to be checked (so or a session key is negociated with an even more expensive and complex protocol, or the use of CGA/KBA is very limited). - last I don't believe you can manage real trust with only one bit and if you need more bits to negociate someting the IPv6 address will become quickly too small. IMHO this is a dead-end. And please apply some "commercial" considerations to this kind of schemes: if the burden is for someone and the benefit is for another one, this shall never work in the real world. Regards Francis.Dupont@enst-bretagne.fr PS: Dave, this message has nothing to do with you... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 13:06:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LL6DKL026164 for ; Thu, 21 Mar 2002 13:06:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LL6Cpp026163 for ipng-dist; Thu, 21 Mar 2002 13:06:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LL68KL026156 for ; Thu, 21 Mar 2002 13:06:09 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA02836 for ; Thu, 21 Mar 2002 13:06:03 -0800 (PST) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA08494 for ; Thu, 21 Mar 2002 14:06:02 -0700 (MST) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 21 Mar 2002 13:06:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D11C.33D6E8BB" Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Thu, 21 Mar 2002 13:06:00 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF189@TNEXVS02.tahoenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Allocating a bit in the RFC2374 Interface Identifier Thread-Index: AcHRGJiNgVvU8uB1ReqtLeAOG1gHbgAAkzMw From: "Mohan Parthasarathy" To: "Jari Arkko" Cc: "Pekka Nikander" , "Pekka Savola" , , "Erik Nordmark" X-OriginalArrivalTime: 21 Mar 2002 21:06:00.0532 (UTC) FILETIME=[34081940:01C1D11C] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1D11C.33D6E8BB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 >=20 >=20 > Mohan Parthasarathy wrote: >=20 > > t very clear as to why you have to reserve a bit in the address to=20 > > express different security mechanisms being used. Why can't this be=20 > > built into the protocol itself ? Is it because that the future=20 > > security mechanisms will not use the same set of message=20 > exchanges as=20 > > RR and hence you want a protocol independent way of indicating the=20 > > method ? I would assume that any mechanism to establish the binding=20 > > between home address and care of address would have a few message=20 > > exchanges. Can you >=20 > Because the MitM attacker can change everything related to=20 > these messages, it doesn't help to put anything to the=20 > messages for the bidding down protection. >=20 > Note that the MitM can also change the IP address, but if he=20 > does so, he is *not* attacking the original host, as the=20 > address is changed. >=20 Ok. This is not very obvious (at least to me). It would be useful to put this in some document. Is it possible that the MN can use both the RR and secure (that is to be defined in the future) mechanism under different occasions ? This means MN should be able to recognise both the addresses.=20 If MN sets the bit (means do something more secure than RR) and attacker clears the bit, the response will still come back and the assumption is MN will be able to detect this. Similarly, when the bit is cleared but set by the attacker. I did not see a good analysis on this (though I saw some references in Pekka's and your other document). Perhaps missed it.. Sorry if this discussion should be happening in mobile-ip working group. But I guess we are evaluating the motivation for reserving the bits. So, I guess it is okay. thanks mohan > Jari >=20 >=20 ------_=_NextPart_001_01C1D11C.33D6E8BB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Allocating a bit in the RFC2374 Interface Identifier

 
>
>
> Mohan Parthasarathy wrote:
>
> > t very clear as to why you have to reserve = a bit in the address to
> > express different security mechanisms being = used. Why can't this be
> > built into the protocol itself ? Is it = because that the future
> > security mechanisms will not use the same = set of message
> exchanges as
> > RR and hence you want a protocol = independent way of indicating the
> > method ? I would assume that any mechanism = to establish the binding
> > between home address and care of = address  would have a few message
> > exchanges. Can you
>
> Because the MitM attacker can change everything = related to
> these messages, it doesn't help to put anything = to the
> messages for the bidding down protection.
>
> Note that the MitM can also change the IP = address, but if he
> does so, he is *not* attacking the original = host, as the
> address is changed.
>
Ok. This is not very obvious (at least to me). It = would be useful
to put this in some document.

Is it possible that the MN can use both the RR and = secure (that is
to be defined in the future) mechanism under = different occasions ?
This means MN should be able to recognise both the = addresses.
If MN sets the bit (means do something more secure = than RR) and
attacker clears the bit, the response will still come = back and
the assumption is MN will be able to detect this. = Similarly, when
the bit is cleared but set by the attacker. I did not = see a good
analysis on this (though I saw some references in = Pekka's and your
other document). Perhaps missed it..

Sorry if this discussion should be happening in = mobile-ip working
group. But I guess we are evaluating the motivation = for reserving
the bits. So, I guess it is okay.

thanks
mohan


> Jari
>
>

------_=_NextPart_001_01C1D11C.33D6E8BB-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 13:18:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LLIbKL026207 for ; Thu, 21 Mar 2002 13:18:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LLIbMq026206 for ipng-dist; Thu, 21 Mar 2002 13:18:37 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LLIYKL026199 for ; Thu, 21 Mar 2002 13:18:34 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA06510 for ; Thu, 21 Mar 2002 13:18:36 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA22569 for ; Thu, 21 Mar 2002 14:18:36 -0700 (MST) content-class: urn:content-classes:message Subject: (ipv6) semantics - TLA MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Thu, 21 Mar 2002 13:18:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046406C492@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: poposed changes to the scoping architecture draft Thread-Index: AcHPj3PPEOqmPks+T3iFGI9R1hOY3wBjRkwg From: "Michel Py" To: , "ipv6mh" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2LLIYKL026200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk As pointed out in the 6bone meeting today and on the ipv6mh list, there is a semantics issue using the acronym "TLA". Unless we have missed something, it does not exist anymore. 1. We still need a word or acronym to describe the concept, even though it does not aggregate at the /16 boundary. 2. The 6bone uses the acronym "pTLA". Instead of re-inventing the wheel, I propose to amend draft-ietf-ipngwg-addr-arch-v3-07.txt to include a definition of "TLA". Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 13:27:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LLRpKL026239 for ; Thu, 21 Mar 2002 13:27:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LLRpIN026238 for ipng-dist; Thu, 21 Mar 2002 13:27:51 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LLRmKL026231 for ; Thu, 21 Mar 2002 13:27:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA26780 for ; Thu, 21 Mar 2002 13:27:50 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA19009 for ; Thu, 21 Mar 2002 14:27:48 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2LLRjM11040; Thu, 21 Mar 2002 23:27:45 +0200 Date: Thu, 21 Mar 2002 23:27:45 +0200 (EET) From: Pekka Savola To: Dave Thaler cc: ipng@sunroof.eng.sun.com Subject: RE: Allocating a bit in the RFC2374 Interface Identifier In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC102DB802A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 21 Mar 2002, Dave Thaler wrote: > For transition (and maybe other reasons), the receiving node wants to > also be able to communicate with nodes which do not do the above, and > hence needs to distinguish upon receipt of the packet in question > whether it should drop the packet because the "owner" of the source > address (which may or may not be reachable at that instant) would have > always included the authentication data, or not. > > Since a spoofer can construct any packet they like, and NOT include any > authentication data, a bit in the source address seems to be the only > way for a receiver who cares, to know whether to drop it (because auth > data is missing) or accept it (because it's a legacy insecure address). What about the receiver having two IP-addresses, one for legacy and one for "secure-only" source addresses? Then the receiver can at least be sure that the packets received at the "secure" IP address would not be spoofed as they will always be verified. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 13:28:01 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LLS0KL026249 for ; Thu, 21 Mar 2002 13:28:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LLS03C026248 for ipng-dist; Thu, 21 Mar 2002 13:28:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LLRuKL026241 for ; Thu, 21 Mar 2002 13:27:56 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA11564 for ; Thu, 21 Mar 2002 13:27:59 -0800 (PST) Received: from iol.unh.edu (io.iol.unh.edu [132.177.123.82]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA19060 for ; Thu, 21 Mar 2002 14:27:58 -0700 (MST) Received: from io.iol.unh.edu (localhost.localdomain [127.0.0.1]) by iol.unh.edu (8.12.2/8.12.2) with ESMTP id g2LLR5VM022907; Thu, 21 Mar 2002 16:27:06 -0500 Received: from localhost (jfl@localhost) by io.iol.unh.edu (8.12.2/8.12.1/Submit) with ESMTP id g2LLR5vt022904; Thu, 21 Mar 2002 16:27:05 -0500 X-Authentication-Warning: io.iol.unh.edu: jfl owned process doing -bs Date: Thu, 21 Mar 2002 16:27:05 -0500 (EST) From: "John F. Leser" To: Erik Nordmark cc: Pekka Savola , Pekka Nikander , Subject: Re: Allocating a bit in the RFC2374 Interface Identifier In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just an idea: If there is an entire class of problems that can only be solved by a flag in the address itself, why not reserve the top 16 bits of the Interface Identifier? To put it another way, if having semantically significant bits in the address is the best solution for a problem or two now, we might well want more bits in the future. Also, if we are not going to support a full 64-bit identifier, 48-bits is the next logical break. -John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 13:29:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LLT3KL026273 for ; Thu, 21 Mar 2002 13:29:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LLT3jA026272 for ipng-dist; Thu, 21 Mar 2002 13:29:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LLSxKL026265 for ; Thu, 21 Mar 2002 13:28:59 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA27057 for ; Thu, 21 Mar 2002 13:29:02 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA27637 for ; Thu, 21 Mar 2002 14:29:00 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2LLSkn11048; Thu, 21 Mar 2002 23:28:47 +0200 Date: Thu, 21 Mar 2002 23:28:46 +0200 (EET) From: Pekka Savola To: Francis Dupont cc: Dave Thaler , Subject: Re: Allocating a bit in the RFC2374 Interface Identifier In-Reply-To: <200203212051.g2LKpMg75993@givry.rennes.enst-bretagne.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 21 Mar 2002, Francis Dupont wrote: > - last I don't believe you can manage real trust with only one bit > and if you need more bits to negociate someting the IPv6 address > will become quickly too small. IMHO this is a dead-end. 100% agree. > And please apply some "commercial" considerations to this kind of > schemes: if the burden is for someone and the benefit is for another one, > this shall never work in the real world. 110% agree. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 13:31:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LLV9KL026290 for ; Thu, 21 Mar 2002 13:31:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LLV9Ba026289 for ipng-dist; Thu, 21 Mar 2002 13:31:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LLV5KL026282 for ; Thu, 21 Mar 2002 13:31:05 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA10632 for ; Thu, 21 Mar 2002 13:31:08 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA07094 for ; Thu, 21 Mar 2002 13:31:10 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2LLV2Y11099; Thu, 21 Mar 2002 23:31:03 +0200 Date: Thu, 21 Mar 2002 23:31:02 +0200 (EET) From: Pekka Savola To: Michel Py cc: ipng@sunroof.eng.sun.com, ipv6mh Subject: Re: (ipv6) semantics - TLA In-Reply-To: <2B81403386729140A3A899A8B39B046406C492@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 21 Mar 2002, Michel Py wrote: > As pointed out in the 6bone meeting today and on the ipv6mh list, there is a semantics issue using the acronym "TLA". Unless we have missed something, it does not exist anymore. > > 1. We still need a word or acronym to describe the concept, even though it does not aggregate at the /16 boundary. > 2. The 6bone uses the acronym "pTLA". > > Instead of re-inventing the wheel, I propose to amend draft-ietf-ipngwg-addr-arch-v3-07.txt to include a definition of "TLA". I'm not sure if the term is useful for _address architecture_ point of view at all -- how routing is managed is another thing altogether, and should not be messed up with standards documents. Or perhaps you should describe in detail what the term would be useful for in this context? -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 13:34:34 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LLYYKL026307 for ; Thu, 21 Mar 2002 13:34:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LLYYUN026306 for ipng-dist; Thu, 21 Mar 2002 13:34:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LLYVKL026299 for ; Thu, 21 Mar 2002 13:34:31 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA28573 for ; Thu, 21 Mar 2002 13:34:33 -0800 (PST) Received: from Kairos.dsa.uqam.ca (kairos.dsa.uqam.ca [132.208.43.57]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00870 for ; Thu, 21 Mar 2002 14:34:32 -0700 (MST) Received: from localhost (bill@localhost) by Kairos.dsa.uqam.ca (8.11.4/8.11.4) with ESMTP id g2LLQKO28052; Thu, 21 Mar 2002 16:26:20 -0500 Date: Thu, 21 Mar 2002 16:26:20 -0500 (EST) From: Bill Strahm X-X-Sender: To: Michel Py cc: , ipv6mh Subject: Re: (ipv6) semantics - TLA In-Reply-To: <2B81403386729140A3A899A8B39B046406C492@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Wow, now we are overloading the acronym TLA... I just got that today for no good reason... TLA: Old acronym that stands for Three Letter Acronym. Technical bodies enjoy creating these objects in their standards TLAng: Next Generation acronym that stands for Top Level Aggregator. See TLA. Sorry, I will take the blame if that shows up in an RFC in April. Bill On Thu, 21 Mar 2002, Michel Py wrote: > As pointed out in the 6bone meeting today and on the ipv6mh list, there is a semantics issue using the acronym "TLA". Unless we have missed something, it does not exist anymore. > > 1. We still need a word or acronym to describe the concept, even though it does not aggregate at the /16 boundary. > 2. The 6bone uses the acronym "pTLA". > > Instead of re-inventing the wheel, I propose to amend draft-ietf-ipngwg-addr-arch-v3-07.txt to include a definition of "TLA". > > Michel. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 21 13:58:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LLwNKL026364 for ; Thu, 21 Mar 2002 13:58:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LLwNgn026363 for ipng-dist; Thu, 21 Mar 2002 13:58:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LLwKKL026356 for ; Thu, 21 Mar 2002 13:58:20 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA21837 for ; Thu, 21 Mar 2002 13:58:21 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17597 for ; Thu, 21 Mar 2002 13:58:13 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A33626A901; Thu, 21 Mar 2002 23:58:18 +0200 (EET) Message-ID: <3C9A57D5.6070400@kolumbus.fi> Date: Thu, 21 Mar 2002 23:59:49 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Francis Dupont Cc: Dave Thaler , ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: <200203212051.g2LKpMg75993@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > - second the verification implies an expensive crypto operation > (typically a signature check) so the scheme is subject to trival DoS > attack, especially if each packet has to be checked (so or a session > key is negociated with an even more expensive and complex protocol, > or the use of CGA/KBA is very limited). This issue can be handled. For an example in the mipv6 space, see draft-roe-mobileip-updateauth-02.txt. > - last I don't believe you can manage real trust with only one bit > and if you need more bits to negociate someting the IPv6 address > will become quickly too small. IMHO this is a dead-end. Actually, I think a single bit is sufficient. Given that any information can be included in the hash besides the public key, the usage of the bit is not limited to the one who first claims it. Of course, we probably would want to limit its use but there are no technical problems in using the same hash scheme for multiple purposes. The same applies also to DNS-based and AAA-based schemes as well. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 14:15:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMFIKL026411 for ; Thu, 21 Mar 2002 14:15:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LMFHhN026410 for ipng-dist; Thu, 21 Mar 2002 14:15:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMFGKL026403 for ; Thu, 21 Mar 2002 14:15:16 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2LMEGsl002385 for ; Thu, 21 Mar 2002 14:14:16 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g2LMEG1D002384 for ipng@sunroof.eng.sun.com; Thu, 21 Mar 2002 14:14:16 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LM61KL026373 for ; Thu, 21 Mar 2002 14:06:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06395 for ; Thu, 21 Mar 2002 14:06:02 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06984 for ; Thu, 21 Mar 2002 15:06:01 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E2EF76A901; Fri, 22 Mar 2002 00:05:58 +0200 (EET) Message-ID: <3C9A59A1.4070001@kolumbus.fi> Date: Fri, 22 Mar 2002 00:07:29 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Mohan Parthasarathy Cc: Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF189@TNEXVS02.tahoenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mohan Parthasarathy wrote: > > Note that the MitM can also change the IP address, but if he > > does so, he is *not* attacking the original host, as the > > address is changed. > > > Ok. This is not very obvious (at least to me). It would be useful > to put this in some document. > > Is it possible that the MN can use both the RR and secure (that is > to be defined in the future) mechanism under different occasions ? > This means MN should be able to recognise both the addresses. > If MN sets the bit (means do something more secure than RR) and > attacker clears the bit, the response will still come back and > the assumption is MN will be able to detect this. Similarly, when > the bit is cleared but set by the attacker. I did not see a good > analysis on this (though I saw some references in Pekka's and your > other document). Perhaps missed it.. If a node wants to allow both RR and another more secure method, it can do so simply by allowing it on its RR address. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 14:17:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMHDKL026428 for ; Thu, 21 Mar 2002 14:17:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LMHCGi026427 for ipng-dist; Thu, 21 Mar 2002 14:17:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMH9KL026420 for ; Thu, 21 Mar 2002 14:17:09 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29290 for ; Thu, 21 Mar 2002 14:17:10 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA25291 for ; Thu, 21 Mar 2002 15:17:09 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2LMH0718919; Thu, 21 Mar 2002 23:17:01 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id XAA03740; Thu, 21 Mar 2002 23:17:00 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2LMH0g76351; Thu, 21 Mar 2002 23:17:00 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203212217.g2LMH0g76351@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jari Arkko cc: Dave Thaler , ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2374 Interface Identifier In-reply-to: Your message of Thu, 21 Mar 2002 23:59:49 +0200. <3C9A57D5.6070400@kolumbus.fi> Date: Thu, 21 Mar 2002 23:17:00 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > - second the verification implies an expensive crypto operation > (typically a signature check) so the scheme is subject to trival DoS > attack, especially if each packet has to be checked (so or a session > key is negociated with an even more expensive and complex protocol, > or the use of CGA/KBA is very limited). This issue can be handled. => I don't believe without one of the two options in the parenthesis. For an example in the mipv6 space, see draft-roe-mobileip-updateauth-02.txt. => in this I-D all mechanisms build session keys (typically with a Deffie-Hellman exchange, i.e. IKE-like). The same applies also to DNS-based and AAA-based schemes as well. => infrastructure based systems don't need a bit per idea, sorry (:-). Francis.Dupont@enst-bretagne.fr PS: I am very unsatisfied by the result of today meeting: we are going nowhere (which is not the same thing than not moving). -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 14:22:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMM9KL026493 for ; Thu, 21 Mar 2002 14:22:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LMM9t0026492 for ipng-dist; Thu, 21 Mar 2002 14:22:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMM5KL026485 for ; Thu, 21 Mar 2002 14:22:05 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA29381 for ; Thu, 21 Mar 2002 14:22:06 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA14726 for ; Thu, 21 Mar 2002 15:22:03 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2LMM0t17322; Thu, 21 Mar 2002 17:22:00 -0500 (EST) Message-Id: <200203212222.g2LMM0t17322@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Dave Thaler" cc: ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2374 Interface Identifier In-reply-to: (Your message of "Thu, 21 Mar 2002 12:15:34 PST.") <2E33960095B58E40A4D3345AB9F65EC102DB802A@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 21 Mar 2002 17:21:59 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Since a spoofer can construct any packet they like, and NOT include > any authentication data, a bit in the source address seems to be the > only way for a receiver who cares, to know whether to drop it (because > auth data is missing) or accept it (because it's a legacy insecure > address). yes, but an MitM can lie about the source address also, or launder packets between the the real source and destination. the source address is not much more reliably associated with the source than any other information that might be in a packet. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 14:23:59 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMNxKL026510 for ; Thu, 21 Mar 2002 14:23:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LMNx2j026509 for ipng-dist; Thu, 21 Mar 2002 14:23:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMNvKL026502 for ; Thu, 21 Mar 2002 14:23:57 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2LMMxsl002396 for ; Thu, 21 Mar 2002 14:22:59 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g2LMMwSv002395 for ipng@sunroof.eng.sun.com; Thu, 21 Mar 2002 14:22:58 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LM61KL026373 for ; Thu, 21 Mar 2002 14:06:01 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA06395 for ; Thu, 21 Mar 2002 14:06:02 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA06984 for ; Thu, 21 Mar 2002 15:06:01 -0700 (MST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id E2EF76A901; Fri, 22 Mar 2002 00:05:58 +0200 (EET) Message-ID: <3C9A59A1.4070001@kolumbus.fi> Date: Fri, 22 Mar 2002 00:07:29 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Mohan Parthasarathy Cc: Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: <416B5AF360DED54088DAD3CA8BFBEA6E1DF189@TNEXVS02.tahoenetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mohan Parthasarathy wrote: > > Note that the MitM can also change the IP address, but if he > > does so, he is *not* attacking the original host, as the > > address is changed. > > > Ok. This is not very obvious (at least to me). It would be useful > to put this in some document. > > Is it possible that the MN can use both the RR and secure (that is > to be defined in the future) mechanism under different occasions ? > This means MN should be able to recognise both the addresses. > If MN sets the bit (means do something more secure than RR) and > attacker clears the bit, the response will still come back and > the assumption is MN will be able to detect this. Similarly, when > the bit is cleared but set by the attacker. I did not see a good > analysis on this (though I saw some references in Pekka's and your > other document). Perhaps missed it.. If a node wants to allow both RR and another more secure method, it can do so simply by allowing it on its RR address. Jari From - Thu Mar 21 14:22:31 2002 Return-Path: Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMKNbu254799 for ; Thu, 21 Mar 2002 14:20:23 -0800 (PST) Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMKKKL026471 for ; Thu, 21 Mar 2002 14:20:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LMKKRU026470; Thu, 21 Mar 2002 14:20:20 -0800 (PST) Date: Thu, 21 Mar 2002 14:20:20 -0800 (PST) From: owner-ipng@sunroof.eng.sun.com Message-Id: <200203212220.g2LMKKRU026470@sunroof.eng.sun.com> X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f To: owner-ipng@sunroof.eng.sun.com Subject: BOUNCE ipng@sunroof.eng.sun.com: Admin request of type /\bchange\b.*\baddress\b/ at line 1 Content-Length: 1629 From owner-ipng Thu Mar 21 14:20:16 2002 Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMKGKL026463 for ; Thu, 21 Mar 2002 14:20:16 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23528; Thu, 21 Mar 2002 14:20:17 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09245; Thu, 21 Mar 2002 15:20:16 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2LMImt17284; Thu, 21 Mar 2002 17:18:48 -0500 (EST) Message-Id: <200203212218.g2LMImt17284@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jari Arkko cc: Mohan Parthasarathy , Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier In-reply-to: (Your message of "Thu, 21 Mar 2002 22:41:16 +0200.") <3C9A456C.1030004@kolumbus.fi> Date: Thu, 21 Mar 2002 17:18:48 -0500 Sender: moore@cs.utk.edu > Note that the MitM can also change the IP address, but if he does > so, he is *not* attacking the original host, as the address is > changed. unless of course the MitM can convince that host to take on that address as an alias. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 14:33:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMXNKL026587 for ; Thu, 21 Mar 2002 14:33:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LMXNE7026586 for ipng-dist; Thu, 21 Mar 2002 14:33:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMXLKL026579 for ; Thu, 21 Mar 2002 14:33:21 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2LMWMsl002411 for ; Thu, 21 Mar 2002 14:32:22 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g2LMWMHq002410 for ipng@sunroof.eng.sun.com; Thu, 21 Mar 2002 14:32:22 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMKGKL026463 for ; Thu, 21 Mar 2002 14:20:16 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA23528; Thu, 21 Mar 2002 14:20:17 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA09245; Thu, 21 Mar 2002 15:20:16 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2LMImt17284; Thu, 21 Mar 2002 17:18:48 -0500 (EST) Message-Id: <200203212218.g2LMImt17284@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Jari Arkko cc: Mohan Parthasarathy , Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier In-reply-to: (Your message of "Thu, 21 Mar 2002 22:41:16 +0200.") <3C9A456C.1030004@kolumbus.fi> Date: Thu, 21 Mar 2002 17:18:48 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Note that the MitM can also change the IP address, but if he does > so, he is *not* attacking the original host, as the address is > changed. unless of course the MitM can convince that host to take on that address as an alias. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 14:43:29 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMhTKL026624 for ; Thu, 21 Mar 2002 14:43:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LMhTde026623 for ipng-dist; Thu, 21 Mar 2002 14:43:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMhPKL026616 for ; Thu, 21 Mar 2002 14:43:25 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA08947 for ; Thu, 21 Mar 2002 14:43:26 -0800 (PST) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [195.212.91.200]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA04490 for ; Thu, 21 Mar 2002 15:43:25 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (1.0.0) with ESMTP id XAA24964; Thu, 21 Mar 2002 23:43:09 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2LMh9F79386; Thu, 21 Mar 2002 23:43:09 +0100 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA17846 from ; Thu, 21 Mar 2002 23:43:04 +0100 Message-Id: <3C9A61E4.A97D873A@hursley.ibm.com> Date: Thu, 21 Mar 2002 23:42:44 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "John F. Leser" Cc: Erik Nordmark , Pekka Savola , Pekka Nikander , ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Kind of tricky for FireWire Brian "John F. Leser" wrote: > > Just an idea: > > If there is an entire class of problems that can only be solved by a flag > in the address itself, why not reserve the top 16 bits of the Interface > Identifier? To put it another way, if having semantically significant > bits in the address is the best solution for a problem or two now, we > might well want more bits in the future. Also, if we are not going to > support a full 64-bit identifier, 48-bits is the next logical break. > > -John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 14:47:48 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMlmKL026644 for ; Thu, 21 Mar 2002 14:47:48 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LMlmKF026643 for ipng-dist; Thu, 21 Mar 2002 14:47:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMliKL026636 for ; Thu, 21 Mar 2002 14:47:44 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA10277 for ; Thu, 21 Mar 2002 14:47:45 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA06616 for ; Thu, 21 Mar 2002 15:47:33 -0700 (MST) Received: from localhost ([2001:460:1:210:202:2dff:fe46:6808]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2LMlHo08665; Fri, 22 Mar 2002 07:47:18 +0900 (JST) Date: Fri, 22 Mar 2002 07:47:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-Reply-To: <4.2.2.20020321080740.01ec9100@mail.windriver.com> References: <200203201653.g2KGrFg70803@givry.rennes.enst-bretagne.fr> <200203210854.KAA04603@burp.tkv.asdf.org> <4.2.2.20020321080740.01ec9100@mail.windriver.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 59 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 21 Mar 2002 08:13:44 -0500, >>>>> Margaret Wasserman said: >> Thus I prefer >> >>
% >> >> and scope type is from address. > I also prefer this notation. It removes any ambiguity about > what a node is supposed to do if the address and the scope > number don't match. Then, does the following plan make sense? - in the definition of zone indices (Section 6 in the 03 draft), specify that a zone ID includes its scope type and an ID in the scope when an implementation handles the zone IDs. - in the textual representation, only define the form of
% and specify that will be translated into an (implementation-dependent) internal form containing both scope type and the zone in the scope. >> And, then make sure every address has >> a definite scope designated (the ones for which scope is a bit unclear >> are/were :: and "::/3" (eg. those pesky IPv4 mappen and kind >> addresses). > Every address has to have a scope, anyway, because routers need to know > when/if a packets should be forwarded. If an address should not be > forwarded at all, it is link-local. If it should be constrained > within a site, it is site-local. If it can be forwarded anywhere, it > is global. If this information is undefined for one or more types > of addresses, we need to define it. It's true that a packet with link-local src or dst should not be forwarded across a link border. However, I do not think it is always true that "if an address should not be forwarded at all, it is link-local." For example, a packet with a multicast source address should not be forwarded, even if the address has a global scope. We'll have to specify how a packet with bogus addresses should be treated, and it may not always be a scoping issue. I think the unspecified address falls into this type of bogus address, and makes much sense to treat it as "no scope" than link-local. > If an address is never meant to be used on the wire, it is effectively > node-local. For a unicast addresses, I think that we should consider > these addresses link-local. That way, mistakes won't be propagated > across the network. (an additional note which is not related to this discussion) the notion of "node-local" has been deprecated. It has been replaced with the notion of "interface-local". JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 21 14:50:08 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMo7KL026661 for ; Thu, 21 Mar 2002 14:50:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LMo7si026660 for ipng-dist; Thu, 21 Mar 2002 14:50:07 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMo4KL026653 for ; Thu, 21 Mar 2002 14:50:04 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA17887; Thu, 21 Mar 2002 14:50:05 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA08321; Thu, 21 Mar 2002 15:50:03 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2LMno721406; Thu, 21 Mar 2002 23:49:50 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id XAA04069; Thu, 21 Mar 2002 23:49:50 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2LMnog76496; Thu, 21 Mar 2002 23:49:50 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203212249.g2LMnog76496@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Brian E Carpenter cc: "John F. Leser" , Erik Nordmark , Pekka Savola , Pekka Nikander , ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2374 Interface Identifier In-reply-to: Your message of Thu, 21 Mar 2002 23:42:44 +0100. <3C9A61E4.A97D873A@hursley.ibm.com> Date: Thu, 21 Mar 2002 23:49:50 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Kind of tricky for FireWire => Brian, do you suggest that FireWire (aka I-Link aka IEEE 1394) uses 64 bit addresses? Regards Francis.Dupont@enst-bretagne.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 Thu Mar 21 14:51:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMpfKL026678 for ; Thu, 21 Mar 2002 14:51:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LMpfsO026677 for ipng-dist; Thu, 21 Mar 2002 14:51:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMpcKL026670 for ; Thu, 21 Mar 2002 14:51:38 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA11780 for ; Thu, 21 Mar 2002 14:51:39 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA02507 for ; Thu, 21 Mar 2002 14:51:42 -0800 (PST) content-class: urn:content-classes:message Subject: RE: (ipv6) semantics - TLA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Mar 2002 14:51:33 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C493@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (ipv6) semantics - TLA Thread-Index: AcHRH9WK/FwdYnD5TZyPuBRmcGwJcAACO4sg From: "Michel Py" To: "Pekka Savola" Cc: , "ipv6mh" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2LMpcKL026671 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Pekka Savola wrote: > Or perhaps you should describe in detail what the term would > be useful for in this context? There different things involved: - Allocation policies, which is "We give a /32 to Joe for this reason and a /35 to Jane for that reason". - Aggregation policies, which is "All networks matching criteria xyz must aggregate at the /xx boundary". - Addressing architecture, which does not define how to do it but what is is. The point I am trying to make here is that we need a name or acronym for "ISPs that receive their addresses directly from a RIR". I am not saying that "TLA" is the best definition, but it does fit, regardless of allocation policies and aggregation policies. There was a reason it was defined in RFC2373 and the changes to draft-ietf-ipngwg-addr-arch-v3-07.txt have not changed this, AFAIK. I am not proposing to define "TLA" or whatever we come up with as an aggregation policy, but as the concept of ISPs that receive their blocks directly for a registry. How big the block they get is an allocation policy issue, where they aggregate is an aggregation policy issue, who they are is an addressing architecture issue. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 14:55:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMtkKL026697 for ; Thu, 21 Mar 2002 14:55:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LMtk1I026696 for ipng-dist; Thu, 21 Mar 2002 14:55:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMthKL026689 for ; Thu, 21 Mar 2002 14:55:43 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19493 for ; Thu, 21 Mar 2002 14:55:44 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11086 for ; Thu, 21 Mar 2002 15:55:43 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2LMtfR11856 for ; Fri, 22 Mar 2002 00:55:41 +0200 Date: Fri, 22 Mar 2002 00:55:41 +0200 (EET) From: Pekka Savola To: ipng@sunroof.eng.sun.com Subject: Prefix delegation options Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I wanted to add a few cents to the discussion, triggered by Francis saying we're going nowhere :-) - router renumbering hasn't been made to work yet, so I doubt that's a good option - pppext might be workable for PPP connections, and is a valid mechanism especially if there is no simple alternative (e.g. if the only alternative is full statefull DHCPv6). - dhcpv6 will work ok, I think, but is a bit complex for being usable in every scenario - APD w/ ICMPv6 is ok but can be simplified (e.g. removing prefix return message) - RA (Lutchansky) is a nice hack, kinda works with hacking. So, IMO the real mainstream solutions will either be: - A combination of APD + RA (Lutchansky), closer to APD - DHCPv6 I think we don't end up with just one mechanism due to different requirements. The choice will be partially dependent on the fact whether configuring the router and nodes (DNS, NTP, ...) will be necessary and/or how. These are two different problems though. DNS etc. only make sense *after* obtaining the prefix. Note that IMO, configuring these with "stateless DHCPv6" but obtaining the prefix with e.g. APD makes perfect sense -- there might be reluctance to implement full DHCP, or even the minimal set of "stateful" DHCP. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 14:56:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMujKL026722 for ; Thu, 21 Mar 2002 14:56:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LMujrS026721 for ipng-dist; Thu, 21 Mar 2002 14:56:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LMufKL026714 for ; Thu, 21 Mar 2002 14:56:41 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA19939 for ; Thu, 21 Mar 2002 14:56:37 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA04171 for ; Thu, 21 Mar 2002 14:56:39 -0800 (PST) Received: from localhost ([2001:460:1:210:202:2dff:fe46:6808]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2LMuTo08797; Fri, 22 Mar 2002 07:56:29 +0900 (JST) Date: Fri, 22 Mar 2002 07:56:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Markku Savela Cc: ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-Reply-To: <200203210854.KAA04603@burp.tkv.asdf.org> References: <200203201653.g2KGrFg70803@givry.rennes.enst-bretagne.fr> <200203210854.KAA04603@burp.tkv.asdf.org> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 50 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 21 Mar 2002 10:54:25 +0200, >>>>> Markku Savela said: > The >
%. > just does not feel right to me. I don't like notations which allow > writing erroneous expressions, whenever it can be avoided. And, I'm > not yet quite convinced, that this case needs such "error-allowing" > notation. > Thus I prefer >
% As for this, I made another proposal in a reply to Margaret. > and scope type is from address. And, then make sure every address has > a definite scope designated (the ones for which scope is a bit unclear > are/were :: and "::/3" (eg. those pesky IPv4 mappen and kind > addresses). I think ::/3 (except ::/128) should be treated as global, in terms of *IPv6* scoping architecture. (The address selection draft (by Rich Draves) treats (e.g.) ::ffff:10.1.1.1 as site-local, but, in my understanding, the main purpose of this is to compare IPv4 addresses and IPv6 addresses in the destination address ordering in terms of scoping. Thus, I don't think the definition in the scoping arch draft contradicts with the definition in the address selection draft.) > I thought my proposal was nice for listen sockets, you don't need a > special separate socket option to set the scope, if you want to limit > your listen to any address of specificic scope. With definitions > fe80::% - ANY address in specified link local zone > fec0::% - ANY address in specified site zone > and normal bind as before, the process seems very simple (how this is > reflected in internal data structures of listen socket is different, > implementation matter). Honestly, I'm not so fascinated by this trick in API, but anyway, this kind of API extension is out of scope of the architecture draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 21 15:16:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LNGDKL026785 for ; Thu, 21 Mar 2002 15:16:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LNGDZh026784 for ipng-dist; Thu, 21 Mar 2002 15:16:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LNGAKL026777 for ; Thu, 21 Mar 2002 15:16:10 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21357 for ; Thu, 21 Mar 2002 15:16:12 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA09944 for ; Thu, 21 Mar 2002 16:16:10 -0700 (MST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id BAA05596; Fri, 22 Mar 2002 01:15:36 +0200 Date: Fri, 22 Mar 2002 01:15:36 +0200 Message-Id: <200203212315.BAA05596@burp.tkv.asdf.org> From: Markku Savela To: jinmei@isl.rdc.toshiba.co.jp CC: mrw@windriver.com, ipng@sunroof.eng.sun.com In-reply-to: Subject: Re: poposed changes to the scoping architecture draft References: <200203201653.g2KGrFg70803@givry.rennes.enst-bretagne.fr> <200203210854.KAA04603@burp.tkv.asdf.org> <4.2.2.20020321080740.01ec9100@mail.windriver.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=ISO-2022-JP Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > From: JINMEI Tatuya / $B?@L@C#:H(B > Then, does the following plan make sense? > > - in the definition of zone indices (Section 6 in the 03 draft), > specify that a zone ID includes its scope type and an ID in the > scope when an implementation handles the zone IDs. > - in the textual representation, only define the form of >
% > and specify that will be translated into an > (implementation-dependent) internal form containing both scope type > and the zone in the scope. Sounds ok to me! Although, I wonder, why is it a REQUIREMENT that system MUST encode into format that that contains both type and zone id? Are there some RFC API's that assume/require such? [aside from this wordage in draft?] If implementation is such that it never needs isolated zone id (without address), why should it encode the type in? [Just curious, I probably end up encoding them together also :] -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 15:16:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LNGrKL026795 for ; Thu, 21 Mar 2002 15:16:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LNGrkJ026794 for ipng-dist; Thu, 21 Mar 2002 15:16:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LNGnKL026787 for ; Thu, 21 Mar 2002 15:16:49 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA21113 for ; Thu, 21 Mar 2002 15:16:51 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA11156 for ; Thu, 21 Mar 2002 15:16:44 -0800 (PST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2LNGg724869; Fri, 22 Mar 2002 00:16:42 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id AAA04316; Fri, 22 Mar 2002 00:16:43 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2LNGgg76633; Fri, 22 Mar 2002 00:16:42 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203212316.g2LNGgg76633@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: Prefix delegation options In-reply-to: Your message of Fri, 22 Mar 2002 00:55:41 +0200. Date: Fri, 22 Mar 2002 00:16:42 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: I wanted to add a few cents to the discussion, triggered by Francis saying we're going nowhere :-) => my comment was about the addressing architecture, for the prefix delegation we have a promise of a requirement document. - router renumbering hasn't been made to work yet, so I doubt that's a good option => this was rejected at the interim meeting too. - pppext might be workable for PPP connections, and is a valid mechanism especially if there is no simple alternative (e.g. if the only alternative is full statefull DHCPv6). => PPP is too restricted. We are still trying to use other things than PPP for standard network access control, so IMHO it is a bad idea to rely again on PPP. - dhcpv6 will work ok, I think, but is a bit complex for being usable in every scenario => full statefull DHCPv6 (to reuse your term) is far too heavy. The stateless new DHCPv6 is not yet specified, so I reverse my assessment to the moment the specs will be available. - APD w/ ICMPv6 is ok but can be simplified (e.g. removing prefix return message) => APD is a good solution inside an organization but is a bit heavy for the poor guy at home. - RA (Lutchansky) is a nice hack, kinda works with hacking. => this is not a secret I am in favor of RA extension for the simple case. It was with APD the favourite solutions at the interim meeting but RA lacked a document (now this is fixed, thanks to Nathan Lutchansky). I believe with some work we can get something nice and very easy to implement (the last point is critical: we are already very late). Note that IMO, configuring these with "stateless DHCPv6" but obtaining the prefix with e.g. APD makes perfect sense -- there might be reluctance to implement full DHCP, or even the minimal set of "stateful" DHCP. => I agree about DHCP: as the dynamic address allocation doesn't make sens for IPv6, DHCPv6 has to be heavily changed (simplified!) before to become a reasonable option. Thanks Francis.Dupont@enst-bretagne.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 Thu Mar 21 15:32:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LNWjKL026865 for ; Thu, 21 Mar 2002 15:32:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2LNWjqb026864 for ipng-dist; Thu, 21 Mar 2002 15:32:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2LNWgKL026857 for ; Thu, 21 Mar 2002 15:32:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA27290 for ; Thu, 21 Mar 2002 15:32:43 -0800 (PST) Received: from laposte.enst-bretagne.fr (laposte.enst-bretagne.fr [192.108.115.3]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA17652 for ; Thu, 21 Mar 2002 16:32:42 -0700 (MST) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by laposte.enst-bretagne.fr (8.11.6/8.11.6) with ESMTP id g2LNVx726703; Fri, 22 Mar 2002 00:31:59 +0100 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id AAA04442; Fri, 22 Mar 2002 00:32:00 +0100 (MET) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.11.3/8.11.3) with ESMTP id g2LNVrg76721; Fri, 22 Mar 2002 00:31:58 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200203212331.g2LNVrg76721@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela cc: jinmei@isl.rdc.toshiba.co.jp, mrw@windriver.com, ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-reply-to: Your message of Fri, 22 Mar 2002 01:15:36 +0200. <200203212315.BAA05596@burp.tkv.asdf.org> Date: Fri, 22 Mar 2002 00:31:53 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: Although, I wonder, why is it a REQUIREMENT that system MUST encode into format that that contains both type and zone id? => oh god! Look for the discussion in the mailing-list archive and please don't reopen it. Regards Francis.Dupont@enst-bretagne.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 Thu Mar 21 18:12:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M2CfKL027098 for ; Thu, 21 Mar 2002 18:12:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2M2CfPc027097 for ipng-dist; Thu, 21 Mar 2002 18:12:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M2CcKL027090 for ; Thu, 21 Mar 2002 18:12:38 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA05002 for ; Thu, 21 Mar 2002 18:12:39 -0800 (PST) Received: from byd.ocn.ad.jp (byd.ocn.ad.jp [203.139.162.147]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA24914 for ; Thu, 21 Mar 2002 18:12:32 -0800 (PST) Received: from r505r (byd.ocn.ad.jp [203.139.162.147]) by byd.ocn.ad.jp (8.8.8/3.6W) with SMTP id LAA01684; Fri, 22 Mar 2002 11:12:21 +0900 (JST) Message-ID: <005b01c1d146$c92cb1f0$45bb3fa6@local> From: "Yamasaki Toshi" To: "Pekka Savola" , References: Subject: Re: Prefix delegation options Date: Fri, 22 Mar 2002 11:10:33 +0900 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > - router renumbering hasn't been made to work yet, so I doubt that's a > good option I agree. Moreover, you can't use it when you assume a site-boundary between a WAN port and LAN ports of CPE. > - pppext might be workable for PPP connections, and is a valid mechanism > especially if there is no simple alternative (e.g. if the only alternative > is full statefull DHCPv6). No. PPPext solves the issue only when you use PPP. That means you need another solution when you don't use PPP, and that makes it difficult to achieve zero-configuration enviroment. > - dhcpv6 will work ok, I think, but is a bit complex for being usable > in every scenario Yes, that's why Ralf proposed the DHCP subset or DHCP-lite named "DNCP". > - APD w/ ICMPv6 is ok but can be simplified (e.g. removing prefix return > message) I think APD is simple enough, and DNCP is also simple enough. Technically there is almost no difference between DNCP and APD. > - RA (Lutchansky) is a nice hack, kinda works with hacking. It assumes only P-to-P enviroment. Again you need another solution for non-P-to-P enviroment. Our goal is to achieve auto-configuration, right? Then, how dose a CPE know whether it is conneted to P-to-P link or P-to-MP link automatically? > Note that IMO, configuring these with "stateless DHCPv6" but obtaining the > prefix with e.g. APD makes perfect sense -- there might be reluctance to > implement full DHCP, or even the minimal set of "stateful" DHCP. Both APD and DNCP are "stateful". I'm providing commercial IPv6 services today, and will start IPv6 over DSL/FTTH services soon. You should understand that "stateful" is one of the most important requirements of commercial ISPs. How do you charge and/or solve abuse problems while you don't know who used which prefixes and when? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 18:24:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M2O3KL027121 for ; Thu, 21 Mar 2002 18:24:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2M2O3qv027120 for ipng-dist; Thu, 21 Mar 2002 18:24:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M2NxKL027110 for ; Thu, 21 Mar 2002 18:23:59 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA21752 for ; Thu, 21 Mar 2002 18:24:01 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id TAA23099 for ; Thu, 21 Mar 2002 19:23:59 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2M2Ni413561; Fri, 22 Mar 2002 04:23:44 +0200 Date: Fri, 22 Mar 2002 04:23:44 +0200 (EET) From: Pekka Savola To: Yamasaki Toshi cc: ipng@sunroof.eng.sun.com Subject: Re: Prefix delegation options In-Reply-To: <005b01c1d146$c92cb1f0$45bb3fa6@local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 22 Mar 2002, Yamasaki Toshi wrote: > > - pppext might be workable for PPP connections, and is a valid mechanism > > especially if there is no simple alternative (e.g. if the only alternative > > is full statefull DHCPv6). > > No. PPPext solves the issue only when you use PPP. That means you need > another solution when you don't use PPP, and that makes it difficult to > achieve zero-configuration enviroment. Which is why I said 'PPP connections'. :-) > > - dhcpv6 will work ok, I think, but is a bit complex for being usable > > in every scenario > > Yes, that's why Ralf proposed the DHCP subset or DHCP-lite named "DNCP". Which may still be too heavy. > > - APD w/ ICMPv6 is ok but can be simplified (e.g. removing prefix return > > message) > > I think APD is simple enough, and DNCP is also simple enough. Technically > there is almost no difference between DNCP and APD. True, but APD has IMO unnecessary components of stateful nature, like prefix return message. > > - RA (Lutchansky) is a nice hack, kinda works with hacking. > > It assumes only P-to-P enviroment. Again you need another solution for > non-P-to-P enviroment. Our goal is to achieve auto-configuration, right? > Then, how dose a CPE know whether it is conneted to P-to-P link or P-to-MP > link automatically? Prefix Delegation need not be (IMO) completely automatic: it's completely ok to have to add a 'request-prefix interface eth0', 'request-prefix interface any', or whatever in the configuration of the CPE. Via that, detecting the link type is irrelevant: we don't necessary end up with one mechanism already. > > Note that IMO, configuring these with "stateless DHCPv6" but obtaining the > > prefix with e.g. APD makes perfect sense -- there might be reluctance to > > implement full DHCP, or even the minimal set of "stateful" DHCP. > > Both APD and DNCP are "stateful". see below. > I'm providing commercial IPv6 services today, and will start IPv6 over > DSL/FTTH services soon. You should understand that "stateful" is one of the > most important requirements of commercial ISPs. > > How do you charge and/or solve abuse problems while you don't know who used > which prefixes and when? I don't think that anyone is assuming 100% automatic prefix generation like EUI64 IID generation: rather, I assume that in (at least almost) every case, the prefixes will be configured statically somewhere, along the lines "identifier/customer: prefix". With stateful above I meant protocols which expect one to request a prefix and return it back, release it, return it back if no longer used, etc. -- consider router advertisements which aren't stateful in that manner. But these are what the requirements document is for.. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 18:34:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M2YWKL027140 for ; Thu, 21 Mar 2002 18:34:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2M2YW9V027139 for ipng-dist; Thu, 21 Mar 2002 18:34:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M2YTKL027132 for ; Thu, 21 Mar 2002 18:34:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA27855 for ; Thu, 21 Mar 2002 18:34:30 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA29760 for ; Thu, 21 Mar 2002 19:34:29 -0700 (MST) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id CAA02531; Fri, 22 Mar 2002 02:34:27 GMT Received: from login.ecs.soton.ac.uk (IDENT:tjc@login.ecs.soton.ac.uk [152.78.68.149]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id CAA20149; Fri, 22 Mar 2002 02:34:28 GMT Date: Fri, 22 Mar 2002 02:34:27 +0000 (GMT) From: Tim Chown To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: Prefix delegation options In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 22 Mar 2002, Pekka Savola wrote: > I don't think that anyone is assuming 100% automatic prefix generation > like EUI64 IID generation: rather, I assume that in (at least almost) > every case, the prefixes will be configured statically somewhere, along > the lines "identifier/customer: prefix". Which is what DHCP(v6) is good at, and it may not be overkill if you also want to run a v6 only network and also use DHCPv6 as your DSTM server, for example. > With stateful above I meant protocols which expect one to request a prefix > and return it back, release it, return it back if no longer used, etc. -- > consider router advertisements which aren't stateful in that manner. I think in many situations you'd expect a static prefix, but there may also be situations where any prefix is OK and so a static dhcpv6 mapping is not necessary. This might be useful in the MONET area to get a temporay prefix for a mobile network, so we shouldn't perhaps constrain thinking to fixed CPE? tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 21 18:41:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M2fBKL027159 for ; Thu, 21 Mar 2002 18:41:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2M2fAms027158 for ipng-dist; Thu, 21 Mar 2002 18:41:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M2f7KL027151 for ; Thu, 21 Mar 2002 18:41:07 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA09785 for ; Thu, 21 Mar 2002 18:41:08 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA01153 for ; Thu, 21 Mar 2002 18:41:10 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2M2eZ213689; Fri, 22 Mar 2002 04:40:35 +0200 Date: Fri, 22 Mar 2002 04:40:35 +0200 (EET) From: Pekka Savola To: Tim Chown cc: ipng@sunroof.eng.sun.com Subject: Re: Prefix delegation options In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 22 Mar 2002, Tim Chown wrote: > On Fri, 22 Mar 2002, Pekka Savola wrote: > > > I don't think that anyone is assuming 100% automatic prefix generation > > like EUI64 IID generation: rather, I assume that in (at least almost) > > every case, the prefixes will be configured statically somewhere, along > > the lines "identifier/customer: prefix". > > Which is what DHCP(v6) is good at, and it may not be overkill if you also > want to run a v6 only network and also use DHCPv6 as your DSTM server, for > example. I'll omit my comments about the marriage of DHCPv6 and DSTM from this forum :-). > > With stateful above I meant protocols which expect one to request a prefix > > and return it back, release it, return it back if no longer used, etc. -- > > consider router advertisements which aren't stateful in that manner. > > I think in many situations you'd expect a static prefix, but there may > also be situations where any prefix is OK and so a static dhcpv6 mapping is > not necessary. This might be useful in the MONET area to get a temporay > prefix for a mobile network, so we shouldn't perhaps constrain thinking to > fixed CPE? "non-stateful" manner does not necessary discount these: just advertise the prefix with e.g. lifetime of 60 seconds. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 18:41:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M2faKL027169 for ; Thu, 21 Mar 2002 18:41:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2M2fa1N027168 for ipng-dist; Thu, 21 Mar 2002 18:41:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M2fVKL027161 for ; Thu, 21 Mar 2002 18:41:31 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA26698 for ; Thu, 21 Mar 2002 18:41:33 -0800 (PST) Received: from d12lmsgate-3.de.ibm.com (d12lmsgate-3.de.ibm.com [195.212.91.201]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id TAA01939 for ; Thu, 21 Mar 2002 19:41:31 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-3.de.ibm.com (1.0.0) with ESMTP id DAA73648; Fri, 22 Mar 2002 03:41:24 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2M2fOF119036; Fri, 22 Mar 2002 03:41:24 +0100 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA82058 from ; Fri, 22 Mar 2002 03:41:17 +0100 Message-Id: <3C9A99B9.5923C93A@hursley.ibm.com> Date: Fri, 22 Mar 2002 03:40:57 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Michel Py Cc: Pekka Savola , ipng@sunroof.eng.sun.com, ipv6mh Subject: Re: (ipv6) semantics - TLA References: <2B81403386729140A3A899A8B39B046406C493@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk HOBBIT = High Order Bytes and BITs The prefix allocated directly to an operator by an RIR. Brian Michel Py wrote: > > > Pekka Savola wrote: > > Or perhaps you should describe in detail what the term would > > be useful for in this context? > > There different things involved: > > - Allocation policies, which is "We give a /32 to Joe for this reason and a /35 to Jane for that reason". > > - Aggregation policies, which is "All networks matching criteria xyz must aggregate at the /xx boundary". > > - Addressing architecture, which does not define how to do it but what is is. > > The point I am trying to make here is that we need a name or acronym for "ISPs that receive their addresses directly from a RIR". I am not saying that "TLA" is the best definition, but it does fit, regardless of allocation policies and aggregation policies. > > There was a reason it was defined in RFC2373 and the changes to draft-ietf-ipngwg-addr-arch-v3-07.txt have not changed this, AFAIK. > > I am not proposing to define "TLA" or whatever we come up with as an aggregation policy, but as the concept of ISPs that receive their blocks directly for a registry. How big the block they get is an allocation policy issue, where they aggregate is an aggregation policy issue, who they are is an addressing architecture issue. > > Michel. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 21 18:42:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M2gvKL027196 for ; Thu, 21 Mar 2002 18:42:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2M2gv74027195 for ipng-dist; Thu, 21 Mar 2002 18:42:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M2gsKL027188 for ; Thu, 21 Mar 2002 18:42:54 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id SAA10076; Thu, 21 Mar 2002 18:42:51 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA03862; Thu, 21 Mar 2002 18:42:43 -0800 (PST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id DAA76890; Fri, 22 Mar 2002 03:42:32 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2M2gWF118792; Fri, 22 Mar 2002 03:42:32 +0100 Received: from gsine06.us.sine.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA17730 from ; Fri, 22 Mar 2002 03:42:28 +0100 Message-Id: <3C9A9A00.79C352C1@hursley.ibm.com> Date: Fri, 22 Mar 2002 03:42:08 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Francis Dupont Cc: "John F. Leser" , Erik Nordmark , Pekka Savola , Pekka Nikander , ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: <200203212249.g2LMnog76496@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote: > > In your previous mail you wrote: > > Kind of tricky for FireWire > > => Brian, do you suggest that FireWire (aka I-Link aka IEEE 1394) uses > 64 bit addresses? Now that would be a silly suggestion wouldn't it? I think I mistyped... it's late in the week. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 19:01:44 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M31hKL027287 for ; Thu, 21 Mar 2002 19:01:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2M31hDW027286 for ipng-dist; Thu, 21 Mar 2002 19:01:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M31eKL027279 for ; Thu, 21 Mar 2002 19:01:40 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA12941 for ; Thu, 21 Mar 2002 19:01:41 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA14793 for ; Thu, 21 Mar 2002 20:01:41 -0700 (MST) content-class: urn:content-classes:message Subject: RE: (ipv6) semantics - TLA MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 21 Mar 2002 19:01:33 -0800 Message-ID: <2B81403386729140A3A899A8B39B046406C494@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: (ipv6) semantics - TLA Thread-Index: AcHRSyyYcgoVVWqKS/aYP2hef2IoxAAApvmw From: "Michel Py" To: "Brian E Carpenter" Cc: "Pekka Savola" , , "ipv6mh" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2M31eKL027280 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> Michel Py wrote: >> The point I am trying to make here is that we need a name >> or acronym for "ISPs that receive their addresses directly >> from a RIR". I am not saying that "TLA" is the best >> definition, but it does fit, regardless of allocation >> policies and aggregation policies. > Brian Carpenter wrote: > HOBBIT = High Order Bytes and BITs > The prefix allocated directly to an operator by an RIR. Mmmm. I like it. Do you think we can, by extension, call the operator a HOBBIT also ? Some of them might not be totally receptive to the idea. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 19:27:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M3RjKL027357 for ; Thu, 21 Mar 2002 19:27:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2M3Rjl1027356 for ipng-dist; Thu, 21 Mar 2002 19:27:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M3ReKL027349 for ; Thu, 21 Mar 2002 19:27:41 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA16726 for ; Thu, 21 Mar 2002 19:27:42 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id UAA15997 for ; Thu, 21 Mar 2002 20:27:40 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2M3Q6t18627; Thu, 21 Mar 2002 22:26:06 -0500 (EST) Message-Id: <200203220326.g2M3Q6t18627@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: gab@sun.com cc: Keith Moore , Jari Arkko , Mohan Parthasarathy , Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier In-reply-to: (Your message of "Fri, 22 Mar 2002 04:22:43 +0100.") <3C9AA383.CAFA1A17@sun.com> Date: Thu, 21 Mar 2002 22:26:06 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > So Mallory says that his address M is an alias for Alice's address A. Ok. > What if Bob looking at A could know (yes, signalled by a bit) that A > it is only aliasable by very secure mechanisms. Bob doesn't necessarily see A. Even if Bob sees A, that doesn't mean that A is reachable from Bob. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 21 19:40:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M3eqKL027424 for ; Thu, 21 Mar 2002 19:40:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2M3eqG2027423 for ipng-dist; Thu, 21 Mar 2002 19:40:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M3enKL027415 for ; Thu, 21 Mar 2002 19:40:49 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA08016; Thu, 21 Mar 2002 19:40:51 -0800 (PST) Received: from sun.com (vpn-129-156-96-10.EMEA.Sun.COM [129.156.96.10]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id g2M3ekL03924; Thu, 21 Mar 2002 19:40:47 -0800 (PST) Message-ID: <3C9AA773.69F1DA25@sun.com> Date: Fri, 22 Mar 2002 04:39:32 +0100 From: gabriel montenegro Reply-To: gab@sun.com X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: Jari Arkko , Mohan Parthasarathy , Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: <200203220326.g2M3Q6t18627@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > Bob doesn't necessarily see A. I'm confused. What problem are you looking at? The problem at hand is that of addresses for which redirection information is fed to the end hosts. This may apply to mobile ip addresses or to anycast addrs (for some implementations of anycast as talked about, for example, by Fred Baker). This redirection is basically equivalent to inserting host route entries for a given address A at end hosts (Bob). So the trick is to convince Bob to insert into its route table a host route entry for A at some_address. If Bob doesn't know A, I think we're talking about a very different problem. What are you asking Bob to insert into its routing table? -gabriel -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 21:29:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M5TvKL027528 for ; Thu, 21 Mar 2002 21:29:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2M5Tuue027527 for ipng-dist; Thu, 21 Mar 2002 21:29:56 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M5TrKL027520 for ; Thu, 21 Mar 2002 21:29:53 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id VAA00497 for ; Thu, 21 Mar 2002 21:29:54 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id WAA03306 for ; Thu, 21 Mar 2002 22:29:54 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id VAA09006; Thu, 21 Mar 2002 21:29:54 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2M5TrA04514; Thu, 21 Mar 2002 21:29:53 -0800 X-mProtect:  Thu, 21 Mar 2002 21:29:53 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.20.246, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHaXSjw; Thu, 21 Mar 2002 21:29:51 PST Message-ID: <3C9AC15F.79CFFBF8@iprg.nokia.com> Date: Thu, 21 Mar 2002 21:30:07 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.75 [en]C-CCK-MCD {Nokia} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Yamasaki Toshi CC: ipng@sunroof.eng.sun.com Subject: Re: Prefix delegation options References: <005b01c1d146$c92cb1f0$45bb3fa6@local> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Yamasaki, Only one comment... Yamasaki Toshi wrote: > I'm providing commercial IPv6 services today, and will start IPv6 over > DSL/FTTH services soon. You should understand that "stateful" is one of the > most important requirements of commercial ISPs. > > How do you charge and/or solve abuse problems while you don't know who used > which prefixes and when? Maybe what's needed is to have the default router report stateless transitions by way of MIB, explicit signaling, ... The right time to do this would be when a stateless autoconfigured host gets a new entry in the router's neighbor cache. This only gives you when, along with the MAC address of who. Maybe AAAv6 would give you who -- but it's not on the standards track :-( but it's easier than DHCPv6... Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 21 22:47:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M6lDKL027642 for ; Thu, 21 Mar 2002 22:47:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2M6lD7e027641 for ipng-dist; Thu, 21 Mar 2002 22:47:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M6lAKL027634 for ; Thu, 21 Mar 2002 22:47:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA04786 for ; Thu, 21 Mar 2002 22:47:12 -0800 (PST) Received: from cs.tut.fi (varis.cs.tut.fi [130.230.4.42]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA23455 for ; Thu, 21 Mar 2002 23:47:10 -0700 (MST) Received: from rami (rampe.atm.tut.fi [130.230.52.68]) by cs.tut.fi (8.8.8/8.8.8) with SMTP id IAA26957; Fri, 22 Mar 2002 08:47:09 +0200 (EET) From: "Rami Lehtonen" To: "Pekka Nikander" Cc: Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Fri, 22 Mar 2002 08:46:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3C99E8B1.40408@nomadiclab.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Pekka Nikander wrote: > Well, the original idea was to reserve a bit to indicate that the > address is Cryptographically Generaged Address (CGA), basically > meaning that > > if the bit is set, then > interface id = low64(hash(PK, stuff)) & mask > > where > PK is a public key to be used as an identifier for the host > stuff is contains other parameters (see the earlier messages) > hash is a cryptographic hash function, e.g. SHA1 > low64 is a function that takes lowest 64 bits > mask indicates that we have to clear/set some bits of the iid > > In essense, that would allow anyone to determine if a given public > key belongs to a host, just inspecting the public key, the address, > and the "stuff" above. See e.g. Does this prove that the public key belongs to the host? What if the attacker just uses different network prefix and the same interface id than the original host? Am I missing something? -Rami Lehtonen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 21 23:06:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M760KL027676 for ; Thu, 21 Mar 2002 23:06:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2M760bj027675 for ipng-dist; Thu, 21 Mar 2002 23:06:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M75vKL027668 for ; Thu, 21 Mar 2002 23:05:57 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA28593 for ; Thu, 21 Mar 2002 23:05:59 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA24677 for ; Thu, 21 Mar 2002 23:06:01 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2M752D07617; Fri, 22 Mar 2002 01:05:02 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 01:05:05 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02BD423C@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: gab@Sun.COM, Keith Moore Cc: Jari Arkko , Mohan Parthasarathy , Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Fri, 22 Mar 2002 01:05:04 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D16F.E46601F0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D16F.E46601F0 Content-Type: text/plain; charset="iso-8859-1" For now, let's assume that Bob is told A but Bob doesn't know if who sent it to him is on the level. I.e. he doesn't know if A is correct and he doesn't know if A has been modified by a third party en-route. Bob also doesn't know if someone between the topologically correct routing infrastructure of A has been compromised either. For instance, someone on A's true network is pretending to be the mobile's HA or just snooping. I guess another scenario is someone on Bob's network is pretending to be a router along the path or snooping, etc.. i.e. any MITM. There is another case of MITM where two nodes could be in collusion, posing as A and its home network, as well, but they have pretty much given up on that as the same affects could occur for non mobile nodes, already, if the routing infrastructure was somehow compromised. They are also concerned about DDoS attack such as pounding the CN with such requests to generate public keys etc.. for this SA establishment process. The "keep it simple" approach is simply RR, return routability i.e. trust that there is no MiTM. But it doesn't protect as well against some MITM attacks and so this has been labeled as weak vs. strong. Note that A would also benefit from knowing that he actually contacted Bob and someone wasn't impersonating Bob due to a MITM situation. Overall, I find this amusing as they are both not bullet proof against MITM due to existing security holes in IP itself - not that the fixes would be acceptable as anything more than a BCP. So a few folks are pushing a "better" encumbered solution with the hopes that at least this BCP for IP holes will be created as well at some point to close the other holes. Then we have the credentials and infrastructure proponents i.e. trust an application trust network, AAA; however, this simply transfers the MITM problem to another route and everyone keeps arguing about just what the AAA is or should be. Then we have to "trust the routers themselves proponents" that assume that the routers close to A both in A's home network and in the visited network somehow know that A is doing the right thing. But this would involve these routers being involved in the signaling and require some sort of infrastructureless and scalable edge to edge SAs. This relies on a great deal of trust for these route updates as you mention but it really would rely on the same trust that the networks are built with today. The ways to set up and cache these SAs without more infrastructure is a contentious issue that results in a battle between the people who make servers vs. people who make routers. Much of the same arguments against RSVP are used to thwart such concepts. Also with Monet and Manet, the question of trusting routers is being portrayed as unprofitable and not necessarily trustworthy. We are also a long way away from this IMHO. The infrstucture solution investors would fight such a thing tooth and nail. Then we have the let's do something completely different folks i.e. the Per-host DNS with no caching, IIP, 8+8ers and HIPpies - not that I would want to stop any research on these topics. I still think we are just getting started on this Internet thing. I have a sneaking suspicion that equivalent strong security mechanisms exist and are comparable end to end - "better" solutions yet do not require these interface changes; however, this may seem to be a rather non-productive task to some for something that is optional anyway. I suspect that these solutions might be encumbered as well and these folks don't really want to try to impose some sort of encumbered solution in the IETF. Keep in mind that for the solution to be effective it should also have hooks to work with infrastructure-based solutions as well. This is the "the key generation operations can be offloaded" statements you might run into when scanning mail archives or related documentation. Anyway, this might end up to be the same state of affairs with IP-based VPN security technology with different vendors having different solutions and variants of the ESP protection etc.. Seems like some sort of broken history record. Then again, people might just say that RR is fine given the weaknesses of IP already and that the infrastructure solutions can be used if you want something stronger. This would be passing the buck to the AAA war, though. I.e. deployment would still be a major issue. Thanks for trying to understand the variables of the problem set - both technical and business oriented. I hope this pretty much sums up the conundrum for all. I think it serves to put this concept of reserving an interface bit in perspective - not the mention issues within the whole IETF. Glenn > -----Original Message----- > From: gabriel montenegro [mailto:gab@Sun.COM] > > So the trick is to convince Bob to insert into its route > table a host route entry for > A at some_address. If Bob doesn't know A, I think we're > talking about a very > different problem. What are you asking Bob to insert into its > routing table? > > -gabriel > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > ------_=_NextPart_001_01C1D16F.E46601F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Allocating a bit in the RFC2374 Interface Identifier

For now, let's assume that Bob is told A but Bob = doesn't know if who sent it to him is on the level. I.e. he doesn't = know if A is correct and he doesn't know if A has been modified by a = third party en-route. 

Bob also doesn't know if someone between the = topologically correct routing infrastructure of A has been compromised = either. For instance, someone on A's true network is pretending to be = the mobile's HA or just snooping. I guess another scenario is someone = on Bob's network is pretending to be a router along the path or = snooping, etc.. i.e. any MITM.

There is another case of MITM where two nodes could = be in collusion, posing as A and its home network, as well, but they = have pretty much given up on that as the same affects could occur for = non mobile nodes, already, if the routing infrastructure was somehow = compromised.

They are also concerned about DDoS attack such as = pounding the CN with such requests to generate public keys etc.. for = this SA establishment process. The "keep it simple" approach = is simply RR, return routability i.e. trust that there is no MiTM. But = it doesn't protect as well against some MITM attacks and so this has = been labeled as weak vs. strong.

Note that A would also benefit from knowing that = he  actually contacted Bob and someone wasn't impersonating Bob = due to a MITM situation.

Overall, I find this amusing as they are both not = bullet proof against MITM due to existing security holes in IP itself - = not that the fixes would be acceptable as anything more than a BCP. So = a few folks are pushing a "better" encumbered solution with = the hopes that at least this BCP for IP holes will be created as well = at some point to close the other holes.

Then we have the credentials and infrastructure = proponents i.e. trust an application trust network, AAA; however, this = simply transfers the MITM problem to another route and everyone keeps = arguing about just what the AAA is or should be.

Then we have to "trust the routers themselves = proponents" that assume that the routers close to A both in A's = home network and in the visited network somehow know that A is doing = the right thing. But this would involve these routers being involved in = the signaling and require some sort of infrastructureless and scalable = edge to edge SAs. This relies on a great deal of trust for these route = updates as you mention but it really would rely on the same trust that = the networks are built with today. The ways to set up and cache these = SAs without more infrastructure is a contentious issue that results in = a battle between the people who make servers vs. people who make = routers. Much of the same arguments against RSVP are used to thwart = such concepts. Also with Monet and Manet, the question of trusting = routers is being portrayed as unprofitable and not necessarily = trustworthy. We are also a long way away from this IMHO. The = infrstucture solution investors would fight such a thing tooth and = nail.

Then we have the let's do something completely = different folks i.e. the Per-host DNS with no caching, IIP, 8+8ers and = HIPpies - not that I would want to stop any research on these topics. I = still think we are just getting started on this Internet = thing.

I have a sneaking suspicion that equivalent strong = security mechanisms exist and are comparable end to end - = "better" solutions yet do not require these interface = changes; however, this may seem to be a rather non-productive task to = some for something that is optional anyway. I suspect that these = solutions might be encumbered as well and these folks don't really want = to try to impose some sort of encumbered solution in the IETF. =

Keep in mind that for the solution to be effective it = should also have hooks to work with infrastructure-based solutions as = well. This is the "the key generation operations can be = offloaded" statements you might run into when scanning mail = archives or related documentation.

Anyway, this might end up to be the same state of = affairs with IP-based VPN security technology with different vendors = having different solutions and variants of the ESP protection etc.. = Seems like some sort of broken history record.

Then again, people might just say that RR is fine = given the weaknesses of IP already and that the infrastructure = solutions can be used if you want something stronger. This would be = passing the buck to the AAA war, though. I.e. deployment would still be = a major issue.

Thanks for trying to understand the variables of the = problem set - both technical and business oriented. I hope this pretty = much sums up the conundrum for all. I think it serves to put this = concept of reserving an interface bit in perspective - not the mention = issues within the whole IETF.

Glenn

> -----Original Message-----
> From: gabriel montenegro [mailto:gab@Sun.COM]
>
> So the trick is to convince Bob to insert into = its route
> table a host route entry for
> A at some_address. If Bob doesn't know A, I = think we're
> talking about a very
> different problem. What are you asking Bob to = insert into its
> routing table?
>
> -gabriel
>
>
>
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>

------_=_NextPart_001_01C1D16F.E46601F0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 04:53:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MCr8KL027910 for ; Fri, 22 Mar 2002 04:53:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MCr8Nt027909 for ipng-dist; Fri, 22 Mar 2002 04:53:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MCr5KL027902 for ; Fri, 22 Mar 2002 04:53:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA14111 for ; Fri, 22 Mar 2002 04:53:06 -0800 (PST) Received: from mail5.nc.rr.com (fe5.southeast.rr.com [24.93.67.52]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12721 for ; Fri, 22 Mar 2002 05:53:05 -0700 (MST) Received: from lorien.sc.innovationslab.net ([24.162.252.183]) by mail5.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Fri, 22 Mar 2002 07:52:55 -0500 Message-ID: <3C9B2953.61A678BC@lorien.sc.innovationslab.net> Date: Fri, 22 Mar 2002 07:53:39 -0500 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Pekka Savola CC: ipng@sunroof.eng.sun.com Subject: Re: Prefix delegation options References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Pekka, Just one comment Pekka Savola wrote: > - APD w/ ICMPv6 is ok but can be simplified (e.g. removing prefix return > message) As one of the authors of APD, I can concretely say that some of the messages used in -02 can be removed. If I recall, the Prefix Return message was added based on someone's suggestion. My original thinking was that the lifetime of the prefix would be used to determine when it was no longer valid. Regards, Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 05:27:52 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MDRqKL027936 for ; Fri, 22 Mar 2002 05:27:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MDRqiN027935 for ipng-dist; Fri, 22 Mar 2002 05:27:52 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MDRmKL027928 for ; Fri, 22 Mar 2002 05:27:48 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA17748 for ; Fri, 22 Mar 2002 05:27:50 -0800 (PST) Received: from tuubi52.adsl.netsonic.fi (tuubi52.adsl.netsonic.fi [194.29.196.52]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA12851 for ; Fri, 22 Mar 2002 06:27:48 -0700 (MST) Received: from nomadiclab.com (localhost [127.0.0.1]) by tuubi52.adsl.netsonic.fi (8.11.6/8.11.6) with ESMTP id g2MDRAm11743; Fri, 22 Mar 2002 15:27:10 +0200 (EET) (envelope-from Pekka.Nikander@nomadiclab.com) Message-ID: <3C9B317A.4010905@nomadiclab.com> Date: Fri, 22 Mar 2002 07:28:26 -0600 From: Pekka Nikander User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020307 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Rami Lehtonen CC: ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Rami Lehtonen wrote: >> if the bit is set, then >> interface id = low64(hash(PK, stuff)) & mask >> >> where >> PK is a public key to be used as an identifier for the host >> stuff is contains other parameters (see the earlier messages) >> hash is a cryptographic hash function, e.g. SHA1 >> low64 is a function that takes lowest 64 bits >> mask indicates that we have to clear/set some bits of the iid >> >>In essense, that would allow anyone to determine if a given public >>key belongs to a host, just inspecting the public key, the address, >>and the "stuff" above. See e.g. > > Does this prove that the public key belongs to the host? What if the > attacker just uses different network prefix and the same interface id than > the original host? > > Am I missing something? Well, I guess my language was just too loose. CGA, as such, only says that "there has been, at some point of time, some party A, who created this interface id IID, using the parameters (PK, stuff)". This comes from the cryptographic properties of the hash function; that is, we assume that it is sufficiently hard to invert the hash function so that the only plausible way for creating (IID, PK, stuff) triples is first to first generate PK and stuff, and only then to calculate IID. Taking a given IID and generating PK or stuff from that is assumed to be hard. (There are details but I don't want to go the them here. Read draft-roe-mobileip-updateauth-02.txt.) To extend from this, we make the agreement that "since A has created this IID using PK, that indicates that A wants to be identified with PK". That creates a binding IID -> PK. Now, if you want to check that the host using IID is really A, you need to create also the reverse binding, PK -> IID. To do that, you ask A to sign a random number (a nonce) using the private key corresponding to PK. Thus, if an attacker takes the (IID, PK, stuff) triple and goes to another network, it can still use the same IID, but it can't sign anything since it doesn't have the private key corresponding to PK. Or am I missing something? --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 07:36:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MFaCKL028087 for ; Fri, 22 Mar 2002 07:36:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MFaCDB028086 for ipng-dist; Fri, 22 Mar 2002 07:36:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MFa8KL028072 for ; Fri, 22 Mar 2002 07:36:08 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA01804 for ; Fri, 22 Mar 2002 07:36:09 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA28216 for ; Fri, 22 Mar 2002 08:36:08 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2MFa6oq019763 for ; Fri, 22 Mar 2002 16:36:07 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 22 16:35:31 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 16:25:28 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053803731128@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Francis Dupont , Dave Thaler Cc: ipng@sunroof.eng.sun.com Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Fri, 22 Mar 2002 16:35:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > I have three concerns about this CGA/KBA idea: > - first this idea is about interface IDs, not addresses > (so for Mobile > IPv6 we need Return Routability too). => Yes you do, but you would be able to generate an SA. This is not the case with RR only. > - second the verification implies an expensive crypto operation > (typically a signature check) so the scheme is subject > to trival DoS > attack, especially if each packet has to be checked (so > or a session > key is negociated with an even more expensive and > complex protocol, => If you want strong authentication, what else can you do? Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 07:36:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MFaTKL028097 for ; Fri, 22 Mar 2002 07:36:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MFaTDL028096 for ipng-dist; Fri, 22 Mar 2002 07:36:29 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MFaPKL028089 for ; Fri, 22 Mar 2002 07:36:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA15392 for ; Fri, 22 Mar 2002 07:36:24 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA29756 for ; Fri, 22 Mar 2002 08:36:12 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2MFa6kY013502 for ; Fri, 22 Mar 2002 16:36:10 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 22 16:35:28 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 16:37:00 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053803731129@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Jari Arkko , Mohan Parthasarathy Cc: Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Fri, 22 Mar 2002 16:35:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Mohan Parthasarathy wrote: > > > t very clear as to why you have to reserve a bit in the > > address to express different security mechanisms being > used. Why can't > > this be built into the protocol itself ? Is it because > that the future > > security mechanisms will not use the same set of message > exchanges as > > RR and hence you want a protocol independent way of > indicating the method ? > > I would assume that any mechanism to establish the > binding between home > > address and care of address would have a few message > exchanges. Can you Jari wrote: > > Because the MitM attacker can change everything related to these > messages, it doesn't help to put anything to the messages for the > bidding down protection. > > Note that the MitM can also change the IP address, but if he does > so, he is *not* attacking the original host, as the address is > changed. > => For all those opposing the addition of the bit in the IID, I really hope you would carefully consider Jari's text above. For mechanisms designed to prove address ownership (relevant to securing ND, MIPv6 BUs and I can think of more), you MUST include the distinction in the _IP_address. The IP address _is_ the identifier relevant for this case, not the host name, URL or anything else. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 07:41:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MFfkKL028194 for ; Fri, 22 Mar 2002 07:41:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MFfjHM028193 for ipng-dist; Fri, 22 Mar 2002 07:41:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MFfgKL028186 for ; Fri, 22 Mar 2002 07:41:42 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07696; Fri, 22 Mar 2002 07:41:43 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01682; Fri, 22 Mar 2002 08:41:41 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2MFf8o19514; Fri, 22 Mar 2002 17:41:08 +0200 Date: Fri, 22 Mar 2002 17:41:07 +0200 (EET) From: Pekka Savola To: "Hesham Soliman (ERA)" cc: Jari Arkko , Mohan Parthasarathy , Pekka Nikander , , Erik Nordmark Subject: RE: Allocating a bit in the RFC2374 Interface Identifier In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053803731129@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 22 Mar 2002, Hesham Soliman (ERA) wrote: > > Mohan Parthasarathy wrote: > > > > > t very clear as to why you have to reserve a bit in the > > > address to express different security mechanisms being > > used. Why can't > > > this be built into the protocol itself ? Is it because > > that the future > > > security mechanisms will not use the same set of message > > exchanges as > > > RR and hence you want a protocol independent way of > > indicating the method ? > > > I would assume that any mechanism to establish the > > binding between home > > > address and care of address would have a few message > > exchanges. Can you > > Jari wrote: > > > > > Because the MitM attacker can change everything related to these > > messages, it doesn't help to put anything to the messages for the > > bidding down protection. > > > > Note that the MitM can also change the IP address, but if he does > > so, he is *not* attacking the original host, as the address is > > changed. > > > > => For all those opposing the addition of the bit > in the IID, I really hope you would carefully consider > Jari's text above. For mechanisms designed to prove > address ownership (relevant to securing ND, MIPv6 BUs > and I can think of more), you MUST include the > distinction in the _IP_address. The IP address _is_ > the identifier relevant for this case, not the host > name, URL or anything else. Two destination addresses, one that requires verification by stronger means, one which does not. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 08:28:49 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MGSnKL028379 for ; Fri, 22 Mar 2002 08:28:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MGSmL9028378 for ipng-dist; Fri, 22 Mar 2002 08:28:48 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MGSgKL028371 for ; Fri, 22 Mar 2002 08:28:42 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17105 for ; Fri, 22 Mar 2002 08:28:42 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA08785 for ; Fri, 22 Mar 2002 08:28:26 -0800 (PST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2MGSWkY002889 for ; Fri, 22 Mar 2002 17:28:32 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Fri Mar 22 17:28:31 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 17:18:28 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6AB61@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Pekka Savola'" , "Hesham Soliman (ERA)" Cc: Jari Arkko , Mohan Parthasarathy , Pekka Nikander , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Fri, 22 Mar 2002 17:28:29 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > => For all those opposing the addition of the bit > > in the IID, I really hope you would carefully consider > > Jari's text above. For mechanisms designed to prove > > address ownership (relevant to securing ND, MIPv6 BUs > > and I can think of more), you MUST include the > > distinction in the _IP_address. The IP address _is_ > > the identifier relevant for this case, not the host > > name, URL or anything else. > > Two destination addresses, one that requires verification > by stronger > means, one which does not. => ?? Which part of my message are you answering ? Hesham > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 08:40:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MGe9KL028489 for ; Fri, 22 Mar 2002 08:40:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MGe9eE028488 for ipng-dist; Fri, 22 Mar 2002 08:40:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MGe6KL028481 for ; Fri, 22 Mar 2002 08:40:06 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17660 for ; Fri, 22 Mar 2002 08:40:07 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA00451 for ; Fri, 22 Mar 2002 09:40:05 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2MGdZs20042; Fri, 22 Mar 2002 18:39:35 +0200 Date: Fri, 22 Mar 2002 18:39:35 +0200 (EET) From: Pekka Savola To: "Hesham Soliman (ERA)" cc: Jari Arkko , Mohan Parthasarathy , Pekka Nikander , , Erik Nordmark Subject: RE: Allocating a bit in the RFC2374 Interface Identifier In-Reply-To: <4DA6EA82906FD511BE2F00508BCF053802C6AB61@Esealnt861.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 22 Mar 2002, Hesham Soliman (ERA) wrote: > > > => For all those opposing the addition of the bit > > > in the IID, I really hope you would carefully consider > > > Jari's text above. For mechanisms designed to prove > > > address ownership (relevant to securing ND, MIPv6 BUs > > > and I can think of more), you MUST include the > > > distinction in the _IP_address. The IP address _is_ > > > the identifier relevant for this case, not the host > > > name, URL or anything else. > > > > Two destination addresses, one that requires verification > > by stronger > > means, one which does not. > > => ?? Which part of my message are you answering ? I was just pointing out a possible alternative to reserving bits in the source addresses. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 08:49:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MGnWKL028546 for ; Fri, 22 Mar 2002 08:49:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MGnWEY028545 for ipng-dist; Fri, 22 Mar 2002 08:49:32 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MGnSKL028538 for ; Fri, 22 Mar 2002 08:49:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA01899 for ; Fri, 22 Mar 2002 08:49:29 -0800 (PST) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA10609 for ; Fri, 22 Mar 2002 09:49:29 -0700 (MST) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 22 Mar 2002 08:49:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D1C1.87F393A3" Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Fri, 22 Mar 2002 08:49:28 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E6349C2@TNEXVS02.tahoenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Allocating a bit in the RFC2374 Interface Identifier Thread-Index: AcHRwDhPDpOWTZe3S3ujf/ybr3ehaAAATrow From: "Mohan Parthasarathy" To: "Pekka Savola" , "Hesham Soliman (ERA)" Cc: "Jari Arkko" , "Pekka Nikander" , , "Erik Nordmark" X-OriginalArrivalTime: 22 Mar 2002 16:49:28.0582 (UTC) FILETIME=[8820AA60:01C1D1C1] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1D1C1.87F393A3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pekka, How do you identify those two addresses without reserving the bits ? -mohan > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Friday, March 22, 2002 8:40 AM > To: Hesham Soliman (ERA) > Cc: Jari Arkko; Mohan Parthasarathy; Pekka Nikander;=20 > ipng@sunroof.eng.sun.com; Erik Nordmark > Subject: RE: Allocating a bit in the RFC2374 Interface Identifier >=20 >=20 > On Fri, 22 Mar 2002, Hesham Soliman (ERA) wrote: > > > > =3D> For all those opposing the addition of the bit > > > > in the IID, I really hope you would carefully consider > > > > Jari's text above. For mechanisms designed to prove > > > > address ownership (relevant to securing ND, MIPv6 BUs > > > > and I can think of more), you MUST include the=20 > > > > distinction in the _IP_address. The IP address _is_ > > > > the identifier relevant for this case, not the host > > > > name, URL or anything else.=20 > > >=20 > > > Two destination addresses, one that requires verification=20 > > > by stronger=20 > > > means, one which does not. > >=20 > > =3D> ?? Which part of my message are you answering ? >=20 > I was just pointing out a possible alternative to reserving=20 > bits in the source addresses. >=20 > --=20 > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords >=20 >=20 ------_=_NextPart_001_01C1D1C1.87F393A3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Allocating a bit in the RFC2374 Interface Identifier

Pekka,

How do you identify those two addresses without = reserving the bits ?

-mohan


> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Friday, March 22, 2002 8:40 AM
> To: Hesham Soliman (ERA)
> Cc: Jari Arkko; Mohan Parthasarathy; Pekka = Nikander;
> ipng@sunroof.eng.sun.com; Erik Nordmark
> Subject: RE: Allocating a bit in the RFC2374 = Interface Identifier
>
>
> On Fri, 22 Mar 2002, Hesham Soliman (ERA) = wrote:
> >   > > =3D> For all those = opposing the addition of the bit
> >   > > in the IID, I really = hope you would carefully consider
> >   > > Jari's text above. = For mechanisms designed to prove
> >   > > address ownership = (relevant to securing ND, MIPv6 BUs
> >   > > and I can think of = more), you MUST include the
> >   > > distinction in the = _IP_address. The IP address _is_
> >   > > the identifier = relevant for this case, not the host
> >   > > name, URL or anything = else.
> >   >
> >   > Two destination addresses, = one that requires verification
> >   > by stronger
> >   > means, one which does = not.
> >
> > =3D> ?? Which part of my message are you = answering ?
>
> I was just pointing out a possible alternative = to reserving
> bits in the source addresses.
>
> --
> Pekka = Savola           &= nbsp;     "Tell me of difficulties = surmounted,
> Netcore = Oy            = ;       not those you stumble over and = fall"
> Systems. Networks. Security.  -- Robert = Jordan: A Crown of Swords
>
>

------_=_NextPart_001_01C1D1C1.87F393A3-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 09:21:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MHLSKL028669 for ; Fri, 22 Mar 2002 09:21:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MHLSOc028668 for ipng-dist; Fri, 22 Mar 2002 09:21:28 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MHLQKL028661 for ; Fri, 22 Mar 2002 09:21:27 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2MHKRsl002695 for ; Fri, 22 Mar 2002 09:20:27 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g2MHKRVC002694 for ipng@sunroof.eng.sun.com; Fri, 22 Mar 2002 09:20:27 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M3O0KL027330 for ; Thu, 21 Mar 2002 19:24:00 -0800 (PST) Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA05539; Thu, 21 Mar 2002 19:24:01 -0800 (PST) Received: from sun.com (vpn-129-156-96-10.EMEA.Sun.COM [129.156.96.10]) by nasnfs.Eng.Sun.COM (8.10.2+Sun/8.10.2) with ESMTP id g2M3NvL03862; Thu, 21 Mar 2002 19:23:57 -0800 (PST) Message-ID: <3C9AA383.CAFA1A17@sun.com> Date: Fri, 22 Mar 2002 04:22:43 +0100 From: gabriel montenegro Reply-To: gab@sun.com X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Keith Moore CC: Jari Arkko , Mohan Parthasarathy , Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: <200203212218.g2LMImt17284@astro.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > Note that the MitM can also change the IP address, but if he does > > so, he is *not* attacking the original host, as the address is > > changed. > > unless of course the MitM can convince that host to take on that address > as an alias. So Mallory says that his address M is an alias for Alice's address A. Ok. What if Bob looking at A could know (yes, signalled by a bit) that A it is only aliasable by very secure mechanisms. That's the whole point. Mallory would then be forced to break any of several very strong (using crypto and explicit trust relationships) mechanisms: - AAA - PKI - CGA - etc RR would definitely not be included here. -gabriel -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 09:22:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MHMDKL028689 for ; Fri, 22 Mar 2002 09:22:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MHMCDs028686 for ipng-dist; Fri, 22 Mar 2002 09:22:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MHMAKL028678 for ; Fri, 22 Mar 2002 09:22:10 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2MHLBsl002706 for ; Fri, 22 Mar 2002 09:21:11 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g2MHLBZC002705 for ipng@sunroof.eng.sun.com; Fri, 22 Mar 2002 09:21:11 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2M7XfKL027720 for ; Thu, 21 Mar 2002 23:33:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA10544 for ; Thu, 21 Mar 2002 23:33:41 -0800 (PST) Received: from sequoia.muada.com (sequoia.muada.com [213.156.1.123]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA07300 for ; Fri, 22 Mar 2002 00:33:39 -0700 (MST) Received: from localhost (iljitsch@localhost) by sequoia.muada.com (8.11.3/8.9.3) with ESMTP id g2M7X9S51112; Fri, 22 Mar 2002 08:33:09 +0100 (CET) (envelope-from iljitsch@muada.com) Date: Fri, 22 Mar 2002 08:33:08 +0100 (CET) From: Iljitsch van Beijnum To: Michel Py cc: Pekka Savola , , ipv6mh Subject: RE: (ipv6) semantics - TLA In-Reply-To: <2B81403386729140A3A899A8B39B046406C493@server2000.arneill-py.sacramento.ca.us> Message-ID: <20020322082137.R50125-100000@sequoia.muada.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 21 Mar 2002, Michel Py wrote: > The point I am trying to make here is that we need a name or acronym for > "ISPs that receive their addresses directly from a RIR". I am not saying > that "TLA" is the best definition, but it does fit, regardless of > allocation policies and aggregation policies. We currently use "PA (provider aggregateable) block" in IPv4. Can't we use this in IPv6 too? Iljitsch van Beijnum -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 09:31:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MHVjKL028748 for ; Fri, 22 Mar 2002 09:31:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MHVjhU028747 for ipng-dist; Fri, 22 Mar 2002 09:31:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MHVZKL028731 for ; Fri, 22 Mar 2002 09:31:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07829; Fri, 22 Mar 2002 09:31:36 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04933; Fri, 22 Mar 2002 10:31:35 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA04286; Fri, 22 Mar 2002 09:26:35 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2MHQYI20229; Fri, 22 Mar 2002 09:26:34 -0800 X-mProtect:  Fri, 22 Mar 2002 09:26:34 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (166.63.190.236, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdaLkEMm; Fri, 22 Mar 2002 09:26:32 PST Message-Id: <4.3.2.7.2.20020322091447.00a9cc28@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Mar 2002 09:19:57 -0800 To: Erik.Nordmark@eng.sun.com, Thomas Narten From: Bob Hinden Subject: Request to Advance "Advanced Sockets API for IPv6" Cc: ipng@sunroof.eng.sun.com, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as an Informational RFC: Title : Advanced Sockets API for IPv6 Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei Filename : draft-ietf-ipngwg-rfc2292bis-06.txt Pages : 80 Date : 28-Feb-02 This document will replace RFC2292 that is an Informational RFC. The changes from RFC2592 are listed in section 17 of the internet draft. A working group last call for this document was completed on February 6, 2002. This draft resolves issues raised during the last call. The IPv6 w.g. agreed to advance it to Informational at the Minneapolis IETF meeting. Bob Hinden / Steve Deering / Margaret Wasserman IPv6 Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 22 09:31:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MHVdKL028745 for ; Fri, 22 Mar 2002 09:31:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MHVd1f028744 for ipng-dist; Fri, 22 Mar 2002 09:31:39 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MHVZKL028730 for ; Fri, 22 Mar 2002 09:31:35 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA07827 for ; Fri, 22 Mar 2002 09:31:36 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA04932 for ; Fri, 22 Mar 2002 10:31:35 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA04284; Fri, 22 Mar 2002 09:26:34 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2MHQYO20140; Fri, 22 Mar 2002 09:26:34 -0800 X-mProtect:  Fri, 22 Mar 2002 09:26:34 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (166.63.190.236, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdX5S9Ch; Fri, 22 Mar 2002 09:26:32 PST Message-Id: <4.3.2.7.2.20020322091228.030a2ff0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 22 Mar 2002 09:22:58 -0800 To: Erik.Nordmark@eng.sun.com, Thomas Narten From: Bob Hinden Subject: Request to Advance "Basic Socket Interface Extensions for IPv6" Cc: ipng@sunroof.eng.sun.com, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as an Informational RFC: Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, J. McCann, W. Stevens Filename : draft-ietf-ipngwg-rfc2553bis-05.txt Pages : 32 Date : 05-Feb-02 This document will replace RFC2553 that is currently an Informational RFC. The changes from RFC2553 are listed on pages 29 and 30 of the draft. A working group last call for this document was completed on December 26, 2001. This draft resolves issues raised during the last call. The IPv6 w.g. agreed to advance it to Informational at the Minneapolis IETF meeting. Bob Hinden / Steve Deering / Margaret Wasserman IPv6 Working Group Co-Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 22 10:50:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MIoUKL029093 for ; Fri, 22 Mar 2002 10:50:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MIoUuG029092 for ipng-dist; Fri, 22 Mar 2002 10:50:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MIoQKL029085 for ; Fri, 22 Mar 2002 10:50:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA27766 for ; Fri, 22 Mar 2002 10:50:27 -0800 (PST) Received: from roll.mentat.com (mentat.com [192.88.122.129]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22357 for ; Fri, 22 Mar 2002 11:50:26 -0700 (MST) Received: from leo.mentat.com (leo [192.88.122.132]) by roll.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA11396; Fri, 22 Mar 2002 10:50:28 -0800 (PST) Received: from feller.mentat.com (feller [192.88.122.144]) by leo.mentat.com (8.9.1b+Sun/8.9.1) with ESMTP id KAA29923; Fri, 22 Mar 2002 10:50:28 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id KAA21116; Fri, 22 Mar 2002 10:52:36 -0800 (PST) Date: Fri, 22 Mar 2002 10:52:36 -0800 (PST) From: Tim Hartrick Message-Id: <200203221852.KAA21116@feller.mentat.com> To: jinmei@isl.rdc.toshiba.co.jp, deering@cisco.com Subject: Re: poposed changes to the scoping architecture draft Cc: richdr@microsoft.com, ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Steve, > >Perhaps we have two choices: > > > >1. treat :: as global > >2. does (explicitly) not define the scope type (level) of :: > > > >Even the choice 2 will make the document clear, and it will not cause > >a problem in a practical point of view. > > I think of :: as indicating the absence of an address, in which case > it doesn't have any scope. For those who feel the need to assign a > scope value to ::, it's probably safest to treat it as link-local > (for example, to ensure that a router receiving a packet with a > source address of :: is not forwarded to another link). > In thinking about how these facilities are going to be used by applications, it seems that we need a way to express a desire to accept connections or datagrams from any address in a specific zone. We also need a way to express a desire to accept connections or datagrams for a specific address within any zone. That is, I would like to be able bind a socket to any of: ::%. ::%. ::%. % (The address specifies the type) % (The address specifies the type) How the unspecified address is treated by the forwarding code is orthogonal to how applications make use of it to specify which connections or datagrams are received on a socket. I agree that the forwarding code should treat :: as a link-local address. I just wanted to point out that the ability to use the scope type and zone id for filtering could have utility to some class of applications. Tim Hartrick Mentat 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 Mar 22 12:01:05 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MK15KL029207 for ; Fri, 22 Mar 2002 12:01:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MK15qf029206 for ipng-dist; Fri, 22 Mar 2002 12:01:05 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MK11KL029199 for ; Fri, 22 Mar 2002 12:01:01 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA04946; Fri, 22 Mar 2002 11:59:57 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA23662; Fri, 22 Mar 2002 11:58:47 -0800 (PST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2MJvtD29211; Fri, 22 Mar 2002 13:57:55 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 13:57:56 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02BD4C6D@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: gab@Sun.COM, Keith Moore Cc: Jari Arkko , Mohan Parthasarathy , Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Fri, 22 Mar 2002 13:57:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D1DB.D776E1A0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D1DB.D776E1A0 Content-Type: text/plain; charset="iso-8859-1" Right, So do people understand why having it in the address provides more protection? Now let's assume that we did not allow just RR, this would avoid the bidding down attack IFF there was only one strong method. But I suspect there may be more than one strong method and arguments as to which strong method is better will fourish and the bidding down attack may still be protrayed as being there between the strong mechanisms. Again this putting the bit in the address for extra protection may be in question over and over, IMHO. I.e. if a field that indicates which strong method to use is in place above the address then it can be alterred as well using the same logic for the bit being in the address now. > -----Original Message----- > From: gabriel montenegro [mailto:gab@Sun.COM] > Sent: Thursday, March 21, 2002 9:23 PM > To: Keith Moore > Cc: Jari Arkko; Mohan Parthasarathy; Pekka Nikander; Pekka Savola; > ipng@sunroof.eng.sun.com; Erik Nordmark > Subject: Re: Allocating a bit in the RFC2374 Interface Identifier > > > Keith Moore wrote: > > > > Note that the MitM can also change the IP address, but if he does > > > so, he is *not* attacking the original host, as the address is > > > changed. > > > > unless of course the MitM can convince that host to take on > that address > > as an alias. > > So Mallory says that his address M is an alias for Alice's > address A. Ok. > What if Bob looking at A could know (yes, signalled by a bit) that A > it is only aliasable by very secure mechanisms. That's the > whole point. > Mallory would then be forced to break any of several very strong > (using crypto and explicit trust relationships) mechanisms: > > - AAA > - PKI > - CGA > - etc > > RR would definitely not be included here. > > -gabriel > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > ------_=_NextPart_001_01C1D1DB.D776E1A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Allocating a bit in the RFC2374 Interface Identifier

Right,

So do people understand why having it in the address = provides more protection?

Now let's assume that we did not allow just RR, this = would avoid the bidding down attack IFF there was only one strong = method. But I suspect there may be more than one strong method and = arguments as to which strong method is better will fourish and the = bidding down attack may still be protrayed as being there between the = strong mechanisms.

Again this putting the bit in the address for extra = protection may be in question over and over, IMHO. I.e. if a field that = indicates which strong method to use is in place above the address then = it can be alterred as well using the same logic for the bit being in = the address now.






> -----Original Message-----
> From: gabriel montenegro [mailto:gab@Sun.COM]
> Sent: Thursday, March 21, 2002 9:23 PM
> To: Keith Moore
> Cc: Jari Arkko; Mohan Parthasarathy; Pekka = Nikander; Pekka Savola;
> ipng@sunroof.eng.sun.com; Erik Nordmark
> Subject: Re: Allocating a bit in the RFC2374 = Interface Identifier
>
>
> Keith Moore wrote:
>
> > > Note that the MitM can also change = the IP address, but if he does
> > > so, he is *not* attacking the = original host, as the address is
> > > changed.
> >
> > unless of course the MitM can convince = that host to take on
> that address
> > as an alias.
>
> So Mallory says that his address M is an alias = for Alice's
> address A. Ok.
> What if Bob looking at A could know (yes, = signalled by a bit) that A
> it is only aliasable by very secure mechanisms. = That's the
> whole point.
> Mallory would then be forced to break any of = several very strong
> (using crypto and explicit trust relationships) = mechanisms:
>
>     - AAA
>     - PKI
>     - CGA
>     - etc
>
> RR would definitely not be included = here.
>
> -gabriel
>
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> FTP archive:      =             =     ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>

------_=_NextPart_001_01C1D1DB.D776E1A0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 22 14:07:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MM7UKL029394 for ; Fri, 22 Mar 2002 14:07:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2MM7UFs029393 for ipng-dist; Fri, 22 Mar 2002 14:07:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2MM7QKL029386 for ; Fri, 22 Mar 2002 14:07:26 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA21638 for ; Fri, 22 Mar 2002 14:07:26 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA29850 for ; Fri, 22 Mar 2002 15:07:26 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2MM6fD05372; Fri, 22 Mar 2002 16:06:41 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Mar 2002 16:06:42 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02BD5006@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: "Glenn Morrow", gab@Sun.COM, Keith Moore Cc: Jari Arkko , Mohan Parthasarathy , Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Fri, 22 Mar 2002 16:06:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D1ED.D8410A40" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D1ED.D8410A40 Content-Type: text/plain; charset="iso-8859-1" Gee, I guess a bidding down threat could also depend on the size of keys used as well. Let's put a key size field in the address as well as a signaling semantics id, too. But even with this you are still stuck with the 2 nodes in collusion MITM attack. I guess this could be used by slaves in multiple sites to make it look like DDoS attack was coming from another node in that site. If you want to get rid of this collusion threat you will have to do the "plug the holes in IPv6" BCP and bring the routers into the security and signaling picture. Even them there will likely be some risks. I guess what I'm saying is that, "I would rather get rid of the simple RR in order to avoid having to reserve such a permiscuous bit in order to meet the rather arbitrary, IMO, acceptable risk qualification. If RR alone without some sort of integrity protection does not meet the acceptable risk then it simply shouldn't be standardized. I do, however, agree with the forsight that reserving some space in the identifier now is a good idea; however, there are already bits reserved in to upper part of the address but these doen't have the same properties in terms of scoping. -----Original Message----- From: Morrow, Glenn [RICH2:C330:EXCH] Right, So do people understand why having it in the address provides more protection? Now let's assume that we did not allow just RR, this would avoid the bidding down attack IFF there was only one strong method. But I suspect there may be more than one strong method and arguments as to which strong method is better will fourish and the bidding down attack may still be protrayed as being there between the strong mechanisms. Again this putting the bit in the address for extra protection may be in question over and over, IMHO. I.e. if a field that indicates which strong method to use is in place above the address then it can be alterred as well using the same logic for the bit being in the address now. > -----Original Message----- > From: gabriel montenegro [mailto:gab@Sun.COM] > Keith Moore wrote: > > > > Note that the MitM can also change the IP address, but if he does > > > so, he is *not* attacking the original host, as the address is > > > changed. > > > > unless of course the MitM can convince that host to take on > that address > > as an alias. > > So Mallory says that his address M is an alias for Alice's > address A. Ok. > What if Bob looking at A could know (yes, signalled by a bit) that A > it is only aliasable by very secure mechanisms. That's the > whole point. > Mallory would then be forced to break any of several very strong > (using crypto and explicit trust relationships) mechanisms: > > - AAA > - PKI > - CGA > - etc > > RR would definitely not be included here. > > -gabriel > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > ------_=_NextPart_001_01C1D1ED.D8410A40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Allocating a bit in the RFC2374 Interface Identifier

Gee, I guess a bidding down threat could also depend = on the size of keys used as well. Let's put a key size field in the = address as well as a signaling semantics id, too. But even with this = you are still stuck with the 2 nodes in collusion MITM attack. I guess = this could be used by slaves in multiple sites to make it look like = DDoS attack was coming from another node in that site. If you want to = get rid of this collusion threat you will have to do the "plug the = holes in IPv6" BCP and bring the routers into the security and = signaling picture. Even them there will likely be some = risks.

I guess what I'm saying is that, "I would rather = get rid of the simple RR in order to avoid having to reserve such a = permiscuous bit in order to meet the rather arbitrary, IMO, acceptable = risk qualification. If RR alone without some sort of integrity = protection does not meet the acceptable risk then it simply shouldn't = be standardized.

I do, however, agree with the forsight that reserving = some space in the identifier now is a good idea; however, there are = already bits reserved in to upper part of the address but these doen't = have the same properties in terms of scoping.

-----Original Message-----
From: Morrow, Glenn [RICH2:C330:EXCH]

Right,
So do people understand why having it in the address = provides more protection?
Now let's assume that we did not allow just RR, this = would avoid the bidding down attack IFF there was only one strong = method. But I suspect there may be more than one strong method and = arguments as to which strong method is better will fourish and the = bidding down attack may still be protrayed as being there between the = strong mechanisms.

Again this putting the bit in the address for extra = protection may be in question over and over, IMHO. I.e. if a field that = indicates which strong method to use is in place above the address then = it can be alterred as well using the same logic for the bit being in = the address now.

> -----Original Message-----
> From: gabriel montenegro [mailto:gab@Sun.COM]
> Keith Moore wrote:
>
> > > Note that the MitM can also change = the IP address, but if he does
> > > so, he is *not* attacking the = original host, as the address is
> > > changed.
> >
> > unless of course the MitM can convince = that host to take on
> that address
> > as an alias.
>
> So Mallory says that his address M is an alias = for Alice's
> address A. Ok.
> What if Bob looking at A could know (yes, = signalled by a bit) that A
> it is only aliasable by very secure mechanisms. = That's the
> whole point.
> Mallory would then be forced to break any of = several very strong
> (using crypto and explicit trust relationships) = mechanisms:
>
>     - AAA
>     - PKI
>     - CGA
>     - etc
>
> RR would definitely not be included here. =
>
> -gabriel
>
> = -------------------------------------------------------------------- =
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = -------------------------------------------------------------------- =
>

------_=_NextPart_001_01C1D1ED.D8410A40-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 23 03:31:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2NBV7KL000349 for ; Sat, 23 Mar 2002 03:31:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2NBV6Jn000348 for ipng-dist; Sat, 23 Mar 2002 03:31:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2NBV3KL000341 for ; Sat, 23 Mar 2002 03:31:03 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id DAA23525 for ; Sat, 23 Mar 2002 03:31:03 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA02633 for ; Sat, 23 Mar 2002 04:31:02 -0700 (MST) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A23856A907; Sat, 23 Mar 2002 13:30:44 +0200 (EET) Message-ID: <3C9C03C8.9060208@kolumbus.fi> Date: Sat, 23 Mar 2002 06:25:44 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Glenn Morrow Cc: gab@Sun.COM, Keith Moore , Mohan Parthasarathy , Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: <933FADF5E673D411B8A30002A5608A0E02BD5006@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Glenn Morrow wrote: > I do, however, agree with the forsight that reserving some space in the > identifier now is a good idea; however, there are already bits reserved > in to upper part of the address but these doen't have the same > properties in terms of scoping. Well, if we could agree on the "reservation" at least then we could move rfc 2374 bis forward and continue the "use" discussion. Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 23 04:22:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2NCMjKL000392 for ; Sat, 23 Mar 2002 04:22:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2NCMjwO000391 for ipng-dist; Sat, 23 Mar 2002 04:22:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2NCMgKL000384 for ; Sat, 23 Mar 2002 04:22:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA23516 for ; Sat, 23 Mar 2002 04:22:42 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA09579 for ; Sat, 23 Mar 2002 05:22:41 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2NCM9e27934; Sat, 23 Mar 2002 14:22:09 +0200 Date: Sat, 23 Mar 2002 14:22:08 +0200 (EET) From: Pekka Savola To: Mohan Parthasarathy cc: "Hesham Soliman (ERA)" , Jari Arkko , Pekka Nikander , , Erik Nordmark Subject: RE: Allocating a bit in the RFC2374 Interface Identifier In-Reply-To: <416B5AF360DED54088DAD3CA8BFBEA6E6349C2@TNEXVS02.tahoenetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 22 Mar 2002, Mohan Parthasarathy wrote: > Pekka, > > How do you identify those two addresses without reserving the bits ? "From the hip", possibly either: 1. invent some nice mechanism and patent it. Good riddance, or 2. the implementations which support ABK add an extra rule in their destination/source address selection rules so addresses which seem to be ABK'ed will be tried first; this can be just a guess, something based on the address, a bit reserved in the IID by the ABK mechanism or whatever, or 3. require manual configuration. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 23 04:42:58 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2NCgwKL000448 for ; Sat, 23 Mar 2002 04:42:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2NCgwXE000447 for ipng-dist; Sat, 23 Mar 2002 04:42:58 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2NCgtKL000440 for ; Sat, 23 Mar 2002 04:42:55 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA02793; Sat, 23 Mar 2002 04:42:55 -0800 (PST) Received: from jade.coe.psu.ac.th ([192.150.250.54]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA20853; Sat, 23 Mar 2002 04:42:45 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (brandenburg.cs.mu.OZ.AU [172.30.0.77]) by jade.coe.psu.ac.th (8.11.3/8.11.3) with ESMTP id g2NCi6e01138; Sat, 23 Mar 2002 19:44:08 +0700 (ICT) Received: from brandenburg.cs.mu.OZ.AU (localhost [127.0.0.1]) by brandenburg.cs.mu.OZ.AU (8.11.0/8.11.0) with ESMTP id g2MIrSS00634; Sat, 23 Mar 2002 01:53:28 +0700 (ICT) From: Robert Elz To: Erik Nordmark cc: ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2437 Interface Identifier In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 23 Mar 2002 01:53:28 +0700 Message-ID: <632.1016823208@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 21 Mar 2002 15:25:58 +0100 (CET) From: Erik Nordmark Message-ID: | Without going into history, the current state | is that the U/L bit has semantics in the sense that we point out [somewhere] | that e.g. future transport protocols might use the knowledge that | the interface ID is globally unique when the U bit is set. Yes, that is written down, but nonsense written down is still nonsense. A IID does not become globally unique just because it has the U bit set, and any future protocol that attempted to assume that it did would be quite rightly laughed out of the I-D directories (if it even made it that far). There can never be such a protocol, the very idea is ludicrous - those words should be deleted from 2373bis. | FWIW we seem to, for whatever reasons, already have embarked on the path | of having semantics associated with the interface ID. There's nothing wrong with that, when people are agreeing to make use of them (it isn't a very good choice, but people can do what they want with their addresses). What you can't do is take some random address, and assume anything at all about it (other than the way to route to it) merely from its bit pattern (nb: issues of link local, site local, IPv4 mapped, ... are all related to "how to route to it"). | While I'm not advocating removing the U/L bit, No, it serves a useful purpose, when we define when it should be set, and when it shouldn't - and allows better interoperation between implementations that all follow those standards. The problems only come when we pretend we can interpret what it means when we see it, as distint from set it (or not) to achieve a particular outcome. | it sure would be interesting | to know whether we think assigning the globally unique semantics is | a bad idea. It isn't that it is a bad idea, it is that it is an impossible idea. It might actually be nice to know if the IID is globally unique, but there's no way you can discover that. I have been pondering collecting the IIDs of all nodes I communicate with and using those exact same IIDs in addresses I assign... Guaranteed non-unique IIDs (with the U bit in either state). There's nothing anyone can do to prevent me from doing that. Except if yours happens by some fluke to be one of the IIDs I make use of, there's not any way for you to tell that an address has been formed that way. | If so perhaps we should make it clear that U=1 means | "assigned by the IEEE according to EUI-64" and nothing more. No, that's not right either. U=1 *means* nothing at all. Or no more than if the bit to the left of it (in the normal printed representation, that is, not the G bit) is set. It is just a bit. But it is a bit that we set when we make use of an EUI-64 for creating an address, and don't set otherwise - and which thus, when we create the address, is extremely unlikely to be a duplicate on the link. That is, we set (or clear) it to achieve a purpose - once that has been achieved, we cannot read any more into the address (bit) than that. | My interpretation is that this is not the current state of things. Probably not - but that's because people seem to be dreaming of some state where they could tell that this IID was unique, and use it without its prefix in some (currently unstated) way. If it were possible, that would be nice. It just isn't possible. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 23 05:10:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2NDAlKL000482 for ; Sat, 23 Mar 2002 05:10:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2NDAl3K000481 for ipng-dist; Sat, 23 Mar 2002 05:10:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2NDAiKL000474 for ; Sat, 23 Mar 2002 05:10:44 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06124 for ; Sat, 23 Mar 2002 05:10:44 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA02128 for ; Sat, 23 Mar 2002 06:10:43 -0700 (MST) Received: from rdroms-w2k.cisco.com (sjc-vpn2-243.cisco.com [10.21.112.243]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA01976; Sat, 23 Mar 2002 08:10:10 -0500 (EST) Message-Id: <4.3.2.7.2.20020323075001.0357f170@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 23 Mar 2002 07:59:11 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Prefix delegation issues from Minneapolis Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk A couple of issues came out of the discussion of the prefix delegation option in Minneapolis: * Disallow reassigning delegated prefix on upstream link (and should this restriction be configurable?) * Allow use of DHCP on NBMA links by reserving a well-known anycast address for client->server messages * Devise a mechanism for prefix delegation through a two-message exchange * Write a specification for a simplified version of DHCP that meets the requirements for prefix delegation; this simplified protocol needs a name that doesn't include the word "Host" I'll kick off discussion on these issues in separate messages on the dhcwg@ietf.org mailing list. - 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 Sat Mar 23 10:09:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2NI9lKL001081 for ; Sat, 23 Mar 2002 10:09:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2NI9lGq001080 for ipng-dist; Sat, 23 Mar 2002 10:09:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2NI9gKL001073 for ; Sat, 23 Mar 2002 10:09:42 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2NI9bx27204; Sat, 23 Mar 2002 19:09:38 +0100 (MET) Date: Sat, 23 Mar 2002 19:09:26 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier To: Pekka Nikander Cc: Rami Lehtonen , ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Or am I missing something? Pekka, Perhaps the question was about the whole address and not just the interface ID. You've described how the interface ID is crypgraphically tied to a public key. But this doesn't per-se prevent somebody fabricating a CGA address using an arbitrary prefix. The way to avoid this for MIPv6 is to do a return routability test when the CGA address is verified. The RR test would ensure that the peer is reachable at the prefix. (And the RR test would essentially be done as part of the challenge to have the peer sign the nonce using the private key.) Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat Mar 23 10:10:14 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2NIAEKL001091 for ; Sat, 23 Mar 2002 10:10:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2NIAD54001090 for ipng-dist; Sat, 23 Mar 2002 10:10:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2NIA8KL001083 for ; Sat, 23 Mar 2002 10:10:08 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2NIA4x27240; Sat, 23 Mar 2002 19:10:04 +0100 (MET) Date: Sat, 23 Mar 2002 19:09:53 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Allocating a bit in the RFC2374 Interface Identifier To: Pekka Savola Cc: Dave Thaler , ipng@sunroof.eng.sun.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > Since a spoofer can construct any packet they like, and NOT include any > > authentication data, a bit in the source address seems to be the only > > way for a receiver who cares, to know whether to drop it (because auth > > data is missing) or accept it (because it's a legacy insecure address). > > What about the receiver having two IP-addresses, one for legacy and one > for "secure-only" source addresses? If the receiver indeed enforced that "secure-only" source address can only be used with the "secure-only" destination this might work as far as the security aspects at the IP layer. (But I haven't thought long and hard about this to tell for sure if this is sufficient - it is required as far as I can tell.) But, that would imply that the receiver somehow being able to control who uses which of its IP addresses i.e. be able to ensure that the peers that want more secure operation get the secure-only address and vice-versa. Thus somehow the distinction between secure and non-secure destination addresses need to be encoded in what is stored in the DNS (and other places that translates "names" to IP addresses). That seems like a fair amount of change to other parts of the system. Do you have good ideas of how this can be done? Erik -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 24 05:58:42 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2ODwgKL002902 for ; Sun, 24 Mar 2002 05:58:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2ODwgdq002901 for ipng-dist; Sun, 24 Mar 2002 05:58:42 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2ODwdKL002894 for ; Sun, 24 Mar 2002 05:58:39 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA00653 for ; Sun, 24 Mar 2002 05:58:41 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA27885 for ; Sun, 24 Mar 2002 05:58:42 -0800 (PST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 9DB72A; Sun, 24 Mar 2002 15:58:43 +0200 (EET) Message-ID: <3C9DDB42.8010309@nomadiclab.com> Date: Sun, 24 Mar 2002 15:57:22 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik Nordmark Cc: Rami Lehtonen , ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, > Perhaps the question was about the whole address and not just the interface > ID. You've described how the interface ID is crypgraphically tied to a > public key. But this doesn't per-se prevent somebody fabricating a > CGA address using an arbitrary prefix. You are right. Michael & Tuomas suggested that "stuff" included also the prefix, hence iid = low64(hash(PK, prefix, stuff)) & mask This makes it harder to transfer iids from one link to another, or to create pre-computed iids. But it doesn't prevent "fabricanting" CGA addresses; they are all fabricated by the host itself, after all. That is explained in detail in draft-roe-mobileip-updateauth-02.txt. What CGA is all about is that it is (believed to be) hard to create two create two pairs that happen to have the same IID, or -- more importantly -- to find a pair that yields a given IID. That also set some restrictions on what one can include in "stuff". > The way to avoid this for MIPv6 is to do a return routability test > when the CGA address is verified. The RR test would ensure that the > peer is reachable at the prefix. (And the RR test would essentially be done > as part of the challenge to have the peer sign the nonce using the private > key.) That's right. CGA alone doesn't really show that somebody "owns" an address. In the non-local case, you must always perform the RR test also, they way you note. --Pekka -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 24 12:44:23 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2OKiNKL003519 for ; Sun, 24 Mar 2002 12:44:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2OKiNm4003518 for ipng-dist; Sun, 24 Mar 2002 12:44:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2OKiKKL003511 for ; Sun, 24 Mar 2002 12:44:20 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA20746 for ; Sun, 24 Mar 2002 12:44:22 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04718 for ; Sun, 24 Mar 2002 13:44:20 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2OKiFa14719; Sun, 24 Mar 2002 22:44:15 +0200 Date: Sun, 24 Mar 2002 22:44:15 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: Dave Thaler , Subject: RE: Allocating a bit in the RFC2374 Interface Identifier In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 23 Mar 2002, Erik Nordmark wrote: > But, that would imply that the receiver somehow being able to control > who uses which of its IP addresses i.e. be able to ensure that the > peers that want more secure operation get the secure-only address > and vice-versa. > > Thus somehow the distinction between secure and non-secure destination > addresses need to be encoded in what is stored in the DNS (and > other places that translates "names" to IP addresses). > That seems like a fair amount of change to other parts of the system. > Do you have good ideas of how this can be done? Practically this would probably require some algorithm in source/destination address selection I think. If DNS is not used, practically this would either mean some encoding in the address (but the "damage" would be limited to the subnet of nodes implementing ABK), or more or less educated guesses based on some heuristics. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 24 13:01:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2OL1FKL003553 for ; Sun, 24 Mar 2002 13:01:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2OL1FVi003552 for ipng-dist; Sun, 24 Mar 2002 13:01:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2OL1CKL003545 for ; Sun, 24 Mar 2002 13:01:12 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23944 for ; Sun, 24 Mar 2002 13:01:14 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA08455 for ; Sun, 24 Mar 2002 13:01:03 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2OL17714848; Sun, 24 Mar 2002 23:01:08 +0200 Date: Sun, 24 Mar 2002 23:01:07 +0200 (EET) From: Pekka Savola To: Yamasaki Toshi cc: ipng@sunroof.eng.sun.com Subject: Re: Prefix delegation options In-Reply-To: <020301c1d357$e0d4ea30$31b57e3d@local> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Mar 2002, Yamasaki Toshi wrote: > Probably what I want to say is that it'd the best idea to have one > "lite-weight" solution to solve major requirements, which is compatible > for a "full-covered" solution to solve also minor requiremnts. To > achieve this, there seems three solutions: > > 1) DNCP (DHCP-lite) as a "lite-weight", DHCP as a "full-covered" > 2) APD as a "lite-weight", APD-heavy as a "full-covered" > 3) RA+PDopt as a "lite-weight", RA+PDopt-heavy as a "full covered" > > Ralf is writing DNCP, and currently nobody seems writing APD-heavy nor > RA+PDopt-heavy. I don't think mechanisms of 2) or 3) (ie. ICMP6) even should be used for "heavy" operations: if one requires these, one can always use DHCPv6 or static allocations. So, the only problems I see outright: 1. writing requirements to see what we actually want 2. developing APD further, e.g. to a bit more lightweight solution 3. writing a lightweight DHCPv6 solution; IMO, DHCPv6 specification should be split anyway though. ( 4. possibly fixing the few problems with RA delegation, if that is preferred to APD) > > > I think APD is simple enough, and DNCP is also simple enough. > Technically > > > there is almost no difference between DNCP and APD. > > > > True, but APD has IMO unnecessary components of stateful nature, like > > prefix return message. > > > Now I see what you mean by "statefull" :-) > I agree with you that you don't need "prefix return" like messages when you > assume only dedicated(fixed) prefix and flat rate access services, and I > guess that is often the case. True. And this can be, to some extent, be remedied by short lifetimes and need be. > But if you assume also non-dedicated(dynamic?) prefix and non-flat rate(per > time?) access services, for exapmle, remote access or roaming services, your > customers probably want "prefix return" like messages, for exapmle when they > want to temporalily stop using IPv6 access to save mony but continue to use > IPv4 access. > > # I don't like this kind of services personally :-), but we should avoid > killing any posibility of new business models. Solutions don't have to cover every corner case. This is IMO one where DHCPv6 could be useful, due to its stateful nature. > > > It assumes only P-to-P enviroment. Again you need another solution for > > > non-P-to-P enviroment. Our goal is to achieve auto-configuration, right? > > > Then, how dose a CPE know whether it is conneted to P-to-P link or > P-to-MP > > > link automatically? > > > > Prefix Delegation need not be (IMO) completely automatic: it's completely > > ok to have to add a 'request-prefix interface eth0', 'request-prefix > > interface any', or whatever in the configuration of the CPE. > > I agree with you that Prefix Delegation doesn't have to be 100% automatic. > > But I still don't think that it is a better idea to define different > mechanisms for P-to-P and non-P-to-P respectively, because, for example, it > is difficlt for a CPE to know whether its eth0 is connceted to P-to-P > ethernet or non-P-to-P ethernet. In non-P-t-P case the security is important (assuming that multiple customers share one ethernet medium); the other case might be more than one ISP in one non-P-t-P medium but with only one customer. In both cases, security associations (e.g. manually keyed ones) could be built which would protect (mostly at least) from unwanted queries and responses. If not via IPSEC, the packets would have to contain some form of identification other than addresses anyway. In the first case, instead of all-routers multicast address,. some other, e.g. "all-delegators" could be used. In the second case, I imagine one would like to use DHCPv6 for policy reasons. Some other issues in non-P-t-P cases could be fixed as well I think; only, I think we'd first have to identify which links are non-P-t-P so we can decide whether this restriction is an important enough one to be required for consideration. Routed ATM? Bridged ATM? Dial-up? Cable? Some Ethernet solutions (which?) ... Potentially, I see only Bridged ATM except some weirder Ethernet ones (e.g. Ethernet to a neighbourhood with one upstream router and all homes there connected to a switch) as possibly problemaic here, but I don't have that deep knowledge on how all of these are used in the world to say for sure. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun Mar 24 20:23:55 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2P4NtKL003998 for ; Sun, 24 Mar 2002 20:23:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2P4NtBt003997 for ipng-dist; Sun, 24 Mar 2002 20:23:55 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2P4NqKL003990 for ; Sun, 24 Mar 2002 20:23:52 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id UAA20406 for ; Sun, 24 Mar 2002 20:23:55 -0800 (PST) From: zhang.hongyuan@zte.com.cn Received: from mail2.zte.com.cn ([210.21.227.66]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA23242 for ; Sun, 24 Mar 2002 20:23:55 -0800 (PST) Subject: About the IPv6 market place To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Mon, 25 Mar 2002 11:22:27 +0800 X-MIMETrack: Serialize by Router on notes_svr7_1/zte_ltd(Release 5.0.6a |January 17, 2001) at 2002-03-25 12:27:27 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I am now involved in writing a report on IPv6, my supervisor wants some concrete figures or charts about the market place of IPv6, but I don't know where I can get them. Could those people who have the statistics ( market surveys or predictions) possibly offer me some data and reference. Thanks --Best regards, ZHANG Hongyuan -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 25 02:01:20 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PA1JKL004476 for ; Mon, 25 Mar 2002 02:01:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PA1JrE004475 for ipng-dist; Mon, 25 Mar 2002 02:01:19 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PA1GKL004468 for ; Mon, 25 Mar 2002 02:01:16 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01179; Mon, 25 Mar 2002 02:01:17 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA24498; Mon, 25 Mar 2002 02:01:18 -0800 (PST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id LAA136906; Mon, 25 Mar 2002 11:00:22 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2PA0J3153652; Mon, 25 Mar 2002 11:00:20 +0100 Received: from dhcp22-167.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA53922 from ; Mon, 25 Mar 2002 11:00:15 +0100 Message-Id: <3C9EF51B.969BEED0@hursley.ibm.com> Date: Mon, 25 Mar 2002 10:59:55 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Glenn Morrow Cc: gab@Sun.COM, Keith Moore , Jari Arkko , Mohan Parthasarathy , Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: <933FADF5E673D411B8A30002A5608A0E02BD4C6D@zrc2c012.us.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Glenn Morrow wrote: > > Right, > > So do people understand why having it in the address provides more protection? No. Quoting Pekka Nikander's original description of the bidding-down attack: Note that an active attacker at the path between Alice and Bob is able o clear a set bit. However, that changes the address, and Alice is not going to answer to any possible replies sent by Bob. Thus, the bit prevents the attacker from impersonating as Alice and fooling Bob to use the less secure protocol. This doesn't satisfy me. If the attacker is capable of clearing the bit in the source address of packets from Alice to Bob, it is equally capable of setting the bit in the destination address of packets from Bob to Alice. (The proof of concept here is every NAT box sold so far.) So I don't see why the attacker can't conduct a complete bidding-down attack in which Alice sees only packets with the bit set, and Bob sees only packets with the bit cleared. Alice will believe she has asserted "strong security available", Bob will believe the opposite, and both will be fooled. Brian > Now let's assume that we did not allow just RR, this would avoid the bidding down attack IFF there was only one strong method. > But I suspect there may be more than one strong method and arguments as to which strong method is better will fourish and the > bidding down attack may still be protrayed as being there between the strong mechanisms. > > Again this putting the bit in the address for extra protection may be in question over and over, IMHO. I.e. if a field that > indicates which strong method to use is in place above the address then it can be alterred as well using the same logic for > the bit being in the address now. > > > -----Original Message----- > > From: gabriel montenegro [mailto:gab@Sun.COM] > > Sent: Thursday, March 21, 2002 9:23 PM > > To: Keith Moore > > Cc: Jari Arkko; Mohan Parthasarathy; Pekka Nikander; Pekka Savola; > > ipng@sunroof.eng.sun.com; Erik Nordmark > > Subject: Re: Allocating a bit in the RFC2374 Interface Identifier > > > > > > Keith Moore wrote: > > > > > > Note that the MitM can also change the IP address, but if he does > > > > so, he is *not* attacking the original host, as the address is > > > > changed. > > > > > > unless of course the MitM can convince that host to take on > > that address > > > as an alias. > > > > So Mallory says that his address M is an alias for Alice's > > address A. Ok. > > What if Bob looking at A could know (yes, signalled by a bit) that A > > it is only aliasable by very secure mechanisms. That's the > > whole point. > > Mallory would then be forced to break any of several very strong > > (using crypto and explicit trust relationships) mechanisms: > > > > - AAA > > - PKI > > - CGA > > - etc > > > > RR would definitely not be included here. > > > > -gabriel > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 25 04:50:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PCorKL004625 for ; Mon, 25 Mar 2002 04:50:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PCorTf004624 for ipng-dist; Mon, 25 Mar 2002 04:50:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PColKL004617 for ; Mon, 25 Mar 2002 04:50:48 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2PCojx22908; Mon, 25 Mar 2002 13:50:45 +0100 (MET) Date: Mon, 25 Mar 2002 13:50:34 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Allocating a bit in the RFC2374 Interface Identifier To: Pekka Savola Cc: Mohan Parthasarathy , "Hesham Soliman (ERA)" , Jari Arkko , Pekka Nikander , ipng@sunroof.eng.sun.com, Erik Nordmark In-Reply-To: "Your message with ID" Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On Fri, 22 Mar 2002, Mohan Parthasarathy wrote: > > Pekka, > > > > How do you identify those two addresses without reserving the bits ? > > "From the hip", possibly either: > > 1. invent some nice mechanism and patent it. Good riddance, or > > 2. the implementations which support ABK add an extra rule in their > destination/source address selection rules so addresses which seem to be > ABK'ed will be tried first; this can be just a guess, something based on > the address, a bit reserved in the IID by the ABK mechanism or whatever, > or But I think ABK as well as CGA addresses would require communicating in order to verify that the address is valid according to ABK or CGA. Thus in order to choose destination and source addresses the node would need to communicate. Seems kind of expensive. In the case of CGA (I haven't wrapped my head around ABK yet) it seems feasible to do things without a bit in the address for MIPv6 if each time a CN receives a BU, the CN would challenge the MN to prove that it has a public key whose hash (really, hash(PK, prefix, stuff)) is the IID. If the MN can't prove that then either the MN is an imposter or is it using a non-CGA IID. Without a bit in the address the CN can't tell which of those is the case. > 3. require manual configuration. Eureka, that's it!! :-) 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 Mar 25 05:08:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PD8NKL004679 for ; Mon, 25 Mar 2002 05:08:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PD8N0u004678 for ipng-dist; Mon, 25 Mar 2002 05:08:23 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PD8KKL004671 for ; Mon, 25 Mar 2002 05:08:20 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA06684; Mon, 25 Mar 2002 05:08:20 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA02249; Mon, 25 Mar 2002 06:08:19 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2PD8Ii22038; Mon, 25 Mar 2002 15:08:18 +0200 Date: Mon, 25 Mar 2002 15:08:17 +0200 (EET) From: Pekka Savola To: Erik Nordmark cc: Mohan Parthasarathy , "Hesham Soliman (ERA)" , Jari Arkko , Pekka Nikander , Subject: RE: Allocating a bit in the RFC2374 Interface Identifier In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Mar 2002, Erik Nordmark wrote: > > 3. require manual configuration. > > Eureka, that's it!! :-) Actually, in some cases (e.g. some ND messages, to prevent spoofing), this wouldn't be all that big an issue :-) -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 25 05:41:19 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PDfIKL004847 for ; Mon, 25 Mar 2002 05:41:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PDfIuX004846 for ipng-dist; Mon, 25 Mar 2002 05:41:18 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PDfFKL004836 for ; Mon, 25 Mar 2002 05:41:15 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA10557 for ; Mon, 25 Mar 2002 05:41:16 -0800 (PST) From: francis.arts@alcatel.be Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA23311 for ; Mon, 25 Mar 2002 05:41:04 -0800 (PST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2PDf6k09708 for ; Mon, 25 Mar 2002 14:41:06 +0100 (MET) To: ipng@sunroof.eng.sun.com Subject: Traffic class MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Mon, 25 Mar 2002 14:41:01 +0100 X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/25/2002 14:41:05, Serialize complete at 03/25/2002 14:41:05 Content-Type: multipart/alternative; boundary="=_alternative 004B2AC6C1256B87_=" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 004B2AC6C1256B87_= Content-Type: text/plain; charset="us-ascii" Hello, The IPv6 header specifies the traffic class field. From RFC 2460 (IPv6 spec.) I understand that it basically is the ipv6 equivalent of the DS byte in the IPv4 header. Is there an RFC/a draft specifying the traffic class encoding for the different PHBs (similar to RFC 2597/RFC 2598 for AF and EF in the IPv4 world)? Thanks for any clarification you can provide, Francis. --=_alternative 004B2AC6C1256B87_= Content-Type: text/html; charset="us-ascii"
Hello,

The IPv6 header specifies the traffic class field. From RFC 2460 (IPv6 spec.) I understand that it basically is the ipv6 equivalent of the DS byte in the IPv4 header. Is there an RFC/a draft specifying the traffic class encoding for the different PHBs (similar to RFC 2597/RFC 2598 for AF and EF in the IPv4 world)?

Thanks for any clarification you can provide,

        Francis. --=_alternative 004B2AC6C1256B87_=-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 25 06:16:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PEGMKL004876 for ; Mon, 25 Mar 2002 06:16:22 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PEGMUt004874 for ipng-dist; Mon, 25 Mar 2002 06:16:22 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PEGFKL004867 for ; Mon, 25 Mar 2002 06:16:15 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14185; Mon, 25 Mar 2002 06:16:16 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA03355; Mon, 25 Mar 2002 07:16:15 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2PEEba13975; Mon, 25 Mar 2002 08:14:41 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 25 Mar 2002 08:14:49 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02C246E5@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Brian E Carpenter Cc: gab@Sun.COM, Keith Moore , Jari Arkko , Mohan Parthasarathy , Pekka Nikander , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Mon, 25 Mar 2002 08:14:43 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D407.68DE4020" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D407.68DE4020 Content-Type: text/plain; charset="iso-8859-1" Brian, I agree with your reasoning. I suspect proponents of the bidding down bit will start using the acceptable risk argument at this point. The bit I think should be reserved long term is already but the terminology describing it should probably be changed. > -----Original Message----- > From: Brian E Carpenter [mailto:brian@hursley.ibm.com] > Sent: Monday, March 25, 2002 4:00 AM > To: Morrow, Glenn [RICH2:C330:EXCH] > Cc: gab@Sun.COM; Keith Moore; Jari Arkko; Mohan Parthasarathy; Pekka > Nikander; Pekka Savola; ipng@sunroof.eng.sun.com; Erik Nordmark > Subject: Re: Allocating a bit in the RFC2374 Interface Identifier > > > > Glenn Morrow wrote: > > > > Right, > > > > So do people understand why having it in the address > provides more protection? > > No. Quoting Pekka Nikander's original description of the > bidding-down attack: > > Note that an active attacker at the path between Alice and > Bob is able > o clear a set bit. However, that changes the address, and Alice is > not going to answer to any possible replies sent by Bob. Thus, the > bit prevents the attacker from impersonating as Alice and fooling Bob > to use the less secure protocol. > > This doesn't satisfy me. If the attacker is capable of > clearing the bit > in the source address of packets from Alice to Bob, it is > equally capable > of setting the bit in the destination address of packets from > Bob to Alice. > (The proof of concept here is every NAT box sold so far.) > So I don't see why the attacker can't conduct a complete > bidding-down attack > in which Alice sees only packets with the bit set, and Bob > sees only packets > with the bit cleared. Alice will believe she has asserted > "strong security > available", Bob will believe the opposite, and both will be fooled. > > Brian > > > Now let's assume that we did not allow just RR, this would > avoid the bidding down attack IFF there was only one strong method. > > But I suspect there may be more than one strong method and > arguments as to which strong method is better will fourish and the > > bidding down attack may still be protrayed as being there > between the strong mechanisms. > > > > Again this putting the bit in the address for extra > protection may be in question over and over, IMHO. I.e. if a > field that > > indicates which strong method to use is in place above the > address then it can be alterred as well using the same logic for > > the bit being in the address now. > > > > > -----Original Message----- > > > From: gabriel montenegro [mailto:gab@Sun.COM] > > > Sent: Thursday, March 21, 2002 9:23 PM > > > To: Keith Moore > > > Cc: Jari Arkko; Mohan Parthasarathy; Pekka Nikander; Pekka Savola; > > > ipng@sunroof.eng.sun.com; Erik Nordmark > > > Subject: Re: Allocating a bit in the RFC2374 Interface Identifier > > > > > > > > > Keith Moore wrote: > > > > > > > > Note that the MitM can also change the IP address, > but if he does > > > > > so, he is *not* attacking the original host, as the address is > > > > > changed. > > > > > > > > unless of course the MitM can convince that host to take on > > > that address > > > > as an alias. > > > > > > So Mallory says that his address M is an alias for Alice's > > > address A. Ok. > > > What if Bob looking at A could know (yes, signalled by a > bit) that A > > > it is only aliasable by very secure mechanisms. That's the > > > whole point. > > > Mallory would then be forced to break any of several very strong > > > (using crypto and explicit trust relationships) mechanisms: > > > > > > - AAA > > > - PKI > > > - CGA > > > - etc > > > > > > RR would definitely not be included here. > > > > > > -gabriel > > > > ------_=_NextPart_001_01C1D407.68DE4020 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Allocating a bit in the RFC2374 Interface Identifier

Brian,

I agree with your reasoning. I suspect proponents of = the bidding down bit will start using the acceptable risk argument at = this point. The bit I think should be reserved long term is already but = the terminology describing it should probably be changed.

> -----Original Message-----
> From: Brian E Carpenter [mailto:brian@hursley.ibm.com]<= /FONT>
> Sent: Monday, March 25, 2002 4:00 AM
> To: Morrow, Glenn [RICH2:C330:EXCH]
> Cc: gab@Sun.COM; Keith Moore; Jari Arkko; Mohan = Parthasarathy; Pekka
> Nikander; Pekka Savola; = ipng@sunroof.eng.sun.com; Erik Nordmark
> Subject: Re: Allocating a bit in the RFC2374 = Interface Identifier
>
>
> > Glenn Morrow wrote:
> >
> > Right,
> >
> > So do people understand why having it in = the address
> provides more protection?
>
> No. Quoting Pekka Nikander's original = description of the
> bidding-down attack:
>
>  Note that an active attacker at the path = between Alice and
> Bob is able
>  o clear a set bit.  However, that = changes the address, and Alice is
>  not going to answer to any possible = replies sent by Bob.  Thus, the
>  bit prevents the attacker from = impersonating as Alice and fooling Bob
>  to use the less secure protocol.
>
> This doesn't satisfy me. If the attacker is = capable of
> clearing the bit
> in the source address of packets from Alice to = Bob, it is
> equally capable
> of setting the bit in the destination address = of packets from
> Bob to Alice.
> (The proof of concept here is every NAT box = sold so far.)
> So I don't see why the attacker can't conduct a = complete
> bidding-down attack
> in which Alice sees only packets with the bit = set, and Bob
> sees only packets
> with the bit cleared. Alice will believe she = has asserted
> "strong security
> available", Bob will believe the opposite, = and both will be fooled.
>
>    Brian
> 
> > Now let's assume that we did not allow = just RR, this would
> avoid the bidding down attack IFF there was = only one strong method.
> > But I suspect there may be more than one = strong method and
> arguments as to which strong method is better = will fourish and the
> > bidding down attack may still be protrayed = as being there
> between the strong mechanisms.
> >
> > Again this putting the bit in the address = for extra
> protection may be in question over and over, = IMHO. I.e. if a
> field that
> > indicates which strong method to use is in = place above the
> address then it can be alterred as well using = the same logic for
> > the bit being in the address now.
> >
> > > -----Original Message-----
> > > From: gabriel montenegro [mailto:gab@Sun.COM]
> > > Sent: Thursday, March 21, 2002 9:23 = PM
> > > To: Keith Moore
> > > Cc: Jari Arkko; Mohan Parthasarathy; = Pekka Nikander; Pekka Savola;
> > > ipng@sunroof.eng.sun.com; Erik = Nordmark
> > > Subject: Re: Allocating a bit in the = RFC2374 Interface Identifier
> > >
> > >
> > > Keith Moore wrote:
> > >
> > > > > Note that the MitM can also = change the IP address,
> but if he does
> > > > > so, he is *not* attacking = the original host, as the address is
> > > > > changed.
> > > >
> > > > unless of course the MitM can = convince that host to take on
> > > that address
> > > > as an alias.
> > >
> > > So Mallory says that his address M is = an alias for Alice's
> > > address A. Ok.
> > > What if Bob looking at A could know = (yes, signalled by a
> bit) that A
> > > it is only aliasable by very secure = mechanisms. That's the
> > > whole point.
> > > Mallory would then be forced to break = any of several very strong
> > > (using crypto and explicit trust = relationships) mechanisms:
> > >
> > >     - AAA
> > >     - PKI
> > >     - CGA
> > >     - etc
> > >
> > > RR would definitely not be included = here.
> > >
> > > -gabriel
> > >
>

------_=_NextPart_001_01C1D407.68DE4020-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 25 09:25:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PHP3KL005935 for ; Mon, 25 Mar 2002 09:25:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PHP30C005934 for ipng-dist; Mon, 25 Mar 2002 09:25:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PHP0KL005927 for ; Mon, 25 Mar 2002 09:25:00 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18639 for ; Mon, 25 Mar 2002 09:25:01 -0800 (PST) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA18955 for ; Mon, 25 Mar 2002 10:25:01 -0700 (MST) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Mon, 25 Mar 2002 09:25:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D421.FE1A6DDF" Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Mon, 25 Mar 2002 09:25:00 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF18B@TNEXVS02.tahoenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Allocating a bit in the RFC2374 Interface Identifier Thread-Index: AcHSlneP8D5wc4j7SxaDJcCDHL2cxgBinWpg From: "Mohan Parthasarathy" To: "Erik Nordmark" , "Pekka Nikander" Cc: "Rami Lehtonen" , X-OriginalArrivalTime: 25 Mar 2002 17:25:00.0869 (UTC) FILETIME=[FE4F1750:01C1D421] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1D421.FE1A6DDF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 >=20 > > Or am I missing something? >=20 > Pekka, >=20 > Perhaps the question was about the whole address and not just=20 > the interface ID. You've described how the interface ID is=20 > crypgraphically tied to a=20 > public key. > But this doesn't per-se prevent somebody fabricating a CGA=20 > address using an arbitrary prefix. >=20 This is the case where somebody owning a given (public key, private key pair) establishes a binding presumably, moves off to a different link and tries to use the same interface id. Can you describe the attack scenarios here ? If the attacker wishes to do reflection attacks,=20 some other node on the old link should have the same IID which is not very likely I guess. > The way to avoid this for MIPv6 is to do a return routability test=20 > when the CGA address is verified. The RR test would ensure that the=20 > peer is reachable at the prefix. (And the RR test would=20 > essentially be done as part of the challenge to have the peer=20 > sign the nonce using the private > key.) > Agreed. -mohan > Erik >=20 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- >=20 ------_=_NextPart_001_01C1D421.FE1A6DDF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Allocating a bit in the RFC2374 Interface Identifier

 
>
> > Or am I missing something?
>
> Pekka,
>
> Perhaps the question was about the whole address = and not just
> the interface ID. You've described how the = interface ID is
> crypgraphically tied to a
> public key.
> But this doesn't per-se prevent somebody = fabricating a CGA
> address using an arbitrary prefix.
>
This is the case where somebody owning a given = (public key, private key
pair) establishes a binding presumably, moves off to = a different link
and tries to use the same interface id. Can you = describe the attack
scenarios here ? If the attacker wishes to do = reflection attacks,
some other node on the old link should have the same = IID which is
not very likely I guess.


> The way to avoid this for MIPv6 is to do a return = routability test
> when the CGA address is verified. The RR test = would ensure that the
> peer is reachable at the prefix. (And the RR = test would
> essentially be done as part of the challenge to = have the peer
> sign the nonce using the private
> key.)
>
Agreed.

-mohan

>    Erik
>
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &n= bsp;          http://playground.sun.com/ipng
> FTP = archive:           = ;           ftp://playground.sun.com/pub/i= png
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>

------_=_NextPart_001_01C1D421.FE1A6DDF-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 25 10:13:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PID6KL006303 for ; Mon, 25 Mar 2002 10:13:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PID6h4006302 for ipng-dist; Mon, 25 Mar 2002 10:13:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PID5KL006295 for ; Mon, 25 Mar 2002 10:13:05 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2PIC3sl003677 for ; Mon, 25 Mar 2002 10:12:03 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g2PIC37u003676 for ipng@sunroof.eng.sun.com; Mon, 25 Mar 2002 10:12:03 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2OHJpKL003108 for ; Sun, 24 Mar 2002 09:19:51 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA29574 for ; Sun, 24 Mar 2002 09:19:53 -0800 (PST) Received: from byd.ocn.ad.jp (byd.ocn.ad.jp [203.139.162.147]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA24900 for ; Sun, 24 Mar 2002 10:19:52 -0700 (MST) Received: from r505r (byd.ocn.ad.jp [203.139.162.147]) by byd.ocn.ad.jp (8.8.8/3.6W) with SMTP id CAA14373; Mon, 25 Mar 2002 02:19:43 +0900 (JST) Message-ID: <020301c1d357$e0d4ea30$31b57e3d@local> From: "Yamasaki Toshi" To: "Pekka Savola" Cc: References: Subject: Re: Prefix delegation options Date: Mon, 25 Mar 2002 01:32:08 +0900 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 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Probably what I want to say is that it'd the best idea to have one "lite-weight" solution to solve major requirements, which is compatible for a "full-covered" solution to solve also minor requiremnts. To achieve this, there seems three solutions: 1) DNCP (DHCP-lite) as a "lite-weight", DHCP as a "full-covered" 2) APD as a "lite-weight", APD-heavy as a "full-covered" 3) RA+PDopt as a "lite-weight", RA+PDopt-heavy as a "full covered" Ralf is writing DNCP, and currently nobody seems writing APD-heavy nor RA+PDopt-heavy. > > No. PPPext solves the issue only when you use PPP. That means you need > > another solution when you don't use PPP, and that makes it difficult to > > achieve zero-configuration enviroment. > > Which is why I said 'PPP connections'. :-) OK, I see :-) > > I think APD is simple enough, and DNCP is also simple enough. Technically > > there is almost no difference between DNCP and APD. > > True, but APD has IMO unnecessary components of stateful nature, like > prefix return message. Now I see what you mean by "statefull" :-) I agree with you that you don't need "prefix return" like messages when you assume only dedicated(fixed) prefix and flat rate access services, and I guess that is often the case. But if you assume also non-dedicated(dynamic?) prefix and non-flat rate(per time?) access services, for exapmle, remote access or roaming services, your customers probably want "prefix return" like messages, for exapmle when they want to temporalily stop using IPv6 access to save mony but continue to use IPv4 access. # I don't like this kind of services personally :-), but we should avoid killing any posibility of new business models. > > It assumes only P-to-P enviroment. Again you need another solution for > > non-P-to-P enviroment. Our goal is to achieve auto-configuration, right? > > Then, how dose a CPE know whether it is conneted to P-to-P link or P-to-MP > > link automatically? > > Prefix Delegation need not be (IMO) completely automatic: it's completely > ok to have to add a 'request-prefix interface eth0', 'request-prefix > interface any', or whatever in the configuration of the CPE. I agree with you that Prefix Delegation doesn't have to be 100% automatic. But I still don't think that it is a better idea to define different mechanisms for P-to-P and non-P-to-P respectively, because, for example, it is difficlt for a CPE to know whether its eth0 is connceted to P-to-P ethernet or non-P-to-P ethernet. ---Toshi Yamasaki / NTT Communications -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 25 11:48:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PJmkKL007164 for ; Mon, 25 Mar 2002 11:48:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PJmk02007163 for ipng-dist; Mon, 25 Mar 2002 11:48:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PJmhKL007156 for ; Mon, 25 Mar 2002 11:48:43 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA24278 for ; Mon, 25 Mar 2002 11:48:43 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA29866 for ; Mon, 25 Mar 2002 12:48:42 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id D0EC764; Mon, 25 Mar 2002 21:50:28 +0200 (EET) Message-ID: <3C9F7F35.3060907@nomadiclab.com> Date: Mon, 25 Mar 2002 21:49:09 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian E Carpenter Cc: Glenn Morrow , gab@Sun.COM, Keith Moore , Jari Arkko , Mohan Parthasarathy , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: <933FADF5E673D411B8A30002A5608A0E02BD4C6D@zrc2c012.us.nortel.com> <3C9EF51B.969BEED0@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > No. Quoting Pekka Nikander's original description of the bidding-down attack: > > Note that an active attacker at the path between Alice and Bob is able > o clear a set bit. However, that changes the address, and Alice is > not going to answer to any possible replies sent by Bob. Thus, the > bit prevents the attacker from impersonating as Alice and fooling Bob > to use the less secure protocol. > > This doesn't satisfy me. If the attacker is capable of clearing the bit > in the source address of packets from Alice to Bob, it is equally capable > of setting the bit in the destination address of packets from Bob to Alice. > (The proof of concept here is every NAT box sold so far.) > So I don't see why the attacker can't conduct a complete bidding-down attack > in which Alice sees only packets with the bit set, and Bob sees only packets > with the bit cleared. Alice will believe she has asserted "strong security > available", Bob will believe the opposite, and both will be fooled. I am tired, and probably the situation is more complex, but this my initial reaction. It looks like in the scenario you describe Alice and Bob would end up running different protocols: Alice the strong one, which the attacker presumedly cannot break, and Bob the not-so-strong one, which the attacker presumedly can break. Thus, Bob would end up running the not-so-strong protocol with the attacker, but the address used would not be Alice's address. But I start to believe that I am missing here things, and that the reality is more complex than what we thought at the MIPv6 DT. That is, at least we need a mechanism for Alice to securely learn about the mechanisms Bob supports. Maybe we could use "the bit" here, too, but my brains just fail to analyze what happens to the address-spoofing MitM in that case; maybe you could perform the attack in both directions? But would that matter? If there is an attacker that can spoof packets and break the less secure protocol, it can create security associations with the less-secure protocol anyway, be there the legitimite peer or not. Erik, Jari, or Gab, I guess it's your turn :-) --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 25 12:11:10 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PKB9KL007247 for ; Mon, 25 Mar 2002 12:11:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PKB9iI007246 for ipng-dist; Mon, 25 Mar 2002 12:11:09 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PKB6KL007239 for ; Mon, 25 Mar 2002 12:11:06 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06414 for ; Mon, 25 Mar 2002 12:11:07 -0800 (PST) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA06662 for ; Mon, 25 Mar 2002 12:10:55 -0800 (PST) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B618B6A901; Mon, 25 Mar 2002 22:10:58 +0200 (EET) Message-ID: <3C9F84B1.6000103@kolumbus.fi> Date: Mon, 25 Mar 2002 22:12:33 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.5) Gecko/20011014 X-Accept-Language: en-us MIME-Version: 1.0 To: Pekka Savola Cc: Erik Nordmark , Mohan Parthasarathy , "Hesham Soliman (ERA)" , Pekka Nikander , ipng@sunroof.eng.sun.com Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: >>> 3. require manual configuration. > > Actually, in some cases (e.g. some ND messages, to prevent spoofing), > this wouldn't be all that big an issue :-) Complete manual configuration in terms of who is expected to use what level of security is probably out of question; I can't expect to inform www.cnn.com about my preferences in any manner. However, it may be possible to think about a single 'flag' that each node has and which determines who strong security it can handle. But this seems to get us into one of two undesirable positions: First, we could allow e.g. www.cnn.com to accept different levels, but this defeats the purpose of stronger security since the weaker method could still be used by someone to trick cnn into diverting your traffic somewhere else. Second, we could be strict about the levels and only talk to nodes that use stronger security. But this would restrict us to a small set of nodes, RO or no RO. Assuming better than RR security becomes necessary at some point, it's deployment would be extremely hard (more on this in draft-aura-mipv6-bu-attacks, section 6.2). Do you Pekka agree, or did you have some other form of manual configuration in mind? Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 25 12:20:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PKKlKL007269 for ; Mon, 25 Mar 2002 12:20:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2PKKlF7007268 for ipng-dist; Mon, 25 Mar 2002 12:20:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2PKKiKL007261 for ; Mon, 25 Mar 2002 12:20:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA08110 for ; Mon, 25 Mar 2002 12:20:45 -0800 (PST) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA16751 for ; Mon, 25 Mar 2002 13:20:44 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g2PKK9m25702; Mon, 25 Mar 2002 22:20:10 +0200 Date: Mon, 25 Mar 2002 22:20:09 +0200 (EET) From: Pekka Savola To: Jari Arkko cc: Erik Nordmark , Mohan Parthasarathy , "Hesham Soliman (ERA)" , Pekka Nikander , Subject: Re: Allocating a bit in the RFC2374 Interface Identifier In-Reply-To: <3C9F84B1.6000103@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 25 Mar 2002, Jari Arkko wrote: > First, we could allow e.g. www.cnn.com to accept different > levels, but this defeats the purpose of stronger security > since the weaker method could still be used by someone > to trick cnn into diverting your traffic somewhere else. As long as backward compatibility is a requirement, I'm not sure this can be worked around anyway. > Second, we could be strict about the levels and only talk to > nodes that use stronger security. But this would restrict us > to a small set of nodes, RO or no RO. Assuming better than RR > security becomes necessary at some point, it's deployment would > be extremely hard (more on this in draft-aura-mipv6-bu-attacks, > section 6.2). > > Do you Pekka agree, or did you have some other form of manual > configuration in mind? Basically I was thinking only about securing some ND link-local messages, not on a global where some other mechanisms, e.g. IPSEC, might apply as well. Another alternative is use new network prefixes for secured sites (e.g. 2801::/16). This strikes me to as an unscalable mechanism, though. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 09:55:31 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2QHtUKL010696 for ; Tue, 26 Mar 2002 09:55:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2QHtU3c010695 for ipng-dist; Tue, 26 Mar 2002 09:55:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2QHtTKL010688 for ; Tue, 26 Mar 2002 09:55:29 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2QHsQsl004110 for ; Tue, 26 Mar 2002 09:54:27 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g2QHsQFA004109 for ipng@sunroof.eng.sun.com; Tue, 26 Mar 2002 09:54:26 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2QDAWKL010303 for ; Tue, 26 Mar 2002 05:10:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA18767 for ; Tue, 26 Mar 2002 05:10:33 -0800 (PST) Received: from mel.alcatel.fr (mel-u.alcatel.fr [212.208.74.132]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA10411 for ; Tue, 26 Mar 2002 06:10:31 -0700 (MST) Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET) with ESMTP id g2QDAPu6001610 for ; Tue, 26 Mar 2002 14:10:25 +0100 Received: from nmu.alcatel.fr (tcmh80.nmu.alcatel.fr [139.54.143.3]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id OAA04331; Tue, 26 Mar 2002 14:10:21 +0100 (MET) Received: from nmu.alcatel.fr (houat [192.200.245.153]) by nmu.alcatel.fr (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id OAA05144; Tue, 26 Mar 2002 14:09:34 +0100 (MET) Message-ID: <3CA07282.14679BE7@nmu.alcatel.fr> Date: Tue, 26 Mar 2002 14:07:14 +0100 From: christophe preguica X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Hop Limit = 0 Content-Type: multipart/mixed; boundary="------------EFC8B244244FB542DC4BC101" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. --------------EFC8B244244FB542DC4BC101 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit What should be the behavior of a router when it receives an IPv6 packet with Hop Limit = 0 ? Does IPv6 have the same behavior as for IPv4 TTL ? Following are some extracts of RFCs. ---------------------------------- (Extract from RFC 1812 -- requirements for ipv4 routers) 4.2.2.9 Time to Live: RFC 791 Section 3.2 Note in particular that a router MUST NOT check the TTL of a packet except when forwarding it. A router MUST NOT originate or forward a datagram with a Time-to-Live (TTL) value of zero. A router MUST NOT discard a datagram just because it was received with TTL equal to zero or one; if it is to the router and otherwise valid, the router MUST attempt to receive it. -------------------------------------------- (Extract from RFC 2463 -- ICMPv6) 3.3 Time Exceeded Message If a router receives a packet with a Hop Limit of zero, or a router decrements a packet's Hop Limit to zero, it MUST discard the packet and send an ICMPv6 Time Exceeded message with Code 0 to the source of the packet. This indicates either a routing loop or too small an initial Hop Limit value. -------------------------- Kind regards, Christophe. --------------EFC8B244244FB542DC4BC101 Content-Type: text/x-vcard; charset=us-ascii; name="christophe.preguica.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for christophe preguica Content-Disposition: attachment; filename="christophe.preguica.vcf" begin:vcard n:; x-mozilla-html:FALSE org:Alcatel;Enabling Software version:2.1 email;internet:christophe.preguica@alcatel.fr title:Christophe Preguiça adr;quoted-printable:;;Route de Nozay=0D=0A91460 Marcoussis;;;;France end:vcard --------------EFC8B244244FB542DC4BC101-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 10:04:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2QI4LKL010778 for ; Tue, 26 Mar 2002 10:04:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2QI4LAd010777 for ipng-dist; Tue, 26 Mar 2002 10:04:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2QI4IKL010770 for ; Tue, 26 Mar 2002 10:04:18 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA25415 for ; Tue, 26 Mar 2002 10:04:20 -0800 (PST) From: francis.arts@alcatel.be Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA03278 for ; Tue, 26 Mar 2002 11:04:19 -0700 (MST) Received: from Bemail06.net.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id g2QI4Hk24492; Tue, 26 Mar 2002 19:04:17 +0100 (MET) To: christophe preguica Cc: ipng@sunroof.eng.sun.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: Date: Tue, 26 Mar 2002 19:04:15 +0100 Subject: Re: Hop Limit = 0 X-MIMETrack: Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 03/26/2002 19:04:17 Content-Type: multipart/mixed; boundary="=_mixed 006340CAC1256B88_=" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=_mixed 006340CAC1256B88_= Content-Type: multipart/alternative; boundary="=_alternative 006340CBC1256B88_=" --=_alternative 006340CBC1256B88_= Content-Type: text/plain; charset="us-ascii" Christophe, Shouldn't launch this question on the ipv6 mailing list (rather than the ipng mailing list) since our question is ipv6 specific, non? Kind regards, Francis. ================= christophe preguica 26/03/2002 14:07 To: ipng@sunroof.eng.sun.com cc: (bcc: Francis ARTS/BE/ALCATEL) Subject: Hop Limit = 0 What should be the behavior of a router when it receives an IPv6 packet with Hop Limit = 0 ? Does IPv6 have the same behavior as for IPv4 TTL ? Following are some extracts of RFCs. ---------------------------------- (Extract from RFC 1812 -- requirements for ipv4 routers) 4.2.2.9 Time to Live: RFC 791 Section 3.2 Note in particular that a router MUST NOT check the TTL of a packet except when forwarding it. A router MUST NOT originate or forward a datagram with a Time-to-Live (TTL) value of zero. A router MUST NOT discard a datagram just because it was received with TTL equal to zero or one; if it is to the router and otherwise valid, the router MUST attempt to receive it. -------------------------------------------- (Extract from RFC 2463 -- ICMPv6) 3.3 Time Exceeded Message If a router receives a packet with a Hop Limit of zero, or a router decrements a packet's Hop Limit to zero, it MUST discard the packet and send an ICMPv6 Time Exceeded message with Code 0 to the source of the packet. This indicates either a routing loop or too small an initial Hop Limit value. -------------------------- Kind regards, Christophe. --=_alternative 006340CBC1256B88_= Content-Type: text/html; charset="us-ascii"
Christophe,

Shouldn't launch this question on the ipv6 mailing list (rather than the ipng mailing list) since our question is ipv6 specific, non?

Kind regards,

        Francis.

=================



christophe preguica <Christophe.Preguica@alcatel.fr>

26/03/2002 14:07

       
        To:        ipng@sunroof.eng.sun.com
        cc:        (bcc: Francis ARTS/BE/ALCATEL)
        Subject:        Hop Limit = 0



What should be the behavior of a router when it receives an IPv6 packet
with Hop Limit = 0 ? Does IPv6 have the same behavior as for IPv4 TTL ?

Following are some extracts of RFCs.

----------------------------------
(Extract from RFC 1812 -- requirements for ipv4 routers)

4.2.2.9 Time to Live: RFC 791 Section 3.2

  Note in particular that a router MUST NOT check the TTL of a packet
  except when forwarding it.

  A router MUST NOT originate or forward a datagram with a Time-to-Live

  (TTL) value of zero.

  A router MUST NOT discard a datagram just because it was received
  with TTL equal to zero or one; if it is to the router and otherwise
  valid, the router MUST attempt to receive it.

--------------------------------------------
(Extract from RFC 2463 -- ICMPv6)

3.3 Time Exceeded Message

If a router receives a packet with a Hop Limit of zero, or a router
 decrements a packet's Hop Limit to zero, it MUST discard the packet
 and send an ICMPv6 Time Exceeded message with Code 0 to the source of

 the packet.  This indicates either a routing loop or too small an
 initial Hop Limit value.
--------------------------

Kind regards,

Christophe.

--=_alternative 006340CBC1256B88_=-- --=_mixed 006340CAC1256B88_= Content-Type: application/octet-stream; name="christophe.preguica.vcf" Content-Disposition: attachment; filename="christophe.preguica.vcf" Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOjsNCngtbW96aWxsYS1odG1sOkZBTFNFDQpvcmc6QWxjYXRlbDtFbmFi bGluZyBTb2Z0d2FyZQ0KdmVyc2lvbjoyLjENCmVtYWlsO2ludGVybmV0OmNocmlzdG9waGUucHJl Z3VpY2FAYWxjYXRlbC5mcg0KdGl0bGU6Q2hyaXN0b3BoZSBQcmVndWnnYQ0KYWRyO3F1b3RlZC1w cmludGFibGU6OztSb3V0ZSBkZSBOb3pheT0wRD0wQTkxNDYwIE1hcmNvdXNzaXM7Ozs7RnJhbmNl DQplbmQ6dmNhcmQNCg== --=_mixed 006340CAC1256B88_=-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 10:25:51 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2QIPpKL010816 for ; Tue, 26 Mar 2002 10:25:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2QIPoBG010815 for ipng-dist; Tue, 26 Mar 2002 10:25:50 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2QIPlKL010808 for ; Tue, 26 Mar 2002 10:25:47 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28607 for ; Tue, 26 Mar 2002 10:25:47 -0800 (PST) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA03995 for ; Tue, 26 Mar 2002 11:25:38 -0700 (MST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 60A832860; Tue, 26 Mar 2002 10:25:09 -0800 (PST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id E9232202B; Tue, 26 Mar 2002 12:25:21 -0600 (CST) Received: from yquarry.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g2QIPFR19734; Tue, 26 Mar 2002 13:25:20 -0500 (EST) Received: from compaq.com by yquarry.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g2QIPFb21638; Tue, 26 Mar 2002 13:25:15 -0500 (EST) Message-ID: <3CA0BCDE.3070609@compaq.com> Date: Tue, 26 Mar 2002 13:24:30 -0500 From: Vladislav Yasevich User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: christophe preguica Cc: ipng@sunroof.eng.sun.com Subject: Re: Hop Limit = 0 References: <3CA07282.14679BE7@nmu.alcatel.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk See RFC 2460, Section 3, description of HopLimit. -vlad christophe preguica wrote: > What should be the behavior of a router when it receives an IPv6 packet > with Hop Limit = 0 ? Does IPv6 have the same behavior as for IPv4 TTL ? > > Following are some extracts of RFCs. > > ---------------------------------- > (Extract from RFC 1812 -- requirements for ipv4 routers) > > 4.2.2.9 Time to Live: RFC 791 Section 3.2 > > Note in particular that a router MUST NOT check the TTL of a packet > except when forwarding it. > > A router MUST NOT originate or forward a datagram with a Time-to-Live > > (TTL) value of zero. > > A router MUST NOT discard a datagram just because it was received > with TTL equal to zero or one; if it is to the router and otherwise > valid, the router MUST attempt to receive it. > > -------------------------------------------- > (Extract from RFC 2463 -- ICMPv6) > > 3.3 Time Exceeded Message > > If a router receives a packet with a Hop Limit of zero, or a router > decrements a packet's Hop Limit to zero, it MUST discard the packet > and send an ICMPv6 Time Exceeded message with Code 0 to the source of > > the packet. This indicates either a routing loop or too small an > initial Hop Limit value. > -------------------------- > > Kind regards, > > Christophe. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 10:29:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2QITOKL010930 for ; Tue, 26 Mar 2002 10:29:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2QITOF2010929 for ipng-dist; Tue, 26 Mar 2002 10:29:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2QITLKL010922 for ; Tue, 26 Mar 2002 10:29:21 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAB04251 for ; Tue, 26 Mar 2002 10:29:18 -0800 (PST) Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA02668 for ; Tue, 26 Mar 2002 10:29:05 -0800 (PST) Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 26 Mar 2002 10:29:17 -0800 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 26 Mar 2002 10:29:16 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 26 Mar 2002 10:28:56 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 26 Mar 2002 10:28:57 -0800 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Tue, 26 Mar 2002 10:25:43 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Hop Limit = 0 Date: Tue, 26 Mar 2002 10:25:42 -0800 Message-ID: <2E33960095B58E40A4D3345AB9F65EC102DB803D@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Hop Limit = 0 Thread-Index: AcHU8KZD4Y2+m/HaQ9ySlEenLFxV/gAAlK3w From: "Dave Thaler" To: , "christophe preguica" Cc: X-OriginalArrivalTime: 26 Mar 2002 18:25:43.0436 (UTC) FILETIME=[A3DC74C0:01C1D4F3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2QITLKL010923 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk christophe preguica wrote: > What should be the behavior of a router when it receives an IPv6 packet > with Hop Limit = 0 ? If it's destined to the router itself, accept it. Otherwise, drop it, and send the ICMPv6 error if the packet wasn't multicast. > Does IPv6 have the same behavior as for IPv4 TTL ? Yes it should be the same. > (Extract from RFC 2463 -- ICMPv6) > > 3.3 Time Exceeded Message > > If a router receives a packet with a Hop Limit of zero, I think the above phrase is incorrect, since it contradicts 2460 as you pointed out. > or a router > decrements a packet's Hop Limit to zero, it MUST discard the packet > and send an ICMPv6 Time Exceeded message with Code 0 to the source of > the packet.  This indicates either a routing loop or too small an > initial Hop Limit value. -Dave -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Mar 26 23:23:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2R7N8KL012846 for ; Tue, 26 Mar 2002 23:23:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2R7N8vs012845 for ipng-dist; Tue, 26 Mar 2002 23:23:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2R7N4KL012835 for ; Tue, 26 Mar 2002 23:23:04 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12501; Tue, 26 Mar 2002 23:23:05 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA01170; Tue, 26 Mar 2002 23:22:51 -0800 (PST) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA11772; Wed, 27 Mar 2002 08:22:52 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay01.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2R7MoG96916; Wed, 27 Mar 2002 08:22:50 +0100 Received: from dhcp22-167.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA40924 from ; Wed, 27 Mar 2002 08:22:40 +0100 Message-Id: <3CA0B85B.AC0D728A@hursley.ibm.com> Date: Tue, 26 Mar 2002 19:05:15 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Pekka Nikander Cc: Glenn Morrow , gab@Sun.COM, Keith Moore , Jari Arkko , Mohan Parthasarathy , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Allocating a bit in the RFC2374 Interface Identifier References: <933FADF5E673D411B8A30002A5608A0E02BD4C6D@zrc2c012.us.nortel.com> <3C9EF51B.969BEED0@hursley.ibm.com> <3C9F7F35.3060907@nomadiclab.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Nikander wrote: > > Brian, > > > No. Quoting Pekka Nikander's original description of the bidding-down attack: > > > > Note that an active attacker at the path between Alice and Bob is able > > o clear a set bit. However, that changes the address, and Alice is > > not going to answer to any possible replies sent by Bob. Thus, the > > bit prevents the attacker from impersonating as Alice and fooling Bob > > to use the less secure protocol. > > > > This doesn't satisfy me. If the attacker is capable of clearing the bit > > in the source address of packets from Alice to Bob, it is equally capable > > of setting the bit in the destination address of packets from Bob to Alice. > > (The proof of concept here is every NAT box sold so far.) > > So I don't see why the attacker can't conduct a complete bidding-down attack > > in which Alice sees only packets with the bit set, and Bob sees only packets > > with the bit cleared. Alice will believe she has asserted "strong security > > available", Bob will believe the opposite, and both will be fooled. > > I am tired, and probably the situation is more complex, but this my initial > reaction. It looks like in the scenario you describe Alice and Bob > would end up running different protocols: Alice the strong one, which > the attacker presumedly cannot break, and Bob the not-so-strong one, > which the attacker presumedly can break. Thus, Bob would end up running > the not-so-strong protocol with the attacker, but the address used would > not be Alice's address. > It depends on how smart the MITM is, but I think in the simplest case, Alice will hear from pseudo-Bob "I can't support strong security" (this will be fabricated by the MITM) so she will be bid down, but Bob never knows about this because he falsely believes that Alice can't support strong security. But I'm also tired; jet lag hasn't completely gone yet :-) > But I start to believe that I am missing here things, and that the > reality is more complex than what we thought at the MIPv6 DT. That is, > at least we need a mechanism for Alice to securely learn about the > mechanisms Bob supports. Maybe we could use "the bit" here, too, but > my brains just fail to analyze what happens to the address-spoofing > MitM in that case; maybe you could perform the attack in both directions? Exactly > But would that matter? If there is an attacker that can spoof packets > and break the less secure protocol, it can create security associations > with the less-secure protocol anyway, be there the legitimite peer or not. Yes. There's a recursion here, and also a moral I think: don't allow weak security, period. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 26 23:23:07 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2R7N6KL012843 for ; Tue, 26 Mar 2002 23:23:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2R7N63M012842 for ipng-dist; Tue, 26 Mar 2002 23:23:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2R7N2KL012828 for ; Tue, 26 Mar 2002 23:23:02 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA18308 for ; Tue, 26 Mar 2002 23:23:04 -0800 (PST) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [195.212.91.199]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA27784 for ; Wed, 27 Mar 2002 00:23:03 -0700 (MST) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (1.0.0) with ESMTP id IAA153404; Wed, 27 Mar 2002 08:22:53 +0100 Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by d12relay02.de.ibm.com (8.11.1m3/NCO/VER6.00) with SMTP id g2R7Mpq38924; Wed, 27 Mar 2002 08:22:51 +0100 Received: from dhcp22-167.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA17820 from ; Wed, 27 Mar 2002 08:22:49 +0100 Message-Id: <3CA0B933.4D778850@hursley.ibm.com> Date: Tue, 26 Mar 2002 19:08:51 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: francis.arts@alcatel.be Cc: ipng@sunroof.eng.sun.com Subject: Re: Traffic class References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Please read RFC 2474 again. There is no difference between IPv4 and IPv6 as far as diffserv is concerned. Brian francis.arts@alcatel.be wrote: > > Hello, > > The IPv6 header specifies the traffic class field. From RFC 2460 (IPv6 spec.) I understand that it basically is the ipv6 > equivalent of the DS byte in the IPv4 header. Is there an RFC/a draft specifying the traffic class encoding for the different > PHBs (similar to RFC 2597/RFC 2598 for AF and EF in the IPv4 world)? > > Thanks for any clarification you can provide, > > Francis. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 09:09:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2RH9rKL013811 for ; Wed, 27 Mar 2002 09:09:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RH9rrN013810 for ipng-dist; Wed, 27 Mar 2002 09:09:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2RH9oKL013803 for ; Wed, 27 Mar 2002 09:09:50 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA16887 for ; Wed, 27 Mar 2002 09:09:52 -0800 (PST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14989 for ; Wed, 27 Mar 2002 10:09:52 -0700 (MST) Received: from xparelay1.corp.hp.com (xparelay1.corp.hp.com [15.58.136.173]) by palrel10.hp.com (Postfix) with ESMTP id C4E4AC009AA for ; Wed, 27 Mar 2002 09:09:51 -0800 (PST) Received: from xpabh1.corp.hp.com (xpabh1.corp.hp.com [15.58.136.191]) by xparelay1.corp.hp.com (Postfix) with ESMTP id BC00FE000A6 for ; Wed, 27 Mar 2002 09:09:51 -0800 (PST) Received: by xpabh1.corp.hp.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 09:09:51 -0800 Message-ID: From: "MANDAVILLI,SWAMY J (HP-FtCollins,ex1)" To: ipng@sunroof.eng.sun.com Subject: SNMP for transport over IPv6 Date: Wed, 27 Mar 2002 09:09:49 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! For SNMP Transported over IPv6, is it a simple matter of modifying and compiling the Agents and Managers for v6 OR is there a standard for SNMP v6/ng? Is there a need to define "var-binds" for v6 addresses? Does it require versioning of SNMP for v6/ng? If so, is there standard and/or a working-group for this? Thanks in advance. Regards, Swamy -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 12:11:37 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2RKBbKL014957 for ; Wed, 27 Mar 2002 12:11:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RKBaQV014956 for ipng-dist; Wed, 27 Mar 2002 12:11:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2RKBXKL014949 for ; Wed, 27 Mar 2002 12:11:33 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18215 for ; Wed, 27 Mar 2002 12:11:35 -0800 (PST) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA28515 for ; Wed, 27 Mar 2002 13:11:34 -0700 (MST) Received: from kenawang ([147.11.233.25]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA19817; Wed, 27 Mar 2002 12:11:01 -0800 (PST) Message-Id: <4.2.2.20020327150143.01f1d640@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 27 Mar 2002 15:12:37 -0500 To: "MANDAVILLI,SWAMY J (HP-FtCollins,ex1)" From: Margaret Wasserman Subject: Re: SNMP for transport over IPv6 Cc: ipng@sunroof.eng.sun.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Swamy, There are a few different issues involved in getting an existing UDP/IPv4 SNMP agent to run over IPv6. First, you need to make changes to the part of the agent that sends/receives packets to allow it receive requests and send responses over IPv6. If you want to support SNMPv3 security over an IPv6 transport, you also need to make some changes to your TAddress/TDomain definitions. There is an Internet-Draft available that describes one set of possible changes, and we are working to get that draft (or a modified version of that draft) accepted by the IETF. This work is happening in the OPS area, outside of any WG. It is also likely that you will want to support some IPv6 MIBs for your TCP/IP stack, at least. Those MIBs are under development in the IPv6 WG. They are very similar to the IPv4 versions, except that they include address types that are capable of holding an IPv6 address. Margaret At 12:09 PM 3/27/02 , MANDAVILLI,SWAMY J (HP-FtCollins,ex1) wrote: >Hi! > > For SNMP Transported over IPv6, is it > a simple matter of modifying and compiling > the Agents and Managers for v6 OR is there > a standard for SNMP v6/ng? > > Is there a need to define "var-binds" for > v6 addresses? Does it require versioning > of SNMP for v6/ng? > > If so, is there standard and/or a working-group > for this? > > Thanks in advance. > >Regards, >Swamy >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Mar 27 13:35:35 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2RLZZKL015347 for ; Wed, 27 Mar 2002 13:35:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2RLZYNm015346 for ipng-dist; Wed, 27 Mar 2002 13:35:34 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2RLZUKL015339 for ; Wed, 27 Mar 2002 13:35:30 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA15062 for ; Wed, 27 Mar 2002 13:35:33 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA01911 for ; Wed, 27 Mar 2002 14:35:33 -0700 (MST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25114; Wed, 27 Mar 2002 16:34:10 -0500 (EST) Message-Id: <200203272134.QAA25114@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: ipng@sunroof.eng.sun.com From: The IESG Subject: Protocol Action: Unicast-Prefix-based IPv6 Multicast Addresses to Proposed Standard Date: Wed, 27 Mar 2002 16:34:10 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IESG has approved the Internet-Draft 'Unicast-Prefix-based IPv6 Multicast Addresses' as a Proposed Standard. This document is the product of the IPNG Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. The IESG also approved Dynamic Allocation Guidelines for IPv6 Multicast Addresses as a Proposed Standard This document is the product of the Multicast-Address Allocation Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary These two specifications are related to each other, though they were developed in different working groups and Areas. One describes a new standard format for the prefix of IPv6 multicast addresses, while the other describes a new standard allocation mechanism and format for the group identifier, the rightmost portion of IPv6 multicast addresses. The unicast prefix-based IPv6 multicast address specification defines an extension to the multicast addressing architecture of IPv6. The extension describes how to embed unicast prefixes within the multicast address format to create multicast prefixes. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. The dynamic allocation guidelines for IPv6 multicast addresses describe the format of the group identifier, the lowest 32 bits of the address. The purpose is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into their MAC layer address. The group identifier format defined in the specification is required for all IPv6 multicast addresses: spaces for IPv6 permanent multicast addresses and IPv6 permanent group identifiers are defined in IANA considerations, as well as the space and format for group identifiers created by allocation services and zeroconf devices. Working Group Summary The two working groups that developed these related specifications supported their advancement. Protocol Quality The specifications were reviewed by the IESG by Allison Mankin and Thomas Narten. The authors reported functioning implementations of these specifications. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 27 23:53:02 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7r2KL016808 for ; Wed, 27 Mar 2002 23:53:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2S7r1uV016807 for ipng-dist; Wed, 27 Mar 2002 23:53:01 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7qwKL016800 for ; Wed, 27 Mar 2002 23:52:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12685 for ; Wed, 27 Mar 2002 23:52:55 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA09965 for ; Thu, 28 Mar 2002 00:52:49 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2S7qmoq012555 for ; Thu, 28 Mar 2002 08:52:49 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 28 08:52:47 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 08:52:47 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053803C0747E@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: Brian E Carpenter , Pekka Nikander Cc: Glenn Morrow , gab@Sun.COM, Keith Moore , Jari Arkko , Mohan Parthasarathy , Pekka Savola , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Thu, 28 Mar 2002 08:52:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian and Pekka, > > I am tired, and probably the situation is more complex, > but this my initial > > reaction. It looks like in the scenario you describe > Alice and Bob > > would end up running different protocols: Alice the > strong one, which > > the attacker presumedly cannot break, and Bob the > not-so-strong one, > > which the attacker presumedly can break. Thus, Bob would > end up running > > the not-so-strong protocol with the attacker, but the > address used would > > not be Alice's address. > > > It depends on how smart the MITM is, but I think in the > simplest case, > Alice will hear from pseudo-Bob "I can't support strong > security" (this > will be fabricated by the MITM) so she will be bid down, > but Bob never knows > about this because he falsely believes that Alice can't > support strong security. => I have to add myself to the list of tired/jetlagged people :). But, in the scenario you mention, it seems to me that Alice will not end up talking to Bob and Bob will not end up talking to Alice. And both will not end up talking to the MITM anyway. In fact, If the MITM modified the first message in the, lets call it SA establishment, then this SA establishment will fail. If it was the last message that was modified then it will also fail because the message will be inconsistent with the intial ones. So it seems to me like a classic DoS attack. Nothing we can do here. What am I missing? > > But I start to believe that I am missing here things, and that the > > reality is more complex than what we thought at the MIPv6 > DT. That is, > > at least we need a mechanism for Alice to securely learn about the > > mechanisms Bob supports. Maybe we could use "the bit" > here, too, but > > my brains just fail to analyze what happens to the > address-spoofing > > MitM in that case; maybe you could perform the attack in > both directions? > > Exactly => But then we end up with Alice talking to Sam and Bob talking to Homer! So what ? > > But would that matter? If there is an attacker that can > spoof packets > > and break the less secure protocol, it can create > security associations > > with the less-secure protocol anyway, be there the > legitimite peer or not. > > Yes. There's a recursion here, and also a moral I think: > don't allow weak > security, period. => I used to wonder about the strength of RR only for MIPv6. But after a long thread with Erik, I am convinced that it is as strong as the weakest link. I.e. ND. So I agree with Erik's statement during the presentation in Minneapolis, which said that securing ND will make RR seem less secure. Hence the need for allowing this stronger mechanism in future. I.e. put the bit in the iid. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From ipng-dist@sunroof.eng.sun.com Wed Mar 27 23:56:11 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

From MAILER-DAEMON Wed Mar 27 23:57:09 2002 Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7v9KL016876 for ; Wed, 27 Mar 2002 23:57:09 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13258 for ; Wed, 27 Mar 2002 23:57:10 -0800 (PST) Received: from mx1.andrew.cmu.edu (MX1.ANDREW.CMU.EDU [128.2.10.111]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29538 for ; Thu, 28 Mar 2002 00:57:10 -0700 (MST) Received: from localhost (localhost) by mx1.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) id g2S7v9l7028539; Thu, 28 Mar 2002 02:57:09 -0500 Date: Thu, 28 Mar 2002 02:57:09 -0500 From: Mail Delivery Subsystem Message-Id: <200203280757.g2S7v9l7028539@mx1.andrew.cmu.edu> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="g2S7v9l7028539.1017302229/mx1.andrew.cmu.edu" Content-Transfer-Encoding: 8bit Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --g2S7v9l7028539.1017302229/mx1.andrew.cmu.edu The original message was received at Thu, 28 Mar 2002 02:57:07 -0500 from patan.Sun.COM [192.18.98.43] ----- The following addresses had permanent fatal errors ----- (reason: 554 5.6.0 Message contains non-ASCII characters in headers) ----- Transcript of session follows ----- ... while talking to mail1.andrew.cmu.edu.: >>> DATA <<< 554 5.6.0 Message contains non-ASCII characters in headers 554 5.0.0 Service unavailable (Message contains non-ASCII characters in headers) --g2S7v9l7028539.1017302229/mx1.andrew.cmu.edu Content-Type: message/delivery-status Reporting-MTA: dns; mx1.andrew.cmu.edu Received-From-MTA: DNS; patan.Sun.COM Arrival-Date: Thu, 28 Mar 2002 02:57:07 -0500 Final-Recipient: RFC822; arpalists+computing.ipng@andrew.cmu.edu X-Actual-Recipient: RFC822; bb+internet.computing.ipng@mx1.andrew.cmu.edu Action: failed Status: 5.6.0 Diagnostic-Code: X-Unix; 554 5.6.0 Message contains non-ASCII characters in headers Last-Attempt-Date: Thu, 28 Mar 2002 02:57:09 -0500 --g2S7v9l7028539.1017302229/mx1.andrew.cmu.edu Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mx1.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id g2S7v6l7028535 for ; Thu, 28 Mar 2002 02:57:07 -0500 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29366; Thu, 28 Mar 2002 00:56:42 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12915; Wed, 27 Mar 2002 23:56:37 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 X-Spam-Warning: SpamAssassin says this message is SPAM Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--g2S7v9l7028539.1017302229/mx1.andrew.cmu.edu-- From MAILER-DAEMON Wed Mar 27 23:57:15 2002 Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7vFKL016878 for ; Wed, 27 Mar 2002 23:57:15 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13027 for ; Wed, 27 Mar 2002 23:57:16 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA11293 for ; Thu, 28 Mar 2002 00:57:15 -0700 (MST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Thu, 28 Mar 2002 08:57:08 +0100 Message-ID: <227AB9CBF164D111B2CA00805F19DA3007014F2B@p-voyageur.rd.francetelecom.fr> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: Undeliverable: ( 1$0m ) @|1b?B59FG3Z ?B From: "@LEBH#" To: ipng-dist4T Subject: ( 1$0m ) @|1b?B59FG3Z ?B; Wed, 27 Mar 2002 23:57:19 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13266 for ; Wed, 27 Mar 2002 23:57:21 -0800 (PST) Received: from smtpgw6.sprintspectrum.com (smtpgw6.sprintspectrum.com [207.40.188.14]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23705 for ; Thu, 28 Mar 2002 00:57:20 -0700 (MST) Received: from pkcex004.sprintspectrum.com (pkcex004.sprintspectrum.com [208.10.75.139]) by smtpgw6.sprintspectrum.com (8.11.2/8.11.3) with ESMTP id g2S7vK515005 for ; Thu, 28 Mar 2002 01:57:20 -0600 (CST) Received: by pkcex004.sprintspectrum.com with Internet Mail Service (5.5.2654.89) id ; Thu, 28 Mar 2002 01:57:20 -0600 Message-ID: From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 01:57:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62E.2FB595E6" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62E.2FB595E6 Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 01:56:02 -0600 did not reach the following recipient(s): BWIGIN01@SPRINTSPECTRUM.COM on Thu, 28 Mar 2002 01:57:18 -0600 The recipient name is not recognized The MTS-ID of the original message is: c=3Dus;a=3D ;p=3Dsprintpcs;l=3DPKCEX0030203280757HWS58VLA MSEXCH:IMS:SprintPCS:USKMEX01:PKCEX003 0 (000C05A6) Unknown = Recipient ------_=_NextPart_000_01C1D62E.2FB595E6 Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 01:56:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) X-MS-Embedded-Report: Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D62E.2FB595E6-- From MAILER-DAEMON Wed Mar 27 23:57:24 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7vOKL016883 for ; Wed, 27 Mar 2002 23:57:24 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA26912 for ; Wed, 27 Mar 2002 23:57:25 -0800 (PST) Received: from mx01.exodus.net (mx01.exodus.net [206.79.74.10]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23748 for ; Thu, 28 Mar 2002 00:57:25 -0700 (MST) Received: from localhost (localhost) by mx01.exodus.net (8.11.2/8.11.2) id g2S7vOD14896; Thu, 28 Mar 2002 02:57:24 -0500 (EST) Date: Thu, 28 Mar 2002 02:57:24 -0500 (EST) From: Mail Delivery Subsystem Message-Id: <200203280757.g2S7vOD14896@mx01.exodus.net> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="g2S7vOD14896.1017302244/mx01.exodus.net" Content-Transfer-Encoding: 8bit Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --g2S7vOD14896.1017302244/mx01.exodus.net The original message was received at Thu, 28 Mar 2002 02:57:21 -0500 (EST) from patan.Sun.COM [192.18.98.43] ----- The following addresses had permanent fatal errors ----- (reason: 554 Invalid data in message) (expanded from: ) ----- Transcript of session follows ----- ... while talking to exoserv.exodus.net.: >>> DATA <<< 554 Invalid data in message 554 5.0.0 ... Service unavailable --g2S7vOD14896.1017302244/mx01.exodus.net Content-Type: message/delivery-status Reporting-MTA: dns; mx01.exodus.net Received-From-MTA: DNS; patan.Sun.COM Arrival-Date: Thu, 28 Mar 2002 02:57:21 -0500 (EST) Final-Recipient: RFC822; X-Actual-Recipient: RFC822; andrewl@exoserv.exodus.net Action: failed Status: 5.0.0 Remote-MTA: DNS; exoserv.exodus.net Diagnostic-Code: SMTP; 554 Invalid data in message Last-Attempt-Date: Thu, 28 Mar 2002 02:57:24 -0500 (EST) --g2S7vOD14896.1017302244/mx01.exodus.net Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by mx01.exodus.net (8.11.2/8.11.2) with ESMTP id g2S7vLD14894 for ; Thu, 28 Mar 2002 02:57:21 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29507; Thu, 28 Mar 2002 00:57:05 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12976; Wed, 27 Mar 2002 23:56:53 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--g2S7vOD14896.1017302244/mx01.exodus.net-- From MAILER-DAEMON Wed Mar 27 23:57:31 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7vVKL016890 for ; Wed, 27 Mar 2002 23:57:31 -0800 (PST) Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA26933 for ; Wed, 27 Mar 2002 23:57:33 -0800 (PST) Received: from localhost (localhost) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with internal id XAA27634; Wed, 27 Mar 2002 23:57:32 -0800 (PST) Date: Wed, 27 Mar 2002 23:57:32 -0800 (PST) From: Mail Delivery Subsystem Message-Id: <200203280757.XAA27634@mercury.Sun.COM> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="XAA27634.1017302252/mercury.Sun.COM" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --XAA27634.1017302252/mercury.Sun.COM The original message was received at Wed, 27 Mar 2002 23:56:56 -0800 (PST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to mailhost.m5p.com.: >>> DATA <<< 550 5.7.1 Message rejected. Please see http://m5p.com/bounce.html for more details. 554 ... Service unavailable --XAA27634.1017302252/mercury.Sun.COM Content-Type: message/delivery-status Reporting-MTA: dns; mercury.Sun.COM Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Wed, 27 Mar 2002 23:56:56 -0800 (PST) Final-Recipient: RFC822; george+ipng@m5p.com Action: failed Status: 5.2.0 Remote-MTA: DNS; mailhost.m5p.com Diagnostic-Code: SMTP; 550 5.7.1 Message rejected. Please see http://m5p.com/bounce.html for more details. Last-Attempt-Date: Wed, 27 Mar 2002 23:57:28 -0800 (PST) --XAA27634.1017302252/mercury.Sun.COM Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27632; Wed, 27 Mar 2002 23:56:56 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12964; Wed, 27 Mar 2002 23:56:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--XAA27634.1017302252/mercury.Sun.COM-- From MAILER-DAEMON Wed Mar 27 23:57:29 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7vTKL016887 for ; Wed, 27 Mar 2002 23:57:29 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA26921 for ; Wed, 27 Mar 2002 23:57:30 -0800 (PST) Received: from switchcore.netcore.se (switchcore.switchcore.com [212.209.176.138]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA11345 for ; Thu, 28 Mar 2002 00:57:28 -0700 (MST) Received: by switchcore.switchcore.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 08:57:27 +0100 Message-ID: <3FC61C6ACB00D41196F6009027E00B9CB2C729@switchcore.switchcore.com> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?EUC-KR?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?EUC-KR?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 08:57:26 +0100 X-MS-TNEF-Correlator: <3FC61C6ACB00D41196F6009027E00B9CB2C729@switchcore.switchcore.com> MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62E.33BBDBD6" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62E.33BBDBD6 Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 08:56:02 +0100 did not reach the following recipient(s): Johan Hellqvist on Thu, 28 Mar 2002 08:57:26 +0100 The message could not be delivered because you do not have create permissions on this folder or it is only available to folder owners at = this time The MTS-ID of the original message is: c=3Dse;a=3D ;p=3Dnetcore ab;l=3DSWITCHCORE0203280757FZ3DQNM0 MSEXCH:MSExchangeMTA:CORE:SWITCHCORE ------_=_NextPart_000_01C1D62E.33BBDBD6 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IhwHAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEJgAEAIQAAAEVERkZCOEExNzE0MzVDNDA4 MzI1MDc2NzRBNzhCMEUxAB4HAQOQBgDkAgAAEAAAAAMANgAAAAAAQAAHMCrG5jMu1sEBAgH5PwEA AAB6AAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPU5FVENPUkUgQUIvT1U9Q09SRS9D Tj1DT05GSUdVUkFUSU9OL0NOPUNPTk5FQ1RJT05TL0NOPUlOVEVSTkVUIE1BSUwgQ09OTkVDVE9S IChTV0lUQ0hDT1JFKQAAAB4A+D8BAAAAIwAAAEludGVybmV0IE1haWwgU2VydmljZSAoU1dJVENI Q09SRSkAAB4AOEABAAAAJQAAAElOVEVSTkVUIE1BSUwgQ09OTkVDVE9SIChTV0lUQ0hDT1JFKQAA AAACAfs/AQAAAHoAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089TkVUQ09SRSBBQi9P VT1DT1JFL0NOPUNPTkZJR1VSQVRJT04vQ049Q09OTkVDVElPTlMvQ049SU5URVJORVQgTUFJTCBD T05ORUNUT1IgKFNXSVRDSENPUkUpAAAAHgD6PwEAAAAjAAAASW50ZXJuZXQgTWFpbCBTZXJ2aWNl IChTV0lUQ0hDT1JFKQAAHgA5QAEAAAAlAAAASU5URVJORVQgTUFJTCBDT05ORUNUT1IgKFNXSVRD SENPUkUpAAAAAAsAKQAAAAAACwAjAAAAAAADAAYQjLk84gMABxCrAQAAAwAQEAAAAAADABEQAAAA AB4ACBABAAAAZQAAAFlPVVJNRVNTQUdFVE86SVBORy1ESVNUoqVPU1VCSkVDVDooob6itKHGSSlB VaG+QaKvQaXsqfaooUOp+FWir0Go+U+ir0Gl7Kn2qKFDqfhVU0VOVDpUSFUsMjhNQVIyMDAyMDgA AAAAAgF/AAEAAABDAAAAPDNGQzYxQzZBQ0IwMEQ0MTE5NkY2MDA5MDI3RTAwQjlDQjJDNzI5QHN3 aXRjaGNvcmUuc3dpdGNoY29yZS5jb20+AAD4ugICkAYADgAAAAEAAAAAACAAIAAAAAAAQQACEIAB ABQAAABVbnRpdGxlZCBBdHRhY2htZW50AHIHAhKAAwAOAAAA0gcDABwACAA5ABsABABYAQITgAMA DgAAANIHAwAcAAgAOQAbAAQAWAECD4AGABoAAABNQVBJIDEuMCBlbWJlZGRlZCBtZXNzYWdlACUI AgWQBgB0PQAACgAAAAMAIQ4AAAAAAwALNwAAAAADACAO+xwAAAMA9w8AAAAAAgEQaAEAAAAOAAAA AAAAAAAAAAAAAAAAAAAAAEAABzDAreYzLtbBAUAACDDAreYzLtbBAQMABTcFAAAAAgH5DwEAAAAQ AAAAjdfpRXbNRkuOQ21l9NK9Wg0AATcBAAAA7DwAAAcDAgAAAAAAwAAAAAAAAEZ4nz4iHAcBBpAI AAQAAAAAAAEAAQABB5AGAAgAAADkBAAAAAAAAOgAAQiABwAgAAAASVBNLk1pY3Jvc29mdCBNYWls Lk5vbi1EZWxpdmVyeQA3CwEKgAEAIQAAADkzM0Y1MDk5OEQ2QjVBNEM4MEE1RUVGNDRERUI2QTJB AGgHAQWAAwAOAAAA0gcDABwACAA5ABoABABXAQEHgAYAAQAAAIGBAAEGgAMADgAAANIHAwAcAAgA OQAaAAQAVwEBIIADAA4AAADSBwMAHAAIADkAGgAEAFcBAQmAAQAhAAAARDlERDk0QUI1RUMwOTU0 Q0EzM0NGODU1RTI2MjA2MkIAUgcBBIABAEIAAABVbmRlbGl2ZXJhYmxlOiAoIKG+orShxmkgKSBB daG+YaKvQaXsqfaooUOp+FUgoq9BqPlvoq9Bpeyp9qihQ6n4VQCSIQENgAQAAgAAAAIAAgABBJAG AFwCAAABAAAAEAAAAB4AATABAAAAEAAAAEpvaGFuIEhlbGxxdmlzdAAeAAIwAQAAAAUAAABTTVRQ AAAAAB4AAzABAAAAHwAAAEpvaGFuLkhlbGxxdmlzdEBzd2l0Y2hjb3JlLmNvbQAAAwAAMAAAAAAC AfYPAQAAAAQAAAAAAAAAAwAVDAEAAAACAQswAQAAAGAAAABFWDovTz1ORVRDT1JFIEFCL09VPUNP UkUvQ049UkVDSVBJRU5UUy9DTj1KT05BUyBIRUxMUVZJU1Q2QjMwRTc2NjZCMzBFNzY2NkIzMEU3 NjY3NTI4QjZCNzAwMkIyQQALAA8OAQAAAAsAQDoBAAAAAwBiZgEAAAALAAgMAQAAAEAAMgAAt0Mz LtbBAQMABAwAAAAAAwAFDCQAAAAeABsMAQAAACUAAABNU0VYQ0g6TVNFeGNoYW5nZU1UQTpDT1JF OlNXSVRDSENPUkUAAAAAHgABEAEAAADwAAAAVGhlIG1lc3NhZ2UgY291bGQgbm90IGJlIGRlbGl2 ZXJlZCBiZWNhdXNlIHlvdSBkbyBub3QgaGF2ZSBjcmVhdGUgcGVybWlzc2lvbnMgb24gdGhpcyBm b2xkZXIgb3IgaXQgaXMgb25seSBhdmFpbGFibGUgdG8gZm9sZGVyIG93bmVycyBhdCB0aGlzIHRp bWUKCVRoZSBNVFMtSUQgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UgaXM6IGM9c2U7YT0gO3A9bmV0 Y29yZSBhYjtsPVNXSVRDSENPUkUwMjAzMjgwNzU3RlozRFFOTTAARJIBA5AGAOQMAABVAAAAAgHc PwEAAAAqAAAAAQAAACIAAAAeAAAAAAAAMIDBFS9vPU5ldGNvcmUgQUIvb3U9Q09SRQAAAAACAWVm AQAAAFkAAAAAAAAAgSsfpL6jEBmdbgDdAQ9UAgAAAABpcG5nLWRpc3RAc3Vucm9vZi5lbmcuc3Vu LmNvbQBTTVRQAGlwbmctZGlzdEBzdW5yb29mLmVuZy5zdW4uY29tAAAAAB4AYkABAAAABQAAAFNN VFAAAAAAHgBjQAEAAAAeAAAAaXBuZy1kaXN0QHN1bnJvb2YuZW5nLnN1bi5jb20AAAAeAGRmAQAA AB4AAABpcG5nLWRpc3RAc3Vucm9vZi5lbmcuc3VuLmNvbQAAAB4AX0ABAAAAHgAAAGlwbmctZGlz dEBzdW5yb29mLmVuZy5zdW4uY29tAAAAAgFkQAEAAAAjAAAAU01UUDpJUE5HLURJU1RAU1VOUk9P Ri5FTkcuU1VOLkNPTQAAAwBcQAAAAAACAWNmAQAAADUAAABjPXNlO2E9IDtwPW5ldGNvcmUgYWI7 bD1TV0lUQ0hDT1JFMDIwMzI4MDc1N0ZaM0RRTk0wAAAAAAIBamYBAAAAuAAAAAEAAAAAAAAAALdD My7WwQEAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAU0UAAE5ldGNvcmUgQUIAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABTV0lUQ0hDT1JFAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAACAWBmAQAAAHAAAAABAAAAAAAAAAC3QzMu1sEBAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAA AFNFAABOZXRjb3JlIEFCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAHgBwAAEAAAAzAAAAKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKv Qaj5b6KvQaXsqfaooUOp+FUAAAIBcQABAAAAGwAAAAHB1i4yKOF4O1PYvU0Tq7+82jfMYdkAAABk NgACARQ6AQAAABAAAACTP1CZjWtaTICl7vRN62oqHgBJAAEAAAAzAAAAKCChvqK0ocZpICkgQXWh vmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FUAAAIBXgABAAAANwAAAAAAAACBKx+k vqMQGZ1uAN0BD1QCAAABAEFJQUFFocwAU01UUABsY2g1MTAxQGtvcmVhLmNvbQAAHgBoAAEAAAAF AAAAU01UUAAAAAAeAGkAAQAAABIAAABsY2g1MTAxQGtvcmVhLmNvbQAAAB4AXQABAAAACAAAAEFJ QUFFocwAHgAzQAEAAAASAAAAbGNoNTEwMUBrb3JlYS5jb20AAAACAV8AAQAAABcAAABTTVRQOkxD SDUxMDFAS09SRUEuQ09NAAADAB5AAAABAAIBWwABAAAANwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QC AAABAEFJQUFFocwAU01UUABsY2g1MTAxQGtvcmVhLmNvbQAAHgBmAAEAAAAFAAAAU01UUAAAAAAe AGcAAQAAABIAAABsY2g1MTAxQGtvcmVhLmNvbQAAAB4AWgABAAAACAAAAEFJQUFFocwAHgAyQAEA AAASAAAAbGNoNTEwMUBrb3JlYS5jb20AAAACAVwAAQAAABcAAABTTVRQOkxDSDUxMDFAS09SRUEu Q09NAAADAB1AAAABAEAATgAAVTIBLtbBAR4AdAABAAAADQAAAGlwbmctZGlzdKKlTwAAAAADAN4/ BccAAEAAX2bW27szLtbBAUAAOQDW27szLtbBAR4AHgwBAAAABQAAAFNNVFAAAAAAHgAfDAEAAAAa AAAAcG9zdG1hc3RlckBzd2l0Y2hjb3JlLmNvbQAAAB4AGgwBAAAAFQAAAFN5c3RlbSBBZG1pbmlz dHJhdG9yAAAAAB4AMEABAAAAAgAAAC4AAAACAR0MAQAAAAUAAABFWDouAAAAAAMAGUAAAAAAAgFB AAEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC4AAAAeAGQAAQAAAAUAAABTTVRQ AAAAAB4AZQABAAAAGgAAAHBvc3RtYXN0ZXJAc3dpdGNoY29yZS5jb20AAAAeAEIAAQAAABUAAABT eXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAAeADFAAQAAAAIAAAAuAAAAAgE7AAEAAAAFAAAARVg6LgAA AAADABpAAAAAAAMAJgAAAAAAAwBTZgAAAABAAAYO1tu7My7WwQECAT8AAQAAAHoAAAAAAAAA3KdA yMBCEBq0uQgAKy/hggEAAAAAAAAAL089TkVUQ09SRSBBQi9PVT1DT1JFL0NOPUNPTkZJR1VSQVRJ T04vQ049Q09OTkVDVElPTlMvQ049SU5URVJORVQgTUFJTCBDT05ORUNUT1IgKFNXSVRDSENPUkUp AAAAHgB1AAEAAAADAAAARVgAAB4AdgABAAAAXgAAAC9PPU5FVENPUkUgQUIvT1U9Q09SRS9DTj1D T05GSUdVUkFUSU9OL0NOPUNPTk5FQ1RJT05TL0NOPUlOVEVSTkVUIE1BSUwgQ09OTkVDVE9SIChT V0lUQ0hDT1JFKQAAAB4AQAABAAAAIwAAAEludGVybmV0IE1haWwgU2VydmljZSAoU1dJVENIQ09S RSkAAB4ANEABAAAAJQAAAElOVEVSTkVUIE1BSUwgQ09OTkVDVE9SIChTV0lUQ0hDT1JFKQAAAAAC AVEAAQAAAGEAAABFWDovTz1ORVRDT1JFIEFCL09VPUNPUkUvQ049Q09ORklHVVJBVElPTi9DTj1D T05ORUNUSU9OUy9DTj1JTlRFUk5FVCBNQUlMIENPTk5FQ1RPUiAoU1dJVENIQ09SRSkAAAAAAwAb QAAAAAACAUMAAQAAAHoAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089TkVUQ09SRSBB Qi9PVT1DT1JFL0NOPUNPTkZJR1VSQVRJT04vQ049Q09OTkVDVElPTlMvQ049SU5URVJORVQgTUFJ TCBDT05ORUNUT1IgKFNXSVRDSENPUkUpAAAAHgB3AAEAAAADAAAARVgAAB4AeAABAAAAXgAAAC9P PU5FVENPUkUgQUIvT1U9Q09SRS9DTj1DT05GSUdVUkFUSU9OL0NOPUNPTk5FQ1RJT05TL0NOPUlO VEVSTkVUIE1BSUwgQ09OTkVDVE9SIChTV0lUQ0hDT1JFKQAAAB4ARAABAAAAIwAAAEludGVybmV0 IE1haWwgU2VydmljZSAoU1dJVENIQ09SRSkAAB4ANUABAAAAJQAAAElOVEVSTkVUIE1BSUwgQ09O TkVDVE9SIChTV0lUQ0hDT1JFKQAAAAACAVIAAQAAAGEAAABFWDovTz1ORVRDT1JFIEFCL09VPUNP UkUvQ049Q09ORklHVVJBVElPTi9DTj1DT05ORUNUSU9OUy9DTj1JTlRFUk5FVCBNQUlMIENPTk5F Q1RPUiAoU1dJVENIQ09SRSkAAAAAAwAcQAAAAAALAFcAAQAAAAsAWAAAAAAACwBZAAEAAAACAUcA AQAAADcAAABjPVNFO2E9IDtwPU5ldGNvcmUgQUI7bD1TV0lUQ0hDT1JFMDIwMzI4MDg1NzI2Q1Iw MDkzMDQAAAIB+T8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAHgD4PwEA AAAVAAAAU3lzdGVtIEFkbWluaXN0cmF0b3IAAAAAHgA4QAEAAAACAAAALgAAAAIB+z8BAAAAHgAA AAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAHgD6PwEAAAAVAAAAU3lzdGVtIEFkbWlu aXN0cmF0b3IAAAAAHgA5QAEAAAACAAAALgAAAEAABzB8ebkzLtbBAUAACDCKoMAzLtbBAR4APQAB AAAAEAAAAFVuZGVsaXZlcmFibGU6IAAeAB0OAQAAADMAAAAoIKG+orShxmkgKSBBdaG+YaKvQaXs qfaooUOp+FUgoq9BqPlvoq9Bpeyp9qihQ6n4VQAACwAbDgEAAAADACMOEywFAB4ANRABAAAAQwAA ADwzRkM2MUM2QUNCMDBENDExOTZGNjAwOTAyN0UwMEI5Q0IyQzcyOUBzd2l0Y2hjb3JlLnN3aXRj aGNvcmUuY29tPgAAAwD0DwYAAAADAAgOuxwAAAMANgAAAAAACwBKZgAAAADewgICkAYADgAAAAEA /////yAAIAAAAAAAPQQCEIABABQAAABVbnRpdGxlZCBBdHRhY2htZW50AHIHAg+ABgAaAAAATUFQ SSAxLjAgZW1iZWRkZWQgbWVzc2FnZQAlCAISgAMADgAAANIHAwAcAAgAOQAaAAQAVwECE4ADAA4A AADSBwMAHAAIADkAGgAEAFcBAgWQBgCQKwAACgAAAAMAIQ4AAAAAAwALN/////8DACAOnRkAAAMA 9w8AAAAAAgEQaAEAAAAOAAAAAAAAAAAAAAAAAAAAAAAAAA0AATcBAAAABisAAAcDAgAAAAAAwAAA AAAAAEZ4nz4iHAcBBpAIAAQAAAAAAAEAAQABB5AGAAgAAADkBAAAAAAAAOgAAQiABwAYAAAASVBN Lk1pY3Jvc29mdCBNYWlsLk5vdGUAMQgBAIAAAC8AAAAEAC8ACAAXAEFJQUFFocwAU01UUDpsY2g1 MTAxQGtvcmVhLmNvbQAAAAAAAAAAAEsKAQyAAgAiBAAADQoNCg0KDQogDQoNCg0KDQogDQoNCg0K DQrIrby6xsez2sDHIDIws+IgsObH6LD6ILHivPq3ziDAzLfox9izvSANCr/4uPG4trfnwOe3zryt IL/Ctbm56LyxsPogv/i48bi2t+ewoSDAz8O8yK21x77uDQqx4sG4IMLKuLa35yC9w7D4sPq0wiC0 3riuIL3DsPjAzCCwo8btx8+w7SC+yMD8DQrHz7jnIL/uwPu/3LyxwLi3ziCwx7CtsKHB9iC7/bCi x8+0wiANCrG5s7sgw9bDysDHIMavx+PA58DUtM+02S4NCg0KIA0KDQogDQqx4sG4wMcgw7bGx8bH s9q/obytILOquasox9XGxynGx7Pat84gsLO537XHvu4gurm757+tt84gwM7H0SDIxrHisKEgsKG1 5sfPv6kgwM7DvL+hILChwOUgwK/AzcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB /CDH9rvzwLsgv8+6rsfPsNQguri/z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCo wPzAxyDAp8fowMwgvvi+7iDD1rDtwMcgvsjA/Ly6wLsgyK66uMfPv7S9wLTPtNkuDQoNCry8tvO5 zSwgwvy9obD6ILOquavAxyCw4cfVwLi3ziDAzsO8wMcgwK/AzcfRIL/4wPu/3CC8scC7ILnmw+LH 1bTPtNkuIA0KvcOw+MDMILCjxu3Hz7+pILTnwM+9w7D4ILTnwM+zrbnmwMwgsKG0yQ0Kx9W0z7TZ DQoNCiANCg0KDQoNCiANCg0KDQogDQoNCiANCg0KyK69x8j3ILTetvPB+CDIssXkueYgv8K89r/C tbnAuiC/77e3sMW4ssDMIL74sO0gvsbB1iCw37Dtx9W0z7TZLg0KseLBuCDBtrizvcS/wrW5wMcg ua7BpsGhtenAzCC48LXOILCzvLHH0SANCr3FsPi5/SDAuLfOILyzxKG68b/rwMwgvcC9xLnMwOWw +Ln9wMcgvPbB2LD6ILCwwMwgvsbB1iDA+rfFx9W0z7TZLg0KDQogDQogDQogICAgDQq758D8IMfj tvQgvvjAzCC43sDPwLsgurizvSDBoSDBy7zbx8+/wLjnILjewM/AuyAgvPa9xcfPwfYgvsrAuLfB uOkgIA0KvPa9xSCwxbrOuKYgxay4r8fYIMHWvcO46SCwqLvnteW4rrDavcC0z7TZLiAgICANCg0K IEhvbWVwYWdlIDogd3d3LmFubmUxMTQuY28ua3IgICAvICAgRW1haWwgOiBsY2g1MTAxQGtvcmVh LmNvbSANCkNvcHlyaWdodKjPIDIwMDIgIGFubmUxMTQuY29tICBBbGwgcmlnaHQgcmVzZXJ2ZWQu IA0KDQoNCgBsXgEJgAEAIQAAADkzM0Y1MDk5OEQ2QjVBNEM4MEE1RUVGNDRERUI2QTJBAGgHAQeA BgABAAAAIyMAAQaAAwAOAAAA0gcDABwACAA5ABcABABUAQEggAMADgAAANIHAwAcAAgAOQAaAAQA VwEBBYADAA4AAADSBwMAHAAIADgAAgAEAD4BAQSAAQAzAAAAKCChvqK0ocZpICkgQXWhvmGir0Gl 7Kn2qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FUA9hsBDYAEAAIAAAACAAIAAQSQBgDgAAAAAQAA AAoAAAAeAAEwAQAAAA0AAABpcG5nLWRpc3SipU8AAAAAHgACMAEAAAAFAAAAU01UUAAAAAAeAAMw AQAAAB4AAABpcG5nLWRpc3RAc3Vucm9vZi5lbmcuc3VuLmNvbQAAAAMAADAAAAAAAgH2DwEAAAAE AAAAAAAAAAMAFQwBAAAAAgELMAEAAAAjAAAAU01UUDpJUE5HLURJU1RAU1VOUk9PRi5FTkcuU1VO LkNPTQAAHgAgOgEAAAANAAAAaXBuZy1kaXN0oqVPAAAAAAsADw4BAAAACwBAOgAAAACdJAEDkAYA gCQAACwAAAADAP0/tQMAAEAAOQAAVTIBLtbBAQIBQQABAAAANwAAAAAAAACBKx+kvqMQGZ1uAN0B D1QCAAABAEFJQUFFocwAU01UUABsY2g1MTAxQGtvcmVhLmNvbQAAHgBkAAEAAAAFAAAAU01UUAAA AAAeAGUAAQAAABIAAABsY2g1MTAxQGtvcmVhLmNvbQAAAB4AQgABAAAACAAAAEFJQUFFocwAHgAx QAEAAAASAAAAbGNoNTEwMUBrb3JlYS5jb20AAAACATsAAQAAABcAAABTTVRQOkxDSDUxMDFAS09S RUEuQ09NAAADABpAAAABAB4AHgwBAAAABQAAAFNNVFAAAAAAHgAfDAEAAAASAAAAbGNoNTEwMUBr b3JlYS5jb20AAAAeABoMAQAAAAgAAABBSUFBRaHMAB4AMEABAAAAEgAAAGxjaDUxMDFAa29yZWEu Y29tAAAAAgEdDAEAAAAXAAAAU01UUDpMQ0g1MTAxQEtPUkVBLkNPTQAAAwAZQAAAAQADAN4/BccA AB4AfQABAAAAuQYAAFJlY2VpdmVkOiBmcm9tIHBhdGFuLlN1bi5DT00gKFsxOTIuMTguOTguNDNd KSBieSBzd2l0Y2hjb3JlLm5ldGNvcmUuc2Ugd2l0aCBTTVRQIChNaWNyb3NvZnQgRXhjaGFuZ2Ug SW50ZXJuZXQgTWFpbCBTZXJ2aWNlIFZlcnNpb24gNS41LjI2NTMuMTMpDQoJaWQgRlozRFFOTTA7 IFRodSwgMjggTWFyIDIwMDIgMDg6NTc6MjMgKzAxMDANClJlY2VpdmVkOiBmcm9tIGVuZ21haWwz LkVuZy5TdW4uQ09NIChbMTI5LjE0NC4xNzAuNV0pDQoJYnkgcGF0YW4uc3VuLmNvbSAoOC45LjMr U3VuLzguOS4zKSB3aXRoIEVTTVRQIGlkIEFBQTI5NTQ5Ow0KCVRodSwgMjggTWFyIDIwMDIgMDA6 NTc6MTEgLTA3MDAgKE1TVCkNClJlY2VpdmVkOiBmcm9tIHN1bnJvb2YuZW5nLnN1bi5jb20gKHN1 bnJvb2YuRW5nLlN1bi5DT00gWzEyOS4xNDYuMTY4Ljg4XSkNCglieSBlbmdtYWlsMy5FbmcuU3Vu LkNPTSAoOC45LjMrU3VuLzguOS4zL0VOU01BSUwsdjIuMXAxKSB3aXRoIEVTTVRQIGlkIFhBQTEy OTc2Ow0KCVdlZCwgMjcgTWFyIDIwMDIgMjM6NTY6NTMgLTA4MDAgKFBTVCkNClJlY2VpdmVkOiBm cm9tIGVuZ21haWwyLkVuZy5TdW4uQ09NIChlbmdtYWlsMiBbMTI5LjE0Ni4xLjI1XSkNCglieSBz dW5yb29mLmVuZy5zdW4uY29tICg4LjEyLjIrU3VuLzguMTIuMikgd2l0aCBFU01UUCBpZCBnMlM3 dUJLTDAxNjgzMQ0KCWZvciA8aXBuZy1kaXN0QHN1bnJvb2YuZW5nLnN1bi5jb20+OyBXZWQsIDI3 IE1hciAyMDAyIDIzOjU2OjExIC0wODAwIChQU1QpDQpSZWNlaXZlZDogZnJvbSBud2tlYS1tYWls LTEuc3VuLmNvbSAoWzE5Mi4xOC40Mi4xM10pDQoJYnkgZW5nbWFpbDIuRW5nLlN1bi5DT00gKDgu OS4zK1N1bi84LjkuMy9FTlNNQUlMLHYyLjFwMSkgd2l0aCBFU01UUCBpZCBYQUEwNDQ0OQ0KCWZv ciA8aXBuZy1kaXN0QHN1bnJvb2YuZW5nLnN1bi5jb20+OyBXZWQsIDI3IE1hciAyMDAyIDIzOjU2 OjEyIC0wODAwIChQU1QpDQpSZWNlaXZlZDogZnJvbSBteDYuc3VuLmNvbSAoWzYxLjEwNC4xOTIu MjldKQ0KCWJ5IG53a2VhLW1haWwtMS5zdW4uY29tICg4LjkuMytTdW4vOC45LjMpIHdpdGggRVNN VFAgaWQgWEFBMjgxOTQNCglmb3IgPGlwbmctZGlzdEBzdW5yb29mLmVuZy5zdW4uY29tPjsgV2Vk LCAyNyBNYXIgMjAwMiAyMzo1NjoxMiAtMDgwMCAoUFNUKQ0KTWVzc2FnZS1JZDogPDIwMDIwMzI4 MDc1Ni5YQUEyODE5NEBud2tlYS1tYWlsLTEuc3VuLmNvbT4NClJlY2VpdmVkOiBmcm9tIFNBTUJP IChTQU1CTyBbNjEuMTA0LjE5Mi4yOV0pIGJ5IG14Ni5zdW4uY29tIHdpdGggRVNNVFAgMS4wLjI4 MzsgDQoJVGh1LCAyOCBNYXIgMjAwMiAxNjo1NjowMiArMDkwMA0KRnJvbTogwMzFwsijIDxsY2g1 MTAxQGtvcmVhLmNvbT4NClRvOiBpcG5nLWRpc3S01CA8aXBuZy1kaXN0QHN1bnJvb2YuZW5nLnN1 bi5jb20+DQpTdWJqZWN0OiAoILGksO0gKSDA/LHiv8K1ucbHs9ogv8K89r/CtbnGx7PaDQpEYXRl OiBUaHUsIDI4IE1hciAyMDAyIDE2OjU2OjAyICswOTAwDQpNSU1FLVZlcnNpb246IDEuMA0KQ29u dGVudC1UeXBlOiB0ZXh0L2h0bWw7DQoJY2hhcnNldD0ia3NfY181NjAxLTE5ODciDQpYLVByaW9y aXR5OiAzDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiBxdW90ZWQtcHJpbnRhYmxlDQpYLU1J TUUtQXV0b2NvbnZlcnRlZDogZnJvbSA4Yml0IHRvIHF1b3RlZC1wcmludGFibGUgYnkgcGF0YW4u c3VuLmNvbSBpZCBBQUEyOTU0OQ0KDQoAAAAAAwAGEL0jxnUDAAcQJAMAAB4ACBABAAAAngAAAEWh qaj5qKyooUOp+FVBQzIwqfhhocapoUNlocZ1ob5hqPl1oaRJQUmhpGVDqKqp+Kj2oq+pqqKsbqKs otKhpGNBY6GkSaj5oamir0Gl7Kn2qfZlqPmhvqHGdaKvqaqirG6irKLSoaRjocairkFJQaj5RaGp pexDqPppob5hQaKsQUWirKLSoaRjqPZBocapqqHGdaKlQaKlqK2irFIAAAADABAQAAAAAAMAERAB AAAAAgEJEAEAAACjGAAAnxgAAIppAABMWkZ1hFSu8wMACgByY3BnOTQ5wQNDaHRtbDEDMAEDnwH3 CoACpAPjAgBjaArAAHNldDEyOSBH/HVsB3ACgA/zAFAEVhGTaENoZRHlMgLjEMcyNwYABsMR5TME RhDHMCC/CFUHsgKAEfMI7wn3Oxiv+DI1NRnDGuEJtAHQFcDJCjI4MhscMTEOQBwz2jQbFDMT4Buk MxwUHmHvGc8ZoRHxDGBjAFALCQFkTDM2FuALpTQgD/IqplwOogGQZzMK4yAR8wcjhyMQJBA8IURP QwBUWVBFIEhUTQBMIFBVQkxJQwAgIi0vL1czQxEnIERURCY0NC4w4ScgRU4iPiSMJB8pUv8dgCWQ DqIorRTQKb8pcSMg8SsQZWFkKK0O4SyPKtAENzclkHRpdGxltStuNA7gVQIwMMJkKg10ODUlkC8w vy7vKnY2kQ7gPGJhESAgaB/AQGY9IkM6XDegJ9xiODfAAQA3wGMBQDhQemY3wWE3wQwwN9AOQCc6 YTgwXABQOFAT4Cdmfjc3oCieNT82RweAAZAgbG5hB4A3YGcJ8ASQYXJ0BbAiIAWgAjAJ8HQFN2BO PZBvIFdlYsxFZDQABbF2MygwOp//O68pYTIBM9At7yw/Q88o+A41FuA2wARweSBiZ9MYIzdgd2g0 AGU+cD7Abng+8QJgANBrPnARsG6ua0iSClA+cHZJJHAIcP8LUEghB0BJMx/BKJEpEwAhJQMwdgiQ d2sLgGQ1vyjENtBI4AnACGBMoCAAADhzaHAo4k4BC4BzdKtN4U4hcwOgZgMQbAhQ4xhBApFzdiA2 gDBwAcDsMTUXwE7oRk+BMpFQFP8XwFJxS6YW4CjLIpFFr1QveSlDOTYlkD+wUEBK0Wd6bjdgYz7R BJBLegAAcf5jAzBS31aHAZE0IEdABbBvBIE3YEBAPoBlT5AKsGT5P7BuZ1unTwAA0Fx2A/CoZHRo N2A1IoAiCqMaIE7AeTQgN2BCT1KAREVSLVJJRyZAADogcmdiKDEwoDEsODcsXmApUFCccHhe8Abw XgA7IF91GFRPUGA/YU8tTEVeRmAvY59fwF9wVGJgTf9lD2YXWCwLCCKoWT9VLyTKlxbgbkIkjDYt sXRyWDv/a29CVGzfKWEd8G5Dbl8q0Dw0ODCRTcBd9WfwOTJvWCxwr28kdQFwKK1zUTxHPWA3JA6g dHA6JyB3fXrALgBwPgAdcCggBaBtwi8FoDA1Mi974WgA9xwAHmB8US4OoV6VfXoBkPdnsBEwN2Bf SLFJQFgsT3C1XABkKOJmgEBOo0gmAfJSJsBOSybwel97b3x6+QMwXG5Q4oChERApUBgQXwBBEaBr T3kpB3BnXvByImN6PXlkbYLxLmuGcjPgOaBod2Evh9F9fMFnBpB9L17gXfk3EGXnV3AOoDdgODE+ cFtIS4nfUrmOT1mvFNAz0GGOL487/wqikBgKgUu3CrGUuGvdAcD/M8F4niMQdQEz4C4ebM9t3/+W rG+ymS+aP5tPby92j3FP/3Jfc290f3WPoY93r6O/ec//gl+Db3z/fg9/H4AvgT+sD/+tH4RvhX+o j4efiK+JugHQ54qfi6+Mtzc0jW+ST7+P/5Cfka/AL5PPlN/Bj5b/mA//nS+jf59PnE/Kj8ufzK+g j3+n76Kvqf+kz6XfpuZHSCP5ASBjYrSwp12M4VdhDqD/RXHTL6lPql+rb7P/rY+un/+vr7C/sc+y 39+PtP+2D7cf/7gvuT+6T4oU4QC737zvjLf9Z/A3vq/Dj/K/wd/C5esvr+w/7U+J9tCgXzPzMe7/ +/APjLczjV9LxeRP5V/4X//5b/p46V/qYFKq8//Eb8V//8aPx5/Ir8m/zt/P78zvzf//DX8Oj9Ev 0j8Jv9Rf1W/Wfw/Xjz5wXw9gFjI1NSzV4KAzaCAyZfA2Zi9iY/9Isx1yZD8cr2ZPZ1ggv2jz/xcU GLEU3wWPJi4H2lnfVxH/+x9XT1hfFc9af1uPXJ/yXf9p/2sPER8SLxM04doTnxSv/zRPFs8X3zdP GT/Xx+Cg8cG/8Sfu0KdfOm/clSt2cozi/Ut7cVSAQf/dn+Yv5z/gz/89T+Iv4z//DwAfR+9I/+iP 3+mfRa/3HwD/iX437u9Zr+/8F0mg2IHxJzb9jybPJp//VK/C313PB38Ij18vCq8Lv/8Q3zu/Ns89 yDhbQU9lHxnt/jZAX2y/NKBlezgt3M8YMygmbmIxYDtNezNc+CdhMGGfYW9if2OPZJ//Za9mv2fP aN9p72r/bA9tH7NuL9flMzRASlwydiuF+HRvcHCPcZ9yr3O/Rt//UC9RP0oPkC9ML00/Tk9PXz+N T45fUo9Tn4PvGeNmb/MsEBsgaXobcadNM9F3KO9Uz1XfVu+7GDhYr6J//Bf//XBcQb4HL/FcepoM 8ND2If+bImDvdv+oT18P9Z+aL5sxf6HfkLubf5yPme5cIKwwYv05WlwkcJXget+mT6dftL//O3J/ jTufPK89fbaveF8oj/8ufy+PMJ8xrzK/M89+b39//4CPPX84X4fPxg+5v7rPz+/3yh+Ez/1gM/HA y7/Mz0NV4Rs1TUFSR5TAIAWXIP8kIKXPrX/Zn67fr++w/6nwGCdjOHZRxKAnYmPV3nFh3fE23fE3 3nF2QW5k3uLFQN9BII7A33Rl16wg3nHgIWXfJWXeIeFS/maMUN5xmRDg8d504pDecf/fYcGwzQ/O H88v52+8ZuAEt96i4eXfUmTiInZBYhpA/7Ifsy+0P7gc3nG+gOKA4iL33iGZAe+jYt8h6ZPj8uFi v99i4/PedMIA4SLvQWPjMvo13nE582TiE96i8ALiZP/kX+Vv5n/4X+iW7z/wTeFS/GEx3eLgIvLS 6qLeod4X9/NR31PyAWXtMesv7D/tT/vuXeL1Y/rD3eIDYuOy8Eu/4SLeYf0D4mLiJ95xNPLi//Uv 9j/3Twq/+WgHQcEw+lRvWAAFj+j24SVhdkHfEmX/BcLj8voB4VPyg/IB3hLgEvxmY/7v//8BDwIe EAfeIa8FZPoB/sARdWL51GTeov/0VeAS8DPj/whfCW8c7/kd3+Aj+9XeYvwDA3RmKgDecf0YAWYf tgNiEBYHTxKvE7/vFM8Cx/OD6qJi3eLfot8i9w9S3+je9GHy0uHiD1LxRR3gEmQigSJzIkVkOS7/ tR+2L71vLp++T3nPJS977/98/34Pxx/ILzlf0T80k8uS3zaPN584rzn/0ccwnpFX4f/AwS4fM380 jzWfPD89Tz5f/zqfO69GT0dfSK9Ar0G/me77ToPCIHZPL1A/Sz9MT01ff8tDixHTn52Pnp+fr6C5 NaAwX3RpdNYwMqGD/aOmNUUQoc9H8G/WpCClHP+Sp5MvlD9az1vfXOiYP5lA/2ZQWF+4XxqfG6+8 T76fv659UbEghxXBsJtAwUCSfHH/DsFnv8AfwS/CP8NPxF/Fb/9Tb1R/R+9WX8t/d/9p32rv93r/ 18/SmDJykIYZl2CG7599X9S/1cKFFdYwZnReP2fa3dYf1yAwbZfQJCpx/5lP2A/br9y/jd8jzyTf aE//WP9aD2PvoOZRUKF/mp+jmOQwNaRYMjNgD2EfYi//Yz+YT5lYZl9nbyzfLe+kn/+VT38fgC+r n7y/MG9tP25P/29fcG+nn3KPc5+1QZn/t0v/dO91/3cPsv95L3o/vq+Bz/98r4ZfqT+qT8UPvz+C T4NZ35xgwV/Cb9Wf1qg2jEPHH//Yz89f2u+Pv90PAxwpCgYCf98i3yXfHvnyICLyOAYBYXcHAvOR tIAo6fX+Et8jKf/WHxmvw0/EX95/He8ZQgYC/fORZBBS/hsO0tiVIPLxc//XQv3S23TUhREi6iL8 Q+ni3/CCAyX79x/m80Jl1cYQUv3XQjnkiv0V1zTbz9zf3e/v7e8eWyAj8UI1/FUp89SyRw/V5XHs LiZuYriQO/vR29hSMK1q2DT90uLx6BP/Ks8r35H/kw/J36hf+M/53//67/v/63/sjwMvC33VP9ZN 9SknYtPxYdRyIHIOwuHS/yCgINUqhSfTGDIQQ9sxDSD/D+z3IOJ2GYIKdehdAH8Bj/8CnxGPHmcH 3wjv5aET8uIS/mbUdRlzGYHjYNNyIoHpEP/UhBPgFRbYJucm1HUYF9Tz/+di23IqQtR2E/AObw9/ EI+/H48SpxXV4hcoJudSZfFy/wdH6bIZueojKPUn1NRxCyL3DHYNevdiYiMF92/8j/2f//6v/78c vx3PL78wz/xfKk//K18sbeoF6jIigfQy2MLxYP4s8HLT8SSD8XHnkxfiGSP/2FsHGvZy7+LZZhZW 5D/p9f/UpS1fLm8vf0GPBLfwv+VV29cyFgZm4zHXMmQVg+oy/+/lChT19gVB0+PZZShdka//Mv80 DzUfJ9MFQhfiG88+3/8/71H/Qg/nRAmiIoEi8w2PP6VPpl9MX46f0XNz0G9sg7TgsTAjZmY3N14A 99G/kPGj4DPS3Bdh9qYok/9OG09vUH9Rj2MfEpheLvV7/1YvVz9YT1lf0U/SX9NiFTj752YoYjlJ 30rvS/8sf2A//2FPdQ92HwTkSG8o8mavZ7//rW96365Pr1KMmHPBcP9zFvQ3MnnhcM0tuyBqYaHw /mTNLbzPvd+Fr7/+gNPBMt+Cz4PfhO+GP8dnMJahofH/tJF6X3+/jQWwoY3Pjt+CH/+Iv4nPlc+U gMBLyS+Rr8ft+ZxpMTO5LZiXgCvAHctS/80t8u/z/3t/fI99n36vmN//gM+Sb5N/lI+Vn5avl7+m f0uZ37sgOZr5NjG1YHYSYXCwZ261MHRvcF+bz5zfne+e/3TDPBkgaBhyZWa5AJtQdHA6iC8vd7iA LmFucNBJb4A0LlrwbS9a8DAoNTIvuaEwj/AzMuuboI/wLnAhIs6vu8uNcGhyZ2WbYV+NkLjAa6Fr XWllbGSpsma+wANwwMuge0hZUEVS8kzMUEsguA+5H7or0tCYXG59rTG/IXJzc1AzXQHnoHVs0tm2 j2ltEmdq0HJjt/15ZG0RwXEua3KNYWVodxRhL8ZRObqQZ2lmZ7rvyjywtjI2mvjSsDPlWtBiWyBk ZVsxm7ujH+uRD3L4OaeyYc1/o3+kj/+ln6avp7+oz6nfqu+sP9W//4gP2T/aT9ufjQ/Rn+B/kD// 4r/dv97P39+tlrYzsy/FHwfGL8c/yEk2MF90afp04dAzyROaZ2pQyV/awP2bFjOyEczfcGK+b79/ 7Z//7q/vuMN/xID5IOsvci9zP390TwSI0r/TxNAcedHkgSDfslU8oFow8zBrXHET8fqPXwFH4aPy 6Vrg9JBs/SBkzfUhZwZnoIBhYwc1a2v7/SE4UHC9cHDAXUDjIFyi/wwxBA/mn+ev6H/pi90C6o// +u8MP/4fDi+v37Dj73Ca+b41sh8QH+MuthMCBnKbMv9rWgOwDHAZX7b/wE/BX7ov/xPfvE+9X/RP 9V8fTyBfwq//w78dD+xf9j/H/m+AyQ8xH/XLKDUW2jRawfL/0b80z//QD9Ef0i/TP9RPNs/Wb9d/ /wtvDH8Nj6zfre88XxWfm4H/FuwYn7QftS+2P6AfoS81n/85PzpPO19E/z1/Po8/n0Cvv0G/Qs9D 31KvRf9rMDjL2f8Xj0gfTn9I/0oDcBYADwTv/zPZMH9m6wa/B88I3wnvW0//Vo9Xn29fFK8Pj1rv Ea8Sv+91v2/vW99c6DddmgaBXo97ck9KX3BmH37ff2YmcHlD4dAGYE1BUkcnAC0ATEVGVDogMG1n IdBVvUYjZm8CoC2Aaf56gLEzsCTMa7BP6CwvLT9/Lk8vWSEAMC+KrzGPFoM0/Zr4NcvRM+/0DyY/ h1+Ib/+Jdip/+j936Y3QVAGDMjhf/2BfT49Qn1GvlX9Tz20Pbh+/oM92r3DPGwCAf4GBNoHDP3t/ la+C/4QPhRlN0GM4tU3RZU3QYmrgqsA3qrT8ZjdzT59PdW+vX/7Wq0BuNE3QjkCrMTar8U3BY08r UKwAGtCqtGIyqrE15U3QZbERYjmzMQGgqzHnmlCqwLLhYmOr8bGRtCf7syGzkmNrgKtAHpC0BB7Q 36sxq6G3M7YxsxJisqa3wt8D0atAqyGyQLeUZRYgrE/frV+ub71fsIerIWOxkbICdmSz47YxZLcC udOrdGRPtbKxESswsOU5LqcMMfUBoWJx6lx6sCggnD/7avurMbIRZbLishG4MKqixzL/tPKyok3B q1OzYrU/q3Kz8tezoasSsgJhv0VhxzKzIv/KBgPQuj+7T7xf0F+wh6vi/7YysyFn8L/VyHO0scai wQP+MeNNw1/Eb8V/qzW1srYx+7mDs6FmFiC2BbKiq6LSw+/TkrHSsRHMA2Gr8ccytsL+Ysyvzb/O z+BP0O+rU7Yy78jGtfK0sbYiZdj/yhq0tfu/c7mVZrZztjK3wrjKvzv/tiLnQNqV0oLBH8Ivlp+Y 7/+Z/5sPnB+dL1RfVW+e75////d/op/ytXHS9M/13/bv+D/9eAcwHmEvQQXB7Z/xv/Qf//q/+8/9 X/kf+i8DfwSP/h/v/y8APwq/kEB2DB8NLwgv/wk/Ck+jtRsvpe+YmByvhf8/hw+SDy+kKaCJrzH7 Mzf9XYkzXlGOH48vkD8Zzxrf/xvmk++U/9Sv1b/xX94f3y8VEs5tKiUzBME8SU0ORzMGxkAZg0M6 ZG9sdDEcEzJFNUYxHwUw/wdNLc8ZdC9fMGsfzyDfIeT/Lzkk3yXvJv8oDykfKi8rPz8Sz0wPTR88 3xio51Boci+28Bm9PJA7QDQjQW0voSNQMDUyL0bhMA5A7DMyG/AOQC7wgXmgksBocmdlehFfZTAi 8Gt/FVtrUTYvIa9Fz0bfR+Rc/FxuOI85kEMvGK8ZvyM//3hxHA+MLF5AHhqNIR8P7g/rWH86bDny 4mEHTUFvQn//Wp8+RjVYXr8/P7CU7w/wFL9a3O0RC8NXiWjjPnBkSsHPaZGo0GdDXVBhY2fTWBv3 plA+catgcEjgZ9BJ8eeg/4TRPkFhXxC/Ec8/z3EPFY9/Xy9s32KPbs94L1ZDelJiGmdTcGxXoB9g I2U4/8yAeEAVXR5hFKEegGs/fQv/FIbSsKhAV9AVWhdQuQF6T7+njFT/gKuof6mPqpJi3RHeZaui 2TK5AquSZdNSsZL/csG5N7i4quGxQriztDLnon5is/LqAshHx4XMAMeFY/vdEbSiZN0Sq6LAUogW quH/hFCHH4gncf9zD3QfdO9cj/9dn1jqtJjYtYt2sgO/w78C/+oB2jvHM8xiYd+TX5RvOm//O388 j46fkj+RP7Balbu/1f+385gCsVKq4ulzsyFosKXF/7Qy6sLHdr+wqzXTUplEt5T+YbKihCXMQ7gF ywLAA+oC/+KG60yZn5qvm7+tj66fr69psL88QUTlbWqAoGBvMDpsY2hWgEdQQGsJV6BlYUzyP3N1 YjhqZWMekJWPpN0mYWZtsgBXkGR5t4Lb0Wb/0oLdU4P0suCM34gv0yXdEv+XN4kiyALTktOS3NJX YUk//0pPS1a1j7aft6+4vbnvuv//vA+9H74vvz/AQU7/UA+gL89Q31HvUv8bcmJ10qDtYJ9Ur9Xf 1hHVLx2FNjceKP+DIFd61xlYP1lPzy9bb+x//+2P2//hL+9/8I/dL/KvAY//a//Qv24fkh8G3+lP 6l/rr/8LH+Bv5c/m3+fv7c/u3/Bv/+zv9s/3328/cE/zD9AfoV/f/N92Xg5A3mB3imaE0KqQG2gh SvB58iAfYEJPUgJES1AtUklHSFREOiBIYGIoMndQLAGDIDMsODIpIDaccHjSMHfQHZA7IAZFmFRP UAcASNFjawgS8Qi3TEVGBv8IDwaBBkD6VAlATQr/DAjaOHi/ecP/9ID/H3tJ1y97/30PEa9/Kb+B r4K/s8+xr7K/FoFITRD2ZQCwSHAgDZBMTCNx/6//AL9irxpvG38cjyKPI58kr34vJa8mvyfPKP8q DysfIP5FwyIeEd7v3/8rj7RftW/7xB/HgjmrNI2DqmLJWxid/8F/wo80vzXPNt835s3fzu//Fw8T LxgfGS9AsTtvL+8w///iT0ivSb/dn96vF49D3xmv/yyPLZ8rf50vnj9Trx/vIP//Ig9HT0rfQM9O TmdAd9QJkx9PP+LRP9CkoVyXQ29wXHlyEQKptD/QIIMgMP/0gFEPUh9TL1pfW29l/9FZX8rgQl9q mfsQDbBl2TFf/QmRbl/daO9dr16/X89g3/9ukB6IRq9nr0oPaI9ML00//0HfQu5wr3G/YTtpb2R/ ZY84IEFsL6BiQw2gZXPxFPB2ZWStfVUPVh9mn/91T3ZfiP/jH+Qv5T/z7/T///YP+y/8P/k/+k+R 3/Fvif/3bp6XMzngdpffmO+Vz1ezfjWQcsdCj26c359v70Y3v48hhYKU7ckBoR+jp32lkAALAB8O AQAAAB4AcAABAAAAMwAAACggob6itKHGaSApIEF1ob5hoq9Bpeyp9qihQ6n4VSCir0Go+W+ir0Gl 7Kn2qKFDqfhVAAACAXEAAQAAABYAAAABwdYuMijheDtT2L1NE6u/vNo3zGHZAABAAAYOgPN5MS7W wQECAfk/AQAAAHoAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089TkVUQ09SRSBBQi9P VT1DT1JFL0NOPUNPTkZJR1VSQVRJT04vQ049Q09OTkVDVElPTlMvQ049SU5URVJORVQgTUFJTCBD T05ORUNUT1IgKFNXSVRDSENPUkUpAAAAHgD4PwEAAAAjAAAASW50ZXJuZXQgTWFpbCBTZXJ2aWNl IChTV0lUQ0hDT1JFKQAAHgA4QAEAAAAlAAAASU5URVJORVQgTUFJTCBDT05ORUNUT1IgKFNXSVRD SENPUkUpAAAAAAIB+z8BAAAANwAAAAAAAACBKx+kvqMQGZ1uAN0BD1QCAAABAEFJQUFFocwAU01U UABsY2g1MTAxQGtvcmVhLmNvbQAAHgD6PwEAAAAIAAAAQUlBQUWhzAAeADlAAQAAABIAAABsY2g1 MTAxQGtvcmVhLmNvbQAAAEAABzBs7igyLtbBAUAACDB8ebkzLtbBAR4APQABAAAAAQAAAAAAAAAe AB0OAQAAADMAAAAoIKG+orShxmkgKSBBdaG+YaKvQaXsqfaooUOp+FUgoq9BqPlvoq9Bpeyp9qih Q6n4VQAACwAbDgAAAAADACMOEiwFAB4ANRABAAAALQAAADwyMDAyMDMyODA3NTYuWEFBMjgxOTRA bndrZWEtbWFpbC0xLnN1bi5jb20+AAAAAAMA9A8GAAAAAwAIDl0ZAAADADYAAAAAAAsASmYAAAAA KVAAAAMABTcFAAAAQAAHMDBcuTMu1sEBQAAIMDBcuTMu1sEBAgH5DwEAAAAQAAAAXJ/HEhEpbUCj rXdSkqBHIts3Shc= ------_=_NextPart_000_01C1D62E.33BBDBD6-- From MAILER-DAEMON Wed Mar 27 23:57:24 2002 Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7vNKL016882 for ; Wed, 27 Mar 2002 23:57:23 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13064 for ; Wed, 27 Mar 2002 23:57:24 -0800 (PST) Received: from quantumexch.qb.local (gatekeeper.quantumbridge.com [63.165.82.130]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17872 for ; Thu, 28 Mar 2002 00:57:24 -0700 (MST) Received: by QUANTUMEXCH with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 02:48:05 -0500 Message-ID: <36FB26FEDE20D511BA9C00508BE050B401F2A566@QUANTUMEXCH> From: postmaster@quantumbridge.com To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 02:48:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62C.E484ECCA" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62C.E484ECCA Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 02:56:02 -0500 did not reach the following recipient(s): MKaycee@quantumbridge.com on Thu, 28 Mar 2002 02:48:04 -0500 The recipient name is not recognized The MTS-ID of the original message is: c=3Dus;a=3D ;p=3Dquantum bridge c;l=3DQUANTUMEXCH0203280748HY1K877Y MSEXCH:IMS:Quantum Bridge COmmunications:QUANTUM:QUANTUMEXCH 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D62C.E484ECCA Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: lch5101@korea.com To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 02:56:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D62C.E484ECCA-- From MAILER-DAEMON Wed Mar 27 23:57:39 2002 Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7vdKL016896 for ; Wed, 27 Mar 2002 23:57:39 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13141 for ; Wed, 27 Mar 2002 23:57:35 -0800 (PST) Received: from kings.mei.co.jp (bulls.mei.co.jp [202.224.189.25]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28400 for ; Wed, 27 Mar 2002 23:57:36 -0800 (PST) Received: by kings.mei.co.jp (8.12.2/3.7W/bulls) with ESMTP id g2S7vXvm011977 for ; Thu, 28 Mar 2002 16:57:33 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/bluejays) id g2S7vXA11279; Thu, 28 Mar 2002 16:57:33 +0900 (JST) Date: Thu, 28 Mar 2002 16:57:33 +0900 (JST) From: Mail Delivery Subsystem Subject: Returned mail: see transcript for details Message-Id: <200203280757.g2S7vXA11279@mail.jp.panasonic.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="g2S7vXA11279.1017302253/mail.jp.panasonic.com" Content-Transfer-Encoding: 8bit Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --g2S7vXA11279.1017302253/mail.jp.panasonic.com The original message was received at Thu, 28 Mar 2002 16:57:32 +0900 (JST) from localhost [127.0.0.1] ----- The following addresses had permanent fatal errors ----- (reason: 554 Invalid data in message) ----- Transcript of session follows ----- ... while talking to [133.183.66.131]: >>> DATA <<< 554 Invalid data in message 554 5.0.0 Service unavailable --g2S7vXA11279.1017302253/mail.jp.panasonic.com Content-Type: message/delivery-status Reporting-MTA: dns; mail.jp.panasonic.com Received-From-MTA: DNS; localhost Arrival-Date: Thu, 28 Mar 2002 16:57:32 +0900 (JST) Final-Recipient: RFC822; J.Sakai@rdmg.mgcs.mei.co.jp Action: failed Status: 5.0.0 Remote-MTA: DNS; [133.183.66.131] Diagnostic-Code: SMTP; 554 Invalid data in message Last-Attempt-Date: Thu, 28 Mar 2002 16:57:33 +0900 (JST) --g2S7vXA11279.1017302253/mail.jp.panasonic.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: by mail.jp.panasonic.com (8.11.6/3.7W/bluejays) with ESMTP id g2S7vWA11273; Thu, 28 Mar 2002 16:57:32 +0900 (JST) Received: by kings.mei.co.jp (8.12.2/3.7W/jazz) with ESMTP id g2S7vV5r014329; Thu, 28 Mar 2002 16:57:32 +0900 (JST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27618; Wed, 27 Mar 2002 23:56:50 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12964; Wed, 27 Mar 2002 23:56:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--g2S7vXA11279.1017302253/mail.jp.panasonic.com-- From MAILER-DAEMON Wed Mar 27 23:57:37 2002 Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7vbKL016894 for ; Wed, 27 Mar 2002 23:57:37 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13303 for ; Wed, 27 Mar 2002 23:57:38 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23833 for ; Thu, 28 Mar 2002 00:57:37 -0700 (MST) Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2S7vakY024598 for ; Thu, 28 Mar 2002 08:57:36 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Mar 28 08:57:35 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 08:57:35 +0100 Message-ID: From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 08:57:35 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62E.38D5D6E4" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62E.38D5D6E4 Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 08:56:02 +0100 did not reach the following recipient(s): MUSHABBAR.SADIQSYED@era.ericsson.se on Thu, 28 Mar 2002 08:55:43 +0100 The recipient name is not recognized The MTS-ID of the original message is: = c=3Dse;a=3D400net;p=3Dericsson;l=3DESEALNT4570203280755F4G5GKK0 MSEXCH:IMS:Ericsson:SE0:ESEALNT457 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D62E.38D5D6E4 Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 08:56:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiAgIDxodHRwOi8v d3d3LmFueWRtLmNvLmtyL3RhZWh3YS9pbWc0MF90aXRsZTEuZ2lmPiANCg0KDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KIA0KDQogPGh0dHA6 Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0KDQrIrby6xsez 2sDHIDIws+IgsObH6LD6ILHivPq3ziDAzLfox9izvSANCr/4uPG4trfnwOe3zrytIL/Ctbm56Lyx sPogv/i48bi2t+ewoSDAz8O8yK21x77uDQqx4sG4IMLKuLa35yC9w7D4sPq0wiC03riuIL3DsPjA zCCwo8btx8+w7SC+yMD8DQrHz7jnIL/uwPu/3LyxwLi3ziCwx7CtsKHB9iC7/bCix8+0wiANCrG5 s7sgw9bDysDHIMavx+PA58DUtM+02S4NCg0KICA8aHR0cDovL3d3dy5hbnlkbS5jby5rci90YWVo d2EvaW1nNTBfdGl0bGUyLmdpZj4gDQoNCg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3Rh ZWh3YS9pbWcxMDAuZ2lmPiANCg0KDQqx4sG4wMcgw7bGx8bHs9q/obytILOquasox9XGxynGx7Pa t84gsLO537XHvu4gurm757+tt84gwM7H0SDIxrHisKEgsKG15sfPv6kgwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxyDAp8fowMwgvvi+7iDD1rDt wMcgvsjA/Ly6wLsgyK66uMfPv7S9wLTPtNkuDQoNCry8tvO5zSwgwvy9obD6ILOquavAxyCw4cfV wLi3ziDAzsO8wMcgwK/AzcfRIL/4wPu/3CC8scC7ILnmw+LH1bTPtNkuIA0KvcOw+MDMILCjxu3H z7+pILTnwM+9w7D4ILTnwM+zrbnmwMwgsKG0yQ0Kx9W0z7TZDQoNCiANCg0KIDxodHRwOi8vd3d3 LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogIDxodHRwOi8vd3d3LmFu eWRtLmNvLmtyL3RhZWh3YS9pbWc2MF90aXRsZTMuZ2lmPiANCg0KDQogPGh0dHA6Ly93d3cuYW5u ZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCiANCg0KDQogIDxodHRwOi8vd3d3 LmFueWRtLmNvLmtyL3RhZWh3YS9pbWcxMjAuZ2lmPiANCg0KyK69x8j3ILTetvPB+CDIssXkueYg v8K89r/CtbnAuiC/77e3sMW4ssDMIL74sO0gvsbB1iCw37Dtx9W0z7TZLg0KseLBuCDBtrizvcS/ wrW5wMcgua7BpsGhtenAzCC48LXOILCzvLHH0SANCr3FsPi5/SDAuLfOILyzxKG68b/rwMwgvcC9 xLnMwOWw+Ln9wMcgvPbB2LD6ILCwwMwgvsbB1iDA+rfFx9W0z7TZLg0KDQogIDxodHRwOi8vd3d3 LmFueWRtLmNvLmtyL3RhZWh3YS9pbWcxMzAuZ2lmPiANCiAgPEM6ZG90MS5naWY+IA0KICAgPGh0 dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gICANCg0KDQq758D8 IMfjtvQgvvjAzCC43sDPwLsgurizvSDBoSDBy7zbx8+/wLjnILjewM/AuyAgvPa9xcfPwfYgvsrA uLfBuOkgIA0KvPa9xSCwxbrOuKYgxay4r8fYIMHWvcO46SCwqLvnteW4rrDavcC0z7TZLiAgICAg PG1haWx0bzpsY2g1MTAxQGtvcmVhLmNvbT9zdWJqZWN0Pbz2vcWwxbrOJmJvZHk9tPXAzLvzILje wM/AuyC6uLO7wfYguLa8vL/kPiANCg0KDQogSG9tZXBhZ2UgOiB3d3cuYW5uZTExNC5jby5rciAg IC8gICBFbWFpbCA6ICA8bWFpbHRvOmxjaDUxMDFAa29yZWEuY29tP3N1YmplY3Q9ua7Ax7jewM8+ IGxjaDUxMDFAa29yZWEuY29tIA0KQ29weXJpZ2h0qM8gMjAwMiAgYW5uZTExNC5jb20gIEFsbCBy aWdodCByZXNlcnZlZC4gDQoNCg0K ------_=_NextPart_000_01C1D62E.38D5D6E4-- From MAILER-DAEMON Wed Mar 27 23:57:43 2002 Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7vgKL016900 for ; Wed, 27 Mar 2002 23:57:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13156 for ; Wed, 27 Mar 2002 23:57:44 -0800 (PST) Received: from tpamail2.bdi.gte.com (tpamail2.bdi.gte.com [192.76.82.136]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA11407 for ; Thu, 28 Mar 2002 00:57:43 -0700 (MST) Received: from smtptpa.interwan.gte.com ([138.83.66.45]) by tpamail2.bdi.gte.com (8.9.3/8.9.3) with ESMTP id CAA14984 for ; Thu, 28 Mar 2002 02:57:42 -0500 (EST) Received: from smtptpa.interwan.gte.com (localhost [127.0.0.1]) by smtptpa.interwan.gte.com (8.9.3/8.9.3) with ESMTP id CAA21687 for ; Thu, 28 Mar 2002 02:57:42 -0500 (EST) Received: from blackberry.ap.bdi.gte.com (blackberry.ap.bdi.gte.com [192.76.64.54]) by smtptpa.interwan.gte.com (8.9.3/8.9.3) with ESMTP id CAA21683 for ; Thu, 28 Mar 2002 02:57:41 -0500 (EST) Received: by blackberry.ap.bdi.gte.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 01:57:25 -0600 Message-ID: <651039283A1ED5118FBE000629135ABE014E56F7@blackberry.ap.bdi.gte.com> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 01:57:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62E.32D86D2E" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62E.32D86D2E Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 01:56:02 -0600 did not reach the following recipient(s): Min.Xie@ap.bdi.gte.com on Thu, 28 Mar 2002 01:57:11 -0600 The recipient name is not recognized The MTS-ID of the original message is: c=3Dus;a=3D ;p=3Dgte;l=3DBLACKBERRY0203280757HRY0S6HB MSEXCH:IMS:GTE:TESTBED:BLACKBERRY 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D62E.32D86D2E Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 01:56:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D62E.32D86D2E-- From MAILER-DAEMON Wed Mar 27 23:57:41 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7vfKL016898 for ; Wed, 27 Mar 2002 23:57:41 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04756 for ; Wed, 27 Mar 2002 23:57:42 -0800 (PST) Received: from polaris-xch.sisa.samsung.com ([67.17.176.250]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28423 for ; Wed, 27 Mar 2002 23:57:43 -0800 (PST) Received: by polaris-xch.ssi.samsung.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 23:58:48 -0800 Message-ID: <7DFF75861D2FD311955700A0C9E5FF5703784113@polaris-xch.ssi.samsung.com> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?EUC-KR?B?VW5kZWxpdmVyYWJsZTogKCCxpLDtICkgwPyx4r/CtbnGx7PaIL/C?= =?EUC-KR?B?vPa/wrW5xsez2g==?= Date: Wed, 27 Mar 2002 23:58:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62E.63E5EEDC" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62E.63E5EEDC Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=B4=D4 Subject: ( =B1=A4=B0=ED ) =C0=FC=B1=E2=BF=C2=B5=B9=C6=C7=B3=DA = =BF=C2=BC=F6=BF=C2=B5=B9=C6=C7=B3=DA Sent: Wed, 27 Mar 2002 23:56:02 -0800 did not reach the following recipient(s): Rwolff@sisa.samsung.com on Wed, 27 Mar 2002 23:58:43 -0800 The recipient name is not recognized The MTS-ID of the original message is: c=3Dus;a=3D ;p=3Dsamsung ;l=3DPOLARIS_XCH0203280758H3KXDACS MSEXCH:IMS:Samsung Semiconductor:SISA:POLARIS_XCH 0 (000C05A6) = Unknown Recipient ------_=_NextPart_000_01C1D62E.63E5EEDC Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?EUC-KR?B?wMzFwsij?= To: =?EUC-KR?B?aXBuZy1kaXN0tNQ=?= Subject: =?EUC-KR?B?KCCxpLDtICkgwPyx4r/CtbnGx7PaIL/CvPa/wrW5xsez2g==?= Date: Wed, 27 Mar 2002 23:56:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D62E.63E5EEDC-- From MAILER-DAEMON Wed Mar 27 23:57:44 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7viKL016902 for ; Wed, 27 Mar 2002 23:57:44 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA26965 for ; Wed, 27 Mar 2002 23:57:45 -0800 (PST) Received: from localhost (localhost) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with internal id AAA23554; Thu, 28 Mar 2002 00:57:45 -0700 (MST) Date: Thu, 28 Mar 2002 00:57:45 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203280757.AAA23554@kathmandu.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="AAA23554.1017302265/kathmandu.sun.com" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --AAA23554.1017302265/kathmandu.sun.com The original message was received at Thu, 28 Mar 2002 00:56:46 -0700 (MST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to bells.cs.ucl.ac.uk.: >>> DATA <<< 554 Syntactically invalid address for from field 'ÀÌŠȣ ' 554 ... Service unavailable --AAA23554.1017302265/kathmandu.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; kathmandu.sun.com Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Thu, 28 Mar 2002 00:56:46 -0700 (MST) Final-Recipient: RFC822; T.Pagtzis@cs.ucl.ac.uk Action: failed Status: 5.0.0 Remote-MTA: DNS; bells.cs.ucl.ac.uk Diagnostic-Code: SMTP; 554 Syntactically invalid address for from field 'ÀÌŠȣ ' Last-Attempt-Date: Thu, 28 Mar 2002 00:56:55 -0700 (MST) --AAA23554.1017302265/kathmandu.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23534; Thu, 28 Mar 2002 00:56:46 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12957; Wed, 27 Mar 2002 23:56:44 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--AAA23554.1017302265/kathmandu.sun.com-- From MAILER-DAEMON Wed Mar 27 23:57:48 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7vmKL016907 for ; Wed, 27 Mar 2002 23:57:48 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04772 for ; Wed, 27 Mar 2002 23:57:49 -0800 (PST) Received: from mx2.andrew.cmu.edu (MX2.ANDREW.CMU.EDU [128.2.10.112]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17973 for ; Thu, 28 Mar 2002 00:57:49 -0700 (MST) Received: from localhost (localhost) by mx2.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) id g2S7vl5t030282; Thu, 28 Mar 2002 02:57:47 -0500 Date: Thu, 28 Mar 2002 02:57:47 -0500 From: Mail Delivery Subsystem Message-Id: <200203280757.g2S7vl5t030282@mx2.andrew.cmu.edu> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="g2S7vl5t030282.1017302267/mx2.andrew.cmu.edu" Content-Transfer-Encoding: 8bit Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --g2S7vl5t030282.1017302267/mx2.andrew.cmu.edu The original message was received at Thu, 28 Mar 2002 02:57:47 -0500 from mercury.Sun.COM [192.9.25.1] ----- The following addresses had permanent fatal errors ----- (reason: 554 5.6.0 Message contains non-ASCII characters in headers) (reason: 554 5.6.0 Message contains non-ASCII characters in headers) ----- Transcript of session follows ----- ... while talking to mail1.andrew.cmu.edu.: >>> DATA <<< 554 5.6.0 Message contains non-ASCII characters in headers 554 5.0.0 Service unavailable (Message contains non-ASCII characters in headers) <<< 554 5.6.0 Message contains non-ASCII characters in headers 554 5.0.0 Service unavailable (Message contains non-ASCII characters in headers) --g2S7vl5t030282.1017302267/mx2.andrew.cmu.edu Content-Type: message/delivery-status Reporting-MTA: dns; mx2.andrew.cmu.edu Received-From-MTA: DNS; mercury.Sun.COM Arrival-Date: Thu, 28 Mar 2002 02:57:47 -0500 Final-Recipient: RFC822; arpalists+computing.ietf.ipng@andrew.cmu.edu X-Actual-Recipient: RFC822; bb+internet.computing.ietf.ipng@mx2.andrew.cmu.edu Action: failed Status: 5.6.0 Diagnostic-Code: X-Unix; 554 5.6.0 Message contains non-ASCII characters in headers Last-Attempt-Date: Thu, 28 Mar 2002 02:57:47 -0500 Final-Recipient: RFC822; grm@andrew.cmu.edu X-Actual-Recipient: RFC822; grm@mx2.andrew.cmu.edu Action: failed Status: 5.6.0 Diagnostic-Code: X-Unix; 554 5.6.0 Message contains non-ASCII characters in headers Last-Attempt-Date: Thu, 28 Mar 2002 02:57:47 -0500 --g2S7vl5t030282.1017302267/mx2.andrew.cmu.edu Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mx2.andrew.cmu.edu (8.12.3.Beta2/8.12.3.Beta2) with ESMTP id g2S7vk5t030277; Thu, 28 Mar 2002 02:57:47 -0500 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27713; Wed, 27 Mar 2002 23:57:38 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13057; Wed, 27 Mar 2002 23:57:23 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 X-Spam-Warning: SpamAssassin says this message is SPAM Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--g2S7vl5t030282.1017302267/mx2.andrew.cmu.edu-- From MAILER-DAEMON Wed Mar 27 23:57:55 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7vtKL016910 for ; Wed, 27 Mar 2002 23:57:55 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04817 for ; Wed, 27 Mar 2002 23:57:56 -0800 (PST) Received: from bnls901a ([194.42.253.17]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id AAA23912 for ; Thu, 28 Mar 2002 00:57:55 -0700 (MST) Received: by bnls205a.sni.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 07:58:19 -0000 Message-ID: From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 07:58:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62E.531A6344" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62E.531A6344 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 07:56:02 -0000 did not reach the following recipient(s): MOSTHAVM@plcman.siemens.co.uk on Thu, 28 Mar 2002 07:58:15 -0000 The recipient name is not recognized The MTS-ID of the original message is: c=3Dgb;a=3Dattmail;p=3Dscn;l=3DBNLS205A0203280758HP7PDMQ3 MSEXCH:IMS:SCN:GBBNLS201E:BNLS205A 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D62E.531A6344 Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 07:56:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D62E.531A6344-- From MAILER-DAEMON Wed Mar 27 23:57:29 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7vSKL016886 for ; Wed, 27 Mar 2002 23:57:29 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA26923 for ; Wed, 27 Mar 2002 23:57:30 -0800 (PST) Received: from localhost (localhost) by patan.sun.com (8.9.3+Sun/8.9.3) with internal id AAA29391; Thu, 28 Mar 2002 00:57:30 -0700 (MST) Date: Thu, 28 Mar 2002 00:57:30 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203280757.AAA29391@patan.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="AAA29391.1017302250/patan.sun.com" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --AAA29391.1017302250/patan.sun.com The original message was received at Thu, 28 Mar 2002 00:56:45 -0700 (MST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to bells.cs.ucl.ac.uk.: >>> DATA <<< 554 Syntactically invalid address for from field 'ÀÌŠȣ ' 554 ... Service unavailable --AAA29391.1017302250/patan.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; patan.sun.com Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Thu, 28 Mar 2002 00:56:45 -0700 (MST) Final-Recipient: RFC822; A.Ghosh@cs.ucl.ac.uk Action: failed Status: 5.0.0 Remote-MTA: DNS; bells.cs.ucl.ac.uk Diagnostic-Code: SMTP; 554 Syntactically invalid address for from field 'ÀÌŠȣ ' Last-Attempt-Date: Thu, 28 Mar 2002 00:57:24 -0700 (MST) --AAA29391.1017302250/patan.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29384; Thu, 28 Mar 2002 00:56:45 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12915; Wed, 27 Mar 2002 23:56:37 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--AAA29391.1017302250/patan.sun.com-- From MAILER-DAEMON Wed Mar 27 23:57:58 2002 Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7vvKL016918 for ; Wed, 27 Mar 2002 23:57:57 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13331 for ; Wed, 27 Mar 2002 23:57:58 -0800 (PST) Received: from mail.primustel.com (mail.primustel.com [209.227.166.140]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28474 for ; Wed, 27 Mar 2002 23:57:59 -0800 (PST) Received: by EX_PRIMUS with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 03:00:28 -0500 Message-ID: From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 03:00:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62E.9F67ED34" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62E.9F67ED34 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 02:56:02 -0500 did not reach the following recipient(s): WTu@PRIMUSTEL.com on Thu, 28 Mar 2002 03:00:22 -0500 The recipient name is not recognized The MTS-ID of the original message is: c=3Dus;a=3D ;p=3Dprimus telecommu;l=3DEX_PRIMUS0203280800H3Y4KM4S MSEXCH:IMS:Primus Telecommunication:PRIMUS:EX_PRIMUS 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D62E.9F67ED34 Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 02:56:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D62E.9F67ED34-- From MAILER-DAEMON Wed Mar 27 23:58:10 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7wAKL016926 for ; Wed, 27 Mar 2002 23:58:10 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04841 for ; Wed, 27 Mar 2002 23:58:11 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18091 for ; Thu, 28 Mar 2002 00:58:10 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2S7w9oq015224 for ; Thu, 28 Mar 2002 08:58:09 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Mar 28 08:58:08 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 08:58:08 +0100 Message-ID: From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 08:58:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62E.4C39B6D8" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62E.4C39B6D8 Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 08:56:02 +0100 did not reach the following recipient(s): Pablo.Cebrian@ex1.etx.ericsson.se on Thu, 28 Mar 2002 08:55:53 +0100 The recipient name is not recognized The MTS-ID of the original message is: = c=3Dse;a=3D400net;p=3Dericsson;l=3DESEALNT4580203280755F4GYN2Q4 MSEXCH:IMS:Ericsson:SE0:ESEALNT458 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D62E.4C39B6D8 Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 08:56:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiAgIDxodHRwOi8v d3d3LmFueWRtLmNvLmtyL3RhZWh3YS9pbWc0MF90aXRsZTEuZ2lmPiANCg0KDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KIA0KDQogPGh0dHA6 Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0KDQrIrby6xsez 2sDHIDIws+IgsObH6LD6ILHivPq3ziDAzLfox9izvSANCr/4uPG4trfnwOe3zrytIL/Ctbm56Lyx sPogv/i48bi2t+ewoSDAz8O8yK21x77uDQqx4sG4IMLKuLa35yC9w7D4sPq0wiC03riuIL3DsPjA zCCwo8btx8+w7SC+yMD8DQrHz7jnIL/uwPu/3LyxwLi3ziCwx7CtsKHB9iC7/bCix8+0wiANCrG5 s7sgw9bDysDHIMavx+PA58DUtM+02S4NCg0KICA8aHR0cDovL3d3dy5hbnlkbS5jby5rci90YWVo d2EvaW1nNTBfdGl0bGUyLmdpZj4gDQoNCg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3Rh ZWh3YS9pbWcxMDAuZ2lmPiANCg0KDQqx4sG4wMcgw7bGx8bHs9q/obytILOquasox9XGxynGx7Pa t84gsLO537XHvu4gurm757+tt84gwM7H0SDIxrHisKEgsKG15sfPv6kgwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxyDAp8fowMwgvvi+7iDD1rDt wMcgvsjA/Ly6wLsgyK66uMfPv7S9wLTPtNkuDQoNCry8tvO5zSwgwvy9obD6ILOquavAxyCw4cfV wLi3ziDAzsO8wMcgwK/AzcfRIL/4wPu/3CC8scC7ILnmw+LH1bTPtNkuIA0KvcOw+MDMILCjxu3H z7+pILTnwM+9w7D4ILTnwM+zrbnmwMwgsKG0yQ0Kx9W0z7TZDQoNCiANCg0KIDxodHRwOi8vd3d3 LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogIDxodHRwOi8vd3d3LmFu eWRtLmNvLmtyL3RhZWh3YS9pbWc2MF90aXRsZTMuZ2lmPiANCg0KDQogPGh0dHA6Ly93d3cuYW5u ZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCiANCg0KDQogIDxodHRwOi8vd3d3 LmFueWRtLmNvLmtyL3RhZWh3YS9pbWcxMjAuZ2lmPiANCg0KyK69x8j3ILTetvPB+CDIssXkueYg v8K89r/CtbnAuiC/77e3sMW4ssDMIL74sO0gvsbB1iCw37Dtx9W0z7TZLg0KseLBuCDBtrizvcS/ wrW5wMcgua7BpsGhtenAzCC48LXOILCzvLHH0SANCr3FsPi5/SDAuLfOILyzxKG68b/rwMwgvcC9 xLnMwOWw+Ln9wMcgvPbB2LD6ILCwwMwgvsbB1iDA+rfFx9W0z7TZLg0KDQogIDxodHRwOi8vd3d3 LmFueWRtLmNvLmtyL3RhZWh3YS9pbWcxMzAuZ2lmPiANCiAgPEM6ZG90MS5naWY+IA0KICAgPGh0 dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gICANCg0KDQq758D8 IMfjtvQgvvjAzCC43sDPwLsgurizvSDBoSDBy7zbx8+/wLjnILjewM/AuyAgvPa9xcfPwfYgvsrA uLfBuOkgIA0KvPa9xSCwxbrOuKYgxay4r8fYIMHWvcO46SCwqLvnteW4rrDavcC0z7TZLiAgICAg PG1haWx0bzpsY2g1MTAxQGtvcmVhLmNvbT9zdWJqZWN0Pbz2vcWwxbrOJmJvZHk9tPXAzLvzILje wM/AuyC6uLO7wfYguLa8vL/kPiANCg0KDQogSG9tZXBhZ2UgOiB3d3cuYW5uZTExNC5jby5rciAg IC8gICBFbWFpbCA6ICA8bWFpbHRvOmxjaDUxMDFAa29yZWEuY29tP3N1YmplY3Q9ua7Ax7jewM8+ IGxjaDUxMDFAa29yZWEuY29tIA0KQ29weXJpZ2h0qM8gMjAwMiAgYW5uZTExNC5jb20gIEFsbCBy aWdodCByZXNlcnZlZC4gDQoNCg0K ------_=_NextPart_000_01C1D62E.4C39B6D8-- From MAILER-DAEMON Wed Mar 27 23:58:22 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7wLKL016934 for ; Wed, 27 Mar 2002 23:58:22 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04865 for ; Wed, 27 Mar 2002 23:58:21 -0800 (PST) Received: from correo.teldat.es ([212.95.195.134]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18138 for ; Thu, 28 Mar 2002 00:58:20 -0700 (MST) Received: by CORREO with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 09:10:29 +0100 Message-ID: <41FAD0CB3B6BD3118BE600C04F43DB20010867DA@CORREO> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: Undeliverable: ( 1$0m ) @|1b?B59FG3Z ?B From: "@LEBH#" To: ipng-dist4T Subject: ( 1$0m ) @|1b?B59FG3Z ?B; Wed, 27 Mar 2002 23:58:24 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04870 for ; Wed, 27 Mar 2002 23:58:23 -0800 (PST) Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA11674 for ; Thu, 28 Mar 2002 00:58:21 -0700 (MST) Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id SAA11186 for ; Thu, 28 Mar 2002 18:58:20 +1100 (EST) Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdePAH8_; Thu Mar 28 18:58:05 2002 Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id SAA12233 for ; Thu, 28 Mar 2002 18:58:04 +1100 (EST) Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdPSj3__; Thu Mar 28 18:57:53 2002 Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id SAA22314 for ; Thu, 28 Mar 2002 18:57:53 +1100 (EST) Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2655.55) id ; Thu, 28 Mar 2002 18:57:52 +1100 Message-ID: From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: Undeliverable: ( 1$0? ) ?|1??B59F??? ?B From: ???B?? To: ipng-dist4? Subject: ( 1$0? ) ?|1??B59F??? ?B; Wed, 27 Mar 2002 23:58:18 -0800 (PST) Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04856 for ; Wed, 27 Mar 2002 23:58:19 -0800 (PST) Received: from localhost (localhost) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with internal id XAA27621; Wed, 27 Mar 2002 23:58:19 -0800 (PST) Date: Wed, 27 Mar 2002 23:58:19 -0800 (PST) From: Mail Delivery Subsystem Message-Id: <200203280758.XAA27621@mercury.Sun.COM> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="XAA27621.1017302299/mercury.Sun.COM" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --XAA27621.1017302299/mercury.Sun.COM The original message was received at Wed, 27 Mar 2002 23:56:50 -0800 (PST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to bells.cs.ucl.ac.uk.: >>> DATA <<< 554 Syntactically invalid address for from field 'ÀÌŠȣ ' 554 ... Service unavailable ... Deferred: Connection timed out with kcmsi1.att.com. --XAA27621.1017302299/mercury.Sun.COM Content-Type: message/delivery-status Reporting-MTA: dns; mercury.Sun.COM Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Wed, 27 Mar 2002 23:56:50 -0800 (PST) Final-Recipient: RFC822; P.OHanlon@cs.ucl.ac.uk Action: failed Status: 5.0.0 Remote-MTA: DNS; bells.cs.ucl.ac.uk Diagnostic-Code: SMTP; 554 Syntactically invalid address for from field 'ÀÌŠȣ ' Last-Attempt-Date: Wed, 27 Mar 2002 23:57:43 -0800 (PST) --XAA27621.1017302299/mercury.Sun.COM Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27618; Wed, 27 Mar 2002 23:56:50 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12964; Wed, 27 Mar 2002 23:56:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--XAA27621.1017302299/mercury.Sun.COM-- From MAILER-DAEMON Wed Mar 27 23:58:33 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7wVKL016949 for ; Wed, 27 Mar 2002 23:58:33 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04879 for ; Wed, 27 Mar 2002 23:58:27 -0800 (PST) Received: from kings.mei.co.jp (kings.mei.co.jp [202.224.189.27]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28538 for ; Wed, 27 Mar 2002 23:58:28 -0800 (PST) Received: by kings.mei.co.jp (8.12.2/3.7W/kings) with ESMTP id g2S7wP0X002417 for ; Thu, 28 Mar 2002 16:58:25 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) id g2S7wPI12532; Thu, 28 Mar 2002 16:58:25 +0900 (JST) Date: Thu, 28 Mar 2002 16:58:25 +0900 (JST) From: Mail Delivery Subsystem Subject: Returned mail: see transcript for details Message-Id: <200203280758.g2S7wPI12532@mail.jp.panasonic.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="g2S7wPI12532.1017302305/mail.jp.panasonic.com" Content-Transfer-Encoding: 8bit Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --g2S7wPI12532.1017302305/mail.jp.panasonic.com The original message was received at Thu, 28 Mar 2002 16:58:25 +0900 (JST) from localhost [127.0.0.1] ----- The following addresses had permanent fatal errors ----- (reason: 554 Invalid data in message) ----- Transcript of session follows ----- ... while talking to [133.183.66.131]: >>> DATA <<< 554 Invalid data in message 554 5.0.0 Service unavailable --g2S7wPI12532.1017302305/mail.jp.panasonic.com Content-Type: message/delivery-status Reporting-MTA: dns; mail.jp.panasonic.com Received-From-MTA: DNS; localhost Arrival-Date: Thu, 28 Mar 2002 16:58:25 +0900 (JST) Final-Recipient: RFC822; segawa@rdmg.mgcs.mei.co.jp Action: failed Status: 5.0.0 Remote-MTA: DNS; [133.183.66.131] Diagnostic-Code: SMTP; 554 Invalid data in message Last-Attempt-Date: Thu, 28 Mar 2002 16:58:25 +0900 (JST) --g2S7wPI12532.1017302305/mail.jp.panasonic.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) with ESMTP id g2S7wPI12526 for ; Thu, 28 Mar 2002 16:58:25 +0900 (JST) Received: by kings.mei.co.jp (8.12.2/3.7W/jazz) with ESMTP id g2S7wN5r014936 for ; Thu, 28 Mar 2002 16:58:24 +0900 (JST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29545; Thu, 28 Mar 2002 00:57:11 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12990; Wed, 27 Mar 2002 23:57:03 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--g2S7wPI12532.1017302305/mail.jp.panasonic.com-- From MAILER-DAEMON Wed Mar 27 23:58:21 2002 Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7wKKL016933 for ; Wed, 27 Mar 2002 23:58:20 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13351 for ; Wed, 27 Mar 2002 23:58:21 -0800 (PST) Received: from mx-relay2.treas.gov (mx-relay2.treas.gov [199.196.144.6]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28533 for ; Wed, 27 Mar 2002 23:58:22 -0800 (PST) Received: from localhost (localhost) by mx-relay2.treas.gov (8.11.6+Sun/8.11.6) id g2S7usl16757; Thu, 28 Mar 2002 02:56:54 -0500 (EST) Date: Thu, 28 Mar 2002 02:56:54 -0500 (EST) From: Mail Delivery Subsystem Message-Id: <200203280756.g2S7usl16757@mx-relay2.treas.gov> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="g2S7usl16757.1017302214/mx-relay2.treas.gov" Content-Transfer-Encoding: 8bit Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --g2S7usl16757.1017302214/mx-relay2.treas.gov The original message was received at Thu, 28 Mar 2002 02:56:53 -0500 (EST) from kathmandu.sun.com [192.18.98.36] ----- The following addresses had permanent fatal errors ----- (reason: 554 Invalid data in message) ----- Transcript of session follows ----- ... while talking to tias-mailgw.treas.gov.: >>> DATA <<< 554 Invalid data in message 554 5.0.0 Service unavailable --g2S7usl16757.1017302214/mx-relay2.treas.gov Content-Type: message/delivery-status Reporting-MTA: dns; mx-relay2.treas.gov Received-From-MTA: DNS; kathmandu.sun.com Arrival-Date: Thu, 28 Mar 2002 02:56:53 -0500 (EST) Final-Recipient: RFC822; LMPham@atfhq.atf.treas.gov Action: failed Status: 5.0.0 Remote-MTA: DNS; tias-mailgw.treas.gov Diagnostic-Code: SMTP; 554 Invalid data in message Last-Attempt-Date: Thu, 28 Mar 2002 02:56:54 -0500 (EST) --g2S7usl16757.1017302214/mx-relay2.treas.gov Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by mx-relay2.treas.gov (8.11.6+Sun/8.11.6) with ESMTP id g2S7url16755 for ; Thu, 28 Mar 2002 02:56:53 -0500 (EST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23556; Thu, 28 Mar 2002 00:56:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12957; Wed, 27 Mar 2002 23:56:44 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--g2S7usl16757.1017302214/mx-relay2.treas.gov-- From MAILER-DAEMON Wed Mar 27 23:58:57 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7wuKL016973 for ; Wed, 27 Mar 2002 23:58:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA27123 for ; Wed, 27 Mar 2002 23:58:55 -0800 (PST) Received: from localhost (localhost) by pheriche.sun.com (8.9.3+Sun/8.9.3) with internal id AAA18090; Thu, 28 Mar 2002 00:58:54 -0700 (MST) Date: Thu, 28 Mar 2002 00:58:54 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203280758.AAA18090@pheriche.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="AAA18090.1017302334/pheriche.sun.com" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --AAA18090.1017302334/pheriche.sun.com The original message was received at Thu, 28 Mar 2002 00:56:53 -0700 (MST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- 451 ... as.airnet.ne.jp: Name server timeout ... while talking to mail.myersinfosys.com.: >>> DATA <<< 554 Invalid data in message 554 ... Service unavailable --AAA18090.1017302334/pheriche.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; pheriche.sun.com Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Thu, 28 Mar 2002 00:56:53 -0700 (MST) Final-Recipient: RFC822; mstiles@myersinfosys.com Action: failed Status: 5.0.0 Remote-MTA: DNS; mail.myersinfosys.com Diagnostic-Code: SMTP; 554 Invalid data in message Last-Attempt-Date: Thu, 28 Mar 2002 00:58:36 -0700 (MST) --AAA18090.1017302334/pheriche.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17688; Thu, 28 Mar 2002 00:56:53 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12971; Wed, 27 Mar 2002 23:56:50 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--AAA18090.1017302334/pheriche.sun.com-- From MAILER-DAEMON Wed Mar 27 23:58:32 2002 Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7wVKL016948 for ; Wed, 27 Mar 2002 23:58:32 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13361 for ; Wed, 27 Mar 2002 23:58:32 -0800 (PST) Received: from localhost (localhost) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with internal id AAA23697; Thu, 28 Mar 2002 00:58:31 -0700 (MST) Date: Thu, 28 Mar 2002 00:58:31 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203280758.AAA23697@kathmandu.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="AAA23697.1017302311/kathmandu.sun.com" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --AAA23697.1017302311/kathmandu.sun.com The original message was received at Thu, 28 Mar 2002 00:57:10 -0700 (MST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to mail.coverall.com.: >>> DATA <<< 554 Invalid data in message 554 ... Service unavailable --AAA23697.1017302311/kathmandu.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; kathmandu.sun.com Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Thu, 28 Mar 2002 00:57:10 -0700 (MST) Final-Recipient: RFC822; LeeC@coverall.com Action: failed Status: 5.0.0 Remote-MTA: DNS; mail.coverall.com Diagnostic-Code: SMTP; 554 Invalid data in message Last-Attempt-Date: Thu, 28 Mar 2002 00:57:50 -0700 (MST) --AAA23697.1017302311/kathmandu.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23663; Thu, 28 Mar 2002 00:57:10 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12994; Wed, 27 Mar 2002 23:57:06 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--AAA23697.1017302311/kathmandu.sun.com-- From MAILER-DAEMON Wed Mar 27 23:58:23 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7wMKL016936 for ; Wed, 27 Mar 2002 23:58:22 -0800 (PST) Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA27069 for ; Wed, 27 Mar 2002 23:58:22 -0800 (PST) Received: from localhost (localhost) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with internal id XAA27721; Wed, 27 Mar 2002 23:58:22 -0800 (PST) Date: Wed, 27 Mar 2002 23:58:22 -0800 (PST) From: Mail Delivery Subsystem Message-Id: <200203280758.XAA27721@mercury.Sun.COM> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="XAA27721.1017302302/mercury.Sun.COM" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --XAA27721.1017302302/mercury.Sun.COM The original message was received at Wed, 27 Mar 2002 23:57:38 -0800 (PST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to mx1.mail.yahoo.com.: >>> DATA <<< 554 delivery error: dd Sorry, your message to kkumbhalkar@yahoo.com cannot be delivered. This account is over quota. - mta494.mail.yahoo.com 554 ... Service unavailable --XAA27721.1017302302/mercury.Sun.COM Content-Type: message/delivery-status Reporting-MTA: dns; mercury.Sun.COM Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Wed, 27 Mar 2002 23:57:38 -0800 (PST) Final-Recipient: RFC822; kkumbhalkar@yahoo.com Action: failed Status: 5.0.0 Remote-MTA: DNS; mx1.mail.yahoo.com Diagnostic-Code: SMTP; 554 delivery error: dd Sorry, your message to kkumbhalkar@yahoo.com cannot be delivered. This account is over quota. - mta494.mail.yahoo.com Last-Attempt-Date: Wed, 27 Mar 2002 23:57:48 -0800 (PST) --XAA27721.1017302302/mercury.Sun.COM Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27713; Wed, 27 Mar 2002 23:57:38 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13057; Wed, 27 Mar 2002 23:57:23 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--XAA27721.1017302302/mercury.Sun.COM-- From MAILER-DAEMON Wed Mar 27 23:58:55 2002 Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7wrKL016970 for ; Wed, 27 Mar 2002 23:58:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13385 for ; Wed, 27 Mar 2002 23:58:54 -0800 (PST) Received: from clavin.turinnetworks.com (63-197-247-13.turinntwks.com [63.197.247.13] (may be forged)) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA11907 for ; Thu, 28 Mar 2002 00:58:53 -0700 (MST) Received: by clavin.turinnetworks.com with Internet Mail Service (5.5.2653.19) id ; Wed, 27 Mar 2002 23:58:53 -0800 Message-ID: <36EF020032CFD411B7B400508B55E59002659FEE@milan.turinnetworks.com> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Wed, 27 Mar 2002 23:58:52 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62E.670BC9B0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62E.670BC9B0 Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Wed, 27 Mar 2002 23:56:02 -0800 did not reach the following recipient(s): MSandstrom@turinnetworks.com on Wed, 27 Mar 2002 23:58:48 -0800 The recipient name is not recognized The MTS-ID of the original message is: c=3Dus;a=3D ;p=3Dturin;l=3DMILAN0203280758HHKRY6HG MSEXCH:IMS:Turin:Petaluma:MILAN 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D62E.670BC9B0 Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Wed, 27 Mar 2002 23:56:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D62E.670BC9B0-- From MAILER-DAEMON Wed Mar 27 23:59:14 2002 Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7xDKL016994 for ; Wed, 27 Mar 2002 23:59:14 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13597 for ; Wed, 27 Mar 2002 23:59:15 -0800 (PST) Received: from lnyexch1.ltd.com ([63.72.211.153]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28671 for ; Wed, 27 Mar 2002 23:59:15 -0800 (PST) Received: by lnyexch1.ltd.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 02:59:13 -0500 Message-ID: <4DCF7F9DC9460A4C9E0B84696FB6BAAD04F6213E@lscexch1.limited.com> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 02:59:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62E.72EC0196" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62E.72EC0196 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 02:56:02 -0500 did not reach the following recipient(s): c=3DUS;a=3D ;p=3DLIMITED;o=3DLSC;dda:SMTP=3DKHeekwan@limited.com; on = Thu, 28 Mar 2002 02:59:06 -0500 The recipient name is not recognized The MTS-ID of the original message is: c=3Dus;a=3D ;p=3Dlimited;l=3DLSCEXCH10203280759H4D036FH MSEXCH:IMS:LIMITED:LSC:LSCEXCH1 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D62E.72EC0196 Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 02:56:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D62E.72EC0196-- From MAILER-DAEMON Wed Mar 27 23:59:22 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7xLKL016996 for ; Wed, 27 Mar 2002 23:59:21 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA27193 for ; Wed, 27 Mar 2002 23:59:21 -0800 (PST) Received: from localhost (localhost) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with internal id AAA23606; Thu, 28 Mar 2002 00:59:21 -0700 (MST) Date: Thu, 28 Mar 2002 00:59:21 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203280759.AAA23606@kathmandu.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="AAA23606.1017302361/kathmandu.sun.com" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --AAA23606.1017302361/kathmandu.sun.com The original message was received at Thu, 28 Mar 2002 00:56:56 -0700 (MST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to caly80.spider.com.: >>> DATA <<< 554 Invalid data in message 554 ... Service unavailable --AAA23606.1017302361/kathmandu.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; kathmandu.sun.com Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Thu, 28 Mar 2002 00:56:56 -0700 (MST) Final-Recipient: RFC822; ipng@spider.com Action: failed Status: 5.0.0 Remote-MTA: DNS; caly80.spider.com Diagnostic-Code: SMTP; 554 Invalid data in message Last-Attempt-Date: Thu, 28 Mar 2002 00:57:00 -0700 (MST) --AAA23606.1017302361/kathmandu.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23597; Thu, 28 Mar 2002 00:56:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12957; Wed, 27 Mar 2002 23:56:44 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--AAA23606.1017302361/kathmandu.sun.com-- From MAILER-DAEMON Wed Mar 27 23:58:32 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7wUKL016947 for ; Wed, 27 Mar 2002 23:58:31 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA27085 for ; Wed, 27 Mar 2002 23:58:31 -0800 (PST) Received: from localhost (localhost) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with internal id AAA23790; Thu, 28 Mar 2002 00:58:31 -0700 (MST) Date: Thu, 28 Mar 2002 00:58:31 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203280758.AAA23790@kathmandu.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="AAA23790.1017302311/kathmandu.sun.com" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --AAA23790.1017302311/kathmandu.sun.com The original message was received at Thu, 28 Mar 2002 00:57:30 -0700 (MST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to mx09.hotmail.com.: >>> RCPT To: <<< 552 Requested mail action aborted: exceeded storage allocation 554 ... Service unavailable --AAA23790.1017302311/kathmandu.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; kathmandu.sun.com Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Thu, 28 Mar 2002 00:57:30 -0700 (MST) Final-Recipient: RFC822; saridder@hotmail.com Action: failed Status: 5.5.0 Remote-MTA: DNS; mx09.hotmail.com Diagnostic-Code: SMTP; 552 Requested mail action aborted: exceeded storage allocation Last-Attempt-Date: Thu, 28 Mar 2002 00:57:49 -0700 (MST) --AAA23790.1017302311/kathmandu.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23783; Thu, 28 Mar 2002 00:57:30 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13128; Wed, 27 Mar 2002 23:57:27 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--AAA23790.1017302311/kathmandu.sun.com-- From MAILER-DAEMON Wed Mar 27 23:59:56 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7xsKL017021 for ; Wed, 27 Mar 2002 23:59:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05132 for ; Wed, 27 Mar 2002 23:59:55 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [193.49.124.31]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id AAA12159 for ; Thu, 28 Mar 2002 00:59:54 -0700 (MST) Received: by p-biset.rd.francetelecom.fr with Internet Mail Service (5.5.2655.55) id ; Thu, 28 Mar 2002 08:59:48 +0100 Message-ID: <227AB9CBF164D111B2CA00805F19DA3006FD502B@p-voyageur.rd.francetelecom.fr> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: Undeliverable: ( 1$0m ) @|1b?B59FG3Z ?B From: "@LEBH#" To: ipng-dist4T Subject: ( 1$0m ) @|1b?B59FG3Z ?B; Wed, 27 Mar 2002 23:59:31 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13663 for ; Wed, 27 Mar 2002 23:59:31 -0800 (PST) Received: from kings.mei.co.jp (kings.mei.co.jp [202.224.189.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00277 for ; Thu, 28 Mar 2002 00:59:30 -0700 (MST) Received: by kings.mei.co.jp (8.12.2/3.7W/kings) with ESMTP id g2S7xT0X002810 for ; Thu, 28 Mar 2002 16:59:29 +0900 (JST) Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) id g2S7xTI13846; Thu, 28 Mar 2002 16:59:29 +0900 (JST) Date: Thu, 28 Mar 2002 16:59:29 +0900 (JST) From: Mail Delivery Subsystem Subject: Returned mail: see transcript for details Message-Id: <200203280759.g2S7xTI13846@mail.jp.panasonic.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="g2S7xTI13846.1017302369/mail.jp.panasonic.com" Content-Transfer-Encoding: 8bit Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --g2S7xTI13846.1017302369/mail.jp.panasonic.com The original message was received at Thu, 28 Mar 2002 16:59:28 +0900 (JST) from localhost [127.0.0.1] ----- The following addresses had permanent fatal errors ----- (reason: 554 Invalid data in message) ----- Transcript of session follows ----- ... while talking to [133.183.66.131]: >>> DATA <<< 554 Invalid data in message 554 5.0.0 Service unavailable --g2S7xTI13846.1017302369/mail.jp.panasonic.com Content-Type: message/delivery-status Reporting-MTA: dns; mail.jp.panasonic.com Received-From-MTA: DNS; localhost Arrival-Date: Thu, 28 Mar 2002 16:59:28 +0900 (JST) Final-Recipient: RFC822; K.Tada@rdmg.mgcs.mei.co.jp Action: failed Status: 5.0.0 Remote-MTA: DNS; [133.183.66.131] Diagnostic-Code: SMTP; 554 Invalid data in message Last-Attempt-Date: Thu, 28 Mar 2002 16:59:29 +0900 (JST) --g2S7xTI13846.1017302369/mail.jp.panasonic.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: by mail.jp.panasonic.com (8.11.6/3.7W/mariners) with ESMTP id g2S7xSI13841 for ; Thu, 28 Mar 2002 16:59:28 +0900 (JST) Received: by kings.mei.co.jp (8.12.2/3.7W/jazz) with ESMTP id g2S7xR5r015810 for ; Thu, 28 Mar 2002 16:59:28 +0900 (JST) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18094; Thu, 28 Mar 2002 00:58:10 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12971; Wed, 27 Mar 2002 23:56:50 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--g2S7xTI13846.1017302369/mail.jp.panasonic.com-- From MAILER-DAEMON Wed Mar 27 23:58:56 2002 Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7wsKL016971 for ; Wed, 27 Mar 2002 23:58:55 -0800 (PST) Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13438 for ; Wed, 27 Mar 2002 23:58:55 -0800 (PST) Received: from localhost (localhost) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with internal id XAA27709; Wed, 27 Mar 2002 23:58:55 -0800 (PST) Date: Wed, 27 Mar 2002 23:58:55 -0800 (PST) From: Mail Delivery Subsystem Message-Id: <200203280758.XAA27709@mercury.Sun.COM> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="XAA27709.1017302335/mercury.Sun.COM" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --XAA27709.1017302335/mercury.Sun.COM The original message was received at Wed, 27 Mar 2002 23:57:34 -0800 (PST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- 451 ... reply: read error from mail.o2.com. ... Deferred: Connection reset by mail.o2.com. ... while talking to isis.lip6.fr.: >>> DATA <<< 550 5.0.0 Access denied 554 ... Service unavailable --XAA27709.1017302335/mercury.Sun.COM Content-Type: message/delivery-status Reporting-MTA: dns; mercury.Sun.COM Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Wed, 27 Mar 2002 23:57:34 -0800 (PST) Final-Recipient: RFC822; Luis.Costa@lip6.fr Action: failed Status: 5.2.0 Remote-MTA: DNS; isis.lip6.fr Diagnostic-Code: SMTP; 550 5.0.0 Access denied Last-Attempt-Date: Wed, 27 Mar 2002 23:58:05 -0800 (PST) --XAA27709.1017302335/mercury.Sun.COM Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27703; Wed, 27 Mar 2002 23:57:34 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13057; Wed, 27 Mar 2002 23:57:23 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--XAA27709.1017302335/mercury.Sun.COM-- From bmah@freebsd.org Wed Mar 27 23:59:58 2002 Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7xvKL017023 for ; Wed, 27 Mar 2002 23:59:58 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13758 for ; Wed, 27 Mar 2002 23:59:57 -0800 (PST) Received: from alias.acm.org (alias.acm.org [199.222.69.90]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id AAA12173 for ; Thu, 28 Mar 2002 00:59:55 -0700 (MST) Received: by alias.acm.org with MERCUR Mailserver (v4.01.11 OTAtMjE3Ni00NjIw) for ; Thu, 28 Mar 2002 02:58:07 -0500 From: postmaster@alias.acm.org To: ipng-dist@sunroof.eng.sun.com Date: Thu, 28 Mar 2002 02:58:06 -0500 Subject: Delivery unsuccesful: Delivery problems Message-Id: <0203280258077200@alias.acm.org> --------------- The following address has delivery problems: bmah@freebsd.org --------------- Part of transaction follows: \--> RCPT TO: <-- 250 Ok --------------- Original Message:Received: from mercury.Sun.COM (192.9.25.1) by alias.acm.org with MERCUR Mailserver (v4.01.11 OTAtMjE3Ni00NjIw) for ; Thu, 28 Mar 2002 02:56:54 -0500 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27626; Wed, 27 Mar 2002 23:56:53 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12964; Wed, 27 Mar 2002 23:56:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mercury.Sun.COM id XAA27626 Untitled

<= a href=3D"http://www.anne114.com/co052/052010323010.htm" target=3D"_blank">

 

=
=20

=C8=AD=BC=BA=C6=C7=B3=DA=C0= =C7 20=B3=E2 =B0=E6=C7=E8=B0=FA =B1=E2=BC=FA=B7=CE=20 =C0=CC=B7=E8=C7=D8=B3=BD
=BF=F8=B8= =F1=B8=B6=B7=E7=C0=E7=B7=CE=BC=AD =BF=C2=B5=B9=B9=E8=BC=B1=B0=FA=20 =BF=F8=B8=F1=B8=B6=B7=E7=B0=A1 =C0=CF= =C3=BC=C8=AD=B5=C7=BE=EE
=B1=E2=C1=B8 =C2=CA=B8=B6=B7=E7 =BD=C3=B0=F8= =B0=FA=B4=C2=20 =B4=DE=B8=AE =BD=C3=B0=F8=C0=CC =B0=A3= =C6=ED=C7=CF=B0=ED =BE=C8=C0=FC
=C7=CF=B8=E7 =BF=EE=C0=FB=BF=DC=BC=B1= =C0=B8=B7=CE=20 =B0=C7=B0=AD=B0=A1=C1=F6 =BB=FD=B0=A2= =C7=CF=B4=C2
=B1=B9=B3=BB =C3=D6=C3=CA=C0=C7 =C6=AF=C7=E3=C0=E7=C0=D4= =B4=CF=B4=D9.

=20


= = =20

=B1=E2=C1=B8=C0=C7 =C3=B6= =C6=C7=C6=C7=B3=DA=BF=A1=BC=AD =B3=AA=B9=AB(=C7=D5=C6=C7)=C6=C7=B3=DA=B7=CE= =20 =B0=B3=B9=DF=B5=C7=BE=EE =BA=B9=BB=E7= =BF=AD=B7=CE =C0=CE=C7=D1 =C8=C6=B1=E2=B0=A1 =B0=A1=B5=E6=C7=CF=BF=A9 =C0= =CE=C3=BC=BF=A1=20 =B0=A1=C0=E5 =C0=AF=C0=CD=C7=D1  = ;=B3=AD=B9=E6=C0=E7=C0=D4=B4=CF=B4=D9.

=20 =C3=B6=C6=C7=C6=C7=B3=DA=C0=C7 =B2=A8= =C1=FC =C7=F6=BB=F3=C0=BB =BF=CF=BA=AE=C7=CF=B0=D4 =BA=B8=BF=CF=C7=CF=BF=A9= =20 =B2=A8=C1=FC =C7=F6=BB=F3=C0=CC =BE=F8= =C0=B8=B8=E7 =B4=A9=C0=FC=C0=CC=B3=AA =B0=A8=C0=FC=C0=C7 =C0=A7=C7=E8=C0=CC= =20 =BE=F8=BE=EE =C3=D6=B0=ED=C0=C7 =BE=C8= =C0=FC=BC=BA=C0=BB =C8=AE=BA=B8=C7=CF=BF=B4=BD=C0=B4=CF=B4=D9.
=20
=BC=BC=B6=F3=B9=CD, =C2=FC=BD=A1= =B0=FA =B3=AA=B9=AB=C0=C7 =B0=E1=C7=D5=C0=B8=B7=CE =C0=CE=C3=BC=C0=C7=20 =C0=AF=C0=CD=C7=D1 =BF=F8=C0=FB=BF=DC= =BC=B1=C0=BB =B9=E6=C3=E2=C7=D5=B4=CF=B4=D9.
=BD=C3=B0=F8=C0=CC=20 =B0=A3=C6=ED=C7=CF=BF=A9 =B4=E7=C0=CF=BD=C3=B0=F8=20 =B4=E7=C0=CF=B3=AD=B9=E6=C0=CC =B0=A1=B4=C9
=20 =C7=D5=B4=CF=B4=D9

 

=20

 

=C8=AE=BD=C7=C8=F7=20 =B4=DE=B6=F3=C1=F8 =C8=B2=C5=E4=B9=E6= =BF=C2=BC=F6=BF=C2=B5=B9=C0=BA =BF=EF=B7=B7=B0=C5=B8=B2=C0=CC =BE=F8=B0=ED= =20 =BE=C6=C1=D6 =B0=DF=B0=ED=C7=D5=B4=CF= =B4=D9.
=B1=E2=C1=B8 =C1=B6=B8=B3=BD=C4=BF=C2=B5=B9=C0=C7 =B9=AE=C1=A6= =C1=A1=B5=E9=C0=CC=20 =B8=F0=B5=CE =B0=B3=BC=B1=C7=D1
= =BD=C5=B0=F8=B9=FD =C0=B8=B7=CE =BC=B3=C4=A1=BA=F1=BF=EB=C0=CC=20 =BD=C0=BD=C4=B9=CC=C0=E5=B0=F8=B9=FD=C0= =C7 =BC=F6=C1=D8=B0=FA =B0=B0=C0=CC =BE=C6=C1=D6 =C0=FA=B7=C5=C7=D5=B4=CF= =B4=D9.



  

=BB=E7=C0=FC =C7=E3=B6=F4 =BE=F8=C0=CC= =B8=DE=C0=CF=C0=BB =BA=B8=B3=BD =C1=A1 =C1=CB=BC=DB=C7=CF=BF=C0=B8=E7 =B8= =DE=C0=CF=C0=BB=20  =BC=F6=BD=C5=C7=CF=C1=F6 =BE=CA=C0=B8=B7=C1= =B8=E9  
=BC=F6=BD=C5 =B0=C5=BA=CE=B8=A6 =C5=AC=B8=AF=C7=D8= =C1=D6=BD=C3=B8=E9 =B0=A8=BB=E7=B5=E5=B8=AE=B0=DA=BD=C0=B4=CF=B4=D9. &nb= sp; 

 Homepage : www.anne1= 14.co.kr=20   /   Email : lch5101@korea.com&nbs= p;
Copyright=A8=CF 2002 =  anne114.com  All right reserved.

From MAILER-DAEMON Thu Mar 28 00:00:06 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S804KL017035 for ; Thu, 28 Mar 2002 00:00:05 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27428 for ; Thu, 28 Mar 2002 00:00:04 -0800 (PST) Received: from localhost (localhost) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with internal id BAA23593; Thu, 28 Mar 2002 01:00:03 -0700 (MST) Date: Thu, 28 Mar 2002 01:00:03 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203280800.BAA23593@kathmandu.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="BAA23593.1017302403/kathmandu.sun.com" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --BAA23593.1017302403/kathmandu.sun.com The original message was received at Thu, 28 Mar 2002 00:56:49 -0700 (MST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to amre-gate.amre.com.: >>> DATA <<< 554 Invalid data in message 554 ... Service unavailable 451 ... reply: read error from iabgfw.iabg.de. ... Deferred: Connection reset by iabgfw.iabg.de. ... while talking to fly.cc.fer.hr.: >>> DATA <<< 553 Spam or junk mail threshold exceeded. See http://www.flame.org/qmail/spamjunk.html (#5.7.1) 554 ... Service unavailable ... Deferred: Connection timed out with smtp.its.uow.edu.au. --BAA23593.1017302403/kathmandu.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; kathmandu.sun.com Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Thu, 28 Mar 2002 00:56:49 -0700 (MST) Final-Recipient: RFC822; TLewis@amre.com Action: failed Status: 5.0.0 Remote-MTA: DNS; amre-gate.amre.com Diagnostic-Code: SMTP; 554 Invalid data in message Last-Attempt-Date: Thu, 28 Mar 2002 00:58:18 -0700 (MST) Final-Recipient: RFC822; grac@fly.cc.fer.hr Action: failed Status: 5.1.0 Remote-MTA: DNS; fly.cc.fer.hr Diagnostic-Code: SMTP; 553 Spam or junk mail threshold exceeded. See http://www.flame.org/qmail/spamjunk.html (#5.7.1) Last-Attempt-Date: Thu, 28 Mar 2002 00:58:45 -0700 (MST) --BAA23593.1017302403/kathmandu.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23556; Thu, 28 Mar 2002 00:56:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12957; Wed, 27 Mar 2002 23:56:44 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--BAA23593.1017302403/kathmandu.sun.com-- From greg@fibercycle.com Thu Mar 28 00:00:03 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S802KL017032 for ; Thu, 28 Mar 2002 00:00:02 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27405 for ; Thu, 28 Mar 2002 00:00:02 -0800 (PST) Received: from invincible.cnchost.com (invincible.concentric.net [207.155.248.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA06037 for ; Wed, 27 Mar 2002 23:59:48 -0800 (PST) Received: (root@localhost) by invincible.cnchost.com id DAA17448; Thu, 28 Mar 2002 03:00:00 -0500 (EST) [ConcentricHost SMTP MX 1.28] Date: Thu, 28 Mar 2002 03:00:00 -0500 (EST) Message-Id: <200203280800.DAA17448@invincible.cnchost.com> Errors-To: From: "Greg Zhang" To: ipng-dist@sunroof.eng.sun.com Precedence: bulk Subject: Automatic response to your mail Greg Zhang is no longer with FiberCycle Networks. Please update your address book to indicate his new address: greg@rollingstreams.com. Your message has been forwarded to the new address, there is no need to resend it. From MAILER-DAEMON Wed Mar 27 23:59:37 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7xaKL017010 for ; Wed, 27 Mar 2002 23:59:36 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA05059 for ; Wed, 27 Mar 2002 23:59:37 -0800 (PST) Received: from localhost (localhost) by pheriche.sun.com (8.9.3+Sun/8.9.3) with internal id AAA17812; Thu, 28 Mar 2002 00:59:37 -0700 (MST) Date: Thu, 28 Mar 2002 00:59:37 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203280759.AAA17812@pheriche.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="AAA17812.1017302377/pheriche.sun.com" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --AAA17812.1017302377/pheriche.sun.com The original message was received at Thu, 28 Mar 2002 00:57:16 -0700 (MST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... Deferred: Connection timed out with indmail.iwavesystems.net. ... while talking to nmsnotes4.nmss.com.: >>> DATA <<< 554 Invalid data in message 554 ... Service unavailable --AAA17812.1017302377/pheriche.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; pheriche.sun.com Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Thu, 28 Mar 2002 00:57:16 -0700 (MST) Final-Recipient: RFC822; Adam_Machalek@nmss.com Action: failed Status: 5.0.0 Remote-MTA: DNS; nmsnotes4.nmss.com Diagnostic-Code: SMTP; 554 Invalid data in message Last-Attempt-Date: Thu, 28 Mar 2002 00:59:26 -0700 (MST) --AAA17812.1017302377/pheriche.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17806; Thu, 28 Mar 2002 00:57:16 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13019; Wed, 27 Mar 2002 23:57:13 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--AAA17812.1017302377/pheriche.sun.com-- From MAILER-DAEMON Thu Mar 28 00:00:05 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S803KL017034 for ; Thu, 28 Mar 2002 00:00:04 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05229 for ; Thu, 28 Mar 2002 00:00:03 -0800 (PST) Received: from kanexch1.kanbay.com ([206.25.103.14]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA06049 for ; Wed, 27 Mar 2002 23:59:49 -0800 (PST) Received: by KANEXCH1 with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 01:51:06 -0600 Message-ID: From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 01:51:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62D.50E34F92" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62D.50E34F92 Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 01:56:02 -0600 did not reach the following recipient(s): RCheema@KANBAY.com on Thu, 28 Mar 2002 01:51:01 -0600 The recipient name is not recognized The MTS-ID of the original message is: c=3Dus;a=3D ;p=3Dkanbay;l=3DKANEXCH10203280751HV1ARHFT MSEXCH:IMS:KANBAY:CHICAGO:KANEXCH1 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D62D.50E34F92 Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 01:56:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="euc-kr" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D62D.50E34F92-- From MAILER-DAEMON Thu Mar 28 00:00:12 2002 Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S80CKL017038 for ; Thu, 28 Mar 2002 00:00:12 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA13867 for ; Thu, 28 Mar 2002 00:00:12 -0800 (PST) Received: from bcfw1d.bridge.com (bcfw1d.ext.bridge.com [167.76.159.31]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA28894 for ; Thu, 28 Mar 2002 00:00:13 -0800 (PST) Received: (from uucp@localhost) by bcfw1d.bridge.com (8.10.2/8.10.2) id g2S81pI17180 for ; Thu, 28 Mar 2002 02:01:51 -0600 (CST) Received: from <> (unknown [167.76.56.34]) by bcfw1d via smap (V2.1) id xma017137; Thu, 28 Mar 02 02:01:42 -0600 Received: from eximcx1.bridge.com (eximcx1.bridge.com [167.76.56.27]) by mail1srv.bridge.com (8.8.8/8.7.3) with ESMTP id CAA03648 for ; Thu, 28 Mar 2002 02:00:02 -0600 (CST) Received: by eximcx1.bridge.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Mar 2002 02:00:01 -0600 Message-ID: From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: Undeliverable: ( 1$0m ) @|1b?B59FG3Z ?B From: "@LEBH#" To: ipng-dist4T Subject: ( 1$0m ) @|1b?B59FG3Z ?B; Thu, 28 Mar 2002 00:00:25 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA27586 for ; Thu, 28 Mar 2002 00:00:22 -0800 (PST) Received: from asc_exch.asc.com (outlook.asc.com [63.82.128.45]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24872 for ; Thu, 28 Mar 2002 01:00:21 -0700 (MST) Received: by ASC_EXCH with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 02:59:00 -0500 Message-ID: <4AA0C69EF2C3D411B94600B0D04931BD01869BBB@ASC_EXCH> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 02:59:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62E.6BBD6AE0" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62E.6BBD6AE0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 02:56:02 -0500 did not reach the following recipient(s): kjohnson@asc.com on Thu, 28 Mar 2002 02:58:55 -0500 The recipient name is not recognized The MTS-ID of the original message is: c=3Dus;a=3D ;p=3Dasc;l=3DASC_EXCH0203280758HNH375F9 MSEXCH:IMS:ASC:Corporate:ASC_EXCH 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D62E.6BBD6AE0 Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 02:56:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D62E.6BBD6AE0-- From Stanley.Konopka@ses-americom.net Thu Mar 28 00:06:02 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S860KL017286 for ; Thu, 28 Mar 2002 00:06:00 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA29056 for ; Thu, 28 Mar 2002 00:06:01 -0800 (PST) Received: from ext-nj2gw-1.online-age.net (ext-nj2gw-1.online-age.net [216.35.73.163]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA21547 for ; Thu, 28 Mar 2002 01:06:01 -0700 (MST) Received: from int-nj2gw-4.online-age.net (int-nj2gw-4.online-age.net [3.159.236.68]) by ext-nj2gw-1.online-age.net (8.9.3+Sun/8.9.1/990426-RLH) with ESMTP id DAA05748 for ; Thu, 28 Mar 2002 03:06:00 -0500 (EST) Received: from msbatl01itscge.gecits.ge.com (localhost [127.0.0.1]) by int-nj2gw-4.online-age.net (8.9.3+Sun/8.9.1/990426-RLH) with ESMTP id DAA15180 for ; Thu, 28 Mar 2002 03:05:55 -0500 (EST) Received: by msbatl01itscge.gecits.ge.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 03:08:04 -0500 Message-ID: <69061403111BD411A96500508BDF409E086EF9A8@msbatl01itscge.gecits.ge.com> From: postmaster@gecits.ge.com To: ipng-dist@sunroof.eng.sun.com Subject: Undeliverable: ( 1$0m ) @|1b?B59FG3Z ?B From: lch5101@korea.com To: ipng-dist@sunroof.eng.sun.com Subject: ( 1$0m ) @|1b?B59FG3Z ?B ????? 20? ??? ??? ???? ??????? ????? ????? ????? ?? ??? ???? ?? ??? ???? ?? ?? ?????? ???? ???? ?? ??? ??????. ??? ?????? ??(??)??? ???? ???? ?? ??? ???? ??? ?? ??? ??????. ????? ?? ??? ???? ???? ?? ??? ??? ???? ??? ??? ?? ??? ???? ???????. ???, ??? ??? ???? ??? ??? ??? ?? ?????. ??? ???? ???? ????? ?? ??? ??? ??? ??? ????? ????? ?? ?? ?????. ?? ?????? ????? ?? ??? ??? ?? ????? ??????? ??? ?? ?? ?????. ?? ?? ?? ??? ?? ? ????? ??? ???? ???? ?? ??? ??? ??? ????????. Homepage : www.anne114.co.kr / Email : lch5101@korea.com Copyright? 2002 anne114.com All right reserved. From MAILER-DAEMON Thu Mar 28 00:13:19 2002 Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S8DHKT017336 for ; Thu, 28 Mar 2002 00:13:18 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA14147 for ; Thu, 28 Mar 2002 00:03:37 -0800 (PST) Received: from localhost (localhost) by patan.sun.com (8.9.3+Sun/8.9.3) with internal id BAA00479; Thu, 28 Mar 2002 01:03:37 -0700 (MST) Date: Thu, 28 Mar 2002 01:03:37 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203280803.BAA00479@patan.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="BAA00479.1017302617/patan.sun.com" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --BAA00479.1017302617/patan.sun.com The original message was received at Thu, 28 Mar 2002 00:59:56 -0700 (MST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to kay.sprintlink.net.: >>> DATA <<< 554 Invalid data in message 554 ... Service unavailable --BAA00479.1017302617/patan.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; patan.sun.com Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Thu, 28 Mar 2002 00:59:56 -0700 (MST) Final-Recipient: RFC822; rdrake@sprint.net Action: failed Status: 5.0.0 Remote-MTA: DNS; kay.sprintlink.net Diagnostic-Code: SMTP; 554 Invalid data in message Last-Attempt-Date: Thu, 28 Mar 2002 01:00:19 -0700 (MST) --BAA00479.1017302617/patan.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00446; Thu, 28 Mar 2002 00:59:56 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12986; Wed, 27 Mar 2002 23:56:59 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--BAA00479.1017302617/patan.sun.com-- From MAILER-DAEMON Thu Mar 28 00:13:18 2002 Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S8DHKP017336 for ; Thu, 28 Mar 2002 00:13:18 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA13690 for ; Thu, 28 Mar 2002 00:00:43 -0800 (PST) Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.34]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA19001 for ; Thu, 28 Mar 2002 01:00:42 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2S80fkY025876 for ; Thu, 28 Mar 2002 09:00:41 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Mar 28 09:00:18 2002 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 08:50:10 +0100 Message-ID: From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 08:50:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62D.2F65C75A" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62D.2F65C75A Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 08:56:02 +0100 did not reach the following recipient(s): Peter.N.Hedman@ecs.ericsson.se on Thu, 28 Mar 2002 08:58:16 +0100 The recipient name is not recognized The MTS-ID of the original message is: = c=3Dse;a=3D400net;p=3Dericsson;l=3DESEALNT4580203280758F4GYN20A MSEXCH:IMS:Ericsson:SE0:ESEALNT458 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D62D.2F65C75A Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 08:56:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiAgIDxodHRwOi8v d3d3LmFueWRtLmNvLmtyL3RhZWh3YS9pbWc0MF90aXRsZTEuZ2lmPiANCg0KDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KIA0KDQogPGh0dHA6 Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0KDQrIrby6xsez 2sDHIDIws+IgsObH6LD6ILHivPq3ziDAzLfox9izvSANCr/4uPG4trfnwOe3zrytIL/Ctbm56Lyx sPogv/i48bi2t+ewoSDAz8O8yK21x77uDQqx4sG4IMLKuLa35yC9w7D4sPq0wiC03riuIL3DsPjA zCCwo8btx8+w7SC+yMD8DQrHz7jnIL/uwPu/3LyxwLi3ziCwx7CtsKHB9iC7/bCix8+0wiANCrG5 s7sgw9bDysDHIMavx+PA58DUtM+02S4NCg0KICA8aHR0cDovL3d3dy5hbnlkbS5jby5rci90YWVo d2EvaW1nNTBfdGl0bGUyLmdpZj4gDQoNCg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3Rh ZWh3YS9pbWcxMDAuZ2lmPiANCg0KDQqx4sG4wMcgw7bGx8bHs9q/obytILOquasox9XGxynGx7Pa t84gsLO537XHvu4gurm757+tt84gwM7H0SDIxrHisKEgsKG15sfPv6kgwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxyDAp8fowMwgvvi+7iDD1rDt wMcgvsjA/Ly6wLsgyK66uMfPv7S9wLTPtNkuDQoNCry8tvO5zSwgwvy9obD6ILOquavAxyCw4cfV wLi3ziDAzsO8wMcgwK/AzcfRIL/4wPu/3CC8scC7ILnmw+LH1bTPtNkuIA0KvcOw+MDMILCjxu3H z7+pILTnwM+9w7D4ILTnwM+zrbnmwMwgsKG0yQ0Kx9W0z7TZDQoNCiANCg0KIDxodHRwOi8vd3d3 LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogIDxodHRwOi8vd3d3LmFu eWRtLmNvLmtyL3RhZWh3YS9pbWc2MF90aXRsZTMuZ2lmPiANCg0KDQogPGh0dHA6Ly93d3cuYW5u ZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCiANCg0KDQogIDxodHRwOi8vd3d3 LmFueWRtLmNvLmtyL3RhZWh3YS9pbWcxMjAuZ2lmPiANCg0KyK69x8j3ILTetvPB+CDIssXkueYg v8K89r/CtbnAuiC/77e3sMW4ssDMIL74sO0gvsbB1iCw37Dtx9W0z7TZLg0KseLBuCDBtrizvcS/ wrW5wMcgua7BpsGhtenAzCC48LXOILCzvLHH0SANCr3FsPi5/SDAuLfOILyzxKG68b/rwMwgvcC9 xLnMwOWw+Ln9wMcgvPbB2LD6ILCwwMwgvsbB1iDA+rfFx9W0z7TZLg0KDQogIDxodHRwOi8vd3d3 LmFueWRtLmNvLmtyL3RhZWh3YS9pbWcxMzAuZ2lmPiANCiAgPEM6ZG90MS5naWY+IA0KICAgPGh0 dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gICANCg0KDQq758D8 IMfjtvQgvvjAzCC43sDPwLsgurizvSDBoSDBy7zbx8+/wLjnILjewM/AuyAgvPa9xcfPwfYgvsrA uLfBuOkgIA0KvPa9xSCwxbrOuKYgxay4r8fYIMHWvcO46SCwqLvnteW4rrDavcC0z7TZLiAgICAg PG1haWx0bzpsY2g1MTAxQGtvcmVhLmNvbT9zdWJqZWN0Pbz2vcWwxbrOJmJvZHk9tPXAzLvzILje wM/AuyC6uLO7wfYguLa8vL/kPiANCg0KDQogSG9tZXBhZ2UgOiB3d3cuYW5uZTExNC5jby5rciAg IC8gICBFbWFpbCA6ICA8bWFpbHRvOmxjaDUxMDFAa29yZWEuY29tP3N1YmplY3Q9ua7Ax7jewM8+ IGxjaDUxMDFAa29yZWEuY29tIA0KQ29weXJpZ2h0qM8gMjAwMiAgYW5uZTExNC5jb20gIEFsbCBy aWdodCByZXNlcnZlZC4gDQoNCg0K ------_=_NextPart_000_01C1D62D.2F65C75A-- From MAILER-DAEMON Thu Mar 28 00:13:17 2002 Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S8DHKL017336 for ; Thu, 28 Mar 2002 00:13:17 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA14284 for ; Thu, 28 Mar 2002 00:04:19 -0800 (PST) Received: from zugitsmxc01.zug.fantastic.com ([212.249.34.40]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA29792 for ; Thu, 28 Mar 2002 00:04:19 -0800 (PST) Received: by zugitsmxc01 with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Mar 2002 09:04:14 +0100 Message-ID: <331AF4286627D511AB9E0050DA6CD58933B7E8@zugitsmxc02> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 09:04:14 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62F.2689823C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62F.2689823C Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 08:56:02 +0100 did not reach the following recipient(s): tianpoh.loo@fantastic.com on Thu, 28 Mar 2002 08:58:37 +0100 The recipient name is not recognized The MTS-ID of the original message is: c=3DCH;a=3D ;p=3DFANTASTIC;l=3DZUGITSMXC020203280758H4CDJWAJ MSEXCH:IMS:FANTASTIC:HQ:ZUGITSMXC02 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D62F.2689823C Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 08:56:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-MS-Embedded-Report: Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D62F.2689823C-- From MAILER-DAEMON Thu Mar 28 00:13:18 2002 Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S8DHKN017336 for ; Thu, 28 Mar 2002 00:13:17 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA13897 for ; Thu, 28 Mar 2002 00:02:04 -0800 (PST) Received: from fsmbpb24.lackland.af.mil (fsmbpb24.lackland.af.mil [137.242.1.55]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06528 for ; Thu, 28 Mar 2002 00:01:49 -0800 (PST) Received: by fsmbpb24.kelly.af.mil with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 02:03:04 -0600 Message-ID: <79CEF514407FD4119CC100D0B7B0DE7F02A5ECA4@fsmpls02.lackland.af.mil> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 02:03:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62E.FC9DCFC8" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62E.FC9DCFC8 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 01:56:02 -0600 did not reach the following recipient(s): Richard.BrumptonJr@KELLY.AF.MIL on Thu, 28 Mar 2002 02:01:17 -0600 The recipient name is not recognized The MTS-ID of the original message is: c=3Dus;a=3Ddms;l=3DFSMPLS020203280801HZCPVHZY MSEXCH:IMS:ORGANIZATION:LACKLANDAFB:FSMPLS02 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D62E.FC9DCFC8 Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 01:56:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D62E.FC9DCFC8-- From MAILER-DAEMON Thu Mar 28 00:14:36 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S8EWKV017376 for ; Thu, 28 Mar 2002 00:14:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05634 for ; Thu, 28 Mar 2002 00:01:14 -0800 (PST) Received: from localhost (localhost) by patan.sun.com (8.9.3+Sun/8.9.3) with internal id BAA00682; Thu, 28 Mar 2002 01:01:14 -0700 (MST) Date: Thu, 28 Mar 2002 01:01:14 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203280801.BAA00682@patan.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="BAA00682.1017302474/patan.sun.com" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --BAA00682.1017302474/patan.sun.com The original message was received at Thu, 28 Mar 2002 00:58:49 -0700 (MST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- 451 ... iwavesystems.net: Name server timeout ... Deferred: Connection timed out with mail-gw2.hursley.ibm.com. ... while talking to bells.cs.ucl.ac.uk.: >>> DATA <<< 554 Syntactically invalid address for from field 'ÀÌŠȣ ' 554 ... Service unavailable --BAA00682.1017302474/patan.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; patan.sun.com Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Thu, 28 Mar 2002 00:58:49 -0700 (MST) Final-Recipient: RFC822; G.Martinez@cs.ucl.ac.uk Action: failed Status: 5.0.0 Remote-MTA: DNS; bells.cs.ucl.ac.uk Diagnostic-Code: SMTP; 554 Syntactically invalid address for from field 'ÀÌŠȣ ' Last-Attempt-Date: Thu, 28 Mar 2002 01:00:43 -0700 (MST) --BAA00682.1017302474/patan.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA00052; Thu, 28 Mar 2002 00:58:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13000; Wed, 27 Mar 2002 23:57:09 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--BAA00682.1017302474/patan.sun.com-- From MAILER-DAEMON Thu Mar 28 00:14:34 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S8EWKT017376 for ; Thu, 28 Mar 2002 00:14:34 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05882 for ; Thu, 28 Mar 2002 00:02:24 -0800 (PST) Received: from localhost (localhost) by patan.sun.com (8.9.3+Sun/8.9.3) with internal id BAA01167; Thu, 28 Mar 2002 01:02:24 -0700 (MST) Date: Thu, 28 Mar 2002 01:02:24 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203280802.BAA01167@patan.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="BAA01167.1017302544/patan.sun.com" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --BAA01167.1017302544/patan.sun.com The original message was received at Thu, 28 Mar 2002 01:00:13 -0700 (MST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to mail1.americantower.com.: >>> DATA <<< 554 Invalid data in message 554 ... Service unavailable --BAA01167.1017302544/patan.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; patan.sun.com Received-From-MTA: DNS; [129.144.170.5] Arrival-Date: Thu, 28 Mar 2002 01:00:13 -0700 (MST) Final-Recipient: RFC822; Robert.Seer@AmericanTower.com Action: failed Status: 5.0.0 Remote-MTA: DNS; mail1.americantower.com Diagnostic-Code: SMTP; 554 Invalid data in message Last-Attempt-Date: Thu, 28 Mar 2002 01:01:20 -0700 (MST) --BAA01167.1017302544/patan.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA00737; Thu, 28 Mar 2002 01:00:13 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13000; Wed, 27 Mar 2002 23:57:09 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--BAA01167.1017302544/patan.sun.com-- From MAILER-DAEMON@vasfw03.fdic.gov Thu Mar 28 00:14:33 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S8EWKN017376 for ; Thu, 28 Mar 2002 00:14:33 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05858 for ; Thu, 28 Mar 2002 00:02:19 -0800 (PST) Received: from vasfw03.fdic.gov (vasfw03.fdic.gov [192.147.69.46]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25902 for ; Thu, 28 Mar 2002 01:02:19 -0700 (MST) Received: by vasfw03.fdic.gov; id DAA25824; Thu, 28 Mar 2002 03:02:18 -0500 (EST) Received: from unknown(151.174.4.145) by vasfw03.fdic.gov via smap (V5.5) id xma025791; Thu, 28 Mar 02 03:01:22 -0500 Received: by s00exc101.fdic.gov with Internet Mail Service (5.5.2655.55) id ; Thu, 28 Mar 2002 02:59:53 -0500 Message-ID: <96A597B141D5D511BEF400A0C997A303025E71D3@s00exc101.fdic.gov> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: Undeliverable: ( 1$0m ) @|1b?B59FG3Z ?B From: "@LEBH#" To: ipng-dist4T Subject: ( 1$0m ) @|1b?B59FG3Z ?B; Thu, 28 Mar 2002 00:14:33 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA05757 for ; Thu, 28 Mar 2002 00:01:51 -0800 (PST) Received: from W2KEXGSWP02.kpnqwest.com (smtp.kpnqwest.com [193.242.92.8]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA06475 for ; Thu, 28 Mar 2002 00:01:36 -0800 (PST) Received: from ntexghub01.kpnqwest.com (unverified) by W2KEXGSWP02.kpnqwest.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 28 Mar 2002 09:01:49 +0100 Received: by ntexghub01 with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 09:01:49 +0100 Message-ID: <6D93A5DCFBF6D411A14100508B649620048B0AE1@ntexghub03> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 09:01:47 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D62E.CF31C18E" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D62E.CF31C18E Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 08:56:02 +0100 did not reach the following recipient(s): Jurgen.van.der.Wilk@kpnqwest.com on Thu, 28 Mar 2002 09:01:42 +0100 The recipient name is not recognized The MTS-ID of the original message is: c=3Dnl;a=3D ;p=3Dkpnqwest;l=3DNTEXGHUB030203280801D4C2T26Z MSEXCH:IMS:KPNQwest:KPNQWEST:NTEXGHUB03 0 (000C05A6) Unknown = Recipient ------_=_NextPart_000_01C1D62E.CF31C18E Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 08:56:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="KS_C_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D62E.CF31C18E-- From owner-ipng@sunroof.eng.sun.com Thu Mar 28 00:43:41 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S8hfKL017468 for ; Thu, 28 Mar 2002 00:43:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2S8hfov017467 for ipng-dist; Thu, 28 Mar 2002 00:43:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S8hbKL017460 for ; Thu, 28 Mar 2002 00:43:37 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA06484 for ; Thu, 28 Mar 2002 00:43:39 -0800 (PST) Received: from fep8.cogeco.net (smtp.cogeco.net [216.221.81.25]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA26788 for ; Thu, 28 Mar 2002 01:43:37 -0700 (MST) Received: from cgocable.net (d141-54-6.home.cgocable.net [24.141.54.6]) by fep8.cogeco.net (Postfix) with ESMTP id 4167B4F13 for ; Thu, 28 Mar 2002 03:43:36 -0500 (EST) Message-ID: <3CA2D922.64025E8E@cgocable.net> Date: Thu, 28 Mar 2002 03:49:39 -0500 From: ryan elson Reply-To: ryane@cogeco.ca X-Mailer: Mozilla 4.78 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ipng@sunroof.eng.sun.com" Subject: Re: Undeliverable: ( 1$0m ) @|1b?B59FG3Z ?B Content-Type: multipart/alternative; boundary="------------B923F501F28DA58C4C8749BB" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------B923F501F28DA58C4C8749BB Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit almost 30 of these. Why am I getting junk in my inbox from ipng? System Administrator wrote: > Your message > > To: ipng-dist4T > Subject: ( 1$0m ) @|1b?B59FG3Z ?B Sent: Thu, 28 Mar 2002 08:56:02 +0100 > > did not reach the following recipient(s): > > mmartin@teldat.es on Thu, 28 Mar 2002 09:10:18 +0100 > The recipient name is not recognized > The MTS-ID of the original message is: c=us;a= > ;p=teldat;l=CORREO0203280810HT45DC8P > MSEXCH:IMS:TELDAT:TEL01:CORREO 0 (000C05A6) Unknown Recipient > > ------------------------------------------------------------------------ > > Subject: ( 1$0m ) @|1b?B59FG3Z ?B Date: Thu, 28 Mar 2002 08:56:02 +0100 > From: "@LEBH#" > To: ipng-dist4T > > > > > > > > > > > > > > > È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½ > ¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î > ±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü > ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â > ±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù. > > > > > > ±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© > ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ ³­¹æÀçÀÔ´Ï´Ù. > > öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ > À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù. > > ¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù. > ½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É > ÇÕ´Ï´Ù > > > > > > > > > > > > > > È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù. > ±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ > ½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù. > > > > > > »çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ» ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é > ¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù. > ¸¶¼¼¿ä> > > Homepage : www.anne114.co.kr / Email : > lch5101@korea.com > Copyright¨Ï 2002 anne114.com All right reserved. --------------B923F501F28DA58C4C8749BB Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit almost 30 of these.  Why am I getting junk in my inbox from ipng?

System Administrator wrote:

Your message

  To:      ipng-dist4T
  Subject: ( 1$0m ) @|1b?B59FG3Z ?B<v?B59FG3Z
  Sent:    Thu, 28 Mar 2002 08:56:02 +0100

did not reach the following recipient(s):

mmartin@teldat.es on Thu, 28 Mar 2002 09:10:18 +0100
    The recipient name is not recognized
        The MTS-ID of the original message is: c=us;a=
;p=teldat;l=CORREO0203280810HT45DC8P
    MSEXCH:IMS:TELDAT:TEL01:CORREO 0 (000C05A6) Unknown Recipient

  ------------------------------------------------------------------------

Subject: ( 1$0m ) @|1b?B59FG3Z ?B<v?B59FG3Z
Date: Thu, 28 Mar 2002 08:56:02 +0100
From: "@LEBH#" <lch5101@korea.com>
To: ipng-dist4T <ipng-dist@sunroof.eng.sun.com>

 <http://www.anne114.com/co052/052010323010.htm>

 <http://www.anne114.com/co052/052010323010.htm>

 <http://www.anne114.com/co052/052010323010.htm>
<http://www.anydm.co.kr/taehwa/img40_title1.gif>

 <http://www.anne114.com/co052/052010323010.htm>
 
 

 <http://www.anne114.com/co052/052010323010.htm>

È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.

  <http://www.anydm.co.kr/taehwa/img50_title2.gif>

  <http://www.anydm.co.kr/taehwa/img100.gif>

±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿©
ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ
À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù
 
 

 <http://www.anne114.com/co052/052010323010.htm>

  <http://www.anydm.co.kr/taehwa/img60_title3.gif>

 <http://www.anne114.com/co052/052010323010.htm>
 
 

  <http://www.anydm.co.kr/taehwa/img120.gif>

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.

  <http://www.anydm.co.kr/taehwa/img130.gif>
  <C:dot1.gif>
   <http://www.anne114.com/co052/052010323010.htm>

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.
<mailto:lch5101@korea.com?subject=¼ö½Å°ÅºÎ&body=´õÀÌ»ó ¸ÞÀÏÀ» º¸³»Áö
¸¶¼¼¿ä>

 Homepage : www.anne114.co.kr   /   Email :
<mailto:lch5101@korea.com?subject=¹®ÀǸÞÀÏ> lch5101@korea.com
Copyright¨Ï 2002  anne114.com  All right reserved.

--------------B923F501F28DA58C4C8749BB-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 01:07:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S97FKL017660 for ; Thu, 28 Mar 2002 01:07:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2S97FmF017659 for ipng-dist; Thu, 28 Mar 2002 01:07:15 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S97CKL017652 for ; Thu, 28 Mar 2002 01:07:12 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA11249 for ; Thu, 28 Mar 2002 01:07:14 -0800 (PST) Received: from ws177.nomadiclab.com (teldanex.hiit.fi [212.68.5.99]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA21326 for ; Thu, 28 Mar 2002 02:07:13 -0700 (MST) Received: from nomadiclab.com (cube.local.nikander.com [192.168.0.33]) by ws177.nomadiclab.com (Postfix) with ESMTP id 78714A; Thu, 28 Mar 2002 11:08:55 +0200 (EET) Message-ID: <3CA2DD5C.4050502@nomadiclab.com> Date: Thu, 28 Mar 2002 11:07:40 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.9+) Gecko/20020313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Hesham Soliman (ERA)" Cc: Brian E Carpenter , gab@Sun.COM, Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Using "a bit" as a protection against bidding down / for something else References: <4DA6EA82906FD511BE2F00508BCF053803C0747E@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hesham, Brian and others, [Note that I've changed the subject, since we are not really speaking about bit reservation/allocation any more.] > => I have to add myself to the list of tired/jetlagged > people :). But, in the scenario you mention, it seems to > me that Alice will not end up talking to Bob and Bob > will not end up talking to Alice. And both will not end > up talking to the MITM anyway. > In fact, If the MITM modified the first message in the, > lets call it SA establishment, then this SA establishment > will fail. If it was the last message that was modified > then it will also fail because the message will be > inconsistent with the intial ones. So it seems to me > like a classic DoS attack. Nothing we can do here. > What am I missing? Well, the devil seems to lie in the details, as usual. If we make either Alice or Bob *committing* to the stronger scheme before Alice contacts Bob, we seem to be safe enough. That we may do in Mobile IPv6, but that does not, as such, require bit allocation. That is, in the case that one of the parties has a priori decided not to support Return Routability (RR), they just end up not doing Route Optimization if there is an attacker on the path. I find that acceptable. Now that the "bit method" has been on the table for some time, I more and more think that the whole issue has its roots in the insecurity of Return Routability (RR). The insecurity of RR creates the so called bombing and future bombing attacks (see the DT writeups), and perhaps other vulnerabilities that we just don't know yet. Thus, the real issue wrt RR is to make stationary hosts protected against these attacks. The current RR design, with its 5-10 minute maximum binding lifetime, restricts an attacker's ability to perform the bombing attacks, but it does not completely remove the threat either. The "bit method" would provide protection for the stationary hosts, but there are also other alternatives. Besides, the "bit method" does not protect against bombing sites, it just protects against bombing hosts. OTOH, as Brian has pointed out, the bit method does not provide adequate protection against MitM bidding down in general. Thus, _allocating_ a bit for _generic_ bidding down protection just does not seem to work well enough. There are scenarios where it seems to work, at least to an extend, but there are also scenarios where it does not. Consequently, I need to withdraw my generalizations and my suggestion that it could be used as a generic bidding down protection scheme. Thanks, Brian, for forcing me to think harder. It is a completely other issue then to _reserve_ a bit or a bit pattern for future use, as Erik has suggested. The so called "generic CGA" or "symmetric CGA" idea, originally my Michael Roe, I guess, may have some value and may need such a bit to be reserved. The basic "generic CGA" is to use an RFC3041 interface id to convey semantics: iid = hash(SEMANTICS, RND) where SEMANTICS = a string describing some semantics for the address, possibly together with some parameters RND = a freshly generated random number Using this Alice, Alice contacting Bob would send an initial packet that contains a Destination Option (DO) that carries the string and the random number. Bob recieving the message recognized the DO, hashes together SEMANTICS and RND, and compares the interface id to the hash result. Again, when Alice and Bob are far from each other, a MitM could remove the DO altogether, and change the iid, too. Thus, in this case reserving a bit seems to fail, again. However, if the generic CGA idea is used at the local link, instead, the attacker may not have the option of changing the iid or the packet. OTOH, an attacker can certainly claim the iid to itself, _possibly_ leading to problems with backward compatibility. I think this all needs much more thinking and analysis. It just seems likely that later using a bit to indicate that an iid encodes semantics may be a good idea, due to the desire to be *backward compatible*. If we do not care about backward compatibility, there is no need for any bits ever, it's just that we *may* want to make a distinction between "old" iids and "new" iids. But maybe it is just easier to update RFC3041, and make all hosts "new", and not to worry about RFC3041 backward compatibility. --Pekka Nikander -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From MAILER-DAEMON Thu Mar 28 01:35:30 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S9ZUKL017740 for ; Thu, 28 Mar 2002 01:35:30 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA16829 for ; Thu, 28 Mar 2002 01:35:32 -0800 (PST) Received: from almso2.proxy.att.com (almso2.att.com [192.128.166.71]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA26877 for ; Thu, 28 Mar 2002 01:35:17 -0800 (PST) Received: from gbpormsx01.emea.att.com ([135.76.31.25]) by almso2.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id g2S9ZU924521 for ; Thu, 28 Mar 2002 04:35:30 -0500 (EST) Received: by gbpormsx01.emea.att.com with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 09:35:37 -0000 Message-ID: <646130FF030FDD4CA2C6608D714A489E03CB3D0E@gbredmsx01.emea.att.com> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqLmocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQairb6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 09:35:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D63B.EA29597C" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D63B.EA29597C Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist?O Subject: ( =A1=BE=A2=E6=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=ABo=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 07:56:02 -0000 did not reach the following recipient(s): Bertrand.Buclin@ch.att.com on Thu, 28 Mar 2002 09:35:23 -0000 The recipient name is not recognized The MTS-ID of the original message is: c=3Dus;a=3D ;p=3Datt;l=3DGBREDMSX010203280935GRLFKS1L MSEXCH:IMS:ATT:EMEA:GBREDMSX01 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D63B.EA29597C Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: ipng-dist?O Subject: =?euc-kr?B?KCChvqLmocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQairb6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 07:56:02 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-MS-Embedded-Report: Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D63B.EA29597C-- From MAILER-DAEMON Thu Mar 28 01:59:35 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S9xZKL017817 for ; Thu, 28 Mar 2002 01:59:35 -0800 (PST) Received: from mercury.Sun.COM (mercury.EBay.Sun.COM [129.150.69.1]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA20438 for ; Thu, 28 Mar 2002 01:59:38 -0800 (PST) Received: from localhost (localhost) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with internal id AAJ05199; Thu, 28 Mar 2002 01:59:37 -0800 (PST) Date: Thu, 28 Mar 2002 01:59:37 -0800 (PST) From: Mail Delivery Subsystem Message-Id: <200203280959.AAJ05199@mercury.Sun.COM> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="AAJ05199.1017309577/mercury.Sun.COM" Content-Transfer-Encoding: 8bit Subject: Returned mail: Service unavailable Auto-Submitted: auto-generated (failure) This is a MIME-encapsulated message --AAJ05199.1017309577/mercury.Sun.COM The original message was received at Wed, 27 Mar 2002 23:57:34 -0800 (PST) from [129.144.170.5] ----- The following addresses had permanent fatal errors ----- ----- Transcript of session follows ----- ... while talking to mail.o2.com.: >>> DATA <<< 554 Invalid data in message 554 ... Service unavailable --AAJ05199.1017309577/mercury.Sun.COM Content-Type: message/delivery-status Reporting-MTA: dns; mercury.Sun.COM Arrival-Date: Wed, 27 Mar 2002 23:57:34 -0800 (PST) Final-Recipient: RFC822; Alexandre.Harmand@o2.com Action: failed Status: 5.0.0 Remote-MTA: DNS; mail.o2.com Diagnostic-Code: SMTP; 554 Invalid data in message Last-Attempt-Date: Thu, 28 Mar 2002 01:59:37 -0800 (PST) --AAJ05199.1017309577/mercury.Sun.COM Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27703; Wed, 27 Mar 2002 23:57:34 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13057; Wed, 27 Mar 2002 23:57:23 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--AAJ05199.1017309577/mercury.Sun.COM-- From MAILER-DAEMON Thu Mar 28 02:04:25 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SA4PKL017827 for ; Thu, 28 Mar 2002 02:04:25 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA21377 for ; Thu, 28 Mar 2002 02:04:27 -0800 (PST) Received: from mast-dc0-sm03.private.ntl.com (cabletel1.cableol.net [194.168.3.4]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA28027 for ; Thu, 28 Mar 2002 03:04:25 -0700 (MST) Received: from gbcwcwari001.isops.cwcom.co.uk (unverified) by mast-dc0-sm03.private.ntl.com (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Thu, 28 Mar 2002 10:04:24 +0000 Received: by gbcwcwari001.isops.cwcom.co.uk with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 10:05:59 -0000 Message-ID: <4BA9FC43AED4D3119CCB00805F193B07043D9E59@gbcwcwari002.isops.cwcom.co.uk> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: Undeliverable: ( 1$0m ) @|1b?B59FG3Z ?B From: "@LEBH#" To: ipng-dist4T Subject: ( 1$0m ) @|1b?B59FG3Z ?B; Thu, 28 Mar 2002 02:06:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SA6ADv017843 for ipng-dist; Thu, 28 Mar 2002 02:06:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SA67KL017836 for ; Thu, 28 Mar 2002 02:06:07 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA28754 for ; Thu, 28 Mar 2002 02:06:09 -0800 (PST) Received: from epo.stelvio.nl (epo.stelvio.nl [62.58.1.135]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA28792 for ; Thu, 28 Mar 2002 03:06:09 -0700 (MST) Received: from Moya (tunnel.stelvio.nl [62.58.1.10]) by epo.stelvio.nl (Postfix) with ESMTP id 391E41F; Thu, 28 Mar 2002 11:06:08 +0100 (CET) Received: from stelvio.nl (Moya [127.0.0.1]) by Moya (Postfix) with ESMTP id A314C52B07; Thu, 28 Mar 2002 11:06:00 +0100 (CET) Message-ID: <3CA2EB08.5040502@stelvio.nl> Date: Thu, 28 Mar 2002 11:06:00 +0100 From: Menno Pieters Reply-To: menno.pieters@stelvio.nl Organization: M&I/Stelvio User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020214 X-Accept-Language: nl, nl-BE, en, af, de MIME-Version: 1.0 To: ryane@cogeco.ca Cc: "ipng@sunroof.eng.sun.com" Subject: [off-topic] Re: Undeliverable: ( 1$0m ) @|1b?B59FG3Z ?B <3CA2D922.64025E8E@cgocable.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ryan elson wrote: > almost 30 of these. Why am I getting junk in my inbox from ipng? Lucky you, only 30? I got over 50 already. It seems some spammer has abused the address ipng-dist@sunroof.eng.sun.com as a From:-address for spam. It happened to a colleague of mine a few days ago. His mail address was used as the From:-address. I'm getting pretty annoyed by the amounts of spam coming from mostly Korean primary and secondary schools lately, either unreadable to me (my Korean, Chinese and Japanese are not so good, yet...) or claiming it's not spam, I subscribed to their list (yeah, sure!). I'm afraid, there's (almost) nothing we can do about it, except changing mail addresses... Regards, Menno Pieters -- Menno Pieters - M&I/STELVIO bv Postbus 2171, 3800 CD Amersfoort, the Netherlands Zonnehof 41, 3811 ND Amersfoort, the Netherlands phone: +31-33-4.697.340 / fax: +31-33-4.697.341 XOIP: +31-84-8.720.349 / Web: http://www.stelvio.nl/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 02:16:13 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SAGDKL017906 for ; Thu, 28 Mar 2002 02:16:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SAGDfq017905 for ipng-dist; Thu, 28 Mar 2002 02:16:13 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SAGAKL017898 for ; Thu, 28 Mar 2002 02:16:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00806 for ; Thu, 28 Mar 2002 02:16:13 -0800 (PST) Received: from titan.bieringer.de (mail.bieringer.de [195.226.187.51]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA18014 for ; Thu, 28 Mar 2002 03:16:12 -0700 (MST) Received: (qmail 30944 invoked by uid 89); 28 Mar 2002 10:16:10 -0000 Message-ID: <20020328101610.30943.qmail@titan.bieringer.de> From: "Peter Bieringer" To: ipng@sunroof.eng.sun.com Subject: Bounces? Date: Thu, 28 Mar 2002 10:16:10 GMT Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, did only me get all this bounces or any existing subscriber? 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 Thu Mar 28 02:19:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SAJHKL017938 for ; Thu, 28 Mar 2002 02:19:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SAJHtA017937 for ipng-dist; Thu, 28 Mar 2002 02:19:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SAJEKL017930 for ; Thu, 28 Mar 2002 02:19:14 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA00955 for ; Thu, 28 Mar 2002 02:19:17 -0800 (PST) Received: from paddock.ermy.net (paddock.ermy.net [62.189.30.132]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id DAA19019 for ; Thu, 28 Mar 2002 03:19:16 -0700 (MST) Received: (qmail 7418 invoked from network); 28 Mar 2002 09:55:02 -0000 Received: from unknown (HELO PILCHARD) (127.0.0.1) by localhost with SMTP; 28 Mar 2002 09:55:02 -0000 Message-ID: <02bc01c1d641$5f81b980$0700000a@ecs.soton.ac.uk> From: "Mark Thompson" To: References: <20020328101610.30943.qmail@titan.bieringer.de> Subject: Re: Bounces? Date: Thu, 28 Mar 2002 10:14:38 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id g2SAJEKL017931 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > did only me get all this bounces or any existing subscriber? Oh I think we all got them :-/ mark/ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 02:22:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SAMAKL017978 for ; Thu, 28 Mar 2002 02:22:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SAMAiW017977 for ipng-dist; Thu, 28 Mar 2002 02:22:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SAM6KL017963 for ; Thu, 28 Mar 2002 02:22:06 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01555 for ; Thu, 28 Mar 2002 02:22:09 -0800 (PST) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA20133 for ; Thu, 28 Mar 2002 03:22:08 -0700 (MST) Received: from intpmail.iprc.lucent.com (h135-254-249-250.lucent.com [135.254.249.250]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g2SAM6p05154 for ; Thu, 28 Mar 2002 05:22:06 -0500 (EST) Received: from VIKRAM by intpmail.iprc.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id PAA12686; Thu, 28 Mar 2002 15:52:05 +0530 (IST) From: "Vikram Shekhar" To: Subject: RE: Bounces? Date: Thu, 28 Mar 2002 15:52:02 +0530 Message-ID: <00b801c1d642$679fdc40$afd5fe87@VIKRAM> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <20020328101610.30943.qmail@titan.bieringer.de> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, The problem is because most the existing subscribers do not have a valid e-mail ID and hence any mails sent to those e-mail Ids are getting bounced back. Its not only you Peter...everyone in this group are getting them... cheers... Vikram Shekhar -----Original Message----- From: owner-ipng@sunroof.eng.sun.com [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Peter Bieringer Sent: Thursday, March 28, 2002 3:46 PM To: ipng@sunroof.eng.sun.com Subject: Bounces? Hi, did only me get all this bounces or any existing subscriber? 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From MAILER-DAEMON Thu Mar 28 02:23:42 2002 Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SANfKL018000 for ; Thu, 28 Mar 2002 02:23:41 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA01890 for ; Thu, 28 Mar 2002 02:23:44 -0800 (PST) Received: from honts307.wal-mart.com ([146.132.234.37]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA29988 for ; Thu, 28 Mar 2002 02:23:45 -0800 (PST) Received: from fwnts002-dmz.wal-mart.com (FWNTS002-DMZ [146.132.238.59]) by honts307.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id H48FX2QP; Thu, 28 Mar 2002 04:23:43 -0600 Received: from honts388.homeoffice.wal-mart.com by fwnts002-dmz.wal-mart.com via smtpd (for mailout.wal-mart.com [146.132.235.35]) with SMTP; 28 Mar 2002 10:23:43 UT Received: from honts342.homeoffice.wal-mart.com (unverified) by honts388.homeoffice.wal-mart.com (Content Technologies SMTPRS 4.1.5) with ESMTP id for ; Thu, 28 Mar 2002 04:23:43 -0600 Received: by HONTS342.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Mar 2002 04:23:43 -0600 Received: from honts386.homeoffice.wal-mart.com ([161.173.132.71]) by honts305.homeoffice.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HB8ZX62K; Thu, 28 Mar 2002 04:23:35 -0600 Received: from fwnts002.homeoffice.wal-mart.com (unverified) by HONTS386.homeoffice.Wal-Mart.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 28 Mar 2002 04:23:35 -0600 Received: from honts322.homeoffice.wal-mart.com ([146.132.235.33]) by fwnts002.homeoffice.wal-mart.com via smtpd (for honts380.homeoffice.wal-mart.com [161.173.132.198]) with SMTP; 28 Mar 2002 10:23:35 UT Received: by honts322.wal-mart.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Mar 2002 04:23:35 -0600 Message-ID: <9698E24E610FD311BFE400902745F097197681D7@honts322.wal-mart.com> From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 04:23:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-MS-Embedded-Report: Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D642.9DEBA9DC" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D642.9DEBA9DC Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 01:56:02 -0600 did not reach the following recipient(s): wzaman@wal-mart.com on Thu, 28 Mar 2002 04:23:34 -0600 Unable to deliver the message due to a communications failure The MTS-ID of the original message is: c=3DUS;a=3DATTMAIL;p=3Dwal- mart;l=3DHONTS3220203281023H48HMAX9 MSEXCH:IMS:wal-mart:RETAILLINK:HONTS322 3554 (000B099C) 554 Invalid data in message ------_=_NextPart_000_01C1D642.9DEBA9DC Content-Type: message/rfc822 Message-ID: <200203280756.XAA28194@nwkea-mail-1.sun.com> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 01:56:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-MS-Embedded-Report: Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D642.9DEBA9DC-- From MAILER-DAEMON Thu Mar 28 02:25:46 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SAPkKL018053 for ; Thu, 28 Mar 2002 02:25:46 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA02903 for ; Thu, 28 Mar 2002 02:25:49 -0800 (PST) Received: from MOE.tra.com (t90.tra.com [12.10.2.90]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA21475 for ; Thu, 28 Mar 2002 03:25:48 -0700 (MST) Message-ID: From: System Administrator To: ipng-dist@sunroof.eng.sun.com Subject: =?euc-kr?B?VW5kZWxpdmVyYWJsZTogKCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2?= =?euc-kr?B?qKFDqfhVIKKvQaj5b6KvQaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 04:25:35 -0600 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D642.E5900F76" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D642.E5900F76 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable Your message To: ipng-dist=A2=A5O Subject: ( =A1=BE=A2=B4=A1=C6i ) = Au=A1=BEa=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U = =A2=AFA=A8=F9o=A2=AFA=A5=EC=A9=F6=A8=A1C=A9=F8U Sent: Thu, 28 Mar 2002 01:56:02 -0600 did not reach the following recipient(s): emccoy@tra.com on Thu, 28 Mar 2002 04:25:27 -0600 The recipient name is not recognized The MTS-ID of the original message is: c=3Dus;a=3D ;p=3Dtra;l=3DMOE0203281025HQP623XH MSEXCH:IMS:TRA:MAILEX:MOE 0 (000C05A6) Unknown Recipient ------_=_NextPart_000_01C1D642.E5900F76 Content-Type: message/rfc822 Message-ID: <0d2e38ba040cb707d2@[10.12.1.38]> From: =?euc-kr?B?QUlBQUWhzA==?= To: =?euc-kr?B?aXBuZy1kaXN0oqVP?= Subject: =?euc-kr?B?KCChvqK0ocZpICkgQXWhvmGir0Gl7Kn2qKFDqfhVIKKvQaj5b6Kv?= =?euc-kr?B?QaXsqfaooUOp+FU=?= Date: Thu, 28 Mar 2002 01:56:02 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 DQogPGh0dHA6Ly93d3cuYW5uZTExNC5jb20vY28wNTIvMDUyMDEwMzIzMDEwLmh0bT4gDQoNCg0K IDxodHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQoNCiA8 aHR0cDovL3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPg0KPGh0dHA6Ly93 d3cuYW55ZG0uY28ua3IvdGFlaHdhL2ltZzQwX3RpdGxlMS5naWY+IA0KDQoNCg0KIDxodHRwOi8v d3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCiA8aHR0cDov L3d3dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KDQoNCsitvLrGx7Pa wMcgMjCz4iCw5sfosPogseK8+rfOIMDMt+jH2LO9IA0Kv/i48bi2t+fA57fOvK0gv8K1ubnovLGw +iC/+LjxuLa357ChIMDPw7zIrbXHvu4NCrHiwbggwsq4trfnIL3DsPiw+rTCILTeuK4gvcOw+MDM ILCjxu3Hz7DtIL7IwPwNCsfPuOcgv+7A+7/cvLHAuLfOILDHsK2wocH2ILv9sKLHz7TCIA0Ksbmz uyDD1sPKwMcgxq/H48DnwNS0z7TZLg0KDQogIDxodHRwOi8vd3d3LmFueWRtLmNvLmtyL3RhZWh3 YS9pbWc1MF90aXRsZTIuZ2lmPiANCg0KDQoNCiAgPGh0dHA6Ly93d3cuYW55ZG0uY28ua3IvdGFl aHdhL2ltZzEwMC5naWY+IA0KDQoNCrHiwbjAxyDDtsbHxsez2r+hvK0gs6q5qyjH1cbHKcbHs9q3 ziCws7nftce+7iC6ubvnv623ziDAzsfRIMjGseKwoSCwobXmx8+/qQ0KwM7DvL+hILChwOUgwK/A zcfRICCzrbnmwOfA1LTPtNkuDQoNCsO2xsfGx7PawMcgsqjB/CDH9rvzwLsgv8+6rsfPsNQguri/ z8fPv6kgsqjB/CDH9rvzwMwgvvjAuLjnILSpwPzAzLOqILCowPzAxw0KwKfH6MDMIL74vu4gw9aw 7cDHIL7IwPy8usC7IMiuurjHz7+0vcC0z7TZLg0KDQq8vLbzuc0sIML8vaGw+iCzqrmrwMcgsOHH 1cC4t84gwM7DvMDHIMCvwM3H0SC/+MD7v9wgvLHAuyC55sPix9W0z7TZLiANCr3DsPjAzCCwo8bt x8+/qSC058DPvcOw+CC058DPs6255sDMILChtMkNCsfVtM+02Q0KDQogDQoNCiA8aHR0cDovL3d3 dy5hbm5lMTE0LmNvbS9jbzA1Mi8wNTIwMTAzMjMwMTAuaHRtPiANCg0KICA8aHR0cDovL3d3dy5h bnlkbS5jby5rci90YWVod2EvaW1nNjBfdGl0bGUzLmdpZj4gDQoNCg0KIDxodHRwOi8vd3d3LmFu bmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+IA0KDQogDQoNCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTIwLmdpZj4gDQoNCsiuvcfI9yC03rbzwfggyLLF5Lnm IL/CvPa/wrW5wLogv++3t7DFuLLAzCC++LDtIL7GwdYgsN+w7cfVtM+02S4NCrHiwbggwba4s73E v8K1ucDHILmuwabBobXpwMwguPC1ziCws7yxx9EgDQq9xbD4uf0gwLi3ziC8s8ShuvG/68DMIL3A vcS5zMDlsPi5/cDHILz2wdiw+iCwsMDMIL7GwdYgwPq3xcfVtM+02S4NCg0KICA8aHR0cDovL3d3 dy5hbnlkbS5jby5rci90YWVod2EvaW1nMTMwLmdpZj4gDQogIDxDOmRvdDEuZ2lmPiANCiAgIDxo dHRwOi8vd3d3LmFubmUxMTQuY29tL2NvMDUyLzA1MjAxMDMyMzAxMC5odG0+ICAgDQoNCg0Ku+fA /CDH47b0IL74wMwguN7Az8C7ILq4s70gwaEgwcu828fPv8C45yC43sDPwLsgILz2vcXHz8H2IL7K wLi3wbjpICANCrz2vcUgsMW6zrimIMWsuK/H2CDB1r3DuOkgsKi757XluK6w2r3AtM+02S4NCjxt YWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD289r3FsMW6ziZib2R5PbT1wMy78yC43sDP wLsgurizu8H2DQq4try8v+Q+IA0KDQoNCiBIb21lcGFnZSA6IHd3dy5hbm5lMTE0LmNvLmtyICAg LyAgIEVtYWlsIDoNCjxtYWlsdG86bGNoNTEwMUBrb3JlYS5jb20/c3ViamVjdD25rsDHuN7Azz4g bGNoNTEwMUBrb3JlYS5jb20gDQpDb3B5cmlnaHSozyAyMDAyICBhbm5lMTE0LmNvbSAgQWxsIHJp Z2h0IHJlc2VydmVkLiANCg0KDQo= ------_=_NextPart_000_01C1D642.E5900F76-- From MAILER-DAEMON Thu Mar 28 04:10:43 2002 Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCAgKL018437 for ; Thu, 28 Mar 2002 04:10:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA17120 for ; Thu, 28 Mar 2002 04:10:44 -0800 (PST) Received: from slab.telia.net (balrog.slab.telia.net [195.67.62.250]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA11806 for ; Thu, 28 Mar 2002 05:10:42 -0700 (MST) Received: from localhost (localhost) by slab.telia.net (8.9.1/8.9.1) with internal id NAD10702; Thu, 28 Mar 2002 13:10:36 +0100 (MET) Date: Thu, 28 Mar 2002 13:10:36 +0100 (MET) From: Mail Delivery Subsystem Message-Id: <200203281210.NAD10702@slab.telia.net> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="NAD10702.1017317436/slab.telia.net" Content-Transfer-Encoding: 8bit Subject: Warning: could not send message for past 4 hours Auto-Submitted: auto-generated (warning-timeout) This is a MIME-encapsulated message --NAD10702.1017317436/slab.telia.net ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Thu, 28 Mar 2002 08:57:16 +0100 (MET) from mercury.Sun.COM [192.9.25.1] ----- The following addresses had transient non-fatal errors ----- anders@rockis.internet42.com (expanded from: ) ----- Transcript of session follows ----- anders@rockis.internet42.com... Deferred: No route to host Warning: message still undelivered after 4 hours Will keep trying until message is 5 days old --NAD10702.1017317436/slab.telia.net Content-Type: message/delivery-status Reporting-MTA: dns; slab.telia.net Arrival-Date: Thu, 28 Mar 2002 08:57:16 +0100 (MET) Final-Recipient: RFC822; X-Actual-Recipient: RFC822; anders@rockis.internet42.com Action: delayed Status: 4.4.1 Remote-MTA: DNS; rockis.internet42.com Last-Attempt-Date: Thu, 28 Mar 2002 13:10:36 +0100 (MET) Will-Retry-Until: Tue, 2 Apr 2002 09:57:16 +0100 (MET) --NAD10702.1017317436/slab.telia.net Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by slab.telia.net (8.9.1/8.9.1) with ESMTP id IAA10362 for ; Thu, 28 Mar 2002 08:57:16 +0100 (MET) Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27635; Wed, 27 Mar 2002 23:56:57 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12964; Wed, 27 Mar 2002 23:56:47 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--NAD10702.1017317436/slab.telia.net-- From MAILER-DAEMON Thu Mar 28 04:11:41 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCBfKL018455 for ; Thu, 28 Mar 2002 04:11:41 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA29975 for ; Thu, 28 Mar 2002 04:11:43 -0800 (PST) Received: from localhost (localhost) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with internal id EAP02040; Thu, 28 Mar 2002 05:11:43 -0700 (MST) Date: Thu, 28 Mar 2002 05:11:43 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203281211.EAP02040@kathmandu.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="EAP02040.1017317503/kathmandu.sun.com" Content-Transfer-Encoding: 8bit Subject: Warning: could not send message for past 4 hours Auto-Submitted: auto-generated (warning-timeout) This is a MIME-encapsulated message --EAP02040.1017317503/kathmandu.sun.com ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Thu, 28 Mar 2002 00:58:37 -0700 (MST) from [129.144.170.5] ----- The following addresses had transient non-fatal errors ----- ----- Transcript of session follows ----- ... while talking to mailhub1.axion.bt.co.uk.: >>> DATA <<< 451 4.3.0 Bad handshake ... while talking to mailhub2.axion.bt.co.uk.: >>> DATA <<< 451 4.3.0 Bad handshake ... while talking to mailhub7.axion.bt.co.uk.: >>> DATA <<< 451 4.3.0 Bad handshake ... while talking to mailhub8.axion.bt.co.uk.: >>> DATA <<< 451 4.3.0 Bad handshake ... while talking to mailhub6.axion.bt.co.uk.: >>> DATA <<< 451 4.3.0 Bad handshake ... while talking to mailhub5.axion.bt.co.uk.: >>> DATA <<< 451 4.3.0 Bad handshake ... while talking to mailhub3.axion.bt.co.uk.: >>> DATA <<< 451 4.3.0 Bad handshake ... while talking to mailhub4.axion.bt.co.uk.: >>> DATA <<< 451 4.3.0 Bad handshake ... Deferred: 451 4.3.0 Bad handshake Warning: message still undelivered after 4 hours Will keep trying until message is 3 days old --EAP02040.1017317503/kathmandu.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; kathmandu.sun.com Arrival-Date: Thu, 28 Mar 2002 00:58:37 -0700 (MST) Final-Recipient: RFC822; gary@jungle.bt.co.uk Action: delayed Status: 4.3.0 Remote-MTA: DNS; mailhub4.axion.bt.co.uk Diagnostic-Code: SMTP; 451 4.3.0 Bad handshake Last-Attempt-Date: Thu, 28 Mar 2002 05:11:43 -0700 (MST) Will-Retry-Until: Sun, 31 Mar 2002 00:58:37 -0700 (MST) --EAP02040.1017317503/kathmandu.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA24211; Thu, 28 Mar 2002 00:58:37 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13028; Wed, 27 Mar 2002 23:57:17 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--EAP02040.1017317503/kathmandu.sun.com-- From owner-ipng@sunroof.eng.sun.com Thu Mar 28 04:14:09 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCE8KL018480 for ; Thu, 28 Mar 2002 04:14:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SCE82R018479 for ipng-dist; Thu, 28 Mar 2002 04:14:08 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCE5KL018472 for ; Thu, 28 Mar 2002 04:14:05 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA19131 for ; Thu, 28 Mar 2002 04:14:07 -0800 (PST) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA02129 for ; Thu, 28 Mar 2002 05:14:05 -0700 (MST) Received: from jpxiong (infonet.ipv6.ustc.edu.cn [202.38.75.75]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id UAA22308 for ; Thu, 28 Mar 2002 20:11:45 +0800 Message-Id: <200203281211.UAA22308@mx1.ustc.edu.cn> Date: Thu, 28 Mar 2002 20:9:18 +0800 From: jpxiong To: "ipng@sunroof.eng.sun.com" Subject: Are there Multicast route protocols for IPv6? X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="US_ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi,everyone! There are many multicast route protocols for IPv4 ,eg PIM-SM,MOSPF and DVMRP.And I wonder whether those protocols can used in IPv6. Thinks very much Thompson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From MAILER-DAEMON Thu Mar 28 04:18:31 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCIVKL018502 for ; Thu, 28 Mar 2002 04:18:31 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA01764 for ; Thu, 28 Mar 2002 04:18:33 -0800 (PST) Received: from localhost (localhost) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with internal id EAT02040; Thu, 28 Mar 2002 05:18:33 -0700 (MST) Date: Thu, 28 Mar 2002 05:18:33 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203281218.EAT02040@kathmandu.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="EAT02040.1017317913/kathmandu.sun.com" Content-Transfer-Encoding: 8bit Subject: Warning: could not send message for past 4 hours Auto-Submitted: auto-generated (warning-timeout) This is a MIME-encapsulated message --EAT02040.1017317913/kathmandu.sun.com ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Thu, 28 Mar 2002 01:00:02 -0700 (MST) from [129.144.170.5] ----- The following addresses had transient non-fatal errors ----- ----- Transcript of session follows ----- ... Deferred: Connection timed out with mail.rediffmail.com. Warning: message still undelivered after 4 hours Will keep trying until message is 3 days old --EAT02040.1017317913/kathmandu.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; kathmandu.sun.com Arrival-Date: Thu, 28 Mar 2002 01:00:02 -0700 (MST) Final-Recipient: RFC822; rama_krishnans@rediffmail.com Action: delayed Status: 4.4.1 Remote-MTA: DNS; mail.rediffmail.com Last-Attempt-Date: Thu, 28 Mar 2002 05:18:33 -0700 (MST) Will-Retry-Until: Sun, 31 Mar 2002 01:00:02 -0700 (MST) --EAT02040.1017317913/kathmandu.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA24722; Thu, 28 Mar 2002 01:00:02 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13028; Wed, 27 Mar 2002 23:57:17 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--EAT02040.1017317913/kathmandu.sun.com-- From MAILER-DAEMON Thu Mar 28 04:24:25 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCOPKL018626 for ; Thu, 28 Mar 2002 04:24:25 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA03257 for ; Thu, 28 Mar 2002 04:24:26 -0800 (PST) Received: from localhost (localhost) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with internal id EAU02040; Thu, 28 Mar 2002 05:24:26 -0700 (MST) Date: Thu, 28 Mar 2002 05:24:26 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203281224.EAU02040@kathmandu.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="EAU02040.1017318266/kathmandu.sun.com" Content-Transfer-Encoding: 8bit Subject: Warning: could not send message for past 4 hours Auto-Submitted: auto-generated (warning-timeout) This is a MIME-encapsulated message --EAU02040.1017318266/kathmandu.sun.com ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Thu, 28 Mar 2002 00:57:31 -0700 (MST) from [129.144.170.5] ----- The following addresses had transient non-fatal errors ----- ----- Transcript of session follows ----- ... Deferred: Connection reset by mailhub4.axion.bt.co.uk. Warning: message still undelivered after 4 hours Will keep trying until message is 3 days old --EAU02040.1017318266/kathmandu.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; kathmandu.sun.com Arrival-Date: Thu, 28 Mar 2002 00:57:31 -0700 (MST) Final-Recipient: RFC822; matthew.ford@bt.com Action: delayed Status: 4.3.0 Remote-MTA: DNS; mailhub4.axion.bt.co.uk Diagnostic-Code: SMTP; 451 4.3.0 Bad handshake Last-Attempt-Date: Thu, 28 Mar 2002 05:24:26 -0700 (MST) Will-Retry-Until: Sun, 31 Mar 2002 00:57:31 -0700 (MST) --EAU02040.1017318266/kathmandu.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23794; Thu, 28 Mar 2002 00:57:31 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13128; Wed, 27 Mar 2002 23:57:27 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--EAU02040.1017318266/kathmandu.sun.com-- From MAILER-DAEMON Thu Mar 28 04:32:54 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCWsKL018724 for ; Thu, 28 Mar 2002 04:32:54 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05671 for ; Thu, 28 Mar 2002 04:32:56 -0800 (PST) Received: from localhost (localhost) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with internal id EAV02040; Thu, 28 Mar 2002 05:32:56 -0700 (MST) Date: Thu, 28 Mar 2002 05:32:56 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203281232.EAV02040@kathmandu.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="EAV02040.1017318776/kathmandu.sun.com" Content-Transfer-Encoding: 8bit Subject: Warning: could not send message for past 4 hours Auto-Submitted: auto-generated (warning-timeout) This is a MIME-encapsulated message --EAV02040.1017318776/kathmandu.sun.com ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Thu, 28 Mar 2002 00:57:35 -0700 (MST) from [129.144.170.5] ----- The following addresses had transient non-fatal errors ----- ----- Transcript of session follows ----- ... Deferred: Connection reset by mailhub4.axion.bt.co.uk. Warning: message still undelivered after 4 hours Will keep trying until message is 3 days old --EAV02040.1017318776/kathmandu.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; kathmandu.sun.com Arrival-Date: Thu, 28 Mar 2002 00:57:35 -0700 (MST) Final-Recipient: RFC822; jonathan.2.stevens@bt.com Action: delayed Status: 4.3.0 Remote-MTA: DNS; mailhub4.axion.bt.co.uk Diagnostic-Code: SMTP; 451 4.3.0 Bad handshake Last-Attempt-Date: Thu, 28 Mar 2002 05:32:56 -0700 (MST) Will-Retry-Until: Sun, 31 Mar 2002 00:57:35 -0700 (MST) --EAV02040.1017318776/kathmandu.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23817; Thu, 28 Mar 2002 00:57:35 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13128; Wed, 27 Mar 2002 23:57:27 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--EAV02040.1017318776/kathmandu.sun.com-- From MAILER-DAEMON Thu Mar 28 04:38:12 2002 Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCcBKL018938 for ; Thu, 28 Mar 2002 04:38:12 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA08330 for ; Thu, 28 Mar 2002 04:38:14 -0800 (PST) Received: from localhost (localhost) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with internal id EAY02040; Thu, 28 Mar 2002 05:38:13 -0700 (MST) Date: Thu, 28 Mar 2002 05:38:13 -0700 (MST) From: Mail Delivery Subsystem Message-Id: <200203281238.EAY02040@kathmandu.sun.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="EAY02040.1017319093/kathmandu.sun.com" Content-Transfer-Encoding: 8bit Subject: Warning: could not send message for past 4 hours Auto-Submitted: auto-generated (warning-timeout) This is a MIME-encapsulated message --EAY02040.1017319093/kathmandu.sun.com ********************************************** ** THIS IS A WARNING MESSAGE ONLY ** ** YOU DO NOT NEED TO RESEND YOUR MESSAGE ** ********************************************** The original message was received at Thu, 28 Mar 2002 00:56:49 -0700 (MST) from [129.144.170.5] ----- The following addresses had transient non-fatal errors ----- ----- Transcript of session follows ----- ... Deferred: Connection reset by iabgfw.iabg.de. Warning: message still undelivered after 4 hours Will keep trying until message is 3 days old --EAY02040.1017319093/kathmandu.sun.com Content-Type: message/delivery-status Reporting-MTA: dns; kathmandu.sun.com Arrival-Date: Thu, 28 Mar 2002 00:56:49 -0700 (MST) Final-Recipient: RFC822; gessler@iabg.de Action: delayed Status: 4.4.2 Remote-MTA: DNS; iabgfw.iabg.de Last-Attempt-Date: Thu, 28 Mar 2002 05:38:13 -0700 (MST) Will-Retry-Until: Sun, 31 Mar 2002 00:56:49 -0700 (MST) --EAY02040.1017319093/kathmandu.sun.com Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Return-Path: Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23556; Thu, 28 Mar 2002 00:56:49 -0700 (MST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA12957; Wed, 27 Mar 2002 23:56:44 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--EAY02040.1017319093/kathmandu.sun.com-- From owner-ipng@sunroof.eng.sun.com Thu Mar 28 04:40:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCekKL018958 for ; Thu, 28 Mar 2002 04:40:46 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SCekLS018957 for ipng-dist; Thu, 28 Mar 2002 04:40:46 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCegKL018950 for ; Thu, 28 Mar 2002 04:40:42 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22088 for ; Thu, 28 Mar 2002 04:40:44 -0800 (PST) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA11288 for ; Thu, 28 Mar 2002 05:40:42 -0700 (MST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 28 Mar 2002 18:28:31 +0530 Received: from chakraa (chakraa.future.futsoft.com [10.4.7.5]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g2SCe6e12138 for ; Thu, 28 Mar 2002 18:10:06 +0530 Reply-To: From: "chakri" To: Subject: ioctl for nd cache Date: Thu, 28 Mar 2002 18:02:30 +0530 Message-Id: <00d201c1d654$a15ce060$0507040a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I am looking for a solution to get the destination machine's MAC address from an IPv6 socket-application. In IPv4, I was using the 'arpping' utility to generate ARP requests. When the ARP cache is updated with the ARP response, i use the ioctl () call to fetch the required entry thus getting the MAC address. What if i have to do a similar stuff in IPv6 application? Is there any utility to generate ND neighbour solicit messages? How to fetch the entries from the ND cache? I am using Linux 7.1 kernel 2.4.2. I dont see the command 'ndp' with this. Can I install any library to get full IPv6 support? Any pointers regarding this will be appreciated. Thanks, Chakri *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 04:45:26 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCjQKL018983 for ; Thu, 28 Mar 2002 04:45:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SCjQlm018982 for ipng-dist; Thu, 28 Mar 2002 04:45:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCjMKL018975 for ; Thu, 28 Mar 2002 04:45:23 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA22839 for ; Thu, 28 Mar 2002 04:45:24 -0800 (PST) Received: from Mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA25316 for ; Thu, 28 Mar 2002 05:45:24 -0700 (MST) Received: from lorien.sc.innovationslab.net ([24.162.252.183]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Thu, 28 Mar 2002 07:44:29 -0500 Message-ID: <3CA3104C.44AE1FA5@lorien.sc.innovationslab.net> Date: Thu, 28 Mar 2002 07:45:00 -0500 From: Brian Haberman X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jpxiong CC: "ipng@sunroof.eng.sun.com" Subject: Re: Are there Multicast route protocols for IPv6? References: <200203281211.UAA22308@mx1.ustc.edu.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The updated PIM-SM spec contains support for IPv6. Take a look at http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-05.txt. Also, OSPFv3 (OSPF for IPv6) supports multicast as well, that is available at http://www.ietf.org/rfc/rfc2740.txt. Regards, Brian jpxiong wrote: > > hi,everyone! > There are many multicast route protocols for IPv4 ,eg PIM-SM,MOSPF and DVMRP.And I wonder whether those protocols can used in IPv6. > Thinks very much > Thompson > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 28 04:57:46 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCvjKL019118 for ; Thu, 28 Mar 2002 04:57:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SCvje9019117 for ipng-dist; Thu, 28 Mar 2002 04:57:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SCvgKL019110 for ; Thu, 28 Mar 2002 04:57:42 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA12496 for ; Thu, 28 Mar 2002 04:57:44 -0800 (PST) Received: from yue.hongo.wide.ad.jp (yue.hongo.wide.ad.jp [203.178.139.94]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA12541 for ; Thu, 28 Mar 2002 05:57:43 -0700 (MST) Received: from localhost (yoshfuji@localhost [127.0.0.1]) by yue.hongo.wide.ad.jp (8.9.3+3.2W/8.9.3/Debian 8.9.3-21) with ESMTP id VAA23978; Thu, 28 Mar 2002 21:57:41 +0900 To: chakraa@future.futsoft.com Cc: ipng@sunroof.eng.sun.com Subject: Re: ioctl for nd cache In-Reply-To: <00d201c1d654$a15ce060$0507040a@future.futsoft.com> References: <00d201c1d654$a15ce060$0507040a@future.futsoft.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.1 (AOI) X-URL: http://www.yoshifuji.org/%7Ehideaki/ X-Fingerprint: 90 22 65 EB 1E CF 3A D1 0B DF 80 D8 48 07 F8 94 E0 62 0E EA X-PGP-Key-URL: http://www.yoshifuji.org/%7Ehideaki/hideaki@yoshifuji.org.asc Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020328215741Z.yoshfuji@linux-ipv6.org> Date: Thu, 28 Mar 2002 21:57:41 +0900 From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= X-Dispatcher: imput version 991025(IM133) Lines: 8 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I do not understand what "full IPv6 support" means. Anyway, just FYI, we, USAGI Project are trying to implement ndp command using rtnetlink(7). And, of course, you can send/recv ICMPv6 packet via raw socket. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 05:06:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SD6jKL019224 for ; Thu, 28 Mar 2002 05:06:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SD6jn0019223 for ipng-dist; Thu, 28 Mar 2002 05:06:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SD6gKL019216 for ; Thu, 28 Mar 2002 05:06:42 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA14443 for ; Thu, 28 Mar 2002 05:06:44 -0800 (PST) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08502 for ; Thu, 28 Mar 2002 06:06:43 -0700 (MST) Received: from jpxiong (infonet.ipv6.ustc.edu.cn [202.38.75.75]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id UAA24499; Thu, 28 Mar 2002 20:53:05 +0800 Message-Id: <200203281253.UAA24499@mx1.ustc.edu.cn> Date: Thu, 28 Mar 2002 20:50:39 +0800 From: jpxiong To: Brian Haberman CC: "ipng@sunroof.eng.sun.com" Subject: Re: Are there Multicast route protocols for IPv6? X-mailer: FoxMail 3.0 beta 2 [cn] 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 have got it,thinks again. at 2002-3-28 7:45:00 you wrote >The updated PIM-SM spec contains support for IPv6. Take a look at >http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-05.txt. > >Also, OSPFv3 (OSPF for IPv6) supports multicast as well, that is >available at http://www.ietf.org/rfc/rfc2740.txt. > >Regards, >Brian > >jpxiong wrote: >> >> hi,everyone! >> There are many multicast route protocols for IPv4 ,eg PIM-SM,MOSPF and DVMRP.And I wonder whether those protocols can used in IPv6. >> Thinks very much >> Thompson >> >> -------------------------------------------------------------------- >> IETF IPng Working Group Mailing List >> IPng Home 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 Thu Mar 28 05:49:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SDmxKL019297 for ; Thu, 28 Mar 2002 05:48:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SDmxtg019296 for ipng-dist; Thu, 28 Mar 2002 05:48:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SDmuKL019289 for ; Thu, 28 Mar 2002 05:48:56 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA12236 for ; Thu, 28 Mar 2002 05:48:59 -0800 (PST) Received: from infobro.com (black.infobro.com [63.71.25.39]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id GAA24011 for ; Thu, 28 Mar 2002 06:48:58 -0700 (MST) Received: from red (unverified [205.161.100.60]) by infobro.com (EMWAC SMTPRS 0.83) with SMTP id ; Thu, 28 Mar 2002 08:48:13 -0500 Received: by localhost with Microsoft MAPI; Thu, 28 Mar 2002 08:48:11 -0500 Message-ID: <01C1D635.4A6F1850.eric@infobro.com> From: "Eric D. Williams" To: "ipng@sunroof.eng.sun.com" Subject: RE: Bounces? Date: Thu, 28 Mar 2002 08:47:58 -0500 Organization: Information Brokers, Inc. X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Not only that, but for some reason the bounces are being redistributed to the list, that looks to me to be a configuration error. ----- Eric Williams, Pres. Information Brokers, Inc. http://www.infobro.com/ mailto:eric@infobro.com For More Info: info@infobro.com PGP Public Key http://new.infobro.com/KeyServ/EricDWilliams.asc Finger Print: 1055 8AED 9783 2378 73EF 7B19 0544 A590 FF65 B789 On Thursday, March 28, 2002 5:22 AM, Vikram Shekhar [SMTP:vikrams@lucent.com] wrote: > Hi all, > The problem is because most the existing subscribers > do not have a valid e-mail ID and hence any mails sent > to those e-mail Ids are getting bounced back. > > Its not only you Peter...everyone in this group are getting > them... > > cheers... > Vikram Shekhar > > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Peter Bieringer > Sent: Thursday, March 28, 2002 3:46 PM > To: ipng@sunroof.eng.sun.com > Subject: Bounces? > > > Hi, > > did only me get all this bounces or any existing subscriber? > > 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 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Mar 28 06:02:18 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SE2HKL019325 for ; Thu, 28 Mar 2002 06:02:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SE2HcC019324 for ipng-dist; Thu, 28 Mar 2002 06:02:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SE2EKL019317 for ; Thu, 28 Mar 2002 06:02:14 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA04240 for ; Thu, 28 Mar 2002 06:02:16 -0800 (PST) Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.46]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA26648 for ; Thu, 28 Mar 2002 07:02:15 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with SMTP id g2SE2Eoq025139 for ; Thu, 28 Mar 2002 15:02:14 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Mar 28 15:02:09 2002 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Thu, 28 Mar 2002 15:02:10 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053802C6ABC8@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Pekka Nikander'" , "Hesham Soliman (ERA)" Cc: Brian E Carpenter , gab@Sun.COM, Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: RE: Using "a bit" as a protection against bidding down / for some thing else Date: Thu, 28 Mar 2002 15:02:06 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So just to make sure we're on the same wavelength here. The scenario Brian mentioned will not be an issue for bidding down attacks related to mobility. I understand Pekka's note to mean that this bit might not solve all of our bidding down attacks for all cases. So I still think it's worth having it for those cases where it will be very important, like MIPv6. This is clearly something that can't be added on later. i also believe that the CGA concept will be a potential solution to ND. Hesham > -----Original Message----- > From: Pekka Nikander [mailto:Pekka.Nikander@nomadiclab.com] > Sent: Thursday, March 28, 2002 10:08 AM > To: Hesham Soliman (ERA) > Cc: Brian E Carpenter; gab@Sun.COM; Jari Arkko; > ipng@sunroof.eng.sun.com; Erik Nordmark > Subject: Using "a bit" as a protection against bidding down / for > something else > > > Hesham, Brian and others, > > [Note that I've changed the subject, since we are not > really speaking about bit reservation/allocation any more.] > > > => I have to add myself to the list of tired/jetlagged > > people :). But, in the scenario you mention, it seems to > > me that Alice will not end up talking to Bob and Bob > > will not end up talking to Alice. And both will not end > > up talking to the MITM anyway. > > In fact, If the MITM modified the first message in the, > > lets call it SA establishment, then this SA establishment > > will fail. If it was the last message that was modified > > then it will also fail because the message will be > > inconsistent with the intial ones. So it seems to me > > like a classic DoS attack. Nothing we can do here. > > What am I missing? > > Well, the devil seems to lie in the details, as usual. If we make > either Alice or Bob *committing* to the stronger scheme before > Alice contacts Bob, we seem to be safe enough. That we may do > in Mobile IPv6, but that does not, as such, require bit allocation. > That is, in the case that one of the parties has a priori decided > not to support Return Routability (RR), they just end up not > doing Route Optimization if there is an attacker on the path. > I find that acceptable. > > Now that the "bit method" has been on the table for some time, I > more and more think that the whole issue has its roots in the > insecurity of Return Routability (RR). The insecurity of RR > creates the so called bombing and future bombing attacks > (see the DT writeups), and perhaps other vulnerabilities that we > just don't know yet. Thus, the real issue wrt RR is to make > stationary hosts protected against these attacks. The current RR > design, with its 5-10 minute maximum binding lifetime, restricts > an attacker's ability to perform the bombing attacks, but it does > not completely remove the threat either. The "bit method" would > provide protection for the stationary hosts, but there are also > other alternatives. Besides, the "bit method" does not protect > against bombing sites, it just protects against bombing hosts. > > OTOH, as Brian has pointed out, the bit method does not provide > adequate protection against MitM bidding down in general. Thus, > _allocating_ a bit for _generic_ bidding down protection just does > not seem to work well enough. There are scenarios where it seems > to work, at least to an extend, but there are also scenarios where > it does not. Consequently, I need to withdraw my generalizations > and my suggestion that it could be used as a generic bidding down > protection scheme. Thanks, Brian, for forcing me to think harder. > > It is a completely other issue then to _reserve_ a bit or a bit > pattern for future use, as Erik has suggested. The so called > "generic CGA" or "symmetric CGA" idea, originally my Michael Roe, > I guess, may have some value and may need such a bit to be reserved. > > The basic "generic CGA" is to use an RFC3041 interface id to > convey semantics: > > iid = hash(SEMANTICS, RND) > > where > > SEMANTICS = a string describing some semantics for the address, > possibly together with some parameters > RND = a freshly generated random number > > Using this Alice, Alice contacting Bob would send an initial packet > that contains a Destination Option (DO) that carries the string and > the random number. Bob recieving the message recognized the DO, > hashes together SEMANTICS and RND, and compares the interface id to > the hash result. > > Again, when Alice and Bob are far from each other, a MitM could > remove the DO altogether, and change the iid, too. Thus, in this > case reserving a bit seems to fail, again. However, if the > generic CGA idea is used at the local link, instead, the attacker > may not have the option of changing the iid or the packet. OTOH, > an attacker can certainly claim the iid to itself, _possibly_ > leading to problems with backward compatibility. > > I think this all needs much more thinking and analysis. It just > seems likely that later using a bit to indicate that an iid > encodes semantics may be a good idea, due to the desire to be > *backward compatible*. If we do not care about backward > compatibility, > there is no need for any bits ever, it's just that we *may* want to > make a distinction between "old" iids and "new" iids. But maybe > it is just easier to update RFC3041, and make all hosts "new", > and not to worry about RFC3041 backward compatibility. > > --Pekka Nikander > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 06:30:25 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SEUPKL019409 for ; Thu, 28 Mar 2002 06:30:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SEUPUx019408 for ipng-dist; Thu, 28 Mar 2002 06:30:25 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SEULKL019401 for ; Thu, 28 Mar 2002 06:30:22 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02091 for ; Thu, 28 Mar 2002 06:30:24 -0800 (PST) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA10780 for ; Thu, 28 Mar 2002 07:30:22 -0700 (MST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 28 Mar 2002 20:18:17 +0530 Received: from chakraa (chakraa.future.futsoft.com [10.4.7.5]) by kailash.future.futsoft.com (8.11.0/8.11.0) with SMTP id g2SETqe19353; Thu, 28 Mar 2002 19:59:52 +0530 Reply-To: From: "chakri" To: =?iso-8859-1?B?J1lPU0hJRlVKSSBIaWRlYWtpIC8gPGcioT9wLb4n?= Cc: Subject: RE: ioctl for nd cache Date: Thu, 28 Mar 2002 19:52:05 +0530 Message-Id: <00df01c1d663$f119f0c0$0507040a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <20020328215741Z.yoshfuji@linux-ipv6.org> X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Mr. Yoshifuji, Thanx for your valuable response. In USAGI, is there any facility like ioctl () mechanism for fetching the ND cache entries? Or is it done by getifaddrs ()? I will have to fetch the MAC address provided the IP6 address. -Chakri -----Original Message----- From: Hideaki YOSHIFUJI [mailto:yoshfuji@cerberus.hongo.wide.ad.jp]On Behalf Of YOSHIFUJI Hideaki / ‹g“¡‰p–¾ Sent: Thursday, March 28, 2002 6:28 PM To: chakraa@future.futsoft.com Cc: ipng@sunroof.eng.sun.com Subject: Re: ioctl for nd cache I do not understand what "full IPv6 support" means. Anyway, just FYI, we, USAGI Project are trying to implement ndp command using rtnetlink(7). And, of course, you can send/recv ICMPv6 packet via raw socket. -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 08:29:03 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SGT3KL019631 for ; Thu, 28 Mar 2002 08:29:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SGT34t019630 for ipng-dist; Thu, 28 Mar 2002 08:29:03 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SGT0KL019623 for ; Thu, 28 Mar 2002 08:29:00 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA24439 for ; Thu, 28 Mar 2002 08:29:02 -0800 (PST) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA29960 for ; Thu, 28 Mar 2002 08:29:02 -0800 (PST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g2SGSFI02149; Thu, 28 Mar 2002 11:28:15 -0500 Message-Id: <200203281628.g2SGSFI02149@cichlid.adsl.duke.edu> To: Margaret Wasserman cc: ipng@sunroof.eng.sun.com Subject: draft-ietf-ipv6-3gpp-recommend-00.txt In-Reply-To: Message from Bob Hinden of "Thu, 14 Mar 2002 17:58:22 PST." <4.3.2.7.2.20020314175238.02477b10@mailhost.iprg.nokia.com> Date: Thu, 28 Mar 2002 11:28:15 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've completed my pre-IESG review of the document and have the following comments. Overall, I think this document is good. The following comments are relatively minor and should be easy to address. The abstract could be better. For example, it might actually say what the recommendations are. :-) (see http://www.rfc-editor.org/policy.html.) Could use more references in places (e.g., NAT, NAT-PT, GTP-U, etc.) This is particularly true in the definitions section. > The GRPS core network elements shown in Figures 1 and 2 are the s/GRPS/GPRS/ It might be good to include some more background about the seattle meeting that led to this particular document. I'm thinking of a reader a couple of years from now who wasn't there and not knowing the background. Might be good to reference specific documents in 3GPP and or the time frame. This document is a reaction to 3GPP draft specs at a certain point in time that have since changed (or will be when folks later read this document). It would be good to make clear to the reader that this is the case. This comment is related to the previous paragraph as well. Also, would it make sense to add a section saying that 3GPP has adopted the changes? (i.e, and cite the meeting?) It might be good for the document to say that the ID has already achieved its main purpose and is being published for the historical record. The document has URLs embedded in the document. It would be better to put them all in the references section. Also, are they all stable? I suspect not. For example, the ARIN minutes reference no longer works... (I haven't checked the others.) There is an ongoing effort to define a set of requirements for cellular hosts [CELLREQ]. This work has been presented to the IPv6 WG, but has not been adopted as an IPv6 WG work item. This work should be continued within the working group, and may feed into a broader effort to define the requirements for all IPv6 nodes. Needs updating. Also is this too detailed for the the final RFC? Thomas -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From MAILER-DAEMON Thu Mar 28 09:21:14 2002 Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SHLEKL019803 for ; Thu, 28 Mar 2002 09:21:14 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA10893 for ; Thu, 28 Mar 2002 09:21:16 -0800 (PST) Received: from relay.bankforce.com (relay.bankforce.com [209.116.118.225]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17208 for ; Thu, 28 Mar 2002 09:21:17 -0800 (PST) From: To: ipng-dist@sunroof.eng.sun.com Date: 28 Mar 2002 11:25:06 -0600 Message-ID: <03e9a0625171c32GFSOWEB01@relay.bankforce.com> Subject: Nondeliverable mail MIME-Version: 1.0 Content-Type: Multipart/mixed; boundary = "GFSOWEB01=tvIfv_Lxeqx_s/??V(P" --GFSOWEB01=tvIfv_Lxeqx_s/??V(P ------Transcript of session follows ------- kenyeo@on-linecorp.com 500 Host server does not support 8bitmime --GFSOWEB01=tvIfv_Lxeqx_s/??V(P Content-Type: message/rfc822; charset=us-ascii Received: from mercury.Sun.COM - 192.9.25.1 by relay.bankforce.com with Microsoft SMTPSVC(5.5.1774.114.11); Thu, 28 Mar 2002 02:02:32 -0600 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA27710; Wed, 27 Mar 2002 23:57:36 -0800 (PST) Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA13057; Wed, 27 Mar 2002 23:57:23 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S7uBKL016831 for ; Wed, 27 Mar 2002 23:56:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id XAA04449 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Received: from mx6.sun.com ([61.104.192.29]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA28194 for ; Wed, 27 Mar 2002 23:56:12 -0800 (PST) Message-Id: <200203280756.XAA28194@nwkea-mail-1.sun.com> Received: from SAMBO (SAMBO [61.104.192.29]) by mx6.sun.com with ESMTP 1.0.283; Thu, 28 Mar 2002 16:56:02 +0900 From: ÀÌÅÂÈ£ To: ipng-dist´Ô Subject: ( ±¤°í ) Àü±â¿Âµ¹ÆÇ³Ú ¿Â¼ö¿Âµ¹ÆÇ³Ú Date: Thu, 28 Mar 2002 16:56:02 +0900 MIME-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" X-Priority: 3 Return-Path: ipng-dist@sunroof.eng.sun.com Untitled

 


È­¼ºÆdzÚÀÇ 20³â °æÇè°ú ±â¼ú·Î ÀÌ·èÇس½
¿ø¸ñ¸¶·çÀç·Î¼­ ¿Âµ¹¹è¼±°ú ¿ø¸ñ¸¶·ç°¡ ÀÏüȭµÇ¾î
±âÁ¸ Âʸ¶·ç ½Ã°ø°ú´Â ´Þ¸® ½Ã°øÀÌ °£ÆíÇÏ°í ¾ÈÀü
ÇÏ¸ç ¿îÀû¿Ü¼±À¸·Î °Ç°­°¡Áö »ý°¢ÇÏ´Â
±¹³» ÃÖÃÊÀÇ Æ¯ÇãÀçÀÔ´Ï´Ù.


±âÁ¸ÀÇ Ã¶ÆÇÆdzڿ¡¼­ ³ª¹«(ÇÕÆÇ)ÆdzڷΠ°³¹ßµÇ¾î º¹»ç¿­·Î ÀÎÇÑ ÈƱⰡ °¡µæÇÏ¿© ÀÎü¿¡ °¡Àå À¯ÀÍÇÑ  ³­¹æÀçÀÔ´Ï´Ù.

öÆÇÆdzÚÀÇ ²¨Áü Çö»óÀ» ¿Ïº®ÇÏ°Ô º¸¿ÏÇÏ¿© ²¨Áü Çö»óÀÌ ¾øÀ¸¸ç ´©ÀüÀ̳ª °¨ÀüÀÇ À§ÇèÀÌ ¾ø¾î ÃÖ°íÀÇ ¾ÈÀü¼ºÀ» È®º¸ÇÏ¿´½À´Ï´Ù.

¼¼¶ó¹Í, Âü½¡°ú ³ª¹«ÀÇ °áÇÕÀ¸·Î ÀÎüÀÇ À¯ÀÍÇÑ ¿øÀû¿Ü ¼±À» ¹æÃâÇÕ´Ï´Ù.
½Ã°øÀÌ °£ÆíÇÏ¿© ´çÀϽðø ´çÀϳ­¹æÀÌ °¡´É
ÇÕ´Ï´Ù

 

 

È®½ÇÈ÷ ´Þ¶óÁø ȲÅä¹æ ¿Â¼ö¿Âµ¹Àº ¿ï··°Å¸²ÀÌ ¾ø°í ¾ÆÁÖ °ß°íÇÕ´Ï´Ù.
±âÁ¸ Á¶¸³½Ä¿Âµ¹ÀÇ ¹®Á¦Á¡µéÀÌ ¸ðµÎ °³¼±ÇÑ
½Å°ø¹ý À¸·Î ¼³Ä¡ºñ¿ëÀÌ ½À½Ä¹ÌÀå°ø¹ýÀÇ ¼öÁØ°ú °°ÀÌ ¾ÆÁÖ Àú·ÅÇÕ´Ï´Ù.



  

»çÀü Çã¶ô ¾øÀÌ ¸ÞÀÏÀ» º¸³½ Á¡ Á˼ÛÇÏ¿À¸ç ¸ÞÀÏÀ»  ¼ö½ÅÇÏÁö ¾ÊÀ¸·Á¸é  
¼ö½Å °ÅºÎ¸¦ Ŭ¸¯ÇØ ÁÖ½Ã¸é °¨»çµå¸®°Ú½À´Ï´Ù.   

 Homepage : www.anne114.co.kr   /   Email : lch5101@korea.com 
Copyright¨Ï 2002  anne114.com  All right reserved.

--GFSOWEB01=tvIfv_Lxeqx_s/??V(P-- From owner-ipng@sunroof.eng.sun.com Thu Mar 28 10:06:53 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SI6rKL020507 for ; Thu, 28 Mar 2002 10:06:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SI6r4O020506 for ipng-distrib; Thu, 28 Mar 2002 10:06:53 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SI6oKL020499 for ; Thu, 28 Mar 2002 10:06:50 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA06142 for ; Thu, 28 Mar 2002 10:06:52 -0800 (PST) Received: from mail.tahoenetworks.com (nat-63-99-114-2.tahoenetworks.com [63.99.114.2]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01961 for ; Thu, 28 Mar 2002 10:06:51 -0800 (PST) Received: from TNEXVS02 ([10.10.1.132]) by mail.tahoenetworks.com with Microsoft SMTPSVC(5.0.2195.1600); Thu, 28 Mar 2002 10:06:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D683.5404190A" Subject: RE: Allocating a bit in the RFC2374 Interface Identifier Date: Thu, 28 Mar 2002 10:06:48 -0800 Message-ID: <416B5AF360DED54088DAD3CA8BFBEA6E1DF19A@TNEXVS02.tahoenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Allocating a bit in the RFC2374 Interface Identifier Thread-Index: AcHWLZFkv5ogA7C2Qye4VHSoWaUUrgAVGBlQ From: "Mohan Parthasarathy" To: "Hesham Soliman (ERA)" , "Brian E Carpenter" , "Pekka Nikander" Cc: "Glenn Morrow" , , "Keith Moore" , "Jari Arkko" , "Pekka Savola" , , "Erik Nordmark" X-OriginalArrivalTime: 28 Mar 2002 18:06:48.0707 (UTC) FILETIME=[54560D30:01C1D683] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C1D683.5404190A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 >=20 > Brian and Pekka,=20 >=20 > > > I am tired, and probably the situation is more complex,=20 > > but this my initial > > > reaction. It looks like in the scenario you describe=20 > > Alice and Bob > > > would end up running different protocols: Alice the=20 > > strong one, which > > > the attacker presumedly cannot break, and Bob the=20 > > not-so-strong one, > > > which the attacker presumedly can break. Thus, Bob would=20 > > end up running > > > the not-so-strong protocol with the attacker, but the=20 > > address used would > > > not be Alice's address. > > >=20 > > It depends on how smart the MITM is, but I think in the=20 > > simplest case, > > Alice will hear from pseudo-Bob "I can't support strong=20 > > security" (this > > will be fabricated by the MITM) so she will be bid down,=20 > > but Bob never knows > > about this because he falsely believes that Alice can't=20 > > support strong security. >=20 > =3D> I have to add myself to the list of tired/jetlagged > people :). But, in the scenario you mention, it seems to > me that Alice will not end up talking to Bob and Bob > will not end up talking to Alice. And both will not end > up talking to the MITM anyway. > In fact, If the MITM modified the first message in the, > lets call it SA establishment, then this SA establishment > will fail. If it was the last message that was modified > then it will also fail because the message will be=20 > inconsistent with the intial ones. So it seems to me=20 > like a classic DoS attack. Nothing we can do here. > What am I missing? >=20 I think the problem is in using the bit to convey whether you want a secure exchange or not. And at the end of the exchange (which effectively created a binding in the mobility case), MN thinks it established securely with CN which it has not i.e I set the bit to indicate I want a secure exchange with some arbitrary node (CN), but this does not really gurantee anything. It does not matter whether you set the bit or not. It all depends on whether MiTM will occur or not. So, in the absence of MiTM attack, the bit reaches CN safely and hence tells CN whether MN needs a secure exchange or not. But in the=20 absence of MiTM attack, RR seems sufficient and hence the bit is not needed. What am I missing ? -mohan > > > But I start to believe that I am missing here things,=20 > and that the > > > reality is more complex than what we thought at the MIPv6=20 > > DT. That is, > > > at least we need a mechanism for Alice to securely=20 > learn about the > > > mechanisms Bob supports. Maybe we could use "the bit"=20 > > here, too, but > > > my brains just fail to analyze what happens to the=20 > > address-spoofing > > > MitM in that case; maybe you could perform the attack in=20 > > both directions? > >=20 > > Exactly >=20 > =3D> But then we end up with Alice talking to Sam > and Bob talking to Homer! So what ? >=20 > > > But would that matter? If there is an attacker that can=20 > > spoof packets > > > and break the less secure protocol, it can create=20 > > security associations > > > with the less-secure protocol anyway, be there the=20 > > legitimite peer or not. > >=20 > > Yes. There's a recursion here, and also a moral I think:=20 > > don't allow weak > > security, period. >=20 > =3D> I used to wonder about the strength of RR only for > MIPv6. But after a long thread with Erik, I am=20 > convinced that it is as strong as the weakest=20 > link. I.e. ND. So I agree with Erik's statement > during the presentation in Minneapolis, which said > that securing ND will make RR seem less secure. > Hence the need for allowing this stronger mechanism > in future. I.e. put the bit in the iid.=20 >=20 > Hesham >=20 >=20 ------_=_NextPart_001_01C1D683.5404190A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Allocating a bit in the RFC2374 Interface Identifier

 
>
> Brian and Pekka,
>
>   > > I am tired, and probably = the situation is more complex,
>   > but this my initial
>   > > reaction.  It looks = like in the scenario you describe
>   > Alice and Bob
>   > > would end up running = different protocols:  Alice the
>   > strong one, which
>   > > the attacker presumedly = cannot break, and Bob the
>   > not-so-strong one,
>   > > which the attacker = presumedly can break.  Thus, Bob would
>   > end up running
>   > > the not-so-strong protocol = with the attacker, but the
>   > address used would
>   > > not be Alice's = address.
>   > >
>   > It depends on how smart the = MITM is, but I think in the
>   > simplest case,
>   > Alice will hear from pseudo-Bob = "I can't support strong
>   > security" (this
>   > will be fabricated by the MITM) = so she will be bid down,
>   > but Bob never knows
>   > about this because he falsely = believes that Alice can't
>   > support strong security.
>
> =3D> I have to add myself to the list of = tired/jetlagged
> people :). But, in the scenario you mention, it = seems to
> me that Alice will not end up talking to Bob and = Bob
> will not end up talking to Alice. And both will = not end
> up talking to the MITM anyway.
> In fact, If the MITM modified the first message = in the,
> lets call it SA establishment, then this SA = establishment
> will fail. If it was the last message that was = modified
> then it will also fail because the message will = be
> inconsistent with the intial ones. So it seems = to me
> like a classic DoS attack. Nothing we can do = here.
> What am I missing?
>
I think the problem is in using the bit to convey = whether you want
a secure exchange or not. And at the end of the = exchange (which
effectively created a binding in the mobility case), = MN thinks
it established securely with CN which it has not i.e = I set the bit
to indicate I want a secure exchange with some = arbitrary node (CN),
but this does not really gurantee anything. It does = not matter whether
you set the bit or not. It all depends on whether = MiTM will occur or not.

So, in the absence of MiTM attack, the bit reaches CN = safely and hence tells
CN whether MN needs  a secure exchange or not. = But in the
absence of MiTM attack, RR seems sufficient and hence = the bit
is not needed. What am I missing ?

-mohan

>   > > But I start to believe that = I am missing here things,
> and that the
>   > > reality is more complex = than what we thought at the MIPv6
>   > DT.  That is,
>   > > at least we need a = mechanism for Alice to securely
> learn about the
>   > > mechanisms Bob = supports.  Maybe we could use "the bit"
>   > here, too, but
>   > > my brains just fail to = analyze what happens to the
>   > address-spoofing
>   > > MitM in that case; maybe = you could perform the attack in
>   > both directions?
>   >
>   > Exactly
>
> =3D> But then we end up with Alice talking to = Sam
> and Bob talking to Homer! So what ?
>
>   > > But would that = matter?  If there is an attacker that can
>   > spoof packets
>   > > and break the less secure = protocol, it can create
>   > security associations
>   > > with the less-secure = protocol anyway, be there the
>   > legitimite peer or not.
>   >
>   > Yes. There's a recursion here, = and also a moral I think:
>   > don't allow weak
>   > security, period.
>
> =3D> I used to wonder about the strength of = RR only for
> MIPv6. But after a long thread with Erik, I am =
> convinced that it is as strong as the weakest =
> link. I.e. ND. So I agree with Erik's = statement
> during the presentation in Minneapolis, which = said
> that securing ND will make RR seem less = secure.
> Hence the need for allowing this stronger = mechanism
> in future. I.e. put the bit in the iid.
>
> Hesham
>
>

------_=_NextPart_001_01C1D683.5404190A-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 10:10:21 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SIALKL020549 for ; Thu, 28 Mar 2002 10:10:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SIAL12020548 for ipng-distrib; Thu, 28 Mar 2002 10:10:21 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SIAIKL020541 for ; Thu, 28 Mar 2002 10:10:18 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA28490; Thu, 28 Mar 2002 10:10:20 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA03238; Thu, 28 Mar 2002 10:10:21 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA15597; Thu, 28 Mar 2002 10:10:20 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2SIAJs16551; Thu, 28 Mar 2002 10:10:19 -0800 X-mProtect:  Thu, 28 Mar 2002 10:10:19 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdHkh4IB; Thu, 28 Mar 2002 10:10:16 PST Message-Id: <4.3.2.7.2.20020328100936.0318e210@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Mar 2002 10:10:12 -0800 To: IPng List From: Bob Hinden Subject: Test Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Test, please ignore. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 28 10:49:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SImxKL021074 for ; Thu, 28 Mar 2002 10:48:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SImx4S021073 for ipng-dist-list; Thu, 28 Mar 2002 10:48:59 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SImwKL021066 for ; Thu, 28 Mar 2002 10:48:58 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2SIlrsl005248 for ; Thu, 28 Mar 2002 10:47:53 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g2SIlrwX005247 for ipng@sunroof.eng.sun.com; Thu, 28 Mar 2002 10:47:53 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2S9sAKL017801 for ; Thu, 28 Mar 2002 01:54:10 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id BAA28310 for ; Thu, 28 Mar 2002 01:54:12 -0800 (PST) Received: from postman.ripe.net (postman.ripe.net [193.0.0.199]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id CAA10379 for ; Thu, 28 Mar 2002 02:54:12 -0700 (MST) Received: (qmail 17999 invoked by uid 0); 28 Mar 2002 09:54:11 -0000 Received: from x22.ripe.net (HELO x22.ripe.net.ripe.net) (193.0.1.22) by postman.ripe.net with SMTP; 28 Mar 2002 09:54:11 -0000 Date: Thu, 28 Mar 2002 10:54:10 +0100 (CET) From: Bruce Campbell X-X-Sender: bc@x22.ripe.net To: ryane@cogeco.ca cc: "ipng@sunroof.eng.sun.com" Subject: Re: Undeliverable: ( 1$0m ) @|1b?B59FG3Z ?B Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 28 Mar 2002, ryan elson wrote: > almost 30 of these. Why am I getting junk in my inbox from ipng? Misconfigured MTAs sending error messages to the 'To' address (the ipng distribution address) instead of the 'From' address. Unless people wish to fake unsubscribes for the problematic addresses, the loop will continue until US business hours when (hopefully) the Sun administrators of the ipng list will notice. -- Bruce Campbell RIPE Systems/Network Engineer NCC www.ripe.net - PGP562C8B1B Operations -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 10:49:32 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SInVKL021090 for ; Thu, 28 Mar 2002 10:49:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SInVHr021089 for ipng-dist-list; Thu, 28 Mar 2002 10:49:31 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from stinker.eng.sun.com (stinker [129.146.86.121]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SInTKL021082 for ; Thu, 28 Mar 2002 10:49:29 -0800 (PST) Received: from stinker.eng.sun.com (localhost [IPv6:::1]) by stinker.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id g2SImPsl005258 for ; Thu, 28 Mar 2002 10:48:25 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id g2SImOCP005257 for ipng@sunroof.eng.sun.com; Thu, 28 Mar 2002 10:48:24 -0800 (PST) Received: from odin.France.Sun.COM (odin.France.Sun.COM [129.157.174.8]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SAM6KL017964 for ; Thu, 28 Mar 2002 02:22:07 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by odin.France.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g2SAM6F12932; Thu, 28 Mar 2002 11:22:06 +0100 (MET) Date: Thu, 28 Mar 2002 11:21:52 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Bounces? To: Peter Bieringer Cc: ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <20020328101610.30943.qmail@titan.bieringer.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I suspect we are all getting them. They are sent to ipng-data - I don't know majordomo enough to tell if that is the list past the filtering. The folks that administer the list are in California so they are presumably asleep now. 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 Mar 28 11:12:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SJCjKL021512 for ; Thu, 28 Mar 2002 11:12:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SJCjPZ021509 for ipng-dist-list; Thu, 28 Mar 2002 11:12:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SJCeKL021500 for ; Thu, 28 Mar 2002 11:12:40 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21342 for ; Thu, 28 Mar 2002 11:12:42 -0800 (PST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA28916 for ; Thu, 28 Mar 2002 12:12:41 -0700 (MST) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g2SJCNZ23236; Thu, 28 Mar 2002 14:12:23 -0500 (EST) Message-Id: <200203281912.g2SJCNZ23236@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bruce Campbell cc: ryane@cogeco.ca, "ipng@sunroof.eng.sun.com" Subject: Re: Undeliverable: ( 1$0m ) @|1b?B59FG3Z ?B Date: Thu, 28 Mar 2002 14:12:23 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Misconfigured MTAs sending error messages to the 'To' address (the ipng > distribution address) instead of the 'From' address. no. the bounces aren't being sent to the address in the To field, they're being sent to the address in the envelope return path. it just happens that the return path isn't being set correctly. this is a problem with the list, not with the recipient's MTAs. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 28 11:54:12 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SJsCKL021899; Thu, 28 Mar 2002 11:54:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SJsBvE021898; Thu, 28 Mar 2002 11:54:11 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SJs8KL021885 for ; Thu, 28 Mar 2002 11:54:08 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA13605 for ; Thu, 28 Mar 2002 11:54:10 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA12954 for ; Thu, 28 Mar 2002 11:53:55 -0800 (PST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA22705 for ; Thu, 28 Mar 2002 11:54:09 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2SJs8A18369; Thu, 28 Mar 2002 11:54:08 -0800 X-mProtect:  Thu, 28 Mar 2002 11:54:08 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNT0dwY; Thu, 28 Mar 2002 11:54:06 PST Message-Id: <4.3.2.7.2.20020328115046.0318e210@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Mar 2002 11:54:01 -0800 To: IPng List From: Bob Hinden Subject: ipng list problems Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The problems seen on the ipng mailing list today is being investigated and work is underway that should keep it from happening again. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 28 15:10:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SNAjKL022926; Thu, 28 Mar 2002 15:10:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2SNAjUS022925; Thu, 28 Mar 2002 15:10:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2SNAgKL022918 for ; Thu, 28 Mar 2002 15:10:42 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA24646 for ; Thu, 28 Mar 2002 15:10:44 -0800 (PST) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23418 for ; Thu, 28 Mar 2002 16:10:43 -0700 (MST) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA05608 for ; Thu, 28 Mar 2002 15:10:43 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g2SNAgw05150 for ; Thu, 28 Mar 2002 15:10:42 -0800 X-mProtect:  Thu, 28 Mar 2002 15:10:42 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdgllmYM; Thu, 28 Mar 2002 15:10:40 PST Message-Id: <4.3.2.7.2.20020328151005.0302d928@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 28 Mar 2002 15:10:31 -0800 To: IPv6 List From: Bob Hinden Subject: Draft IPv6 working group meeting minutes Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The draft meeting minutes and presentations from last weeks IPv6 w.g. meetings can be found at: http://playground.sun.com/pub/ipng/html/meetings.html Please send me corrections. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Mar 28 19:10:47 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2T3AlKL023303; Thu, 28 Mar 2002 19:10:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2T3Alki023302; Thu, 28 Mar 2002 19:10:47 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2T3AhKL023295 for ; Thu, 28 Mar 2002 19:10:44 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id TAA28802 for ; Thu, 28 Mar 2002 19:10:46 -0800 (PST) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA10733 for ; Thu, 28 Mar 2002 20:10:44 -0700 (MST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g2T39oC06296; Thu, 28 Mar 2002 22:09:51 -0500 Message-Id: <200203290309.g2T39oC06296@cichlid.adsl.duke.edu> To: "Michel Py" cc: "Pekka Savola" , ipng@sunroof.eng.sun.com, "ipv6mh" Subject: Re: (ipv6) semantics - TLA In-Reply-To: Message from "Michel Py" of "Thu, 21 Mar 2002 14:51:33 PST." <2B81403386729140A3A899A8B39B046406C493@server2000.arneill-py.sacramento.ca.us> Date: Thu, 28 Mar 2002 22:09:45 -0500 From: Thomas Narten Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The point I am trying to make here is that we need a name or acronym > for "ISPs that receive their addresses directly from a RIR". I am > not saying that "TLA" is the best definition, but it does fit, > regardless of allocation policies and aggregation policies. I think the registry terminology would be Local Internet Registry (LIR). RIRs allocate address space to LIRs. From: IPv6 Address Allocation and Assignment Global Policy ftp://ftp.cs.duke.edu/pub/narten/global-ipv6-assign-2001-12-22.txt 2.4. Regional Internet Registry (RIR) Regional Internet Registries (RIRs) are established and authorized by respective regional communities, and recognized by the IANA to serve and represent large geographical regions. The primary role of RIRs is to manage and distribute public Internet address space within their respective regions. Currently, there are three RIRs: APNIC, RIPE NCC, and ARIN. Preparations are being made to establish LACNIC and AfriNIC. 2.5. National Internet Registry (NIR) A National Internet Registry (NIR) is an IR that primarily allocates address space to its members, which are Local Internet Registries (LIRs). NIR members are generally Internet Service Providers (ISPs) organized at a national level. A NIR is constituted from ISPs, but the NIR itself does not function as an ISP. NIRs are expected to remain neutral to the interests of ISPs of their constituency. NIRs exist mostly in the Asia Pacific Region. 2.6. Local Internet Registry (LIR) A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally ISPs, whose customers are primarily end users and possibly other ISPs. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 29 00:03:15 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2T83FKL023691; Fri, 29 Mar 2002 00:03:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2T83Ef1023690; Fri, 29 Mar 2002 00:03:14 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2T83BKL023683 for ; Fri, 29 Mar 2002 00:03:11 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA21566 for ; Fri, 29 Mar 2002 00:03:14 -0800 (PST) Received: from server2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA23850 for ; Fri, 29 Mar 2002 00:03:14 -0800 (PST) Subject: RE: (ipv6) semantics - TLA MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 29 Mar 2002 00:03:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: <2B81403386729140A3A899A8B39B046405DF39@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: Content-Class: urn:content-classes:message X-MS-TNEF-Correlator: Thread-Topic: (ipv6) semantics - TLA thread-index: AcHWz2xouYw5AfcHTXC9puiBpMkhjQAJkIIQ From: "Michel Py" To: "Thomas Narten" Cc: "Pekka Savola" , , "ipv6mh" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id g2T83CKL023684 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas, >> Michel Py wrote: >> The point I am trying to make here is that we need a name or acronym >> for "ISPs that receive their addresses directly from a RIR". I am >> not saying that "TLA" is the best definition, but it does fit, >> regardless of allocation policies and aggregation policies. > Thomas Narten wrote: > I think the registry terminology would be Local Internet Registry > (LIR). RIRs allocate address space to LIRs. I find the LIR definition below somehow inconsistent with RIR and NIR. If one was to follow the same logic, RIR, NIR and LIR would be similar (RIR assigns to NIR and LIR, NIR assigns to LIR) except for their scope: - RIR : ~continent. - NIR : nation. - LIR : city / metropolitan area. Indeed, the logical definition for a LIR should be something like "A provider-independent organization that assigns PI addresses to end-user sites". It does not mean that the actual function could not be performed by an ISP (as mentioned in 6.1.8 of [MHAP]), but the ISP should then be clearly wearing two different hats. I am not convinced that making an ISP a registry is a good idea in the sense that most people would want a registry to be independent from the operators. Which still leaves us (when RFC2373 is obsolete) with no replacement for "TLA" and "pTLA". I still don't understand what is wrong with these. Michel [MHAP] = http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt > From: > IPv6 Address Allocation and Assignment Global Policy > ftp://ftp.cs.duke.edu/pub/narten/global-ipv6-assign-2001-12-22.txt > 2.4. Regional Internet Registry (RIR) > Regional Internet Registries (RIRs) are established and authorized by > respective regional communities, and recognized by the IANA to serve > and represent large geographical regions. The primary role of RIRs > is to manage and distribute public Internet address space within > their respective regions. Currently, there are three RIRs: APNIC, > RIPE NCC, and ARIN. Preparations are being made to establish LACNIC > and AfriNIC. > 2.5. National Internet Registry (NIR) > A National Internet Registry (NIR) is an IR that primarily allocates > address space to its members, which are Local Internet Registries > (LIRs). NIR members are generally Internet Service Providers (ISPs) > organized at a national level. A NIR is constituted from ISPs, but > the NIR itself does not function as an ISP. NIRs are expected to > remain neutral to the interests of ISPs of their constituency. NIRs > exist mostly in the Asia Pacific Region. > 2.6. Local Internet Registry (LIR) > A Local Internet Registry (LIR) is an IR that primarily assigns > address space to the users of the network services that it provides. > LIRs are generally ISPs, whose customers are primarily end users and > possibly other ISPs. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 29 02:05:28 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TA5SKL023836; Fri, 29 Mar 2002 02:05:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TA5RXp023835; Fri, 29 Mar 2002 02:05:27 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TA5NKL023828 for ; Fri, 29 Mar 2002 02:05:23 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id CAA06201 for ; Fri, 29 Mar 2002 02:05:27 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29426 for ; Fri, 29 Mar 2002 03:05:25 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2TA5Bo65392; Fri, 29 Mar 2002 19:05:12 +0900 (JST) Date: Fri, 29 Mar 2002 19:05:14 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Tim Hartrick Cc: ipng@sunroof.eng.sun.com Subject: Re: poposed changes to the scoping architecture draft In-Reply-To: <200203221852.KAA21116@feller.mentat.com> References: <200203221852.KAA21116@feller.mentat.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 49 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 22 Mar 2002 10:52:36 -0800 (PST), >>>>> Tim Hartrick said: > How the unspecified address is treated by the forwarding code is orthogonal > to how applications make use of it to specify which connections or datagrams > are received on a socket. Okay, and I think this also means we should separate architecture (or protocol) issues and API issues more clearly. So, I'd propose: in the architecture draft, clarify that the form of
% is intended to be used for disambiguating scoped addresses (that have ambiguity) and that the format should not be used for global addresses or addresses that do not have scope (i.e., ::). (but this does not mean it prohibits an implementation -particularly an API- from using the format for global addresses or for :: in an implementation dependent manner.) With this policy > That is, I would like to be able bind a socket to any of: > ::%. > ::%. > ::%. all of the above are out of scope of the architecture draft (but are not prohibited by the draft). > % (The address specifies the type) The architecture draft only defines this format, and the usage in the API will not contradict the semantics of the architecture. > % (The address specifies the type) This will be implemented by using 0 as , but this is rather an API issue and is out of scope of the architecture draft. Does this make sense to you? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 29 04:04:45 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TC4jKL024000; Fri, 29 Mar 2002 04:04:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TC4jNR023999; Fri, 29 Mar 2002 04:04:45 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TC4gKL023992 for ; Fri, 29 Mar 2002 04:04:42 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA08964 for ; Fri, 29 Mar 2002 04:04:44 -0800 (PST) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA07288 for ; Fri, 29 Mar 2002 05:04:43 -0700 (MST) Received: from hawk.ecs.soton.ac.uk (hawk.ecs.soton.ac.uk [152.78.68.142]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA00815; Fri, 29 Mar 2002 12:04:38 GMT Received: from login.ecs.soton.ac.uk (IDENT:tjc@login.ecs.soton.ac.uk [152.78.68.149]) by hawk.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA18859; Fri, 29 Mar 2002 12:04:39 GMT Date: Fri, 29 Mar 2002 12:04:37 +0000 (GMT) From: Tim Chown To: Brian Haberman cc: jpxiong , "ipng@sunroof.eng.sun.com" Subject: Re: Are there Multicast route protocols for IPv6? In-Reply-To: <3CA3104C.44AE1FA5@lorien.sc.innovationslab.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Also, there are open implementations, such as PIM-SM in FreeBSD. Tim On Thu, 28 Mar 2002, Brian Haberman wrote: > The updated PIM-SM spec contains support for IPv6. Take a look at > http://www.ietf.org/internet-drafts/draft-ietf-pim-sm-v2-new-05.txt. > > Also, OSPFv3 (OSPF for IPv6) supports multicast as well, that is > available at http://www.ietf.org/rfc/rfc2740.txt. > > Regards, > Brian > > jpxiong wrote: > > > > hi,everyone! > > There are many multicast route protocols for IPv4 ,eg PIM-SM,MOSPF and DVMRP.And I wonder whether those protocols can used in IPv6. > > Thinks very much > > Thompson > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Fri Mar 29 07:21:36 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TFLaKL024178; Fri, 29 Mar 2002 07:21:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TFLa6l024177; Fri, 29 Mar 2002 07:21:36 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TFLXKL024170 for ; Fri, 29 Mar 2002 07:21:33 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22343 for ; Fri, 29 Mar 2002 07:21:35 -0800 (PST) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09151 for ; Fri, 29 Mar 2002 08:21:35 -0700 (MST) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g2TFHZk24045; Fri, 29 Mar 2002 09:17:35 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Mar 2002 09:17:36 -0600 Message-ID: <933FADF5E673D411B8A30002A5608A0E02DF9B3F@zrc2c012.us.nortel.com> From: "Glenn Morrow" To: Bob Hinden , IPv6 List Subject: RE: Draft IPv6 working group meeting minutes Date: Fri, 29 Mar 2002 09:17:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D734.D5E0B830" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1D734.D5E0B830 Content-Type: text/plain; charset="iso-8859-1" http://playground.sun.com/pub/ipng/html/minutes/ipv6-wg-minutes-march2002.tx t > -----Original Message----- > From: Bob Hinden [mailto:hinden@iprg.nokia.com] > Sent: Thursday, March 28, 2002 5:11 PM > To: IPv6 List > Subject: Draft IPv6 working group meeting minutes > > > The draft meeting minutes and presentations from last weeks IPv6 w.g. > meetings can be found at: > > http://playground.sun.com/pub/ipng/html/meetings.html > > Please send me corrections. > > Thanks, > Bob > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > ------_=_NextPart_001_01C1D734.D5E0B830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Draft IPv6 working group meeting minutes

http://playground.sun.com/pub/ipng/html/minutes/ipv6-w= g-minutes-march2002.txt

> -----Original Message-----
> From: Bob Hinden [mailto:hinden@iprg.nokia.com]<= /FONT>
> Sent: Thursday, March 28, 2002 5:11 PM
> To: IPv6 List
> Subject: Draft IPv6 working group meeting = minutes
>
>
> The draft meeting minutes and presentations = from last weeks IPv6 w.g.
> meetings can be found at:
>
>    http://playground.sun.com/pub/ipng/html/meetings.html<= /A>
>
> Please send me corrections.
>
> Thanks,
> Bob
>
> = --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home = Page:           &= nbsp;          http://playground.sun.com/ipng
> FTP = archive:          &nbs= p;           ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to = majordomo@sunroof.eng.sun.com
> = --------------------------------------------------------------------
>

------_=_NextPart_001_01C1D734.D5E0B830-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 29 08:00:30 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TG0UKL024269; Fri, 29 Mar 2002 08:00:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TG0UUH024268; Fri, 29 Mar 2002 08:00:30 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TG0RKL024261 for ; Fri, 29 Mar 2002 08:00:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA22819 for ; Fri, 29 Mar 2002 08:00:30 -0800 (PST) Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24186 for ; Fri, 29 Mar 2002 09:00:29 -0700 (MST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id LAA17449 for ; Fri, 29 Mar 2002 11:00:28 -0500 (EST) Message-ID: <3CA48F9A.9070509@ulticom.com> Date: Fri, 29 Mar 2002 11:00:26 -0500 From: David Lehmann Organization: Ulticom, Inc. User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: ICMP protocol filtering Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Y'all, RFC 2292bis, section 3.2 describes ICMPv6 type filtering. Would it be useful to have protocol (Next header) filtering on an ICMP socket? e.g. I am developing SCTP and would only like to receive ICMP _error_ messages for SCTP. i.e. I would like only packets in which the offending IPv6 packet has a Next Header field == IPPROTO_SCTP in the IPv6 header. -David -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 29 09:38:24 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2THcOKL024631; Fri, 29 Mar 2002 09:38:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2THcO5p024630; Fri, 29 Mar 2002 09:38:24 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2THcKKL024623 for ; Fri, 29 Mar 2002 09:38:20 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA14938 for ; Fri, 29 Mar 2002 09:38:24 -0800 (PST) Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25744 for ; Fri, 29 Mar 2002 10:38:24 -0700 (MST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id 3FC16160D; Fri, 29 Mar 2002 09:42:25 -0800 (PST) Received: from oflume.zk3.dec.com (brbflume.zk3.dec.com [16.141.24.6]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id A2DDB22AC; Fri, 29 Mar 2002 11:38:22 -0600 (CST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.11.6/1.1.22.3/03Mar00-0551AM) id g2THcKR12625; Fri, 29 Mar 2002 12:38:20 -0500 (EST) Received: from compaq.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id MAA0000179081; Fri, 29 Mar 2002 12:38:20 -0500 (EST) Message-ID: <3CA4A68C.2A9BDE82@compaq.com> Date: Fri, 29 Mar 2002 12:38:20 -0500 From: Vladislav Yasevich Organization: Compaq X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: David Lehmann Cc: ipng@sunroof.eng.sun.com Subject: Re: ICMP protocol filtering References: <3CA48F9A.9070509@ulticom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David A possible problem with this would be intervening extension headers even though the transport was SCTP. Would you want to filter on those headers as well? -vlad David Lehmann wrote: > > Y'all, > > RFC 2292bis, section 3.2 describes ICMPv6 type filtering. > Would it be useful to have protocol (Next header) filtering > on an ICMP socket? > > e.g. I am developing SCTP and would only like to receive ICMP > _error_ messages for SCTP. i.e. I would like only packets in which > the offending IPv6 packet has a Next Header field == IPPROTO_SCTP > in the IPv6 header. > > -David > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich IPv6 Project Lead Compaq Computer Corp. 110 Spit Brook Rd ZK03-3/T07 Tel: (603) 884-1079 Nashua, NH 03062 Fax: (435) 514-6884 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 29 09:40:43 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2THehKL024660; Fri, 29 Mar 2002 09:40:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2THehOo024659; Fri, 29 Mar 2002 09:40:43 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2THedKL024652 for ; Fri, 29 Mar 2002 09:40:39 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA15256 for ; Fri, 29 Mar 2002 09:40:43 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA07985 for ; Fri, 29 Mar 2002 10:40:40 -0700 (MST) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2THeSo67913; Sat, 30 Mar 2002 02:40:28 +0900 (JST) Date: Sat, 30 Mar 2002 02:40:31 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: David Lehmann Cc: ipng@sunroof.eng.sun.com Subject: Re: ICMP protocol filtering In-Reply-To: <3CA48F9A.9070509@ulticom.com> References: <3CA48F9A.9070509@ulticom.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 24 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 29 Mar 2002 11:00:26 -0500, >>>>> David Lehmann said: > RFC 2292bis, section 3.2 describes ICMPv6 type filtering. > Would it be useful to have protocol (Next header) filtering > on an ICMP socket? > e.g. I am developing SCTP and would only like to receive ICMP > _error_ messages for SCTP. i.e. I would like only packets in which > the offending IPv6 packet has a Next Header field == IPPROTO_SCTP > in the IPv6 header. This example seems too specific to incorporate the extension into the document at this late stage. Also, I don't get why the next header is so special. If we added this, then other implementors would want filtering based on inner flowlabel, inner hop limit, inner source or destination addresses, inner extension headers... So...sorry, but I don't think we can add the feature to rfc2292bis. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 29 09:58:38 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2THwcKL024690; Fri, 29 Mar 2002 09:58:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2THwcEa024689; Fri, 29 Mar 2002 09:58:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2THwZKL024682 for ; Fri, 29 Mar 2002 09:58:35 -0800 (PST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA08771 for ; Fri, 29 Mar 2002 09:58:39 -0800 (PST) Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA23824 for ; Fri, 29 Mar 2002 09:58:22 -0800 (PST) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id TAA29124; Fri, 29 Mar 2002 19:58:18 +0200 Date: Fri, 29 Mar 2002 19:58:18 +0200 Message-Id: <200203291758.TAA29124@burp.tkv.asdf.org> From: Markku Savela To: lehmann@ulticom.com cc: ipng@sunroof.eng.sun.com In-reply-to: Subject: Re: ICMP protocol filtering References: <3CA48F9A.9070509@ulticom.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > e.g. I am developing SCTP and would only like to receive ICMP > > _error_ messages for SCTP. i.e. I would like only packets in which > > the offending IPv6 packet has a Next Header field == IPPROTO_SCTP > > in the IPv6 header. Isn't there already last error or something, that you could query from the SCTP socket. That error would be the last ICMP error specific to that socket. Or, there is no such feature in sockets? It would be a sensible feature for the stack to route ICMP errors that are specific to a socket to the specific socket. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 29 10:03:00 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TI30KL024707; Fri, 29 Mar 2002 10:03:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TI305W024706; Fri, 29 Mar 2002 10:03:00 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TI2vKL024699 for ; Fri, 29 Mar 2002 10:02:57 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA14904 for ; Fri, 29 Mar 2002 10:03:01 -0800 (PST) Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA21401 for ; Fri, 29 Mar 2002 11:03:00 -0700 (MST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id NAA09368 for ; Fri, 29 Mar 2002 13:02:59 -0500 (EST) Message-ID: <3CA4AC52.10202@ulticom.com> Date: Fri, 29 Mar 2002 13:02:58 -0500 From: David Lehmann Organization: Ulticom, Inc. User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: ICMP protocol filtering References: <3CA48F9A.9070509@ulticom.com> <3CA4A68C.2A9BDE82@compaq.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Vladislav Yasevich wrote: > David > > A possible problem with this would be intervening > extension headers even though the transport was > SCTP. Would you want to filter on those headers > as well? Yes, I can see that simply checking the Next Header on the IPv6 header is not enough. If ICMP could filter on a particular header, then the packet would pass through the filter if any of the headers had the specified header ID. -- David Lehmann Ulticom, Inc. AOL IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 29 10:21:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TILvKL024913; Fri, 29 Mar 2002 10:21:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TILvCc024912; Fri, 29 Mar 2002 10:21:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TILsKL024905 for ; Fri, 29 Mar 2002 10:21:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA03118 for ; Fri, 29 Mar 2002 10:21:56 -0800 (PST) Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA26842 for ; Fri, 29 Mar 2002 11:21:55 -0700 (MST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id NAA12374 for ; Fri, 29 Mar 2002 13:21:53 -0500 (EST) Message-ID: <3CA4B0C1.2090404@ulticom.com> Date: Fri, 29 Mar 2002 13:21:53 -0500 From: David Lehmann Organization: Ulticom, Inc. User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: ICMP protocol filtering References: <3CA48F9A.9070509@ulticom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya wrote: > This example seems too specific to incorporate the extension into the > document at this late stage. The lateness of this proposal was pointed out to me by Erik, but thought I could give a shot nonetheless. > Also, I don't get why the next header is > so special. The reason is that if I am implementing a particular protocol (e.g. SCTP), I don't want to be bothered by errors generated for every other protocol on the node. I would only want errors for my particular protocol. > If we added this, then other implementors would want > filtering based on inner flowlabel, inner hop limit, inner source or > destination addresses, inner extension headers... If they are generally useful, so be it. However, I don't know how great the dangers are of those additional requests. -- David Lehmann Ulticom, Inc. AOL IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 29 10:40:57 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TIevKL025060; Fri, 29 Mar 2002 10:40:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TIevGW025059; Fri, 29 Mar 2002 10:40:57 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TIerKL025052 for ; Fri, 29 Mar 2002 10:40:54 -0800 (PST) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA00682 for ; Fri, 29 Mar 2002 10:40:56 -0800 (PST) Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA05313 for ; Fri, 29 Mar 2002 11:40:55 -0700 (MST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id NAA15444 for ; Fri, 29 Mar 2002 13:40:53 -0500 (EST) Message-ID: <3CA4B535.8010606@ulticom.com> Date: Fri, 29 Mar 2002 13:40:53 -0500 From: David Lehmann Organization: Ulticom, Inc. User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: ICMP protocol filtering References: <3CA48F9A.9070509@ulticom.com> <200203291758.TAA29124@burp.tkv.asdf.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Markku Savela wrote: >>>e.g. I am developing SCTP and would only like to receive ICMP >>>_error_ messages for SCTP. i.e. I would like only packets in which >>>the offending IPv6 packet has a Next Header field == IPPROTO_SCTP >>>in the IPv6 header. >>> > > Isn't there already last error or something, that you could query from > the SCTP socket. That error would be the last ICMP error specific to > that socket. > > Or, there is no such feature in sockets? It would be a sensible > feature for the stack to route ICMP errors that are specific to a > socket to the specific socket. I agree that it is a sensible feature to get ICMP errors that are specific to a socket. In the raw socket case, the socket is based on a protocol. This is why a protocol filter would be useful. However, I am NOT suggesting to use the same socket which implements the protocol to be used also for ICMP error messages. (This would be too complicated.) I am suggesting that we can expand the filtering capabilities of an ICMPv6 socket to filter on 'protocol' as well. -- David Lehmann Ulticom, Inc. AOL IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 29 11:10:06 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TJA6KL025101; Fri, 29 Mar 2002 11:10:06 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TJA67F025100; Fri, 29 Mar 2002 11:10:06 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TJA2KL025093 for ; Fri, 29 Mar 2002 11:10:02 -0800 (PST) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA28705 for ; Fri, 29 Mar 2002 11:10:04 -0800 (PST) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA10952 for ; Fri, 29 Mar 2002 11:10:04 -0800 (PST) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g2TJ9so68956; Sat, 30 Mar 2002 04:09:54 +0900 (JST) Date: Sat, 30 Mar 2002 04:09:55 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: David Lehmann Cc: ipng@sunroof.eng.sun.com Subject: Re: ICMP protocol filtering In-Reply-To: <3CA4B0C1.2090404@ulticom.com> References: <3CA48F9A.9070509@ulticom.com> <3CA4B0C1.2090404@ulticom.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 55 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 29 Mar 2002 13:21:53 -0500, >>>>> David Lehmann said: >> This example seems too specific to incorporate the extension into the >> document at this late stage. > The lateness of this proposal was pointed out to me by Erik, > but thought I could give a shot nonetheless. Yes, anyone can basically raise their own requests at any time, but whether the requests are accepted or not depends on the timing...IMO, just saying "this could be useful" cannot be a reason to adopt the request at this stage, and, honestly, I don't see much benefit of the idea comparing to the status of the document. (But, of course, I may be wrong or be biased, so I'll hear from others' opinions for a while.) >> Also, I don't get why the next header is >> so special. > The reason is that if I am implementing a particular protocol > (e.g. SCTP), I don't want to be bothered by errors generated > for every other protocol on the node. I would only want errors > for my particular protocol. If you're implementing SCTP itself in the user space, I would point out that this API is not intended to aid implementing a transport layer protocol in the user space (at least in my understanding.) If you want to let an SCTP application accept ICMPv6 error messages, I'd say it's a so special case (even though this is the "advanced" API). Secondly, one of the reasons why ICMPv6-type based filtering was introduced was because we can see many ICMPv6 messages even in normal operation, because ND and MLD are both using ICMPv6 messages. Error messages, however, are basically exceptions. Thus, I don't see much validity for the motivation to filter ICMPv6 error messages. >> If we added this, then other implementors would want >> filtering based on inner flowlabel, inner hop limit, inner source or >> destination addresses, inner extension headers... > If they are generally useful, so be it. However, I don't know how > great the dangers are of those additional requests. My point is that the request of filtering on the next header is as special as others, at least for me. But, again, I may be wrong, and will hear from others. At this moment I sill do not think we can add the feature to the document. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Mar 29 12:14:17 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TKEHKL025147; Fri, 29 Mar 2002 12:14:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TKEHrS025146; Fri, 29 Mar 2002 12:14:17 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TKEEKL025139 for ; Fri, 29 Mar 2002 12:14:14 -0800 (PST) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16318 for ; Fri, 29 Mar 2002 12:14:17 -0800 (PST) Received: from chuckie.dgms.com (angelica.ulticom.com [208.255.120.2]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18847 for ; Fri, 29 Mar 2002 13:14:16 -0700 (MST) Received: from ulticom.com (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with ESMTP id PAA28762 for ; Fri, 29 Mar 2002 15:14:15 -0500 (EST) Message-ID: <3CA4CB17.5020901@ulticom.com> Date: Fri, 29 Mar 2002 15:14:15 -0500 From: David Lehmann Organization: Ulticom, Inc. User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: ICMP protocol filtering References: <3CA48F9A.9070509@ulticom.com> <3CA4B0C1.2090404@ulticom.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JINMEI Tatuya wrote: > Yes, anyone can basically raise their own requests at any time, but > whether the requests are accepted or not depends on the timing...IMO, > just saying "this could be useful" cannot be a reason to adopt the > request at this stage, and, honestly, I don't see much benefit of > the idea comparing to the status of the document. (But, of course, I > may be wrong or be biased, so I'll hear from others' opinions for a > while.) I agree that my sole opinion is not enough to adopt a change. > If you're implementing SCTP itself in the user space, I would point > out that this API is not intended to aid implementing a transport > layer protocol in the user space (at least in my understanding.) If > you want to let an SCTP application accept ICMPv6 error messages, I'd > say it's a so special case (even though this is the "advanced" API). Actually, I am implementing it in both the kernel and user space. In either location, the concept is still the same. In the kernel (Solaris), I simply link the socket under the SCTP driver, in which case I still only want ICMP error packets which are SCTP related. -- David Lehmann Ulticom, Inc. AOL/Yahoo IM: davidULCM 1020 Briggs Road 1-856-787-2729 Mt. Laurel, NJ 08054 USA -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 29 14:23:54 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TMNsKL025281; Fri, 29 Mar 2002 14:23:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2TMNsSS025280; Fri, 29 Mar 2002 14:23:54 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from eastmail1.East.Sun.COM (eastmail1.East.Sun.COM [129.148.1.240]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2TMNoKL025273 for ; Fri, 29 Mar 2002 14:23:51 -0800 (PST) Received: from strat.East.Sun.COM (strat.East.Sun.COM [129.148.174.103]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA22840 for ; Fri, 29 Mar 2002 17:23:53 -0500 (EST) Received: from strat (localhost [127.0.0.1]) by strat.East.Sun.COM (8.12.2+Sun/8.12.2) with ESMTP id g2TMNoW9024088 for ; Fri, 29 Mar 2002 17:23:50 -0500 (EST) Message-Id: <200203292223.g2TMNoW9024088@strat.East.Sun.COM> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipng@sunroof.eng.sun.com From: Sebastien Roy Subject: deprecated addrs in src addr selection question Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Mar 2002 17:23:50 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I could probably piece together an answer by going way back in the mail archives but... The "Default Address Selection for IPv6" draft's source address selection seems to prefer addresses of appropriate scope over "preferred" or non-deprecated addresses. What is the reasoning behind that? For example, a system has one interface configured with a deprecated site-local address and a non-deprecated global address. When communicating with a site-local destination, the draft specifies that the deprecated site-local source address would be used instead of the global address. According to the addressing architecture, "A deprecated address should be used only by applications that have been using it and would have difficulty switching to another address without a service disruption." I don't believe applications would have much difficulty switching to the global address to communicate with site-local destinations in the above example. -Seb -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 30 00:24:11 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2U8OAKL025834; Sat, 30 Mar 2002 00:24:10 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2U8OAhS025833; Sat, 30 Mar 2002 00:24:10 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2U8O7KL025826 for ; Sat, 30 Mar 2002 00:24:07 -0800 (PST) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id AAA15821 for ; Sat, 30 Mar 2002 00:24:11 -0800 (PST) Received: from mx1.ustc.edu.cn ([61.132.182.1]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA07588 for ; Sat, 30 Mar 2002 01:24:09 -0700 (MST) Received: from jpxiong (infonet.ipv6.ustc.edu.cn [202.38.75.75]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id QAA03842 for ; Sat, 30 Mar 2002 16:15:56 +0800 Message-Id: <200203300815.QAA03842@mx1.ustc.edu.cn> Date: Sat, 30 Mar 2002 16:13:24 +0800 From: jpxiong To: "ipng@sunroof.eng.sun.com" Subject: Security Multicast In IPv6 visit IPv4 X-mailer: FoxMail 3.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="US_ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi I know IETF has an active MSECwg working on the security of multicast,how about the same issue in IPv6? I argue that there are no improvments in IPv6? So I think the results of MSECwg can simple introduce in ipv6.How do u think of it? best regards thompson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Mar 30 22:43:39 2002 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2V6hdKL027213; Sat, 30 Mar 2002 22:43:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2/Submit) id g2V6hc4v027212; Sat, 30 Mar 2002 22:43:38 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g2V6hZKL027205 for ; Sat, 30 Mar 2002 22:43:36 -0800 (PST) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA10963 for ; Sat, 30 Mar 2002 22:43:40 -0800 (PST) Received: from web21309.mail.yahoo.com (web21309.mail.yahoo.com [216.136.173.254]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with SMTP id XAA00396 for ; Sat, 30 Mar 2002 23:43:39 -0700 (MST) Message-ID: <20020331064338.29704.qmail@web21309.mail.yahoo.com> Received: from [203.200.5.104] by web21309.mail.yahoo.com via HTTP; Sat, 30 Mar 2002 22:43:38 PST Date: Sat, 30 Mar 2002 22:43:38 -0800 (PST) From: user user Subject: IPv6 address To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1046625125-1017557018=:27883" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0-1046625125-1017557018=:27883 Content-Type: text/plain; charset=us-ascii I want to pass messages between two machines using raw sockets ( IPv6 protocol ). I have the ipv6 module compiled in my linux box. Where do I get IPv6 address from ? thanks, linux_user --------------------------------- Do You Yahoo!? Yahoo! Greetings - send greetings for Easter, Passover --0-1046625125-1017557018=:27883 Content-Type: text/html; charset=us-ascii

I want to pass messages between two machines using raw sockets ( IPv6 protocol ).

I have the ipv6 module compiled in my linux box.  Where do I get IPv6 address from ?

thanks,

linux_user


Do You Yahoo!?
Yahoo! Greetings - send greetings for Easter, Passover --0-1046625125-1017557018=:27883-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------