From owner-ipng@sunroof.eng.sun.com Thu Nov 1 04:32:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1CWxQO009396 for ; Thu, 1 Nov 2001 04:32:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA1CWxt3009395 for ipng-dist; Thu, 1 Nov 2001 04:32: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1CWtQO009388 for ; Thu, 1 Nov 2001 04:32:55 -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 EAA22851 for ; Thu, 1 Nov 2001 04:32:30 -0800 (PST) Received: from HKISRV06.teleware.fi (mail.teleware.fi [193.65.76.33]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA08380 for ; Thu, 1 Nov 2001 06:09:00 -0700 (MST) Received: from hkisrv08.teleware.fi ([10.204.2.28]) by HKISRV06.teleware.fi with Microsoft SMTPSVC(5.0.2195.1600); Thu, 1 Nov 2001 14:32:40 +0200 MIME-Version: 1.0 Subject: RE: newbie question Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 Date: Thu, 1 Nov 2001 14:32:37 +0200 content-class: urn:content-classes:message Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: newbie question Thread-Index: AcFhb0QFilGO7xMhTNG0z0SU3uQTmQAaYawwAAFYLeAAFhHVQAAAv8cAACWqKDA= From: "Anssi Porttikivi" To: Cc: X-OriginalArrivalTime: 01 Nov 2001 12:32:40.0143 (UTC) FILETIME=[4BBCB5F0:01C162D1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fA1CWtQO009389 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is there any documentation of XP IP6 anywhere? Which included software besides the TCP/IP stack is able to open IP6 sockets? I've been told these can: - IE - ftp text mode client - ping6, tracert6, 6to4cfg? They all can process IP6 textual addresses and resolve DNS names to IP6 also, which I guess usually goes together with being able to open IP6 sockets. IE also can open IP6 numeric URLs in the form of http://[::1]/ Can you configure the address selection criteria of XP in any way? If DNS returns both an IP4 and IP6 address, which is the application using? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 1 08:30:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1GU7QO009693 for ; Thu, 1 Nov 2001 08:30:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA1GU7pn009692 for ipng-dist; Thu, 1 Nov 2001 08:30: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1GU2QO009685 for ; Thu, 1 Nov 2001 08:30:03 -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 IAA23834 for ; Thu, 1 Nov 2001 08:29:49 -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 JAA18793 for ; Thu, 1 Nov 2001 09:28:30 -0700 (MST) Received: from kenawang ([128.224.4.111]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA16454 for ; Thu, 1 Nov 2001 08:29:36 -0800 (PST) Message-Id: <4.2.2.20011101113519.00a80ec0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 01 Nov 2001 11:37:13 -0500 To: From: Margaret Wasserman Subject: Fwd: I-D ACTION:draft-wasserman-3gpp-advice-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI -- The IPV6-3GPP Design Committee has published the following draft. Feedback from the working group is encouraged. Thanks, Margaret >To: IETF-Announce:; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-wasserman-3gpp-advice-00.txt >Date: Thu, 01 Nov 2001 07:04:08 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Recommendations for IPv6 in 3GPP Standards > Author(s) : M. Wasserman > Filename : draft-wasserman-3gpp-advice-00.txt > Pages : 19 > Date : 31-Oct-01 > >This document contains recommendations from the Internet >Engineering Task Force (IETF) IPv6 Working Group to the Third >Generation Partnership Project (3GPP) community regarding the use >of IPv6 in the 3GPP standards. The IPv6 Working Group supports the >use of IPv6 within 3GPP and offers these recommendations in a >spirit of open cooperation between the IPv6 Working Group and the >3GPP community. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-wasserman-3gpp-advice-00.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-wasserman-3gpp-advice-00.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-wasserman-3gpp-advice-00.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. >Content-Type: text/plain >Content-ID: <20011031112255.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-wasserman-3gpp-advice-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 Thu Nov 1 12:03:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1K3bQO009944 for ; Thu, 1 Nov 2001 12:03:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA1K3bh0009943 for ipng-dist; Thu, 1 Nov 2001 12:03: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1K3XQO009936 for ; Thu, 1 Nov 2001 12:03: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 MAA07871 for ; Thu, 1 Nov 2001 12:03:34 -0800 (PST) Received: from smtp.tndh.net (evrtwa1-ar8-4-60-069-141.vz.dsl.gtei.net [4.60.69.141]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA21969 for ; Thu, 1 Nov 2001 12:03:29 -0800 (PST) Received: by smtp.tndh.net from localhost (router,SLMail V3.2); Thu, 01 Nov 2001 12:03:19 -0800 Received: from eagleswings [127.0.0.1] by smtp.tndh.net [4.60.68.77] (SLmail 3.2.3113) with SMTP id 8EB4FE8D3641422DBB3354C9B45D643B for plus 2 more; Thu, 01 Nov 2001 12:03:18 -0800 From: "Tony Hain" To: "Anssi Porttikivi" , Cc: Subject: RE: newbie question Date: Thu, 1 Nov 2001 12:03:18 -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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: X-SLUIDL: 81207597-90BA4AF8-B68A28A3-43300C6F Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Start / Help / Search / IPv6 ... all the details are in the product As for address selection criterion read: draft-ietf-ipngwg-default-addr-select-06.txt The discriminator between IPv4 & IPv6 is the best scope match, with ties going to IPv6. Also, the IE in XP does not understand the [::1] form, only the W2k preview. Tony > -----Original Message----- > From: owner-ipng@sunroof.eng.sun.com > [mailto:owner-ipng@sunroof.eng.sun.com]On Behalf Of Anssi Porttikivi > Sent: Thursday, November 01, 2001 4:33 AM > To: msripv6-users@list.research.microsoft.com > Cc: ipng@sunroof.eng.sun.com > Subject: RE: newbie question > > > Is there any documentation of XP IP6 anywhere? Which included software > besides the TCP/IP stack is able to open IP6 sockets? > > I've been told these can: > > - IE > - ftp text mode client > - ping6, tracert6, 6to4cfg? > > They all can process IP6 textual addresses and resolve DNS > names to IP6 > also, which I guess usually goes together with being able to open IP6 > sockets. IE also can open IP6 numeric URLs in the form of > http://[::1]/ > > Can you configure the address selection criteria of XP in any way? If > DNS returns both an IP4 and IP6 address, which is the > application using? > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 1 13:12:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1LC8QO010018 for ; Thu, 1 Nov 2001 13:12:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA1LC8JI010017 for ipng-dist; Thu, 1 Nov 2001 13:12: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1LC4QO010010 for ; Thu, 1 Nov 2001 13:12:04 -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 NAA00140 for ; Thu, 1 Nov 2001 13:12:02 -0800 (PST) Received: from mail7.wlv.netzero.net (mail7.wlv.netzero.net [209.247.163.57]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id OAA07704 for ; Thu, 1 Nov 2001 14:11:47 -0700 (MST) Received: (qmail 11179 invoked from network); 1 Nov 2001 21:11:51 -0000 Received: from ppp-65-91-60-152.mclass.broadwing.net (HELO mcmillan) (65.91.60.152) by mail7.wlv.netzero.net with SMTP; 1 Nov 2001 21:11:51 -0000 Message-ID: <002e01c1631a$8fdcdb40$03000004@mcmillan> From: "mxwickra" To: "ipng" Subject: Tunnel Configuration Problem with Cisco routers Date: Thu, 1 Nov 2001 15:17:04 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C162E8.4321AE20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C162E8.4321AE20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi: I would appreciate your help. I am new to IPv6 configuration on Cisco routers. My name is Mohan. I am = a stundent=20 at Wichita State University. We have a studnet Cisco lab. My project involves IPv6, IPv4 transition. I need some help with some IPv6 basics. I tried few times, but just = could not get the 'tunnels' to work. My configuration files follows. PROBLEM: IPv6 Traffic does not go thru R7(IPv4) even with tunnels installed? (for example, ping ipv6 from R3 to int s0/0 in R4 fails) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Network used (IOS 12.2(T), Cisco3640s) s0/0 s1/0 s1/1 = s0/0 -----serial-link-------------------serial-link--------< R6-IPv6/IPv4 dual stack> = | fa0/0 = --------------------- = | fa0/0 = = =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Interface Addresses IPv4 Address IPv6 Address =20 =20 R4 int s0/0 193.30.60.1/24 3001::/64 eui-64 =20 R7 int s1/0 193.30.60.2/24 NA int s1/1 156.27.0.2/16 NA R6 int s0/0 156.27.0.1/16 3001::/64 eui-64 int fa0/0 10.10.10.1/8 3002::/64 eui-64 R3 int fa0/0 3002::/64 eui-64 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Router R6 - dual stack router, runs RIP, RIPv6, connected to IPv6 only = router R3 and IPv4 only router R7 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r6#sh run Building configuration... Current configuration : 1564 bytes ! version 12.2 hostname r6 ! boot system flash:c3640-jk9s-mz.122-2.T.bin ipv6 unicast-routing ! interface Tunnel0 no ip address ipv6 address 3FFE:B00:C18:1::3/127 tunnel source 10.10.10.1 tunnel destination 20.20.20.1 tunnel mode ipv6ip ! interface Tunnel1 no ip address no ip redirects tunnel source Serial0/0 tunnel mode ipv6ip auto-tunnel ! interface FastEthernet0/0 ip address 10.10.10.1 255.0.0.0 duplex auto speed auto ipv6 address 3002::/64 eui-64 ipv6 rip Rip6 enable ! interface Serial0/0 ip address 156.27.0.1 255.255.0.0 ipv6 address 3001::/64 eui-64 ipv6 rip Rip6 enable ! interface TokenRing0/0 no ip address shutdown ring-speed 16 ! router rip network 10.0.0.0 network 156.27.0.0 ! ! ipv6 router rip Rip6 ! end r6# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r6#sh ip rou Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS = inter area * - candidate default, U - per-user static route, o - ODR P - periodic downloaded static route Gateway of last resort is not set R 193.30.60.0/24 [120/1] via 156.27.0.2, 00:00:00, Serial0/0 R 20.0.0.0/8 [120/2] via 156.27.0.2, 00:00:00, Serial0/0 C 156.27.0.0/16 is directly connected, Serial0/0 C 10.0.0.0/8 is directly connected, FastEthernet0/0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r6#sh ipv6 int brief FastEthernet0/0 [up/up] 3002::204:9AFF:FE8A:5641 Serial0/0 [up/up] 3001::4:9A8A:5641:3 TokenRing0/0 [administratively down/down] unassigned Serial0/1 [administratively down/down] unassigned ATM2/0 [administratively down/down] unassigned Tunnel0 [up/up] 3FFE:B00:C18:1::3 Tunnel1 [up/up] ::156.27.0.1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r6#sh ipv6 int FastEthernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::204:9AFF:FE8A:5641 Global unicast address(es): 3002::204:9AFF:FE8A:5641, subnet is 3002::/64 Joined group address(es): FF02::1 FF02::2 FF02::1:FF8A:5641 FF02::9 MTU is 1500 bytes ICMP error messages limited to one every 500 milliseconds ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 seconds Hosts use stateless autoconfig for addresses. Serial0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::4:9A8A:5641:3 Global unicast address(es): 3001::4:9A8A:5641:3, subnet is 3001::/64 Joined group address(es): FF02::1 FF02::2 FF02::1:FF41:3 FF02::9 MTU is 1500 bytes ICMP error messages limited to one every 500 milliseconds ND reachable time is 30000 milliseconds Hosts use stateless autoconfig for addresses. Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::A0A:A01 Global unicast address(es): 3FFE:B00:C18:1::3, subnet is 3FFE:B00:C18:1::3/127 Joined group address(es): FF02::1 FF02::2 FF02::1:FF41:A FF02::1:FF00:3 FF02::1:FFC8:D201 FF02::1:FF0A:A01 MTU is 1480 bytes ICMP error messages limited to one every 500 milliseconds ND reachable time is 30000 milliseconds Hosts use stateless autoconfig for addresses. Tunnel1 is up, line protocol is up IPv6 is enabled, link-local address is FE80::9C1B:1 Global unicast address(es): ::156.27.0.1, subnet is ::/96 Joined group address(es): FF02::1 FF02::2 FF02::1:FF41:B FF02::1:FF1B:1 MTU is 1480 bytes ICMP error messages limited to one every 500 milliseconds ND reachable time is 30000 milliseconds Hosts use stateless autoconfig for addresses. r6# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r6#sh ipv6 rou IPv6 Routing Table - 9 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP Timers: Uptime/Expires L ::156.27.0.1/128 [0/0] via ::156.27.0.1, Tunnel1, 00:39:32/never via ::, Tunnel1, 00:39:31/never C ::156.27.0.1/96 [0/0] via ::, Tunnel1, 00:39:31/never L 3001::4:9A8A:5641:3/128 [0/0] via ::, Serial0/0, 01:00:07/never C 3001::/64 [0/0] via ::, Serial0/0, 01:00:07/never L 3002::204:9AFF:FE8A:5641/128 [0/0] via ::, FastEthernet0/0, 01:00:07/never C 3002::/64 [0/0] via ::, FastEthernet0/0, 01:00:07/never L 3FFE:B00:C18:1::3/128 [0/0] via ::, Tunnel0, 00:04:02/never C 3FFE:B00:C18:1::3/127 [0/0] via ::, Tunnel0, 00:04:02/never L FE80::/64 [0/0] via ::, Null0, 01:00:07/never r6# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Router R4 -dual stack router at the other end of IPv4 router r4#sh run Building configuration... Current configuration : 1167 bytes ! version 12.2 hostname r4 ! ipv6 unicast-routing ! ! interface Tunnel0 no ip address ipv6 address 3FFE:B00:C18:1::2/127 tunnel source 20.20.20.1 tunnel destination 10.10.10.1 tunnel mode ipv6ip ! interface Tunnel1 no ip address no ip redirects tunnel source Serial0/0 tunnel mode ipv6ip auto-tunnel ! interface FastEthernet0/0 ip address 20.20.20.1 255.0.0.0 duplex auto speed auto ipv6 enable ipv6 rip rip4 enable ! interface Serial0/0 ip address 193.30.60.1 255.255.255.0 ipv6 address 3001::/64 eui-64 ipv6 rip rip4 enable no fair-queue ! router rip network 20.0.0.0 network 193.30.60.0 ! ! ipv6 router rip rip4 ! end r4# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r4# r4#sh ipv6 rou IPv6 Routing Table - 7 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP Timers: Uptime/Expires L ::193.30.60.1/128 [0/0] via ::193.30.60.1, Tunnel1, 00:42:54/never via ::, Tunnel1, 00:42:53/never C ::193.30.60.1/96 [0/0] via ::, Tunnel1, 00:42:53/never L 3001::4:9AE4:4B81:3/128 [0/0] via ::, Serial0/0, 01:28:41/never C 3001::/64 [0/0] via ::, Serial0/0, 01:28:41/never L 3FFE:B00:C18:1::2/128 [0/0] via ::, Tunnel0, 00:08:50/never C 3FFE:B00:C18:1::2/127 [0/0] via ::, Tunnel0, 00:08:50/never L FE80::/64 [0/0] via ::, Null0, 01:47:39/never r4# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r4# r4#sh ipv6 neigh r4#sh ipv6 int brief FastEthernet0/0 [up/up] FE80::204:9AFF:FEE4:4B81 Serial0/0 [up/up] 3001::4:9AE4:4B81:3 TokenRing0/0 [administratively down/down] unassigned Tunnel0 [up/up] 3FFE:B00:C18:1::2 Tunnel1 [up/up] ::193.30.60.1 r4# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r4#sh ipv6 int FastEthernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::204:9AFF:FEE4:4B81 No global unicast address is configured Joined group address(es): FF02::1 FF02::1:FFE4:4B81 FF02::2 FF02::9 MTU is 1500 bytes ICMP error messages limited to one every 500 milliseconds ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 seconds Hosts use stateless autoconfig for addresses. Serial0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::4:9AE4:4B81:3 Global unicast address(es): 3001::4:9AE4:4B81:3, subnet is 3001::/64 Joined group address(es): FF02::1 FF02::1:FF81:3 FF02::2 FF02::9 MTU is 1500 bytes ICMP error messages limited to one every 500 milliseconds ND reachable time is 30000 milliseconds Hosts use stateless autoconfig for addresses. Tunnel0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::1414:1401 Global unicast address(es): 3FFE:B00:C18:1::2, subnet is 3FFE:B00:C18:1::2/127 Joined group address(es): FF02::1 FF02::2 FF02::1:FF81:8 FF02::1:FF00:2 FF02::1:FFC8:C801 FF02::1:FF14:1401 MTU is 1480 bytes ICMP error messages limited to one every 500 milliseconds ND reachable time is 30000 milliseconds Hosts use stateless autoconfig for addresses. Tunnel1 is up, line protocol is up IPv6 is enabled, link-local address is FE80::C11E:3C01 Global unicast address(es): ::193.30.60.1, subnet is ::/96 Joined group address(es): FF02::1 FF02::2 FF02::1:FF81:9 FF02::1:FF1E:3C01 MTU is 1480 bytes ICMP error messages limited to one every 500 milliseconds ND reachable time is 30000 milliseconds Hosts use stateless autoconfig for addresses. r4# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r4#sh ipv6 rip RIP process "rip4", port 521, multicast-group FF02::9, pid 112 Administrative distance is 120. Routing table is 0 Updates every 30 seconds, expire after 180 Holddown lasts 180 seconds, garbage collect after 120 Split horizon is on; poison reverse is off Default routes are not generated Periodic updates 221, trigger updates 0 r4# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r3#sh ipv6 rou IPv6 Routing Table - 4 entries Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP Timers: Uptime/Expires R 3001::/64 [120/2] via FE80::204:9AFF:FE8A:5641, FastEthernet0/0, 00:02:07/00:02:47 L 3002::204:9AFF:FEE4:4B61/128 [0/0] via ::, FastEthernet0/0, 02:50:48/never C 3002::/64 [0/0] via ::, FastEthernet0/0, 02:50:48/never L FE80::/64 [0/0] via ::, Null0, 02:50:48/never =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r3#ping ipv6 3001::4:9A8A:5641:3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3001::4:9A8A:5641:3, timeout is 2 = seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max =3D 1/2/4 ms r3#ping ipv6 3001::4:9AE4:4B81:3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 3001::4:9AE4:4B81:3, timeout is 2 = seconds: ..... Success rate is 0 percent (0/5) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r3#sh run Building configuration... Current configuration : 916 bytes ! version 12.2 hostname r3 ! ipv6 unicast-routing ! ! interface FastEthernet0/0 ip address 10.10.10.2 255.0.0.0 duplex auto speed auto ipv6 address 3002::/64 eui-64 ipv6 rip rip3 enable ipv6 rip rip3 default-information originate ! ! ipv6 router rip rip3 ! end =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r3# r3#sh ipv6 neigh IPv6 Address Age Link-layer Addr State = Interface 3002::204:9AFF:FE8A:5641 131 0004.9a8a.5641 STALE = FastEthernet 0/0 FE80::204:9AFF:FE8A:5641 2 0004.9a8a.5641 STALE = FastEthernet 0/0 r3# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r3#sh ipv6 int FastEthernet0/0 is up, line protocol is up IPv6 is enabled, link-local address is FE80::204:9AFF:FEE4:4B61 Global unicast address(es): 3002::204:9AFF:FEE4:4B61, subnet is 3002::/64 Joined group address(es): FF02::1 FF02::2 FF02::1:FFE4:4B61 FF02::9 MTU is 1500 bytes ICMP error messages limited to one every 500 milliseconds ND reachable time is 30000 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 seconds Hosts use stateless autoconfig for addresses. r3# =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D r7#sh run Building configuration... version 12.2 hostname r7 ! ! interface Serial1/0 ip address 193.30.60.2 255.255.255.0 clockrate 2000000 ! interface Serial1/1 ip address 156.27.0.2 255.255.0.0 clockrate 2000000 ! router rip network 193.30.60.0 network 156.27.0.0 ! end r7# ------=_NextPart_000_002B_01C162E8.4321AE20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi:
 
I would appreciate your = help.
 
I am new to IPv6 configuration on Cisco = routers. My=20 name is Mohan. I am a stundent
at Wichita State University.
We = have a=20 studnet Cisco lab. My project involves IPv6, IPv4 = transition.
 
I need some help with some IPv6 basics. = I tried few=20 times, but just could not get the 'tunnels' to work.
 
My configuration files = follows.
 
 
 
PROBLEM:
IPv6 Traffic does not go = thru R7(IPv4)=20 even with tunnels installed?
(for example, ping ipv6 from R3 to int = s0/0 in=20 R4=20 fails)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
 

Network used (IOS 12.2(T),=20 Cisco3640s)
 

          =             &= nbsp;=20 s0/0           &nb= sp;       =20 s1/0           &nb= sp;   =20 s1/1           &nb= sp;           &nbs= p;   =20 s0/0
    <R4dual stack>=20 -----serial-link--------<R7/IPv4 = only>-----------serial-link--------<=20 R6-IPv6/IPv4 dual=20 stack>
          =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;       =20 |   =20 fa0/0
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =        =20 ---------------------
        =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;         =20 |   =20 fa0/0
          &nbs= p;            = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;  =20 <R3-IPv6 only router>       =20
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Interface=20 Addresses
 
 IPv4 Address    = IPv6=20 Address
    
 
R4 int s0/0=20 193.30.60.1/24   3001::/64 eui-64
 
 
R7 int s1/0 = 193.30.60.2/24  =20 NA
 int s1/1 156.27.0.2/16   NA
 

R6 int s0/0 = 156.27.0.1/16   =20 3001::/64 eui-64
 int fa0/0 10.10.10.1/8   3002::/64=20 eui-64
 

R3 int fa0/0    = 3002::/64=20 eui-64
 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 

Router R6 - dual stack router, runs = RIP, RIPv6,=20 connected to IPv6 only router
R3 and IPv4 only router=20 R7
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
r6#sh run
Building = configuration...
 
Current configuration : 1564 = bytes
!
version=20 12.2
 
hostname r6
!
boot system=20 flash:c3640-jk9s-mz.122-2.T.bin
 
ipv6 unicast-routing
!
interface=20 Tunnel0
 no ip address
 ipv6 address=20 3FFE:B00:C18:1::3/127
 tunnel source 10.10.10.1
 tunnel=20 destination 20.20.20.1
 tunnel mode ipv6ip
!
interface=20 Tunnel1
 no ip address
 no ip redirects
 tunnel = source=20 Serial0/0
 tunnel mode ipv6ip auto-tunnel
!
interface=20 FastEthernet0/0
 ip address 10.10.10.1 255.0.0.0
 duplex = auto
 speed auto
 ipv6 address 3002::/64 = eui-64
 ipv6=20 rip Rip6 enable
!
interface Serial0/0
 ip address = 156.27.0.1=20 255.255.0.0
 ipv6 address 3001::/64 eui-64
 ipv6 rip = Rip6=20 enable
!
interface TokenRing0/0
 no ip=20 address
 shutdown
 ring-speed 16
!
router=20 rip
 network 10.0.0.0
 network = 156.27.0.0
!
!
ipv6=20 router rip Rip6
!
end
 
r6#
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /FONT>
 
r6#sh ip rou
Codes: C - connected, S = - static, I=20 - IGRP, R - RIP, M - mobile, B - = BGP
       D -=20 EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter=20 area
       N1 - OSPF NSSA external = type 1, N2=20 - OSPF NSSA external type 2
       E1 - = OSPF=20 external type 1, E2 - OSPF external type 2, E -=20 EGP
       i - IS-IS, L1 - IS-IS = level-1, L2 -=20 IS-IS level-2, ia - IS-IS inter = area
       * -=20 candidate default, U - per-user static route, o -=20 ODR
       P - periodic downloaded = static=20 route
 
Gateway of last resort is not = set
 
R    193.30.60.0/24 = [120/1] via=20 156.27.0.2, 00:00:00, Serial0/0
R    20.0.0.0/8 = [120/2] via=20 156.27.0.2, 00:00:00, Serial0/0
C    156.27.0.0/16 is = directly=20 connected, Serial0/0
C    10.0.0.0/8 is directly = connected,=20 FastEthernet0/0
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
= r6#sh=20 ipv6 int=20 brief
FastEthernet0/0        &= nbsp;  =20 [up/up]
   =20 3002::204:9AFF:FE8A:5641
Serial0/0      =            =20 [up/up]
   =20 3001::4:9A8A:5641:3
TokenRing0/0      &n= bsp;       =20 [administratively down/down]
   =20 unassigned
Serial0/1        &n= bsp;        =20 [administratively down/down]
   =20 unassigned
ATM2/0         = ;           =20 [administratively down/down]
   =20 unassigned
Tunnel0        &nbs= p;          =20 [up/up]
   =20 3FFE:B00:C18:1::3
Tunnel1       &nb= sp;           =20 [up/up]
   =20 ::156.27.0.1
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
 
r6#sh ipv6 int
FastEthernet0/0 is = up, line=20 protocol is up
  IPv6 is enabled, link-local address is=20 FE80::204:9AFF:FE8A:5641
  Global unicast=20 address(es):
    3002::204:9AFF:FE8A:5641, subnet is=20 3002::/64
  Joined group address(es):
   =20 FF02::1
    FF02::2
   =20 FF02::1:FF8A:5641
    FF02::9
  MTU is 1500=20 bytes
  ICMP error messages limited to one every 500=20 milliseconds
  ND reachable time is 30000 milliseconds
  = ND=20 advertised reachable time is 0 milliseconds
  ND advertised = retransmit=20 interval is 0 milliseconds
  ND router advertisements are sent = every 200=20 seconds
  ND router advertisements live for 1800 = seconds
  Hosts=20 use stateless autoconfig for addresses.
Serial0/0 is up, line = protocol is=20 up
  IPv6 is enabled, link-local address is=20 FE80::4:9A8A:5641:3
  Global unicast = address(es):
   =20 3001::4:9A8A:5641:3, subnet is 3001::/64
  Joined group=20 address(es):
    FF02::1
   =20 FF02::2
    FF02::1:FF41:3
   =20 FF02::9
  MTU is 1500 bytes
  ICMP error messages = limited to one=20 every 500 milliseconds
  ND reachable time is 30000=20 milliseconds
  Hosts use stateless autoconfig for = addresses.
Tunnel0=20 is up, line protocol is up
  IPv6 is enabled, link-local address = is=20 FE80::A0A:A01
  Global unicast = address(es):
   =20 3FFE:B00:C18:1::3, subnet is 3FFE:B00:C18:1::3/127
  Joined = group=20 address(es):
    FF02::1
   =20 FF02::2
    FF02::1:FF41:A
   =20 FF02::1:FF00:3
    = FF02::1:FFC8:D201
   =20 FF02::1:FF0A:A01
  MTU is 1480 bytes
  ICMP error = messages=20 limited to one every 500 milliseconds
  ND reachable time is = 30000=20 milliseconds
  Hosts use stateless autoconfig for = addresses.
Tunnel1=20 is up, line protocol is up
  IPv6 is enabled, link-local address = is=20 FE80::9C1B:1
  Global unicast address(es):
    = ::156.27.0.1, subnet is ::/96
  Joined group=20 address(es):
    FF02::1
   =20 FF02::2
    FF02::1:FF41:B
   =20 FF02::1:FF1B:1
  MTU is 1480 bytes
  ICMP error messages = limited=20 to one every 500 milliseconds
  ND reachable time is 30000=20 milliseconds
  Hosts use stateless autoconfig for=20 addresses.
r6#
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
r6#sh ipv6 rou
IPv6 Routing Table - = 9=20 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B -=20 BGP
Timers: Uptime/Expires
 
L ::156.27.0.1/128 [0/0]
  via=20 ::156.27.0.1, Tunnel1, 00:39:32/never
  via ::, Tunnel1,=20 00:39:31/never
C ::156.27.0.1/96 [0/0]
  via ::, Tunnel1,=20 00:39:31/never
L 3001::4:9A8A:5641:3/128 [0/0]
  via ::, = Serial0/0,=20 01:00:07/never
C 3001::/64 [0/0]
  via ::, Serial0/0,=20 01:00:07/never
L 3002::204:9AFF:FE8A:5641/128 [0/0]
  via ::, = FastEthernet0/0, 01:00:07/never
C 3002::/64 [0/0]
  via ::,=20 FastEthernet0/0, 01:00:07/never
L 3FFE:B00:C18:1::3/128 = [0/0]
  via=20 ::, Tunnel0, 00:04:02/never
C 3FFE:B00:C18:1::3/127 [0/0]
  = via ::,=20 Tunnel0, 00:04:02/never
L FE80::/64 [0/0]
  via ::, Null0,=20 01:00:07/never
r6#
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
 
Router R4 -dual stack router at the = other end of=20 IPv4 router
 
r4#sh run
Building = configuration...
 
Current configuration : 1167 = bytes
!
version=20 12.2
 
hostname r4
!
ipv6=20 unicast-routing
!
!
interface Tunnel0
 no ip=20 address
 ipv6 address 3FFE:B00:C18:1::2/127
 tunnel = source=20 20.20.20.1
 tunnel destination 10.10.10.1
 tunnel mode=20 ipv6ip
!
interface Tunnel1
 no ip address
 no ip=20 redirects
 tunnel source Serial0/0
 tunnel mode ipv6ip=20 auto-tunnel
!
interface FastEthernet0/0
 ip address = 20.20.20.1=20 255.0.0.0
 duplex auto
 speed auto
 ipv6=20 enable
 ipv6 rip rip4 enable
!
interface = Serial0/0
 ip=20 address 193.30.60.1 255.255.255.0
 ipv6 address 3001::/64=20 eui-64
 ipv6 rip rip4 enable
 no = fair-queue
!
router=20 rip
 network 20.0.0.0
 network = 193.30.60.0
!
!
ipv6=20 router rip rip4
!
end
 
r4#
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
r4#
r4#sh ipv6 rou
IPv6 Routing = Table - 7=20 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B -=20 BGP
Timers: Uptime/Expires
 
L ::193.30.60.1/128 [0/0]
  via = ::193.30.60.1, Tunnel1, 00:42:54/never
  via ::, Tunnel1,=20 00:42:53/never
C ::193.30.60.1/96 [0/0]
  via ::, Tunnel1,=20 00:42:53/never
L 3001::4:9AE4:4B81:3/128 [0/0]
  via ::, = Serial0/0,=20 01:28:41/never
C 3001::/64 [0/0]
  via ::, Serial0/0,=20 01:28:41/never
L 3FFE:B00:C18:1::2/128 [0/0]
  via ::, = Tunnel0,=20 00:08:50/never
C 3FFE:B00:C18:1::2/127 [0/0]
  via ::, = Tunnel0,=20 00:08:50/never
L FE80::/64 [0/0]
  via ::, Null0,=20 01:47:39/never
r4#
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
r4#
r4#sh ipv6 neigh
r4#sh ipv6 = int=20 brief
FastEthernet0/0        &= nbsp;  =20 [up/up]
   =20 FE80::204:9AFF:FEE4:4B81
Serial0/0      =            =20 [up/up]
   =20 3001::4:9AE4:4B81:3
TokenRing0/0      &n= bsp;       =20 [administratively down/down]
   =20 unassigned
Tunnel0        &nbs= p;          =20 [up/up]
   =20 3FFE:B00:C18:1::2
Tunnel1       &nb= sp;           =20 [up/up]
    ::193.30.60.1
r4#
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /FONT>
 
r4#sh ipv6 int
FastEthernet0/0 is = up, line=20 protocol is up
  IPv6 is enabled, link-local address is=20 FE80::204:9AFF:FEE4:4B81
  No global unicast address is=20 configured
  Joined group address(es):
   =20 FF02::1
    FF02::1:FFE4:4B81
   =20 FF02::2
    FF02::9
  MTU is 1500 = bytes
  ICMP=20 error messages limited to one every 500 milliseconds
  ND = reachable time=20 is 30000 milliseconds
  ND advertised reachable time is 0=20 milliseconds
  ND advertised retransmit interval is 0=20 milliseconds
  ND router advertisements are sent every 200=20 seconds
  ND router advertisements live for 1800 = seconds
  Hosts=20 use stateless autoconfig for addresses.
Serial0/0 is up, line = protocol is=20 up
  IPv6 is enabled, link-local address is=20 FE80::4:9AE4:4B81:3
  Global unicast = address(es):
   =20 3001::4:9AE4:4B81:3, subnet is 3001::/64
  Joined group=20 address(es):
    FF02::1
   =20 FF02::1:FF81:3
    FF02::2
   =20 FF02::9
  MTU is 1500 bytes
  ICMP error messages = limited to one=20 every 500 milliseconds
  ND reachable time is 30000=20 milliseconds
  Hosts use stateless autoconfig for = addresses.
Tunnel0=20 is up, line protocol is up
  IPv6 is enabled, link-local address = is=20 FE80::1414:1401
  Global unicast = address(es):
   =20 3FFE:B00:C18:1::2, subnet is 3FFE:B00:C18:1::2/127
  Joined = group=20 address(es):
    FF02::1
   =20 FF02::2
    FF02::1:FF81:8
   =20 FF02::1:FF00:2
    = FF02::1:FFC8:C801
   =20 FF02::1:FF14:1401
  MTU is 1480 bytes
  ICMP error = messages=20 limited to one every 500 milliseconds
  ND reachable time is = 30000=20 milliseconds
  Hosts use stateless autoconfig for = addresses.
Tunnel1=20 is up, line protocol is up
  IPv6 is enabled, link-local address = is=20 FE80::C11E:3C01
  Global unicast = address(es):
   =20 ::193.30.60.1, subnet is ::/96
  Joined group=20 address(es):
    FF02::1
   =20 FF02::2
    FF02::1:FF81:9
   =20 FF02::1:FF1E:3C01
  MTU is 1480 bytes
  ICMP error = messages=20 limited to one every 500 milliseconds
  ND reachable time is = 30000=20 milliseconds
  Hosts use stateless autoconfig for=20 addresses.
r4#
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
 
r4#sh ipv6 rip
RIP process "rip4", = port 521,=20 multicast-group FF02::9, pid 112
     = Administrative=20 distance is 120.  Routing table is 0
     = Updates=20 every 30 seconds, expire after 180
     Holddown = lasts=20 180 seconds, garbage collect after 120
     Split = horizon=20 is on; poison reverse is off
     Default routes = are not=20 generated
     Periodic updates 221, trigger = updates=20 0
r4#
 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
 
r3#sh ipv6 rou
IPv6 Routing Table - = 4=20 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B -=20 BGP
Timers: Uptime/Expires
 
R 3001::/64 [120/2]
  via=20 FE80::204:9AFF:FE8A:5641, FastEthernet0/0, 00:02:07/00:02:47
L=20 3002::204:9AFF:FEE4:4B61/128 [0/0]
  via ::, FastEthernet0/0,=20 02:50:48/never
C 3002::/64 [0/0]
  via ::, FastEthernet0/0,=20 02:50:48/never
L FE80::/64 [0/0]
  via ::, Null0,=20 02:50:48/never
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
r3#ping ipv6 = 3001::4:9A8A:5641:3
 
Type escape sequence to = abort.
Sending 5,=20 100-byte ICMP Echos to 3001::4:9A8A:5641:3, timeout is 2=20 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip = min/avg/max =3D=20 1/2/4 ms
r3#ping ipv6 3001::4:9AE4:4B81:3
 
Type escape sequence to = abort.
Sending 5,=20 100-byte ICMP Echos to 3001::4:9AE4:4B81:3, timeout is 2=20 seconds:
.....
Success rate is 0 percent (0/5)
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
r3#sh=20 run
Building configuration...
 
Current configuration : 916 = bytes
!
version=20 12.2
 
hostname r3
!
ipv6=20 unicast-routing
!
!
interface FastEthernet0/0
 ip = address=20 10.10.10.2 255.0.0.0
 duplex auto
 speed = auto
 ipv6=20 address 3002::/64 eui-64
 ipv6 rip rip3 enable
 ipv6 rip = rip3=20 default-information originate
!
!
ipv6 router rip=20 rip3
!
end
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
r3#
 
r3#sh ipv6 neigh
IPv6=20 Address           =             &= nbsp;     =20 Age Link-layer Addr State=20 Interface
3002::204:9AFF:FE8A:5641      =            =20 131 0004.9a8a.5641  STALE=20 FastEthernet
0/0
FE80::204:9AFF:FE8A:5641    &n= bsp;           &nb= sp;  =20 2 0004.9a8a.5641  STALE FastEthernet
0/0
 
r3#
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
r3#sh=20 ipv6 int
FastEthernet0/0 is up, line protocol is up
  IPv6 is = enabled, link-local address is FE80::204:9AFF:FEE4:4B61
  Global = unicast=20 address(es):
    3002::204:9AFF:FEE4:4B61, subnet is=20 3002::/64
  Joined group address(es):
   =20 FF02::1
    FF02::2
   =20 FF02::1:FFE4:4B61
    FF02::9
  MTU is 1500=20 bytes
  ICMP error messages limited to one every 500=20 milliseconds
  ND reachable time is 30000 milliseconds
  = ND=20 advertised reachable time is 0 milliseconds
  ND advertised = retransmit=20 interval is 0 milliseconds
  ND router advertisements are sent = every 200=20 seconds
  ND router advertisements live for 1800 = seconds
  Hosts=20 use stateless autoconfig for addresses.
r3#
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
r7#sh run
Building = configuration...
 
version 12.2
 
hostname r7
!
!
interface=20 Serial1/0
 ip address 193.30.60.2 = 255.255.255.0
 clockrate=20 2000000
!
interface Serial1/1
 ip address 156.27.0.2=20 255.255.0.0
 clockrate 2000000
!
router = rip
 network=20 193.30.60.0
 network 156.27.0.0
!
end
 
r7#
 
 
------=_NextPart_000_002B_01C162E8.4321AE20-- ---------------------------------------------------- Sign Up for NetZero Platinum Today Only $9.95 per month! http://my.netzero.net/s/signup?r=platinum&refcd=PT97 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 1 13:14:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1LEoQO010038 for ; Thu, 1 Nov 2001 13:14:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA1LEo2c010037 for ipng-dist; Thu, 1 Nov 2001 13:14: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1LEkQO010030 for ; Thu, 1 Nov 2001 13:14:47 -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 NAA14812 for ; Thu, 1 Nov 2001 13:14:48 -0800 (PST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA01574 for ; Thu, 1 Nov 2001 13:14:47 -0800 (PST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA03903 for ; Thu, 1 Nov 2001 14:05:50 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA06741 for ; Thu, 1 Nov 2001 14:14:45 -0700 (MST)] Received: from beast.arc.corp.mot.com (beast.arc.corp.mot.com [10.238.80.11]) by homer.arc.corp.mot.com (8.11.2/8.11.2) with ESMTP id fA1LEhX12122 for ; Fri, 2 Nov 2001 08:14:43 +1100 (EST) Received: (from kwchin@localhost) by beast.arc.corp.mot.com (8.11.6/8.10.2) id fA1LEh830654 for ipng@sunroof.eng.sun.com; Fri, 2 Nov 2001 08:14:43 +1100 From: Kwan-Wu Chin Message-Id: <200111012114.fA1LEh830654@beast.arc.corp.mot.com> Subject: Final CFP for IPDPS-2002 Workshop, DEADLINE 10th November 2001 To: ipng@sunroof.eng.sun.com Date: Fri, 2 Nov 2001 08:14:43 +1100 (EST) X-Mailer: ELM [version 2.5 PL3] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Collegues, Sorry if you received multiple copies of this CFP. Note that the deadline has been extended to the 10th of November. Best Regards, Kwan-Wu +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ FIRST CALL FOR PAPERS 2nd International Workshop on Parallel and Distributed Computing Issues in Wireless Networks and Mobile Computing IPDPS 2002 WORKSHOPS Ft. Lauderdale Marina Marriott April 15-19, 2002 ***DEADLINE : NOVEMBER 10, 2001*** ************************************************************************** Program Co-Chairs Mohan Kumar, The University of Texas at Arlington, USA C S Raghavandra, University of Southern California, Los Angeles, USA ********************************************************* GENERAL CHAIR Sajal K Das, The University of Texas at Arlington, USA ----------------------------------------------------------- Publicity Co-Chairs Kwan-Wu Chin, Motorola, Sydney, Australia Sotiris Nikoletseas, Computer Technology Institute, Patras, Greece =================================================== Mobile computing has emerged as an important area of computing today as we move to the next millennium. This has been made possible due to the tremendous and continued growth of wireless communications and network technology over the past decade, providing infrastructures for "anytime anywhere" access to distributed computing systems and information repositories. The mobility of users offers new challenges to seamless connectivity in a distributed, heterogeneous network of wireline and wireless components. Several techniques and algorithms developed by the parallel and distributed computing community can be applied to solve typical wireless networks and mobile computing: routing, scheduling, load balancing, cache coherence, information access, and QoS provisioning problems. The objective of this workshop is to bring together technologists and researchers of international reputation in the areas of Parallel and Distributed Computing and Wireless Networks and Mobile Computing in order to have a forum for discussions, exchange of ideas and presentations. Authors are invited to submit original unpublished manuscripts for this workshop. Accepted papers will be published in the proceedings (by IEEE CS Press) of the IPDPS workshops. Topics of interest include (but are not limited to): * Processor Architectures for Mobile and Wearable Computers * Wireless networks in grid computing applications * Algorithms * Routing in ad hoc networks * Parallel and distributed techniques for solving problems in mobile computing * Distributed techniques for QoS Provisioning in wireless networks * Distributed caches in mobile computing environments * Caching, prefetching, pushcaching and replication to enhance information access in wireless networks * Distributed wireless sensor networks * Routing and location independent information access * Scheduling issues in mobile computing * Parallel/distributed algorithms for mobile computing systems * Distributed wireless multimedia systems * Active Networks SUBMISSION GUIDELINES: Authors are invited to submit summaries of original unpublished research to one of the Workshop Chairs. All submissions will be reviewed by referees. Summaries should not exceed ten (10) single-spaced pages of text using 12-point size type on 8.5 x 11 inch pages. References, figures, tables, etc., may be included in addition to the ten pages of text. The summary should include an abstract of approximately 100 words. The corresponding author is requested to include in a cover letter: (1) complete postal address; (2) email address; and (3) Phone/fax numbers. Submissions may be by hard copy or by email. Electronic submissions are preferred and should be sent to kumar@cse.uta.edu or raghu@usc.edu. Authors should submit the cover page in ASCII form followed by a PostScript (level 2) file and make sure that it will print on a PostScript printer that uses 8.5 x 11 inch (US letter size) paper. IMPORTANT DATES: November 10, 2001 Workshop Paper Due December 10, 2001 Notification of Acceptance/Rejection January 15, 2002 Camera-Ready Paper Due URLs: http://www.ipdps.org http://ranger.uta.edu/~kumar/ipdpswpim.html ********************************************************* For hard copy submissions, authors should submit seven (7) hard copies of their paper along with the cover letter to Mohan Kumar or C S Raghavendra All manuscripts will be reviewed. Manuscripts must be received by November 10, 2001. Submissions received after the due date or exceeding the length limit may not be considered. Notification of review decisions will be e-mailed by December 10, 2001. Camera-ready papers are due January 15, 2002. Proceedings will be available at the Conference. Workshop Program Co-Chairs Mohan Kumar Department of Computer Science and Engineering The University of Texas at Arlington Box 19015 Arlington, TX 76019-0015 Tel: 817-272-3610; Fax: 817-272-3784 E-mail: kumar@cse.uta.edu and C S Raghavendra Department of Electrical Engineering-Systems University of Southern California Los Angeles, CA 90089-2562 Tel: (213) 740-9133 Fax: (213) 740-4418 Email: raghu@usc.edu ++++++++++++++++++++++++++++++++++++++++ Technical Program Committee ============================ Stefano Basagni, The University of Texas at Dallas, USA Brahim Bensaou, Hong Kong University of Science & Technology Maurizio Bonuccelli, University of Pisa, Italy Azzedine Boukerche, University of North Texas, USA Luca Cardelli, Microsoft Research, Cambridge, UK Kee Chaing Chua, National University of Singapore Marco Conti, Italian National Research Council, Italy Samir Das, University of Cincinatti, USA John Heidemann, USC/ISI, USA Ahmed Helmy, University of Southern California, USA Muhammad Jaseemuddin, Nortel Networks, USA Sirisha Medidi, Washington State University, USA Cristina Pinotti, University of Trento, Italy Paul Spirakis, Computer Technology Institute, Patras, Greece Mani Srivastava, University of California, Los Angeles, USA Martha Steenstrup, BBN Technologies, USA Mukesh Singhal, Ohio State University, USA Nitin Vaidya, Texas A&M University, USA Hee Yong Youn, Sungkyunkwan University, Korea Gergley Zaruba, The University of Texas at Arlington, USA Albert Zomaya, University of Western Australia, Perth, Australia ================================================= Steering Committee -------------------------------------- Victor Bahl, Microsoft, Seattle, USA Kalyan Basu, Yotta Networks, Richardson, USA Andrew Campbell, Columbia University, USA Imrich Chlamtac, The University of Texas at Dallas Sajal Das, The University of Texas at Arlington, 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 Thu Nov 1 15:50:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1NoOQO010239 for ; Thu, 1 Nov 2001 15:50:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA1NoOlq010238 for ipng-dist; Thu, 1 Nov 2001 15:50:24 -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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1NoKQO010231 for ; Thu, 1 Nov 2001 15:50:20 -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 PAA18674 for ; Thu, 1 Nov 2001 15:50:22 -0800 (PST) Received: from purgatory.unfix.org (purgatory.xs4all.nl [194.109.237.229]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA27435 for ; Thu, 1 Nov 2001 16:50:23 -0700 (MST) Received: from HELL (hell.unfix.org [::ffff:10.100.13.66]) by purgatory.unfix.org (Postfix) with ESMTP id D8C363347; Fri, 2 Nov 2001 00:49:31 +0100 (CET) From: "Jeroen Massar" To: "'Thomas Scholz'" , Cc: Subject: RE: newbie question Date: Fri, 2 Nov 2001 00:48:06 +0100 Organization: Unfix Message-ID: <005e01c1632f$a7d98df0$420d640a@HELL> 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.2616 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas Scholz [mailto:thomas@scholz.dk] wrote: > Microsoft IPv6 stack is pretty feature lacking. I works, but they still > haven't made IIS or any other program compatible with IPv6. Stack != software IIS is a _program_ and has nothing to do with the stack although it uses it's _API_ to communicate over IPv6... (I didn't see IIS on *BSD yet for example :) And just like all those *nix programs.... they'll have to be patched/updated to support IPv6... Apache 1.3.x doesn't support IPv6 natively either (unless you apply the patch from the nice KAME peoples :) Apache 2.x does... and so will IIS 7 or something in the future... well that's quite possible at least... IPv6 is still in a development fase... and soon all stacks (KAME, USAGI, MS, Solaris.... etc...) will all be ready for production. Some people (among me :) use it for production already though even the MS stack... and actually I don't have any problems with it whatsoever. That most windows applications are closed source and those people need to get paid for adding features and the fact that IPv6 isn't deployed everywhere (yet :) simply doesn't 'push' those programmers to implement IPv6 compatibility... even though MS have made it quite easy to do so... So windows programmers check out: http://www.microsoft.com/ipv6/ and especially http://www.microsoft.com/windows2000/technologies/communications/ipv6/ip v6winsok.asp and go IPv6-enable those applications... If you want an example of a nice IPv6 ported application and how it fixes the IPv6 check: http://cvs.tartarus.org/putty/winnet.c?annotate=1.8 which shows the patch for PuTTY... Please note that when a host has both an IPv6 and a IPv4 addy and IPv6 is down you currently have to use the IPv4 address... I'll have to fix that one day... > And they have removed numricc URLs in XP, now you can only call AAAA > records. But if a AAAA record is found, it tries it before the A record. You mean that they removed numberic URL's in wininet.dll .... :) > XP's new stack has some enhancements over the one 2000 is using. They have > made it possible to view connection with netstat, and a few more > configuration options. > > But still, they are a long way from completing it. Depends on which part you look at.... the stack is only 'missing' things like mobility but most other stacks around don't have full support for that yet either. The software part is a kinda worse as I describe above... but that will come in the future... as businesses and thus the programmers get asked for IPv6 support by the people who buy their software... ... ah I am repeating myself :) Greets, Jeroen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 1 16:52:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA20qlQO010316 for ; Thu, 1 Nov 2001 16:52:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA20qlQa010315 for ipng-dist; Thu, 1 Nov 2001 16:52: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA20qhQO010308 for ; Thu, 1 Nov 2001 16:52:43 -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 QAA19052 for ; Thu, 1 Nov 2001 16:52:32 -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 RAA25239 for ; Thu, 1 Nov 2001 17:52:46 -0700 (MST) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id AAA21781; Fri, 2 Nov 2001 00:52:15 GMT X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: "mxwickra" Cc: "ipng" Subject: Re: Tunnel Configuration Problem with Cisco routers References: <002e01c1631a$8fdcdb40$03000004@mcmillan> From: Ole Troan Date: Fri, 02 Nov 2001 00:52:14 +0000 In-Reply-To: <002e01c1631a$8fdcdb40$03000004@mcmillan> ("mxwickra"'s message of "Thu, 1 Nov 2001 15:17:04 -0600") Message-ID: <7t5g07yuh8h.fsf@mrwint.cisco.com> Lines: 529 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) 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 Mxwickra, this list is for IPv6 standardisation work. feel free to contact cisco support directly for your issues. the TAC for released software, or ipv6-support@cisco.com for IPv6 beta/EFT software. cheers, Ole > I would appreciate your help. > > I am new to IPv6 configuration on Cisco routers. My name is Mohan. I am a stundent > at Wichita State University. > We have a studnet Cisco lab. My project involves IPv6, IPv4 transition. > > I need some help with some IPv6 basics. I tried few times, but just could not get the 'tunnels' to work. > > My configuration files follows. > > > > PROBLEM: > IPv6 Traffic does not go thru R7(IPv4) even with tunnels installed? > (for example, ping ipv6 from R3 to int s0/0 in R4 fails) > ======================================================================== > > > Network used (IOS 12.2(T), Cisco3640s) > > > s0/0 s1/0 s1/1 s0/0 > -----serial-link-------------------serial-link--------< R6-IPv6/IPv4 dual stack> > | fa0/0 > --------------------- > | fa0/0 > > > ======================================================================== > Interface Addresses > > IPv4 Address IPv6 Address > > > R4 int s0/0 193.30.60.1/24 3001::/64 eui-64 > > > R7 int s1/0 193.30.60.2/24 NA > int s1/1 156.27.0.2/16 NA > > > R6 int s0/0 156.27.0.1/16 3001::/64 eui-64 > int fa0/0 10.10.10.1/8 3002::/64 eui-64 > > > R3 int fa0/0 3002::/64 eui-64 > > > ========================================================== > > > Router R6 - dual stack router, runs RIP, RIPv6, connected to IPv6 only router > R3 and IPv4 only router R7 > ======================================================================= > > r6#sh run > Building configuration... > > Current configuration : 1564 bytes > ! > version 12.2 > > hostname r6 > ! > boot system flash:c3640-jk9s-mz.122-2.T.bin > > ipv6 unicast-routing > ! > interface Tunnel0 > no ip address > ipv6 address 3FFE:B00:C18:1::3/127 > tunnel source 10.10.10.1 > tunnel destination 20.20.20.1 > tunnel mode ipv6ip > ! > interface Tunnel1 > no ip address > no ip redirects > tunnel source Serial0/0 > tunnel mode ipv6ip auto-tunnel > ! > interface FastEthernet0/0 > ip address 10.10.10.1 255.0.0.0 > duplex auto > speed auto > ipv6 address 3002::/64 eui-64 > ipv6 rip Rip6 enable > ! > interface Serial0/0 > ip address 156.27.0.1 255.255.0.0 > ipv6 address 3001::/64 eui-64 > ipv6 rip Rip6 enable > ! > interface TokenRing0/0 > no ip address > shutdown > ring-speed 16 > ! > router rip > network 10.0.0.0 > network 156.27.0.0 > ! > ! > ipv6 router rip Rip6 > ! > end > > r6# > > ======================================================================= > > r6#sh ip rou > Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP > D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area > N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 > E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP > i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area > * - candidate default, U - per-user static route, o - ODR > P - periodic downloaded static route > > Gateway of last resort is not set > > R 193.30.60.0/24 [120/1] via 156.27.0.2, 00:00:00, Serial0/0 > R 20.0.0.0/8 [120/2] via 156.27.0.2, 00:00:00, Serial0/0 > C 156.27.0.0/16 is directly connected, Serial0/0 > C 10.0.0.0/8 is directly connected, FastEthernet0/0 > > ====================================================================== > r6#sh ipv6 int brief > FastEthernet0/0 [up/up] > 3002::204:9AFF:FE8A:5641 > Serial0/0 [up/up] > 3001::4:9A8A:5641:3 > TokenRing0/0 [administratively down/down] > unassigned > Serial0/1 [administratively down/down] > unassigned > ATM2/0 [administratively down/down] > unassigned > Tunnel0 [up/up] > 3FFE:B00:C18:1::3 > Tunnel1 [up/up] > ::156.27.0.1 > ================================================================== > > r6#sh ipv6 int > FastEthernet0/0 is up, line protocol is up > IPv6 is enabled, link-local address is FE80::204:9AFF:FE8A:5641 > Global unicast address(es): > 3002::204:9AFF:FE8A:5641, subnet is 3002::/64 > Joined group address(es): > FF02::1 > FF02::2 > FF02::1:FF8A:5641 > FF02::9 > MTU is 1500 bytes > ICMP error messages limited to one every 500 milliseconds > ND reachable time is 30000 milliseconds > ND advertised reachable time is 0 milliseconds > ND advertised retransmit interval is 0 milliseconds > ND router advertisements are sent every 200 seconds > ND router advertisements live for 1800 seconds > Hosts use stateless autoconfig for addresses. > Serial0/0 is up, line protocol is up > IPv6 is enabled, link-local address is FE80::4:9A8A:5641:3 > Global unicast address(es): > 3001::4:9A8A:5641:3, subnet is 3001::/64 > Joined group address(es): > FF02::1 > FF02::2 > FF02::1:FF41:3 > FF02::9 > MTU is 1500 bytes > ICMP error messages limited to one every 500 milliseconds > ND reachable time is 30000 milliseconds > Hosts use stateless autoconfig for addresses. > Tunnel0 is up, line protocol is up > IPv6 is enabled, link-local address is FE80::A0A:A01 > Global unicast address(es): > 3FFE:B00:C18:1::3, subnet is 3FFE:B00:C18:1::3/127 > Joined group address(es): > FF02::1 > FF02::2 > FF02::1:FF41:A > FF02::1:FF00:3 > FF02::1:FFC8:D201 > FF02::1:FF0A:A01 > MTU is 1480 bytes > ICMP error messages limited to one every 500 milliseconds > ND reachable time is 30000 milliseconds > Hosts use stateless autoconfig for addresses. > Tunnel1 is up, line protocol is up > IPv6 is enabled, link-local address is FE80::9C1B:1 > Global unicast address(es): > ::156.27.0.1, subnet is ::/96 > Joined group address(es): > FF02::1 > FF02::2 > FF02::1:FF41:B > FF02::1:FF1B:1 > MTU is 1480 bytes > ICMP error messages limited to one every 500 milliseconds > ND reachable time is 30000 milliseconds > Hosts use stateless autoconfig for addresses. > r6# > > ================================================================== > > r6#sh ipv6 rou > IPv6 Routing Table - 9 entries > Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP > Timers: Uptime/Expires > > L ::156.27.0.1/128 [0/0] > via ::156.27.0.1, Tunnel1, 00:39:32/never > via ::, Tunnel1, 00:39:31/never > C ::156.27.0.1/96 [0/0] > via ::, Tunnel1, 00:39:31/never > L 3001::4:9A8A:5641:3/128 [0/0] > via ::, Serial0/0, 01:00:07/never > C 3001::/64 [0/0] > via ::, Serial0/0, 01:00:07/never > L 3002::204:9AFF:FE8A:5641/128 [0/0] > via ::, FastEthernet0/0, 01:00:07/never > C 3002::/64 [0/0] > via ::, FastEthernet0/0, 01:00:07/never > L 3FFE:B00:C18:1::3/128 [0/0] > via ::, Tunnel0, 00:04:02/never > C 3FFE:B00:C18:1::3/127 [0/0] > via ::, Tunnel0, 00:04:02/never > L FE80::/64 [0/0] > via ::, Null0, 01:00:07/never > r6# > > ============================================================================= > ============================================================================= > > Router R4 -dual stack router at the other end of IPv4 router > > r4#sh run > Building configuration... > > Current configuration : 1167 bytes > ! > version 12.2 > > hostname r4 > ! > ipv6 unicast-routing > ! > ! > interface Tunnel0 > no ip address > ipv6 address 3FFE:B00:C18:1::2/127 > tunnel source 20.20.20.1 > tunnel destination 10.10.10.1 > tunnel mode ipv6ip > ! > interface Tunnel1 > no ip address > no ip redirects > tunnel source Serial0/0 > tunnel mode ipv6ip auto-tunnel > ! > interface FastEthernet0/0 > ip address 20.20.20.1 255.0.0.0 > duplex auto > speed auto > ipv6 enable > ipv6 rip rip4 enable > ! > interface Serial0/0 > ip address 193.30.60.1 255.255.255.0 > ipv6 address 3001::/64 eui-64 > ipv6 rip rip4 enable > no fair-queue > ! > router rip > network 20.0.0.0 > network 193.30.60.0 > ! > ! > ipv6 router rip rip4 > ! > end > > r4# > ================================================================= > > r4# > r4#sh ipv6 rou > IPv6 Routing Table - 7 entries > Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP > Timers: Uptime/Expires > > L ::193.30.60.1/128 [0/0] > via ::193.30.60.1, Tunnel1, 00:42:54/never > via ::, Tunnel1, 00:42:53/never > C ::193.30.60.1/96 [0/0] > via ::, Tunnel1, 00:42:53/never > L 3001::4:9AE4:4B81:3/128 [0/0] > via ::, Serial0/0, 01:28:41/never > C 3001::/64 [0/0] > via ::, Serial0/0, 01:28:41/never > L 3FFE:B00:C18:1::2/128 [0/0] > via ::, Tunnel0, 00:08:50/never > C 3FFE:B00:C18:1::2/127 [0/0] > via ::, Tunnel0, 00:08:50/never > L FE80::/64 [0/0] > via ::, Null0, 01:47:39/never > r4# > > ====================================================================== > > r4# > r4#sh ipv6 neigh > r4#sh ipv6 int brief > FastEthernet0/0 [up/up] > FE80::204:9AFF:FEE4:4B81 > Serial0/0 [up/up] > 3001::4:9AE4:4B81:3 > TokenRing0/0 [administratively down/down] > unassigned > Tunnel0 [up/up] > 3FFE:B00:C18:1::2 > Tunnel1 [up/up] > ::193.30.60.1 > r4# > > ======================================================================= > > r4#sh ipv6 int > FastEthernet0/0 is up, line protocol is up > IPv6 is enabled, link-local address is FE80::204:9AFF:FEE4:4B81 > No global unicast address is configured > Joined group address(es): > FF02::1 > FF02::1:FFE4:4B81 > FF02::2 > FF02::9 > MTU is 1500 bytes > ICMP error messages limited to one every 500 milliseconds > ND reachable time is 30000 milliseconds > ND advertised reachable time is 0 milliseconds > ND advertised retransmit interval is 0 milliseconds > ND router advertisements are sent every 200 seconds > ND router advertisements live for 1800 seconds > Hosts use stateless autoconfig for addresses. > Serial0/0 is up, line protocol is up > IPv6 is enabled, link-local address is FE80::4:9AE4:4B81:3 > Global unicast address(es): > 3001::4:9AE4:4B81:3, subnet is 3001::/64 > Joined group address(es): > FF02::1 > FF02::1:FF81:3 > FF02::2 > FF02::9 > MTU is 1500 bytes > ICMP error messages limited to one every 500 milliseconds > ND reachable time is 30000 milliseconds > Hosts use stateless autoconfig for addresses. > Tunnel0 is up, line protocol is up > IPv6 is enabled, link-local address is FE80::1414:1401 > Global unicast address(es): > 3FFE:B00:C18:1::2, subnet is 3FFE:B00:C18:1::2/127 > Joined group address(es): > FF02::1 > FF02::2 > FF02::1:FF81:8 > FF02::1:FF00:2 > FF02::1:FFC8:C801 > FF02::1:FF14:1401 > MTU is 1480 bytes > ICMP error messages limited to one every 500 milliseconds > ND reachable time is 30000 milliseconds > Hosts use stateless autoconfig for addresses. > Tunnel1 is up, line protocol is up > IPv6 is enabled, link-local address is FE80::C11E:3C01 > Global unicast address(es): > ::193.30.60.1, subnet is ::/96 > Joined group address(es): > FF02::1 > FF02::2 > FF02::1:FF81:9 > FF02::1:FF1E:3C01 > MTU is 1480 bytes > ICMP error messages limited to one every 500 milliseconds > ND reachable time is 30000 milliseconds > Hosts use stateless autoconfig for addresses. > r4# > ======================================================================== > > r4#sh ipv6 rip > RIP process "rip4", port 521, multicast-group FF02::9, pid 112 > Administrative distance is 120. Routing table is 0 > Updates every 30 seconds, expire after 180 > Holddown lasts 180 seconds, garbage collect after 120 > Split horizon is on; poison reverse is off > Default routes are not generated > Periodic updates 221, trigger updates 0 > r4# > > > ========================================================================= > ========================================================================= > > r3#sh ipv6 rou > IPv6 Routing Table - 4 entries > Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP > Timers: Uptime/Expires > > R 3001::/64 [120/2] > via FE80::204:9AFF:FE8A:5641, FastEthernet0/0, 00:02:07/00:02:47 > L 3002::204:9AFF:FEE4:4B61/128 [0/0] > via ::, FastEthernet0/0, 02:50:48/never > C 3002::/64 [0/0] > via ::, FastEthernet0/0, 02:50:48/never > L FE80::/64 [0/0] > via ::, Null0, 02:50:48/never > > ================================================================== > > r3#ping ipv6 3001::4:9A8A:5641:3 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 3001::4:9A8A:5641:3, timeout is 2 seconds: > !!!!! > Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms > r3#ping ipv6 3001::4:9AE4:4B81:3 > > Type escape sequence to abort. > Sending 5, 100-byte ICMP Echos to 3001::4:9AE4:4B81:3, timeout is 2 seconds: > ..... > Success rate is 0 percent (0/5) > > ================================================================== > r3#sh run > Building configuration... > > Current configuration : 916 bytes > ! > version 12.2 > > hostname r3 > ! > ipv6 unicast-routing > ! > ! > interface FastEthernet0/0 > ip address 10.10.10.2 255.0.0.0 > duplex auto > speed auto > ipv6 address 3002::/64 eui-64 > ipv6 rip rip3 enable > ipv6 rip rip3 default-information originate > ! > ! > ipv6 router rip rip3 > ! > end > > ================================================================== > r3# > > r3#sh ipv6 neigh > IPv6 Address Age Link-layer Addr State Interface > 3002::204:9AFF:FE8A:5641 131 0004.9a8a.5641 STALE FastEthernet > 0/0 > FE80::204:9AFF:FE8A:5641 2 0004.9a8a.5641 STALE FastEthernet > 0/0 > > r3# > > ================================================================== > r3#sh ipv6 int > FastEthernet0/0 is up, line protocol is up > IPv6 is enabled, link-local address is FE80::204:9AFF:FEE4:4B61 > Global unicast address(es): > 3002::204:9AFF:FEE4:4B61, subnet is 3002::/64 > Joined group address(es): > FF02::1 > FF02::2 > FF02::1:FFE4:4B61 > FF02::9 > MTU is 1500 bytes > ICMP error messages limited to one every 500 milliseconds > ND reachable time is 30000 milliseconds > ND advertised reachable time is 0 milliseconds > ND advertised retransmit interval is 0 milliseconds > ND router advertisements are sent every 200 seconds > ND router advertisements live for 1800 seconds > Hosts use stateless autoconfig for addresses. > r3# > > ==================================================================== > ==================================================================== > > r7#sh run > Building configuration... > > version 12.2 > > hostname r7 > ! > ! > interface Serial1/0 > ip address 193.30.60.2 255.255.255.0 > clockrate 2000000 > ! > interface Serial1/1 > ip address 156.27.0.2 255.255.0.0 > clockrate 2000000 > ! > router rip > network 193.30.60.0 > network 156.27.0.0 > ! > end > > r7# -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 1 21:04:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2547QO010460 for ; Thu, 1 Nov 2001 21:04:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2547ST010459 for ipng-dist; Thu, 1 Nov 2001 21:04: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2543QO010452 for ; Thu, 1 Nov 2001 21:04:03 -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 VAA03219 for ; Thu, 1 Nov 2001 21:04:06 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA08838 for ; Thu, 1 Nov 2001 21:04:03 -0800 (PST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3187D4B23; Fri, 2 Nov 2001 14:03:59 +0900 (JST) To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com In-reply-to: Erik.Nordmark's message of Mon, 29 Oct 2001 14:42:48 +0100. 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: 2292bis-02: zero-length setsockopt From: itojun@iijlab.net Date: Fri, 02 Nov 2001 14:03:59 +0900 Message-ID: <29837.1004677439@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >I guess I stuck that text in there based on some goal of consistency with >the other IPV6_ options in the spec. > >Clearly(?) for IPv6_DSTOPTHDR it makes sense to be able to >clear the sticky option by setting it to zero length. >(I think this is consistent with setting IP_OPTIONS to zero length.) > >So what about IPV6_HOPLIMIT that is a fixed length quantity? >Is it more important to be consistent with the other IPv6 options >(and allow zero length as a way to clear it) or is it more >important to make the option value always have a fixed length (meaning >that -1 is the only way to set if to "default"). > >I don't have a strong opinion either way. I don't feel the need for consistensy among 2292bis setsockopts. -1 should be fine for setting the default value for IPV6_HOPLIMIT and other integer setsockopt. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 2 10:39:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2IddQO011977 for ; Fri, 2 Nov 2001 10:39:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA2Idd6P011976 for ipng-dist; Fri, 2 Nov 2001 10:39: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA2IdaQO011969 for ; Fri, 2 Nov 2001 10:39:36 -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 KAA26061 for ; Fri, 2 Nov 2001 10:39:22 -0800 (PST) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA25541 for ; Fri, 2 Nov 2001 11:39:39 -0700 (MST) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 2 Nov 2001 10:37:52 -0800 Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 02 Nov 2001 10:37:51 -0800 Received: from red-msg-04.redmond.corp.microsoft.com ([157.54.12.74]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 2 Nov 2001 10:37:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: newbie question Date: Fri, 2 Nov 2001 10:37:43 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: newbie question thread-index: AcFjMGZJOOwEZ4PtQ6SPgmjeipdS8gAkeIbw From: "Brian Zill" To: "Jeroen Massar" , "Thomas Scholz" , Cc: X-OriginalArrivalTime: 02 Nov 2001 18:37:44.0943 (UTC) FILETIME=[766DAFF0:01C163CD] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fA2IdaQO011970 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Yes, there seems to be some confusion here between the "stack" and things that run over it. Although I suppose this distinction is probably more important to those of us who worked on it than it is to the average end user. The IPv6 stack currently shipping in Windows XP is primarily intended for developers and trial network deployments. The new getadrinfo and getnameinfo APIs are supported for use with IPv6 and IPv4, so developers can write their programs to be protocol agnostic. Additionally, other APIs (like GetAdaptersAddresses) are now IPv6-aware. We'd like to encourage independent developers to port their applications to support IPv6. As other people have pointed out, many of the network utilities (e.g. telnet, ftp) that are included with Windows XP are IPv6-enabled. A number of people had been asking for netstat support, and that's there now. Netsh can be used for configuration, the hosts file can contain IPv6 addresses, etc. And IE 6 (really wininet as Jeroen points out) now supports native IPv6 web browsing. One thing that I haven't seen mentioned yet is RPC. RPC is IPv6-enabled in XP, so any applications that run over RPC can use IPv6 between XP machines. Most of the other things people are asking for here (like IIS, file sharing, DNS over v6 transport, Windows Media Services, etc) are being worked on. I've used working prototypes for several of these. I don't want to disappoint anyone by promising any specific release dates though. The FAQ for IPv6 on Windows XP can be found at http://www.microsoft.com/windowsxp/pro/techinfo/administration/ipv6/defa ult.asp And more info about our IPv6 plans can be found at http://www.microsoft.com/ipv6 Thanks, --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 Sun Nov 4 22:00:22 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA560LQO015681 for ; Sun, 4 Nov 2001 22:00:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA560LAT015680 for ipng-dist; Sun, 4 Nov 2001 22:00: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA560IQO015673 for ; Sun, 4 Nov 2001 22:00:18 -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 WAA03017 for ; Sun, 4 Nov 2001 22:00:21 -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 WAA15234 for ; Sun, 4 Nov 2001 22:00:17 -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 WAA22764; Sun, 4 Nov 2001 22:00:08 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fA5607W03565; Sun, 4 Nov 2001 22:00:07 -0800 X-mProtect: Sun, 4 Nov 2001 22:00:07 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (216.83.44.21, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdfj8g1M; Sun, 04 Nov 2001 22:00:05 PST Message-Id: <4.3.2.7.2.20011104215358.01dcec38@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 04 Nov 2001 21:59:18 -0800 To: IPng List From: Bob Hinden Subject: Request for Agenda Items for Salt Lake City IPv6 Sessions Cc: hinden@iprg.nokia.com, deering@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPv6 working group has been scheduled for two sessions at the Salt Lake City IETF. They are: TUESDAY, December 11, 2001, 0900-1130 THURSDAY, December 13, 2001, 0900-1130 Note that these date and times are tentative and subject to change by the IETF secretariat. Please send us requests for agenda items. When we put together the agenda we plan to give priority to current working group activities and documents, new individual submissions, and last to status reports. Thanks, Bob Hinden / Steve Deering IPv6 Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 5 09:04:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5H4oQO017384 for ; Mon, 5 Nov 2001 09:04:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA5H4ovr017383 for ipng-dist; Mon, 5 Nov 2001 09:04: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5H4jQO017376 for ; Mon, 5 Nov 2001 09:04:45 -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 JAA25070 for ; Mon, 5 Nov 2001 09:04:48 -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 KAA28512 for ; Mon, 5 Nov 2001 10:04:45 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fA5H4Z324298; Tue, 6 Nov 2001 02:04:35 +0900 (JST) Date: Tue, 06 Nov 2001 02:03:07 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Lilian Fernandes Cc: Subject: Re: TCP and Ancillary data in RFC2292bis In-Reply-To: References: User-Agent: Wanderlust/2.7.5 (Too Funky) 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 980905(IM100) Lines: 34 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Wed, 31 Oct 2001 15:19:52 -0600 (CST), >>>>> Lilian Fernandes said: > RFC2292bis-02 states that applications using TCP can use ancillary data to > receive IPv6 and extension header information (Section 4.1 - TCP Implications) > What are other implementations doing about this? Is there a common > strategy that most implementations have adopted? I'm not sure about the "common strategy", but KAME's implementation does this. Basically, it is not so tricky about the implementation; it just appends the optional information as control data to the receiving socket. However, I'm not sure if this specification really makes sense. Even with the per-segment control data, it still does not follow all changes about the optional information during a TCP session. Also, if the TCP socket does not receive actual data (i.e. it only receives SYN, FIN, and ACK-only segments), the socket cannot receive any information. Although the new spec can reduce the polling overhead that RFC2292 had, I myself tend to revive the old behavior... > Also, what could be a reason for delivering data like "destination > address" as ancillary data? This will always be constant as part of the > TCP connection's 4-tuple. I think it's just for consistency with the UDP/raw socket specification, and there is no practical usage of the data for a TCP socket. 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 Mon Nov 5 12:59:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5KxJQO017963 for ; Mon, 5 Nov 2001 12:59:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA5KxJmp017962 for ipng-dist; Mon, 5 Nov 2001 12:59: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5KxFQO017955 for ; Mon, 5 Nov 2001 12:59: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 MAA10232 for ; Mon, 5 Nov 2001 12:59:18 -0800 (PST) Received: from mg01.austin.ibm.com (mg01.austin.ibm.com [192.35.232.18]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11721 for ; Mon, 5 Nov 2001 13:59:16 -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 OAA21066; Mon, 5 Nov 2001 14:59:02 -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 OAB25466; Mon, 5 Nov 2001 14:57:55 -0600 Received: from localhost (lilianf@localhost) by porkchop.austin.ibm.com (AIX5.1/8.11.0/8.11.0-client1.01) with ESMTP id fA5Kvtx44050; Mon, 5 Nov 2001 14:57:55 -0600 Date: Mon, 5 Nov 2001 14:57:54 -0600 (CST) From: Lilian Fernandes To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: Subject: Re: TCP and Ancillary data in RFC2292bis 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 My question was in regard to the mapping of the packet data from the arriving packet to the point in the bytestream when it is actually 'recv'd by the application. e.g. 2 packets of payload length 40 bytes each may arrive, but be delivered to the application as a single 80 byte piece. What is delivered to the application if both packets had different control data? Or is the intent that we save just the control information from the last packet that arrived and return that as control data? After re-reading section 4.1 of 2292bis-02, I have another question about the "getsockopt" behavior. Is not the normal behavior of getsockopt to just return whatever value was set with setsockopt? e.g. if I use setsockopt to set the IPV6_HOPLIMIT to be 33, then getsockopt should return 33. It seemed to me that recvmsg will be the only way for an application to retrieve data about arriving packets...can someone please clarify this also? Thanks again, Lilian On Tue, 6 Nov 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >>>>> On Wed, 31 Oct 2001 15:19:52 -0600 (CST), > >>>>> Lilian Fernandes said: > > > RFC2292bis-02 states that applications using TCP can use ancillary data to > > receive IPv6 and extension header information (Section 4.1 - TCP Implications) > > > What are other implementations doing about this? Is there a common > > strategy that most implementations have adopted? > > I'm not sure about the "common strategy", but KAME's implementation > does this. Basically, it is not so tricky about the implementation; > it just appends the optional information as control data to the > receiving socket. > > However, I'm not sure if this specification really makes sense. Even > with the per-segment control data, it still does not follow all > changes about the optional information during a TCP session. Also, if > the TCP socket does not receive actual data (i.e. it only receives > SYN, FIN, and ACK-only segments), the socket cannot receive any > information. Although the new spec can reduce the polling overhead > that RFC2292 had, I myself tend to revive the old behavior... > > > Also, what could be a reason for delivering data like "destination > > address" as ancillary data? This will always be constant as part of the > > TCP connection's 4-tuple. > > I think it's just for consistency with the UDP/raw socket > specification, and there is no practical usage of the data for a TCP > socket. > > 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 > -------------------------------------------------------------------- > _____________________________________________________________________ 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 Nov 5 13:14:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5LDxQO017991 for ; Mon, 5 Nov 2001 13:13:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA5LDxfa017990 for ipng-dist; Mon, 5 Nov 2001 13:13: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA5LDvQO017983 for ; Mon, 5 Nov 2001 13:13:57 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id fA5LApG04858 for ipng@sunroof.eng.sun.com; Mon, 5 Nov 2001 13:10:51 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA1HJqQO009722 for ; Thu, 1 Nov 2001 09:19:52 -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 JAA05063 for ; Thu, 1 Nov 2001 09:19:40 -0800 (PST) Received: from fepD.post.tele.dk (fepD.post.tele.dk [195.41.46.149]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28262 for ; Thu, 1 Nov 2001 10:18:18 -0700 (MST) Received: from thomas ([80.63.111.8]) by fepD.post.tele.dk (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20011101171943.DXVL16766.fepD.post.tele.dk@thomas>; Thu, 1 Nov 2001 18:19:43 +0100 From: "Thomas Scholz" To: Cc: Subject: SV: newbie question Date: Thu, 1 Nov 2001 18:19:42 +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) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Microsoft IPv6 stack is pretty feature lacking. I works, but they still haven't made IIS or any other program compatible with IPv6. And they have removed numricc URLs in XP, now you can only call AAAA records. But if a AAAA record is found, it tries it before the A record. XP's new stack has some enhancements over the one 2000 is using. They have made it possible to view connection with netstat, and a few more configuration options. But still, they are a long way from completing it. +-----< Thomas Scholz >---- --- -- - | E-Mail: [ thomas@scholz.dk ] PGP: [ 0x23E4B5F0 ] | ICQ: [ 4838106 ] IPv6 (6Bone): [ 3ffe:b80:2:67::2 ] +-----< http://tscholz.2y.net >---- --- -- - -----Oprindelig meddelelse----- Fra: Anssi Porttikivi [mailto:anssi.porttikivi@teleware.fi] Sendt: 1. november 2001 13:33 Til: msripv6-users@list.research.microsoft.com Cc: ipng@sunroof.eng.sun.com Emne: RE: newbie question Is there any documentation of XP IP6 anywhere? Which included software besides the TCP/IP stack is able to open IP6 sockets? I've been told these can: - IE - ftp text mode client - ping6, tracert6, 6to4cfg? They all can process IP6 textual addresses and resolve DNS names to IP6 also, which I guess usually goes together with being able to open IP6 sockets. IE also can open IP6 numeric URLs in the form of http://[::1]/ Can you configure the address selection criteria of XP in any way? If DNS returns both an IP4 and IP6 address, which is the application using? --- You are currently subscribed to msripv6-users as: thomas@scholz.dk To unsubscribe send a blank email to leave-msripv6-users-4931P@list.research.microsoft.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 Nov 5 22:58:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA66wJQO019681 for ; Mon, 5 Nov 2001 22:58:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA66wJ8F019680 for ipng-dist; Mon, 5 Nov 2001 22:58: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA66wCQO019673 for ; Mon, 5 Nov 2001 22:58:13 -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 WAA19009 for ; Mon, 5 Nov 2001 22:58:14 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA11050 for ; Mon, 5 Nov 2001 23:58:11 -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 fA66wDS01551; Tue, 6 Nov 2001 13:58:16 +0700 (ICT) From: Robert Elz To: "Thomas Scholz" cc: msripv6-users@list.research.microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: SV: newbie question In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Nov 2001 13:58:13 +0700 Message-ID: <1549.1005029893@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 1 Nov 2001 18:19:42 +0100 From: "Thomas Scholz" Message-ID: | And they have removed numricc URLs in XP, I'm not a user of any of their systems, so I'm just guessing what this means, but if it is what it sounds like, it will be a HUGE win for the internet as a whole way off into the distant future (provided they resist the temptation to give way to the very few people who suffer some negative impact - who are over represented in the IETF for sure). This one (assuming it is as I am guessing) deserves a great vote of thanks. 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 Nov 6 00:35:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA68ZhQO019889 for ; Tue, 6 Nov 2001 00:35:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA68ZhPC019888 for ipng-dist; Tue, 6 Nov 2001 00: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA68ZeQO019881 for ; Tue, 6 Nov 2001 00:35:40 -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 AAA22815 for ; Tue, 6 Nov 2001 00:35:43 -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 BAA22275 for ; Tue, 6 Nov 2001 01:35:41 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fA68Zej24645 for ; Tue, 6 Nov 2001 10:35:40 +0200 Date: Tue, 6 Nov 2001 10:35:39 +0200 (EET) From: Pekka Savola To: Subject: /127 for P-t-P Considered Harmful Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, RFC2373 (addrarch) defines Subnet-Router Anycast address: --- 2.6.1 Required Anycast Address The Subnet-Router anycast address is predefined. Its format is as follows: | n bits | 128-n bits | +------------------------------------------------+----------------+ | subnet prefix | 00000000000000 | +------------------------------------------------+----------------+ [...] Packets sent to the Subnet-Router anycast address will be delivered to one router on the subnet. All routers are required to support the Subnet-Router anycast addresses for the subnets which they have interfaces. --- In practise this means that /127 prefix length must not be used in point-to-point links, because then the other end would always have to configure the subnet router anycast address as its _ipv6 address_. This is bad because one router of the two would respond to it (depending on DAD), not necessarily the one which configured it. Not nice. Example: 3ffe:ffff::2/127 configured for router A, and 3ffe:ffff::3/127 for router B. 3ffe:ffff::2 is also subnet-router anycast address, which router B should also recognize. Why everything still works: very few implementations do implement subnet-router anycast addresses. Recommendation: /64 or /126 for Point-to-point links. Another alternative: no subnet-router anycast address for those subnets where prefix >64 bits. Caveat: we've worked hard not to hardcode 64 in too many places.. Or is there something I've missed? If this would use a more "formal" approach, I could write a 2-page informational I-D of this (or more generally, on choosing p-t-p prefix length) I suppose. -- 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 Nov 6 00:57:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA68v4QO019923 for ; Tue, 6 Nov 2001 00:57:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA68v4G1019922 for ipng-dist; Tue, 6 Nov 2001 00:57: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA68v1QO019915 for ; Tue, 6 Nov 2001 00:57:01 -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 AAA19089 for ; Tue, 6 Nov 2001 00:56:49 -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 BAA15177 for ; Tue, 6 Nov 2001 01:56:41 -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 fA68vfS02532; Tue, 6 Nov 2001 15:57:42 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Nov 2001 15:57:41 +0700 Message-ID: <2530.1005037061@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 6 Nov 2001 10:35:39 +0200 (EET) From: Pekka Savola Message-ID: | Or is there something I've missed? First, I certainly have no objection to the use of /126 for p2p links (or wider masks if the organisation so desires) - not only does it avoid your current concern, but its also just slightly cleaner. However, I don't think it is required - anycast addresses are syntactically identical to unicast addresses for many reasons. All that's required of an anycast address is that packets get delivered to something in the appropriate class. How the decision of which particular something is made isn't defined, and shouldn't be. There are 3 cases to consider for a p2p link using a /127 in this: Both end points connect to routers. One end point connects to a router, the other to a host. Neither end point connects to a router, it is a private link between two hosts. The third case is easy - there are no routers, so no need for any router anycast addresses, no problem at all. Where one end is a router, that end would need to have the xxx0 address, then packets sent to that address would arrive at the (only) router on the link. That's exactly what is required. It suggests that where addresses on the link are auto-configured, a node that is a router should always try for the xxx0 address first, falling back to the xxx1 address only if the other node is a router. It also suggests that hosts should act the other way - always try the xxx1 address first, falling back to the xxx0 address only if the other node isn't a router. Where both ends are routers, then all the anycast address requires is that one of the two of them receives the packet. It doesn't suggest which one. So, if one has the xxx0 address, and the other has the xxx1 address, then normal unicast packet forwarding will get the packet there. Note, that on a p2p link using a /127 this way, we know there will be exactly 1 router using the anycast address - so, the reasons for prohibiting use of anycast addresses for certain purposes all vanish. No-one else can tell that it is an anycast address (only a configured node knows for sure), so in this case there's no reason at all the node can't simultaneously use the address as its unicast addr, and as the defined subnet-router anycast address. Hence, I don't see any problem that needs fixing. 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 Nov 6 01:27:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA69RIQO020001 for ; Tue, 6 Nov 2001 01:27:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA69RIWO020000 for ipng-dist; Tue, 6 Nov 2001 01:27: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA69REQO019993 for ; Tue, 6 Nov 2001 01:27: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 BAA27574 for ; Tue, 6 Nov 2001 01:27:18 -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 CAA16089 for ; Tue, 6 Nov 2001 02:27:18 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fA69R9725004; Tue, 6 Nov 2001 11:27:09 +0200 Date: Tue, 6 Nov 2001 11:27:08 +0200 (EET) From: Pekka Savola To: Robert Elz cc: Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: <2530.1005037061@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 On Tue, 6 Nov 2001, Robert Elz wrote: > All that's required of an anycast address is that packets get delivered to > something in the appropriate class. How the decision of which particular > something is made isn't defined, and shouldn't be. Note that we're discussing 'subnet-router' anycast address, not general anycast case. Subnet-router is clearly meant for stub networks, for choosing one proper next-hop router. It is not stated in the spec though, and probably should not be. > There are 3 cases to consider for a p2p link using a /127 in this: > > Both end points connect to routers. I'd say this is at least 95% of cases. > One end point connects to a router, the other to a host. Possible, e.g. with connections from tunnel brokers to workstations. > Neither end point connects to a router, it is a private link > between two hosts. Pretty rare, as you probably agree. > Where one end is a router, that end would need to have the xxx0 address, > then packets sent to that address would arrive at the (only) router on > the link. That's exactly what is required. It suggests that where > addresses on the link are auto-configured, a node that is a router should > always try for the xxx0 address first, falling back to the xxx1 address > only if the other node is a router. It also suggests that hosts should > act the other way - always try the xxx1 address first, falling back to the > xxx0 address only if the other node isn't a router. This scenario can be avoided by proper operational procedures: always assign the ipv6 address that is also the subnet-router address on the router. No problems then (except of course, if the host changes to be a router at some point). I'm not sure whether this kind of 'fallback mechanism' you're describing is actually manageable, and configurable, see below. > Where both ends are routers, then all the anycast address requires is that > one of the two of them receives the packet. It doesn't suggest which one. > So, if one has the xxx0 address, and the other has the xxx1 address, then > normal unicast packet forwarding will get the packet there. > > Note, that on a p2p link using a /127 this way, we know there will be > exactly 1 router using the anycast address - so, the reasons for prohibiting > use of anycast addresses for certain purposes all vanish. No-one else can > tell that it is an anycast address (only a configured node knows for sure), > so in this case there's no reason at all the node can't simultaneously use > the address as its unicast addr, and as the defined subnet-router anycast > address. Problem here is that: Router A: 3ffe:ffff::0/127 (configured) Router B: 3ffe:ffff::1/127 (configured) Now, if router B also manages to get the anycast address 3ffe:ffff::0, Router A does not have any addresses left to pick! There was only one address candidate set before it, and it has been taken. You may want to configure e.g. eBGP peerings using point-to-point addresses (other than link-local); there are a lot of other uses for them too. I see no use for subnet-router anycast addresses in point-to-point links, as it is always known that there is only one other 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 Tue Nov 6 01:47:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA69lDQO020037 for ; Tue, 6 Nov 2001 01:47:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA69lCir020036 for ipng-dist; Tue, 6 Nov 2001 01:47: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA69l7QO020029 for ; Tue, 6 Nov 2001 01:47:08 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fA69l8q18148; Tue, 6 Nov 2001 10:47:08 +0100 (MET) Date: Tue, 6 Nov 2001 10:46:47 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: TCP and Ancillary data in RFC2292bis To: Lilian Fernandes Cc: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= , 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 > > My question was in regard to the mapping of the packet data from the > arriving packet to the point in the bytestream when it is actually > 'recv'd by the application. e.g. 2 packets of payload length 40 bytes each > may arrive, but be delivered to the application as a single 80 byte piece. > What is delivered to the application if both packets had different control > data? > Or is the intent that we save just the control information from the last > packet that arrived and return that as control data? I don't recall the wording in the spec and the intent when 2292bis was written, and I agree with Jimei's point that you can't what extension headers etc were present in TCP segments without any data bytes, but ... For what it is worth, the Solaris implementation compares the set of information the application has requested (using IPV6_RECV* socket options) and determines when that informating changes from one TCP data segment to the other. For the first data segment in the connection (or the first after IPV6_RECV* has been enabled), as well as when there are any changes in the info from one data segment to the next, TCP delivers the ancillary data. So in your example the application would see recvmsg returning the first 40 bytes and the next recvmsg would return the second 40 bytes with the new ancillary data. This means that e.g. if the sender switches from using one routing header content to another routing header content in the middle of the connection, the application would be able to observe this. (But it can't observe anything if it is on the side that is only receiving ACK packets.) So I don't know how useful this is in practice. Just being able to capture the "last received" extension headers might not be useful either - it depends for what the application is using the extension headers. For instance, if security depends on it then presumably the TCP needs to be able to "latch in" a given content i.e. be able to reject packets which do not have the extension header content that was used to create the connection. And in such a "latch in" case a the "last received" semantics make sense because the extension header content can by definition not change during the connection. So the problem is that while we have applications using the ancillary data for ICMP (and perhaps UDP) to ensure that the hoplimit is 255 and that there is no routing header, we do not have similar applications that need this ability with TCP. So we are stumbling around in the dark a bit. > After re-reading section 4.1 of 2292bis-02, I have another question about > the "getsockopt" behavior. Is not the normal behavior of getsockopt to > just return whatever value was set with setsockopt? e.g. if I use > setsockopt to set the IPV6_HOPLIMIT to be 33, then getsockopt should > return 33. In general that is true. (I think that if hoplimit is set to -1 for "default" the getsockopt might actually return the default value that is being used instead of returning -1). > It seemed to me that recvmsg will be the only way for an application to > retrieve data about arriving packets...can someone please clarify this > also? Yes, that is the intent. 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 Nov 6 02:11:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6ABYQO020065 for ; Tue, 6 Nov 2001 02:11:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6ABYMR020064 for ipng-dist; Tue, 6 Nov 2001 02:11: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6ABUQO020057 for ; Tue, 6 Nov 2001 02:11: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 CAA05126 for ; Tue, 6 Nov 2001 02:11:33 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA07184 for ; Tue, 6 Nov 2001 03:11:31 -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 fA6ACrS02763; Tue, 6 Nov 2001 17:12:53 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Nov 2001 17:12:53 +0700 Message-ID: <2761.1005041573@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 6 Nov 2001 11:27:08 +0200 (EET) From: Pekka Savola Message-ID: | Note that we're discussing 'subnet-router' anycast address, not general | anycast case. Yes, I know. | Subnet-router is clearly meant for stub networks, for choosing one proper | next-hop router. It is not stated in the spec though, and probably should | not be. I'm not sure it is that limited - if it were it would be (have to be) restricted to being a link local address, and it isn't. subnet-router addresses are also useful for network mapping, and all kinds of other purposes. RA's should be used to locate next-hop routers (though this on a p2p link is esoteric at best...) 2373 does say as it happens ... The subnet-router anycast address is intended to be used for applications where a node needs to communicate with one of a set of routers on a remote subnet. For example when a mobile host needs to communicate with one of the mobile agents on its "home" subnet. | > Both end points connect to routers. | I'd say this is at least 95% of cases. Yes. Don't know about the actual number, but it is certainly the common case - the rest of the analysis was just because we have to deal with all of the cases, not just the common one. I think it showed that this is the case that needs most concern though, so that's OK... | This scenario can be avoided by proper operational procedures: always | assign the ipv6 address that is also the subnet-router address on the | router. Assuming someone is assigning addresses, then yes, of course. The text I included was only intended to apply where the nodes were doing autoconf, and assigning their own addresses. | No problems then (except of course, if the host changes to be a | router at some point). That just changes the scenario from one to another case - the only weird one would be if the host & router swapped roles. Then they'd need to also swap addresses. I think this is going to be such a rare event that simply requiring them to swap addresses would be OK. | Problem here is that: | | Router A: 3ffe:ffff::0/127 (configured) | Router B: 3ffe:ffff::1/127 (configured) | | Now, if router B also manages to get the anycast address 3ffe:ffff::0, But it can't, that address is already taken. What's more, it knows that. It knows it is a /127 prefix. Thus there are exactly 2 addresses. It knows it is a p2p link. Thus it knows there is another node at the other end of the link (or will be someday) which also needs an address. So, if router B has 3ffe:ffff::1/127 then it cannot possibly also take 3ffe:ffff::0/127 for any purpose whatever. | You may want to configure e.g. eBGP peerings using point-to-point | addresses (other than link-local); there are a lot of other uses for them | too. I see no use for subnet-router anycast addresses in point-to-point | links, as it is always known that there is only one other there. I think that's perhaps because you missed the point of subnet-router anycast addresses - though I will certainly admit that the uses of them are likely to be fewer than uses of the concept in other places. But deprecating them in this context wasn't what you were proposing, rather it was deprecating use of /127 in order to be able to support them better. I don't think that's needed. 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 Nov 6 02:16:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6AG7QO020084 for ; Tue, 6 Nov 2001 02:16:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6AG62x020083 for ipng-dist; Tue, 6 Nov 2001 02:16: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6AG3QO020076 for ; Tue, 6 Nov 2001 02:16:03 -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 CAA09907 for ; Tue, 6 Nov 2001 02:16:05 -0800 (PST) Received: from purgatory.unfix.org (purgatory.xs4all.nl [194.109.237.229]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA29221 for ; Tue, 6 Nov 2001 03:15:46 -0700 (MST) Received: from cyan (intranet.azr.nl [::ffff:156.83.254.8]) by purgatory.unfix.org (Postfix) with ESMTP id 75CED314D; Tue, 6 Nov 2001 11:15:56 +0100 (CET) From: "Jeroen Massar" To: "'Robert Elz'" , "'Thomas Scholz'" Cc: , Subject: RE: SV: newbie question Date: Tue, 6 Nov 2001 11:15:10 +0100 Organization: Unfix Message-ID: <000701c166ab$eb9d2630$2a1410ac@kei.azr.nl> 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.2616 In-Reply-To: <1549.1005029893@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: > To: Thomas Scholz > Date: Thu, 1 Nov 2001 18:19:42 +0100 > From: "Thomas Scholz" > Message-ID: > > | And they have removed numricc URLs in XP, With "numberic URL's" they probably mean the http://[2001:6e0::1]/example/ addressing... > I'm not a user of any of their systems, so I'm just guessing what this > means, but if it is what it sounds like, it will be a HUGE win for the > internet as a whole way off into the distant future (provided they > resist the temptation to give way to the very few people who suffer > some negative impact - who are over represented in the IETF for sure). > This one (assuming it is as I am guessing) deserves a great vote of thanks. Wellps... from a developers & network point of view one would like to see that feature though As one could quickly check if a site is running without adding dns entries... then again most network people have knowledge enough to use telnet 80 and issue a get to test that out ;) And it surely 'saves' the surfing crowd from the IP hassle... and though the above example can probably be remembered correctly... I don't think many people would like a full EUI-64 IP to remember But that's why we got that nice DNS system ;) Greets, Jeroen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 6 02:41:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6AffQO020108 for ; Tue, 6 Nov 2001 02:41:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6AffqH020107 for ipng-dist; Tue, 6 Nov 2001 02: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6AfbQO020100 for ; Tue, 6 Nov 2001 02:41: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 CAA27656 for ; Tue, 6 Nov 2001 02:41:24 -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 DAA13451 for ; Tue, 6 Nov 2001 03:41:21 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fA6AfT225463; Tue, 6 Nov 2001 12:41:29 +0200 Date: Tue, 6 Nov 2001 12:41:29 +0200 (EET) From: Pekka Savola To: Robert Elz cc: Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: <2761.1005041573@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 On Tue, 6 Nov 2001, Robert Elz wrote: > | > | Router A: 3ffe:ffff::0/127 (configured) > | Router B: 3ffe:ffff::1/127 (configured) > | > | Now, if router B also manages to get the anycast address 3ffe:ffff::0, > > But it can't, that address is already taken. What's more, it knows that. > It knows it is a /127 prefix. Thus there are exactly 2 addresses. > It knows it is a p2p link. Thus it knows there is another node at the > other end of the link (or will be someday) which also needs an address. > > So, if router B has 3ffe:ffff::1/127 then it cannot possibly also take > 3ffe:ffff::0/127 for any purpose whatever. Perhaps I should have used the word 'configured' more carefully. What I meant was "defined in the configuration", not necessarily configured as such, performed DAD, etc. ie. "ready and working". Consider a scenario: Router B plugged in the network with Router A (e.g. cross-over cable). Neither has anything configured or set up yet on this link. 3ffe:ffff::1/127 address is added to Router A; now it DAD's for 3ffe:ffff::1 (normal address) and, being a router in the subnet, also 3ffe:ffff::0, and succeeds. Now Router B has been planned to use 3ffe:ffff::0/127 as an IPv6 address, but adding it will fail DAD, and P-t-P link cannot be established. Now, there are interesting variations of this in cases of router reloads, crashes etc. when this subnet-router anycast address becomes "free to get". > | You may want to configure e.g. eBGP peerings using point-to-point > | addresses (other than link-local); there are a lot of other uses for them > | too. I see no use for subnet-router anycast addresses in point-to-point > | links, as it is always known that there is only one other there. > > I think that's perhaps because you missed the point of subnet-router > anycast addresses - though I will certainly admit that the uses of them > are likely to be fewer than uses of the concept in other places. > > But deprecating them in this context wasn't what you were proposing, > rather it was deprecating use of /127 in order to be able to support > them better. I don't think that's needed. The point is, indeed, not the uses of subnet-router anycast address. The fact remains, as shown in the scenario above, that on router-router links, using /127 is impossible unless subnet-router anycast addresses are restricted or disabled. -- 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 Nov 6 03:00:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6B0qQO020160 for ; Tue, 6 Nov 2001 03:00:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6B0q4s020159 for ipng-dist; Tue, 6 Nov 2001 03: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6B0nQO020152 for ; Tue, 6 Nov 2001 03:00: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 DAA12993 for ; Tue, 6 Nov 2001 03:00:48 -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 DAA22156 for ; Tue, 6 Nov 2001 03:00:46 -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 fA6B1uS03036; Tue, 6 Nov 2001 18:01:57 +0700 (ICT) From: Robert Elz To: "Jeroen Massar" cc: "'Thomas Scholz'" , msripv6-users@list.research.microsoft.com, ipng@sunroof.eng.sun.com Subject: Re: SV: newbie question In-Reply-To: <000701c166ab$eb9d2630$2a1410ac@kei.azr.nl> References: <000701c166ab$eb9d2630$2a1410ac@kei.azr.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Nov 2001 18:01:56 +0700 Message-ID: <3034.1005044516@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 6 Nov 2001 11:15:10 +0100 From: "Jeroen Massar" Message-ID: <000701c166ab$eb9d2630$2a1410ac@kei.azr.nl> Aside: I'm not on msripv6-users@list.research.microsoft.com so the copies of messages I'm sending to that just bounce. I'm leaving it there so replies others send won't drop the list by accident. But do be aware that readers of that list will be seeing only a one sided exchange. | With "numberic URL's" they probably mean the | http://[2001:6e0::1]/example/ addressing... That's what I assumed. | Wellps... from a developers & network point of view one would like to | see that feature though Yes, as I said, the IETF is over represented with people who can perhaps make reasonable use of it, and should know when to, and when not to. But the much wider Internet community is not. | As one could quickly check if a site is running without adding dns | entries... If it is running without DNS entries, what use is it? Especially if a popular browser doesn't support finding it any other way? It might just as well be down. The supposed justification for those things is for accessing things that aren't web sites but just happen to use http as a config tool, and similar. | And it surely 'saves' the surfing crowd from the IP hassle... It isn't the hassle - it is that if these things work, they will get embedded in web pages. Perhaps by some web page designer who has calculated that their web pages load 70ms faster (avoiding 3 or 4 DNS lookups) when embedded addresses are used. But that then makes it almost impossible to ever change those addresses, if you fear that some other site might have links to your web pages using numeric addresses, and you want to keep attracting visitors, rather than discouraging them, then you have to keep the same address forever. That's not what we want. The best way to avoid that is to simply make this fail, and if that is what Microsoft have done, then I applaud their foresight. Note: I don't mind as much if "numeric URLs" work when some user types them into a locator box - that's much less of a problem. Where they really must not work, is when they're extracted from HTML. (Of course, typically, one parser will handle all cases, so breaking them for one breaks them for 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 Tue Nov 6 03:09:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6B92QO020177 for ; Tue, 6 Nov 2001 03:09:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6B929f020176 for ipng-dist; Tue, 6 Nov 2001 03:09: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6B8wQO020169 for ; Tue, 6 Nov 2001 03:08:59 -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 DAA09280 for ; Tue, 6 Nov 2001 03:08:58 -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 EAA28642 for ; Tue, 6 Nov 2001 04:08:39 -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 fA6BAOS03052; Tue, 6 Nov 2001 18:10:24 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Nov 2001 18:10:24 +0700 Message-ID: <3050.1005045024@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 6 Nov 2001 12:41:29 +0200 (EET) From: Pekka Savola Message-ID: | Consider a scenario: | | Router B plugged in the network with Router A (e.g. cross-over cable). | Neither has anything configured or set up yet on this link. | 3ffe:ffff::1/127 address is added to Router A; now it DAD's for | 3ffe:ffff::1 (normal address) and, being a router in the subnet, also | 3ffe:ffff::0, and succeeds. My point was that it must not. That is, if there are to be two nodes on a link, and there are two addresses available, it is positively insane for one of the two nodes to take both of them. If it wants (either via some config file, or just random chance) to pick the xxx0 address, then it gets to be the target of the anycast. If it doesn't, then it doesn't... It can't pick the xxx1 address for itself, and then go ahead and also pick the xxx0 address to be anycast. If an I-D needs to be written to make this (self-evident) truth clear, then I guess we should write one. I know that the normal use of anycast is for everyone eligible to assign themselves the address, but there's nothing in the definition that requires that - this just happens to be a scenario where that is inappropriate behaviour. | Now, there are interesting variations of this in cases of router reloads, | crashes etc. when this subnet-router anycast address becomes "free to | get". If you mean that things can flap around in such cases when using auto-config (not based upon stable identifiers), then yes, of course. That's pretty much self-evident too. | The fact remains, as shown in the scenario above, that on router-router | links, using /127 is impossible unless subnet-router anycast addresses are | restricted or disabled. No, go back to my first message - it isn't impossible at all. It just needs rational considered implementations. If anything, what we have now when systems use /127 for p2p links is the use of the subnet-router anycast address ready made (even though most probably the nodes don't know that's what they're doing, and in the rare cases when one end is a host rather than a router, the host might have the subnet-router address inappropriately). Everything is working just like it should. 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 Nov 6 04:04:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6C4KQO020303 for ; Tue, 6 Nov 2001 04:04:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6C4KFq020302 for ipng-dist; Tue, 6 Nov 2001 04:04: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6C4GQO020295 for ; Tue, 6 Nov 2001 04:04:16 -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 EAA04502 for ; Tue, 6 Nov 2001 04:04:01 -0800 (PST) Received: from purgatory.unfix.org (purgatory.xs4all.nl [194.109.237.229]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA13929 for ; Tue, 6 Nov 2001 04:04:14 -0800 (PST) Received: from cyan (intranet.azr.nl [::ffff:156.83.254.8]) by purgatory.unfix.org (Postfix) with ESMTP id 91A233216; Tue, 6 Nov 2001 13:04:11 +0100 (CET) From: "Jeroen Massar" To: "'Robert Elz'" Cc: , Subject: RE: SV: newbie question Date: Tue, 6 Nov 2001 13:03:25 +0100 Organization: Unfix Message-ID: <002201c166bb$0ab3fd50$2a1410ac@kei.azr.nl> 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.2616 In-Reply-To: <3034.1005044516@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: > To: Jeroen Massar > From: "Jeroen Massar" > The supposed justification for those things is for accessing things that > aren't web sites but just happen to use http as a config > tool, and similar. Ah.... I usually simply throw those into dns also... I hate remembering IP's :) Actually I remember only the IP of some shellboxes which should always work that way I can always ssh in and use the tools there to do the resolving... > > | And it surely 'saves' the surfing crowd from the IP hassle... > > It isn't the hassle - it is that if these things work, they will get > embedded in web pages. Perhaps by some web page designer who has > calculated that their web pages load 70ms faster (avoiding 3 or 4 DNS > lookups) when embedded addresses are used. They should learn those 'webdesigners' to use .. in url's ;) > But that then makes it almost impossible to ever change those addresses, > if you fear that some other site might have links to your web pages > using numeric addresses, and you want to keep attracting > visitors, rather than discouraging them, then you have to keep the same address forever. On another note.... though that's probably more userspace related... Scenario: Company has a webserver with 1 nic in it... they use rtsols to get a route and do a nice autoconfig. The nic in the webserver dies (made in holland blabla ;) and they exchange it with a new one. Because of the new nic the IPv6 autoconfigged address changes and thus alongside the downtime because of the nic-brokage they now also have DNS downtime (till TTL)... Wouldn't it be nice to have a script or other defacto functionality which would then get the EUI-64 part from a database/file/setting/... and then using the prefix it gets from the rtsol to config an alias IP for the webserver. This so the DNS can contain the IP address of the webserver say f00:b44::80 (which takes care of the nic-breaking problem). Point of problem: The prefix changes, admins know it and start updating the dns, the machine is notified with router announcements and the autoconfigged address (the real EUI-64 enabled one) automagically gets enabled, the old one goes away when it's TTL expires... The f00:b44::80 IP though doesn't get notified yet... What this would need (and haven't found in the most common IPv6 stack implementations, unless something like this would need to be hacked in) is somekind of notify of rtsols, or a facility where one can specify which EUI-64 part a host should also bind too as an alias... yup I am preferring the EUI-64 address instead of this 'virtual' one... > Note: I don't mind as much if "numeric URLs" work when some user types > them into a locator box - that's much less of a problem. Where they > really must not work, is when they're extracted from HTML. > (Of course, typically, one parser will handle all cases, so breaking them for one breaks them for all.) IE handles URL's with the dll wininet.dll, as the functionality of the numberic URL's have been taken out from there any program using wininet.dll (for instance WinAmp and Cam32) don't support it anymore either... So maybe in this case the parser (mshtml.dll :) still does know about the numberic stuff ? :) Greets, Jeroen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 6 04:42:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6CgEQO020395 for ; Tue, 6 Nov 2001 04:42:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6CgED1020394 for ipng-dist; Tue, 6 Nov 2001 04:42: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6CgBQO020387 for ; Tue, 6 Nov 2001 04:42:11 -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 EAA13783 for ; Tue, 6 Nov 2001 04:42:11 -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 FAA18669 for ; Tue, 6 Nov 2001 05:41:52 -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 fA6ChoS03258; Tue, 6 Nov 2001 19:43:50 +0700 (ICT) From: Robert Elz To: "Jeroen Massar" cc: ipng@sunroof.eng.sun.com Subject: Re: SV: newbie question In-Reply-To: <002201c166bb$0ab3fd50$2a1410ac@kei.azr.nl> References: <002201c166bb$0ab3fd50$2a1410ac@kei.azr.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Nov 2001 19:43:50 +0700 Message-ID: <3256.1005050630@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 6 Nov 2001 13:03:25 +0100 From: "Jeroen Massar" Message-ID: <002201c166bb$0ab3fd50$2a1410ac@kei.azr.nl> This time I took the msripv6... address out of the headers, nothing vendor specific left in this message. | Ah.... I usually simply throw those into dns also... Me too. The (lame) argument is "but I need to use http to configure the DNS" (as if the DNS isn't (at least) have its own address in there, essentially all of the time...) | Wouldn't it be nice to have a script or other defacto functionality | which would then get the EUI-64 part from a database/file/setting/... | and then using the prefix it gets from the rtsol to config an alias IP | for the webserver. Yes, a way by which the implementation would remember the address it auto-config itself before, and repeat that would be useful. This is an implementation feature (or lack thereof) though. | is somekind of notify of rtsols, or a facility where one can specify | which EUI-64 part a host should also bind too I have also wanted (for other reasons) to be able to specify just the interface ID part of the IPv6 address, and have the autoconf code then apply that to prefixes advertised from the router(s). This is the kind of thing that (I expect) will appear as more experience is gained with the implementations. 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 Nov 6 05:47:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6DlHQO020629 for ; Tue, 6 Nov 2001 05:47:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6DlHPL020628 for ipng-dist; Tue, 6 Nov 2001 05:47: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6DlEQO020621 for ; Tue, 6 Nov 2001 05:47:14 -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 FAA13515 for ; Tue, 6 Nov 2001 05:46:55 -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 GAA00965 for ; Tue, 6 Nov 2001 06:46:52 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fA6DkvF26716; Tue, 6 Nov 2001 15:46:57 +0200 Date: Tue, 6 Nov 2001 15:46:57 +0200 (EET) From: Pekka Savola To: Robert Elz cc: Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: <3050.1005045024@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 On Tue, 6 Nov 2001, Robert Elz wrote: > | Router B plugged in the network with Router A (e.g. cross-over cable). > | Neither has anything configured or set up yet on this link. > | 3ffe:ffff::1/127 address is added to Router A; now it DAD's for > | 3ffe:ffff::1 (normal address) and, being a router in the subnet, also > | 3ffe:ffff::0, and succeeds. > > My point was that it must not. That is, if there are to be two nodes > on a link, and there are two addresses available, it is positively insane > for one of the two nodes to take both of them. Sure.. > If it wants (either via some config file, or just random chance) to pick > the xxx0 address, then it gets to be the target of the anycast. If it > doesn't, then it doesn't... > > It can't pick the xxx1 address for itself, and then go ahead and also > pick the xxx0 address to be anycast. If an I-D needs to be written to > make this (self-evident) truth clear, then I guess we should write one. > > I know that the normal use of anycast is for everyone eligible to assign > themselves the address, but there's nothing in the definition that requires > that - this just happens to be a scenario where that is inappropriate > behaviour. .. but as you noted, this is different from the "normal" use of anycast. This operational/technical restriction has not been discussed anywhere (AFAICS). It'd be pretty optimistic to assume every implementation would do the "right" thing (contrary to "do it by the spec"). > | The fact remains, as shown in the scenario above, that on router-router > | links, using /127 is impossible unless subnet-router anycast addresses are > | restricted or disabled. > > No, go back to my first message - it isn't impossible at all. It just > needs rational considered implementations. Sure. This approach would case the following, I suppose: 1) (at least almost) everybody implements by the spec (thinking of "normal procedure") 2) some implementation, later, notices this problem, discards it by giving operational advice; "don't do /127 ptp" 3) some implementation, later, notices this problem, fixes it by a few rational rules, but if the other end of the pipe is non-rational, everything can still break. 4) there will be non-rational implementations forever I believe, the only thing there is to nail this for good is to either/and: - make it widely known that this should be operationally avoided - specify the rational behaviour of anycast assignment in this case > If anything, what we have now when systems use /127 for p2p links is > the use of the subnet-router anycast address ready made (even though > most probably the nodes don't know that's what they're doing, and in the > rare cases when one end is a host rather than a router, the host might > have the subnet-router address inappropriately). Everything is working > just like it should. This is an illusion that will break. Nobody that I know of implements subnet-router anycast address yet. (just checked Linux, FreeBSD 4.4, Cisco), so this is not yet a problem that it would be one day. -- 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 Nov 6 06:13:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6ED6QO020691 for ; Tue, 6 Nov 2001 06:13:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6ED6qQ020690 for ipng-dist; Tue, 6 Nov 2001 06: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6ED3QO020683 for ; Tue, 6 Nov 2001 06:13: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 GAA26895 for ; Tue, 6 Nov 2001 06:13:04 -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 HAA22119 for ; Tue, 6 Nov 2001 07:12:41 -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 fA6EEXS03608; Tue, 6 Nov 2001 21:14:33 +0700 (ICT) From: Robert Elz To: Pekka Savola cc: ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Nov 2001 21:14:33 +0700 Message-ID: <3606.1005056073@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 6 Nov 2001 15:46:57 +0200 (EET) From: Pekka Savola Message-ID: | I believe, the only thing there is to nail this for good is to either/and: | - specify the rational behaviour of anycast assignment in this case I certainly have no problem if someone wants to write a draft which details the issues, and explains the way to deal with it - just as long as the way isn't "use /126 or smaller" (except possibly to suggest that as a workaround to deal with implementations that don't do the sensible thing). That is, I have no problem as long as the someone isn't me... 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 Nov 6 07:56:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6FuQQO021008 for ; Tue, 6 Nov 2001 07:56:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6FuPg1021007 for ipng-dist; Tue, 6 Nov 2001 07:56: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6FuLQO021000 for ; Tue, 6 Nov 2001 07:56: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 HAA01800; Tue, 6 Nov 2001 07:56:01 -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 IAA22692; Tue, 6 Nov 2001 08:56:14 -0700 (MST) Received: from localhost ([3ffe:501:100f:13ff::a]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fA6FuA332153; Wed, 7 Nov 2001 00:56:11 +0900 (JST) Date: Wed, 07 Nov 2001 00:56:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: TCP and Ancillary data in RFC2292bis In-Reply-To: References: User-Agent: Wanderlust/2.7.5 (Too Funky) 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 980905(IM100) Lines: 56 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 6 Nov 2001 10:46:47 +0100 (CET), >>>>> Erik Nordmark said: > Just being able to capture the "last received" extension headers > might not be useful either - it depends for what the application is using the > extension headers. > For instance, if security depends on it then presumably the TCP needs > to be able to "latch in" a given content i.e. be able to reject packets > which do not have the extension header content that was used to create the > connection. > And in such a "latch in" case a the "last received" semantics make sense > because the extension header content can by definition not change during > the connection. That's true, but I think security-conscious applications would want to check the contents of the extension headers in ack-only segments as well as in data segments. Thus, the current specification cannot satisfy such applications. > So the problem is that while we have applications using the ancillary data > for ICMP (and perhaps UDP) to ensure that the hoplimit is 255 > and that there is no routing header, we do not have similar applications > that need this ability with TCP. So we are stumbling around in the dark > a bit. Yes, that's the point. And, I tend to feel that (= treat TCP like UDP/raw-IP6 on this point) is an impossible goal, because applications essentially cannot get access to TCP data per segment basis (some segments do not contain actual data, some can be silently discarded in the kernel due to duplication/overlapping/etc). So, IMO, we should admit that this kind of mechanism can only be provided in lower layer filtering, and the optional information passed from a TCP stack to an application should be used just as some hints. Based on this view, my current feeling is that the best way is to fall back to a single get-only socket option like RFC2292's IPV6_PKTOPTIONS (though the option could be "set" in the RFC) with the simple "keep the last received ones" logic. Although this change can cause backward compatibility issues with existing applications that rely on the former versions of rfc2292-bis, I personally think it is negligible. We implemented the older versions of the API almost two years ago, but I've not seen any TCP applications that rely on the spec. What do other implementors think? Does this change make sense? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp p.s. sine some might be wondering about the current situation of the spec...I'm now editting a revised version of the spec, which will be available before the cut-off date for the next IETF 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 Tue Nov 6 08:00:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6G0TQO021030 for ; Tue, 6 Nov 2001 08:00:29 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6G0TQm021029 for ipng-dist; Tue, 6 Nov 2001 08:00: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6G0PQO021022 for ; Tue, 6 Nov 2001 08:00:25 -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 IAA18166 for ; Tue, 6 Nov 2001 08:00:25 -0800 (PST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09965 for ; Tue, 6 Nov 2001 08:00:24 -0800 (PST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GMD00E8DZ4GM0@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Tue, 06 Nov 2001 10:00:16 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id fA6G0El06840; Tue, 06 Nov 2001 10:00:15 -0600 (CST) Date: Tue, 06 Nov 2001 10:00:14 -0600 From: Matt Crawford Subject: Re: /127 for P-t-P Considered Harmful In-reply-to: "06 Nov 2001 11:27:08 +0200." To: Pekka Savola Cc: Robert Elz , ipng@sunroof.eng.sun.com Message-id: <200111061600.fA6G0El06840@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've never been able to think of a theoretical reason why the two endpoints of a point-to-point link have to have addresses which are related in any way. Is there some more practical reason why they should be? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 6 08:11:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GB0QO021057 for ; Tue, 6 Nov 2001 08:11:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6GB0fI021056 for ipng-dist; Tue, 6 Nov 2001 08: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GAvQO021049 for ; Tue, 6 Nov 2001 08:10:57 -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 IAA05654 for ; Tue, 6 Nov 2001 08:10:41 -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 JAA09928 for ; Tue, 6 Nov 2001 09:10:39 -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 IAA00824 for ; Tue, 6 Nov 2001 08:10:56 -0800 (PST) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fA6GAtG06410 for ; Tue, 6 Nov 2001 08:10:55 -0800 X-mProtect: Tue, 6 Nov 2001 08:10:55 -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(P1.5 smtpdhdlkBs; Tue, 06 Nov 2001 08:10:54 PST Message-ID: <3BE80B8E.779A5051@iprg.nokia.com> Date: Tue, 06 Nov 2001 08:10:54 -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: ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful References: <3606.1005056073@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, Why isn't it sensible to declare that 120 bits is the longest possible subnet prefix, so that point-to-point links can conform to RFC 2526 "Reserved IPv6 Subnet Anycast Addresses"? There may be other anycast addresses useful in the future that cannot be handled by the sort of special-case analysis that has been applied to the "Subnet Router" anycast address. Then applications using those addresses would not work on point-to-point links, which seems like a mistake to me. Regards, Charlie P. Robert Elz wrote: > > Date: Tue, 6 Nov 2001 15:46:57 +0200 (EET) > From: Pekka Savola > Message-ID: > > | I believe, the only thing there is to nail this for good is to either/and: > | - specify the rational behaviour of anycast assignment in this case > > I certainly have no problem if someone wants to write a draft which > details the issues, and explains the way to deal with it - just as > long as the way isn't "use /126 or smaller" (except possibly to suggest > that as a workaround to deal with implementations that don't do the > sensible thing). > > That is, I have no problem as long as the someone isn't me... > > 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 Tue Nov 6 08:19:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GJ4QO021150 for ; Tue, 6 Nov 2001 08:19:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6GJ4RR021149 for ipng-dist; Tue, 6 Nov 2001 08:19: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GJ0QO021140 for ; Tue, 6 Nov 2001 08:19:00 -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 IAA14803 for ; Tue, 6 Nov 2001 08:19:01 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17941 for ; Tue, 6 Nov 2001 09:18:41 -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.2966); Tue, 6 Nov 2001 08:18:48 -0800 Received: from 157.54.8.23 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 06 Nov 2001 08:18:48 -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.2966); Tue, 6 Nov 2001 08:18:44 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 6 Nov 2001 08:18:47 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3562.0); Tue, 6 Nov 2001 08:18:07 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: /127 for P-t-P Considered Harmful Date: Tue, 6 Nov 2001 08:18:06 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: /127 for P-t-P Considered Harmful thread-index: AcFm3IcndBDlPfoVR++QVMlOt8ajqwAAcQBw From: "Christian Huitema" To: "Matt Crawford" , "Pekka Savola" Cc: "Robert Elz" , X-OriginalArrivalTime: 06 Nov 2001 16:18:07.0043 (UTC) FILETIME=[9E769930:01C166DE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fA6GJ1QO021143 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk /127 for a P-t-P link? This must be a bug! We need a /64! Have people considered the privacy implications? The computer at the end of the link may well want to use privacy addresses. Also, there is a credible possibility that a computer is composed of multiple subsystems, each with their own IPv6 address. In the aggregatable architecture, it makes a lot of sense if "n" is in fact 64 for most links. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 6 08:20:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GKLQO021212 for ; Tue, 6 Nov 2001 08:20:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6GKLpJ021211 for ipng-dist; Tue, 6 Nov 2001 08:20: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GKGQO021198 for ; Tue, 6 Nov 2001 08:20:16 -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 IAA07040 for ; Tue, 6 Nov 2001 08:20:01 -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 IAA11011 for ; Tue, 6 Nov 2001 08:20:15 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fA6GK7B27873; Tue, 6 Nov 2001 18:20:07 +0200 Date: Tue, 6 Nov 2001 18:20:06 +0200 (EET) From: Pekka Savola To: Matt Crawford cc: Robert Elz , Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: <200111061600.fA6G0El06840@gungnir.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 6 Nov 2001, Matt Crawford wrote: > I've never been able to think of a theoretical reason why the two > endpoints of a point-to-point link have to have addresses which are > related in any way. Is there some more practical reason why they > should be? I'm not really sure what you mean, but unless I'm mistaking... You usually want to add routes, the other end as the next hop. If the other end is not "connected", this is may be difficult. As for theoretical reasons, I guess it would be enough just to be able to declare arbitrary addresses "connected" to specified interfaces by adding host routes if the implementation allows adding such for P-t-P links without an explicit next-hop. -- 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 Nov 6 08:27:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GRQQO021298 for ; Tue, 6 Nov 2001 08:27:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6GRQog021297 for ipng-dist; Tue, 6 Nov 2001 08: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GRMQO021290 for ; Tue, 6 Nov 2001 08:27: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 IAA16414 for ; Tue, 6 Nov 2001 08:27:23 -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 JAA26298 for ; Tue, 6 Nov 2001 09:27:04 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fA6GR0a27926; Tue, 6 Nov 2001 18:27:00 +0200 Date: Tue, 6 Nov 2001 18:26:59 +0200 (EET) From: Pekka Savola To: Christian Huitema cc: Matt Crawford , Robert Elz , Subject: RE: /127 for P-t-P Considered Harmful 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 Tue, 6 Nov 2001, Christian Huitema wrote: > /127 for a P-t-P link? This must be a bug! We need a /64! Tell that to ARIN et al which advocate(d) a single /64 as an IX allocation. Does "640kb should be enough for everyone." sound familiar... :-) > Have people considered the privacy implications? The computer at the end > of the link may well want to use privacy addresses. Also, there is a > credible possibility that a computer is composed of multiple subsystems, > each with their own IPv6 address. In the aggregatable architecture, it > makes a lot of sense if "n" is in fact 64 for most links. I don't think it's being pushed that /127 be used (/64 should be preferred), but sometimes a smaller allocation might make more sense, in one way or another. Under these circumstances, it is not often necessary to worry about privacy. -- 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 Nov 6 08:32:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GWaQO021334 for ; Tue, 6 Nov 2001 08:32:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6GWafn021333 for ipng-dist; Tue, 6 Nov 2001 08: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GWXQO021326 for ; Tue, 6 Nov 2001 08:32:33 -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 IAA24988 for ; Tue, 6 Nov 2001 08:32:34 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA01202 for ; Tue, 6 Nov 2001 08:32:31 -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 fA6GXiS04180; Tue, 6 Nov 2001 23:33:44 +0700 (ICT) From: Robert Elz To: "Christian Huitema" cc: "Matt Crawford" , "Pekka Savola" , ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Nov 2001 23:33:44 +0700 Message-ID: <4178.1005064424@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 6 Nov 2001 08:18:06 -0800 From: "Christian Huitema" Message-ID: | Have people considered the privacy implications? The computer at the end | of the link may well want to use privacy addresses. Also, there is a | credible possibility that a computer is composed of multiple subsystems, | each with their own IPv6 address. In the aggregatable architecture, it | makes a lot of sense if "n" is in fact 64 for most links. Your message, and Matt's, are both missing the point. The question isn't whether using a /127 is the right way, or the only way, or whether a subnet number needs to be allocated at all (Matt - one reason is for connecting isolated systems, which have the P2P link as their only network connection - they have no other addresses to use). The issue Pekka raised, was assuming that a /127 is being used, how are these particular anycast addresses to be allocated - and does that mean that we should prohibit /127's or something. It was certainly a reasonable question. Looking for ways to avoid the problem might be nice if you're faced with deciding what to do in the field, but it isn't the correct approach when what is being done is writing the specs. I'll answer Charlie's message separately... 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 Nov 6 08:33:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GXCQO021351 for ; Tue, 6 Nov 2001 08:33:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6GXCQH021350 for ipng-dist; Tue, 6 Nov 2001 08:33: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GX8QO021343 for ; Tue, 6 Nov 2001 08:33:08 -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 IAA09113 for ; Tue, 6 Nov 2001 08:32:54 -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 IAA01583 for ; Tue, 6 Nov 2001 08:33:08 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fA6GX3A27987; Tue, 6 Nov 2001 18:33:03 +0200 Date: Tue, 6 Nov 2001 18:33:03 +0200 (EET) From: Pekka Savola To: "Charles E. Perkins" cc: Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: <3BE80B8E.779A5051@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 Tue, 6 Nov 2001, Charles E. Perkins wrote: > There may be other anycast addresses useful in the future > that cannot be handled by the sort of special-case analysis > that has been applied to the "Subnet Router" anycast > address. Then applications using those addresses would > not work on point-to-point links, which seems like a > mistake to me. Clarification for the record: point-to-point links where one decides to use a very short prefix. Everything works fine with a proper /64 of course. -- 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 Nov 6 08:35:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GZpQO021368 for ; Tue, 6 Nov 2001 08:35:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6GZoXi021367 for ipng-dist; Tue, 6 Nov 2001 08: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GZlQO021360 for ; Tue, 6 Nov 2001 08:35:47 -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 IAA19788 for ; Tue, 6 Nov 2001 08:35:48 -0800 (PST) Received: from sem.renater.fr (sem.renater.fr [193.49.160.1]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19040 for ; Tue, 6 Nov 2001 08:35:47 -0800 (PST) Received: from stagiairev6 (stagiaireV6.renater.fr [193.49.160.16]) by sem.renater.fr (8.11.0/8.11.0) with SMTP id fA6GZkC26630 for ; Tue, 6 Nov 2001 17:35:46 +0100 Message-ID: <00ad01c166e0$b3678d20$10a031c1@renater.fr> From: =?iso-8859-1?B?Suly9G1lIER1cmFuZA==?= To: References: Subject: Re: /127 for P-t-P Considered Harmful Date: Tue, 6 Nov 2001 17:33:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello I think it is necessary to have interconnexion networks using public addresses for debugging routes (ex: traceroute or things like that) so we need to number those networks. a /127 wouldn't be a good idea. It's difficult for a provider to play with prefixes that do not fit with the beginning or the end of a quartil. It's not very simple to deal with the /35 given to providers as well ! So I think that a /64 is a good idea for interconnexion networks. Regards Jerome Durand GIP Renater IPv6 Multicast ----- Original Message ----- From: Pekka Savola To: Matt Crawford Cc: Robert Elz ; Sent: Tuesday, November 06, 2001 5:20 PM Subject: Re: /127 for P-t-P Considered Harmful > On Tue, 6 Nov 2001, Matt Crawford wrote: > > I've never been able to think of a theoretical reason why the two > > endpoints of a point-to-point link have to have addresses which are > > related in any way. Is there some more practical reason why they > > should be? > > I'm not really sure what you mean, but unless I'm mistaking... > > You usually want to add routes, the other end as the next hop. If the > other end is not "connected", this is may be difficult. > > As for theoretical reasons, I guess it would be enough just to be able to > declare arbitrary addresses "connected" to specified interfaces by adding > host routes if the implementation allows adding such for P-t-P links > without an explicit next-hop. > > -- > 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 Tue Nov 6 08:44:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GioQO021415 for ; Tue, 6 Nov 2001 08:44:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6Giopi021414 for ipng-dist; Tue, 6 Nov 2001 08:44: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GijQO021407 for ; Tue, 6 Nov 2001 08:44:45 -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 IAA27505 for ; Tue, 6 Nov 2001 08:44:46 -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 IAA09464 for ; Tue, 6 Nov 2001 08:44:44 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fA6Gic228078; Tue, 6 Nov 2001 18:44:38 +0200 Date: Tue, 6 Nov 2001 18:44:38 +0200 (EET) From: Pekka Savola To: "Charles E. Perkins" cc: Subject: Re: /127 for P-t-P Considered Harmful 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 Tue, 6 Nov 2001, Pekka Savola wrote: > On Tue, 6 Nov 2001, Charles E. Perkins wrote: > > There may be other anycast addresses useful in the future > > that cannot be handled by the sort of special-case analysis > > that has been applied to the "Subnet Router" anycast > > address. Then applications using those addresses would > > not work on point-to-point links, which seems like a > > mistake to me. > > Clarification for the record: point-to-point links where one decides to > use a very short prefix. Everything works fine with a proper /64 of > course. sigh. very long prefix, of course. -- 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 Nov 6 08:51:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GpfQO021527 for ; Tue, 6 Nov 2001 08:51:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6GpfmH021526 for ipng-dist; Tue, 6 Nov 2001 08: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6GpcQO021519 for ; Tue, 6 Nov 2001 08:51:38 -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 IAA13319 for ; Tue, 6 Nov 2001 08:51:23 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14072 for ; Tue, 6 Nov 2001 08:51:37 -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 fA6GrCS04202; Tue, 6 Nov 2001 23:53:12 +0700 (ICT) From: Robert Elz To: "Charles E. Perkins" cc: ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: <3BE80B8E.779A5051@iprg.nokia.com> References: <3BE80B8E.779A5051@iprg.nokia.com> <3606.1005056073@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Nov 2001 23:53:12 +0700 Message-ID: <4200.1005065592@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 06 Nov 2001 08:10:54 -0800 From: "Charles E. Perkins" Message-ID: <3BE80B8E.779A5051@iprg.nokia.com> | Why isn't it sensible to declare that 120 bits is the | longest possible subnet prefix, so that point-to-point | links can conform to RFC 2526 "Reserved IPv6 Subnet | Anycast Addresses"? That is a much more relevant concern - though I think the magic number would need to be 119 bits - otherwise those reserved IPv6 Subnet Anycast Addresses would use the entire remaining space - there'd be nothing left to use to number the two end-points. That is, unless we could reserve a couple of values from the reserved space, or something... If we went down that road we'd start arguing about just how many bits should be the longest possible - anything from Christian's /64 (which then presses very hard against the one small number that is in IPv6 addresses - the 16 bit number of subnets field) and up. As I understand 2526, the idea is that some addresses should be reserved for some particular purposes (and as usual, most of them have yet to be invented). Unlike 2373 (which really should have been mentioned in 2526, it defines a reserved anycast address that doesn't fit the 2526 pattern) which requires the subnet anycast address - nothing in 2526 actually requires that the addresses exist on any particular subnet, right? That is, if I choose to allocate lots of addresses (subnet or otherwise) from some subnet number, then clearly the prefix length for that subnet must be short enough to handle that. On the other hand, if I'm not going to be doing that, then I don't need to allow space for them, and we can avoid the "how many is enough" arguments. Note that there's no way for a remote application to simply decide that they want to use an anycast address on my subnet, and calculate it based upon some specification - they have to have more information than that. Even 2526 sets out two different bit patterns for the bits between the prefix and the reserved bits, depending upon the nature of the subnet under consideration. There's no way a random remote node can possibly know which is to apply. The one anycast address already allocated in 2526 meets that property, a roaming mobile node can be assumed to know the prefix length of the subnet, and whether it is an EUI-64 subnet or not (after all, sometimes it lives there) - so it can calculate the anycast address for when it needs to use it. There are unlikely to be many more applications where those conditions apply though (only if you can find some more in MobileIP). All this leads me to conclude that this isn't something that we need to worry about either - we can safely allow /127's for p2p links if that's what the net operators want to use. Those /127's won't be able to support any of the 2526 anycast addresses, but that's OK, without knowledge that they would be supported (and how) no-one could use them anyway. 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 Nov 6 09:13:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6HDaQO021799 for ; Tue, 6 Nov 2001 09:13:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6HDaPp021798 for ipng-dist; Tue, 6 Nov 2001 09:13: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6HDWQO021790 for ; Tue, 6 Nov 2001 09:13:32 -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 JAA17786 for ; Tue, 6 Nov 2001 09:13:17 -0800 (PST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13228 for ; Tue, 6 Nov 2001 10:13:15 -0700 (MST) 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 fA6H5xn19224; Tue, 6 Nov 2001 09:05:59 -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 AAG73647; Tue, 6 Nov 2001 09:05:21 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA15178; Tue, 6 Nov 2001 09:05:57 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15336.6261.322571.397972@thomasm-u1.cisco.com> Date: Tue, 6 Nov 2001 09:05:57 -0800 (PST) To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: <4200.1005065592@brandenburg.cs.mu.OZ.AU> References: <3BE80B8E.779A5051@iprg.nokia.com> <3606.1005056073@brandenburg.cs.mu.OZ.AU> <4200.1005065592@brandenburg.cs.mu.OZ.AU> 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 Robert Elz writes: > Note that there's no way for a remote application to simply decide that > they want to use an anycast address on my subnet, and calculate it based > upon some specification - they have to have more information than that. Tangential -- all that's required is the prefix length, right? 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 Nov 6 09:19:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6HJYQO021925 for ; Tue, 6 Nov 2001 09:19:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6HJYse021924 for ipng-dist; Tue, 6 Nov 2001 09: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6HJVQO021915 for ; Tue, 6 Nov 2001 09:19: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 JAA00182 for ; Tue, 6 Nov 2001 09:19:32 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19522 for ; Tue, 6 Nov 2001 10:19:14 -0700 (MST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 1619sh-000AOZ-00; Tue, 06 Nov 2001 09:19:23 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: =?iso-8859-1?B?Suly9G1lIER1cmFuZA==?= Cc: Subject: Re: /127 for P-t-P Considered Harmful References: <00ad01c166e0$b3678d20$10a031c1@renater.fr> Message-Id: Date: Tue, 06 Nov 2001 09:19:23 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think it is necessary to have interconnexion networks using public > addresses for debugging routes (ex: traceroute or things like that) so we > need to number those networks. > a /127 wouldn't be a good idea. It's difficult for a provider to play with > prefixes that do not fit with the beginning or the end of a quartil. It's > not very simple to deal with the /35 given to providers as well ! > So I think that a /64 is a good idea for interconnexion networks. since it is a subnet, should it not get a /48. maybe, just to be safe, a /44? after all, 128 bits is infinite, right? 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 Tue Nov 6 09:22:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6HM7QO021954 for ; Tue, 6 Nov 2001 09:22:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6HM7sr021953 for ipng-dist; Tue, 6 Nov 2001 09:22: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6HM3QO021946 for ; Tue, 6 Nov 2001 09:22:03 -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 JAA01129 for ; Tue, 6 Nov 2001 09:22:04 -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 JAA15390 for ; Tue, 6 Nov 2001 09:22:04 -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 JAA05784; Tue, 6 Nov 2001 09:22:04 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fA6HM3904665; Tue, 6 Nov 2001 09:22:03 -0800 X-mProtect: Tue, 6 Nov 2001 09:22:03 -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(P1.5 smtpd5UGRy6; Tue, 06 Nov 2001 09:22:02 PST Message-ID: <3BE81C3B.EA87B3B5@iprg.nokia.com> Date: Tue, 06 Nov 2001 09:22:03 -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: Robert Elz CC: ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful References: <3BE80B8E.779A5051@iprg.nokia.com> <3606.1005056073@brandenburg.cs.mu.OZ.AU> <4200.1005065592@brandenburg.cs.mu.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Robert Elz wrote: > | Why isn't it sensible to declare that 120 bits is the > | longest possible subnet prefix, so that point-to-point > | links can conform to RFC 2526 "Reserved IPv6 Subnet > | Anycast Addresses"? > > That is a much more relevant concern - though I think the magic number > would need to be 119 bits - otherwise those reserved IPv6 Subnet > Anycast Addresses would use the entire remaining space - there'd be > nothing left to use to number the two end-points. The reserved space for anycast addresses is 7 bits long, and then there is the all-zeros identifier, which would leave over 100 addresses with a 120-bit prefix -- isn't that right? > That is, unless we could reserve a couple of values from the reserved > space, or something... :-) > As I understand 2526, the idea is that some addresses should be reserved > for some particular purposes (and as usual, most of them have yet to be > invented). Here, I am arguing to improve the chances that they will at some point be better able to be invented, by now avoiding problems for their future existence. > Unlike 2373 (which really should have been mentioned in 2526, > it defines a reserved anycast address that doesn't fit the 2526 pattern) > which requires the subnet anycast address - nothing in 2526 actually > requires that the addresses exist on any particular subnet, right? Citing 2373, I assume you mean the "Subnet Routers" anycast address. Deciding whether or not 2526 mandates the existence of those addresses is the point of this discussion. I think it would "typically" be read to place the requirement, but we can certainly decide otherwise. I favor mandating the addresses, and I don't see any downside. > That is, if I choose to allocate lots of addresses (subnet or otherwise) > from some subnet number, then clearly the prefix length for that subnet > must be short enough to handle that. On the other hand, if I'm not going > to be doing that, then I don't need to allow space for them, and we > can avoid the "how many is enough" arguments. We can decide whether the address space is always there, or whether it has to be configured to be there, or whether applications have to negotiate to figure out whether it's there, or probe it, or "whatever". I think it is simplest to just decide that it's there. Then applications can be written more easily, both in the cases of successful connection and failure condtions. > Note that there's no way for a remote application to simply decide that > they want to use an anycast address on my subnet, and calculate it based > upon some specification - they have to have more information than that. Can you say more about why this is impossible? > Even 2526 sets out two different bit patterns for the bits between the > prefix and the reserved bits, depending upon the nature of the subnet > under consideration. There's no way a random remote node can possibly > know which is to apply. If the remote node knows that the prefix has more than 64 bits, it can form the anycast address. For shorter prefixes, it seems to me that this problem is as hard as passing a flag to a subroutine that says whether or not the subnet is EUI-64 conformant. I agree with you that this is unfortunate. Or else the application could try twice :-). > The one anycast address already allocated in 2526 meets that property, > a roaming mobile node can be assumed to know the prefix length of the > subnet, and whether it is an EUI-64 subnet or not (after all, sometimes > it lives there) - so it can calculate the anycast address for when it > needs to use it. There are unlikely to be many more applications > where those conditions apply though (only if you can find some more in > MobileIP). I don't really believe your statement here. I think that anycast is more appropriate for service discovery than multicast, which is already being used for that purpose. But I am curious to find out what is the downside on making this restriction on longest-possible prefix length? 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 Nov 6 09:26:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6HQJQO021981 for ; Tue, 6 Nov 2001 09:26:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6HQJUv021980 for ipng-dist; Tue, 6 Nov 2001 09:26: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6HQFQO021973 for ; Tue, 6 Nov 2001 09:26: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 JAA02592 for ; Tue, 6 Nov 2001 09:26:16 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA06936 for ; Tue, 6 Nov 2001 09:26:14 -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 fA6HRcS04489; Wed, 7 Nov 2001 00:27:38 +0700 (ICT) From: Robert Elz To: Michael Thomas cc: ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: <15336.6261.322571.397972@thomasm-u1.cisco.com> References: <15336.6261.322571.397972@thomasm-u1.cisco.com> <3BE80B8E.779A5051@iprg.nokia.com> <3606.1005056073@brandenburg.cs.mu.OZ.AU> <4200.1005065592@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Nov 2001 00:27:38 +0700 Message-ID: <4487.1005067658@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 6 Nov 2001 09:05:57 -0800 (PST) From: Michael Thomas Message-ID: <15336.6261.322571.397972@thomasm-u1.cisco.com> | Tangential -- all that's required is the prefix length, | right? Unless it is /64 in which case you'd also need to know whether EUI-64 was in use or not. I know there's the theory that the initial 3 bit prefix, if between 1 and 6 (inclusive) mandates use of /64 and EUI-64 everywhere. That's simply ludicrous, there's no reason for it, and long term it will never last. So I certainly don't want to start designing anything anywhere that is built based upon that assumption. You'd also want to have some idea whether you can expect the relevant anycast address to exist or not ... most links aren't going to have mobile IP home agents for example (or in any case, not all links will). All in all (if you actually want to achieve a productive result, rather than just send out packets to see what happens) you're going to need a reasonable amount of knowledge about the destination. Computing addresses that relate to anything that isn't local has never been a good idea, and it isn't going to start becoming one anytime soon. jre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 6 09:32:49 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6HWnQO022015 for ; Tue, 6 Nov 2001 09:32:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6HWmTA022014 for ipng-dist; Tue, 6 Nov 2001 09:32: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6HWeQO022007 for ; Tue, 6 Nov 2001 09:32: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 JAA04500 for ; Tue, 6 Nov 2001 09:32:42 -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 JAA22052 for ; Tue, 6 Nov 2001 09:32:40 -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 fA6HWuS04503; Wed, 7 Nov 2001 00:32:57 +0700 (ICT) From: Robert Elz To: =?iso-8859-1?B?Suly9G1lIER1cmFuZA==?= cc: ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: <00ad01c166e0$b3678d20$10a031c1@renater.fr> References: <00ad01c166e0$b3678d20$10a031c1@renater.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Wed, 07 Nov 2001 00:32:56 +0700 Message-ID: <4501.1005067976@brandenburg.cs.mu.OZ.AU> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fA6HWjQO022008 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 6 Nov 2001 17:33:00 +0100 From: Jérôme Durand Message-ID: <00ad01c166e0$b3678d20$10a031c1@renater.fr> | I think it is necessary to have interconnexion networks using public | addresses for debugging routes (ex: traceroute or things like that) so we | need to number those networks. This argument is as old as the arc - we're not about to reach any consensus on it here. Some people will number p2p links, so won't, both camps simply need to live with that. | a /127 wouldn't be a good idea. It's difficult for a provider to play with | prefixes that do not fit with the beginning or the end of a quartil. It might be difficult for providers - many of them seem to be pretty simple people (lots are even avoiding deploying IPv6 as quickly as possible...). I think I can manage on my nets however, not all p2p links run between unrelated parties, with all of the problems that can add. We should stop trying to figure out we think is the right way to number things - there is no answer to that - and instead go back to look at the technical issues that might force some restrictions. Only if we can find some of those should restrictions be imposed. Otherwise, the more flexibility we leave, the more room for future innovation. 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 Nov 6 10:19:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6IJaQO022187 for ; Tue, 6 Nov 2001 10:19:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6IJa2h022186 for ipng-dist; Tue, 6 Nov 2001 10:19: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6IJXQO022179 for ; Tue, 6 Nov 2001 10:19: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 KAA16549 for ; Tue, 6 Nov 2001 10:19:35 -0800 (PST) Received: from brandenburg.cs.mu.OZ.AU (96-1.nat.psu.ac.th [202.28.96.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA14207 for ; Tue, 6 Nov 2001 10:19:33 -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 fA6ILCS04583; Wed, 7 Nov 2001 01:21:12 +0700 (ICT) From: Robert Elz To: "Charles E. Perkins" cc: ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: <3BE81C3B.EA87B3B5@iprg.nokia.com> References: <3BE81C3B.EA87B3B5@iprg.nokia.com> <3BE80B8E.779A5051@iprg.nokia.com> <3606.1005056073@brandenburg.cs.mu.OZ.AU> <4200.1005065592@brandenburg.cs.mu.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Nov 2001 01:21:12 +0700 Message-ID: <4581.1005070872@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 06 Nov 2001 09:22:03 -0800 From: "Charles E. Perkins" Message-ID: <3BE81C3B.EA87B3B5@iprg.nokia.com> | The reserved space for anycast addresses is 7 bits long, and then | there is the all-zeros identifier, which would leave over 100 | addresses with a 120-bit prefix -- isn't that right? Yes, of course, somehow that 7 bits blinded me, I just assumed it was 8, even though it is clearly 7 ... | Here, I am arguing to improve the chances that they will at some point | be better able to be invented, by now avoiding problems for their future | existence. Sure. But I see nothing here which would make that any harder. Nothing is going to tell people to use /127's, and if they need to use those future anycast addresses, all they need to do is assign a /120 or something to the link. On the other hand, if they're not going to be used, allocating empty address space on the link doesn't actually achieve anything productive does it? | Deciding whether or not 2526 mandates the existence of those addresses | is the point of this discussion. Surely the existence of the addresses can't be mandated? I have no mobile nodes (in the mobile IP sense) so I have no need of home agents, so I'm not going to have anything assigned to the one currently defined anycast address from 2526. What's left is whether it mandates that those addresses must be reserved, and never used for any other purpose. I'm not sure how that fits with the random address assignment stuff for the private addresses (random doesn't tend to know much about "avoid that one") - but I confess to not having looked there recently to know if they mandate that if the random address is in the magic block of reserved addresses, to try again. I just see no sense, or need, for mandating that addresses not be used. I have no problem with "if you are going to do this, do it this way", but "if you're not going to do this, you still have to do it this way" doesn't seem needed to me. | I favor mandating the addresses, and I don't see any downside. Certainly allocating /120's instead of /127's isn't going to run anyone out of allocatable space... I guess its just that I prefer to mandate nothing that I can't see a positive requirement for, and here I don't see that requirement. Certainly I think we'd agree that unnumbered links must remain an option for people (that was always one of the requirements). An unnumbered link certainly could not have any of those anycast addresses assigned to it, and no-one is going to start lamenting that loss. If the link could survive unnumbered without the anycast stuff, and I decide I need to number it for diagnostic purposes, or something, why should that suddenly mean that now I have to be able to support the anycast addresses? | I think it is simplest to just decide that it's there. Then applications | can be written more easily, both in the cases of successful connection | and failure condtions. I actually doubt that, other than in some particular scenarios (like finding home agents) where it is reasonable to assume that it is just there - that is, if you're going to be assigning mobile nodes addresses from this link, and so you're going to have a home agent (or more) there, then you'd better make sure its anycast address works. That's fine. I don't think it is reasonable to assume that every link (especally not p2p links) is going to have this - if there's no home agent there, then what do you care what the address is, or is not, used for? | Can you say more about why this is impossible? Well... | If the remote node knows that the prefix has more than 64 bits, it can | form the anycast address. For shorter prefixes, it seems to me that | this problem is as hard as passing a flag to a subroutine that says | whether or not the subnet is EUI-64 conformant. There's extra information, the prefix length, and that flag. It has to find the actual prefix from somewhere as well of course. | I think that anycast is | more appropriate for service discovery than multicast, There I disagree, but this isn't the place for that discussion. | But I am curious to find out what is the downside on making this | restriction on longest-possible prefix length? Really just avoiding any kind of restriction that isn't imperative. 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 Nov 6 12:06:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6K6nQO022331 for ; Tue, 6 Nov 2001 12:06:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6K6nZA022330 for ipng-dist; Tue, 6 Nov 2001 12:06: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6K6kQO022323 for ; Tue, 6 Nov 2001 12:06:46 -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 MAA20936 for ; Tue, 6 Nov 2001 12:06:47 -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 NAA00213 for ; Tue, 6 Nov 2001 13:06:29 -0700 (MST) Received: from malasada.lava.net ([64.65.64.17]) (2224 bytes) by babingka.lava.net; Tue, 6 Nov 2001 10:03:57 -1000 (HST) via sendmail [esmtp] id for Date: Tue, 6 Nov 2001 10:03:56 -1000 (HST) From: Antonio Querubin To: Matt Crawford cc: Pekka Savola , Robert Elz , Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: <200111061600.fA6G0El06840@gungnir.fnal.gov> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 6 Nov 2001, Matt Crawford wrote: > I've never been able to think of a theoretical reason why the two > endpoints of a point-to-point link have to have addresses which are > related in any way. Is there some more practical reason why they > should be? The main reason I've found is that for cases where the link addresses are not learned dynamically via a routing protocol, having them related through a common subnet saves having to manually configure a static route. Consider an EBGP IPv4 example for illustration. Suppose you wanted to use unrelated addresses on a link between EBGP peers - for example they might be unnumbered links referencing and loopback or ethernet port address. You could do that but somehow you have to prime one routers RIB with the route to the other router so that the BGP session between them can start up - ie. a static route to the other routers link address needs to be manually configured. If however, you specify a common /30 subnet for each routers link address then the route between the two routers is implicitly created and no extra static route needs to be configured. Additionally the common /30 subnet allows an administrator to uniquely determine what the IP addresses of each end of the link is once one of them is known. This practice of using numbered links continues to be used for IPv6 EBGP links as well. While maybe not necessarry anymore due to builtin IPv6 neighbor discovery this practice continues I suspect mainly due to history and inertia. IMHO though, it's not a big deal. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 6 12:11:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6KBEQO022353 for ; Tue, 6 Nov 2001 12:11:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA6KBD9e022352 for ipng-dist; Tue, 6 Nov 2001 12:11: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6KBAQO022345 for ; Tue, 6 Nov 2001 12:11:10 -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 MAA16155 for ; Tue, 6 Nov 2001 12:11:11 -0800 (PST) Received: from ensemada.lava.net (ensemada.lava.net [64.65.64.27]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA04535 for ; Tue, 6 Nov 2001 13:10:53 -0700 (MST) Received: from malasada.lava.net ([64.65.64.17]) (1219 bytes) by ensemada.lava.net; Tue, 6 Nov 2001 10:11:02 -1000 (HST) via sendmail [esmtp] id for Date: Tue, 6 Nov 2001 10:10:59 -1000 (HST) From: Antonio Querubin To: =?iso-8859-1?B?Suly9G1lIER1cmFuZA==?= cc: Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: <00ad01c166e0$b3678d20$10a031c1@renater.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 6 Nov 2001, [iso-8859-1] Jérôme Durand wrote: > I think it is necessary to have interconnexion networks using public > addresses for debugging routes (ex: traceroute or things like that) so we > need to number those networks. I think those are actually separate issues anyway. Public addresses are important for debugging but that doesn't automatically imply that numbered links should be preferred over unnumbered links. In the IPv4 world personally I find using unnumbered links for large routing domains referencing loopback addresses to be simpler than managing many /30 subnets. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 7 02:10:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7AAUQO023471 for ; Wed, 7 Nov 2001 02:10:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA7AAUMl023470 for ipng-dist; Wed, 7 Nov 2001 02:10: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7AAOQO023463 for ; Wed, 7 Nov 2001 02:10:25 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fA7AAKq05512; Wed, 7 Nov 2001 11:10:21 +0100 (MET) Date: Wed, 7 Nov 2001 11:09:56 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: /127 for P-t-P Considered Harmful To: Christian Huitema Cc: Matt Crawford , Pekka Savola , Robert Elz , 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 > Have people considered the privacy implications? The computer at the end > of the link may well want to use privacy addresses. Also, there is a > credible possibility that a computer is composed of multiple subsystems, > each with their own IPv6 address. In the aggregatable architecture, it > makes a lot of sense if "n" is in fact 64 for most links. I can imagine router-router pt-pt links within a single domain (i.e. not the link from the ISP to my house) could use different prefix lengths than the other pt-pt links. There shouldn't be any privacy considerations for the former. But such router-router links might also not need any IPv6 addresses (except the link local addresses assigned to the two attached interfaces). 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 Nov 7 12:57:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7KvvQO025224 for ; Wed, 7 Nov 2001 12:57:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA7KvumY025223 for ipng-dist; Wed, 7 Nov 2001 12:57: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7KvnQO025207 for ; Wed, 7 Nov 2001 12:57:50 -0800 (PST) Received: from lillen (vpn133-11.EBay.Sun.COM [129.150.133.11]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fA7Kvlq08822 for ; Wed, 7 Nov 2001 21:57:47 +0100 (MET) Date: Wed, 7 Nov 2001 21:57:20 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: /127 for P-t-P Considered Harmful 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 The subnet anycast address and the other ones reserved in RFC 2526 "Reserved IPv6 Subnet Anycast Addresses" seems rather analogous to the subnet broadcast address in IPv4 - basically reserving some bit patterns in the low order bits of the IP address. For IPv4 we have RFC 3021 "Using 31-Bit Prefixes on IPv4 Point-to-Point Links" which works for router-router links by boldly saying that such links don't have a subnet broadcast address. Why couldn't we define the /127 prefixes analogous to that - declaring that such links don't have a subnet anycast address and no reserved ones either. Working the same as IPv4 practice can't be a disadvatage. 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 Nov 7 14:24:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7MOCQO025433 for ; Wed, 7 Nov 2001 14:24:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA7MOCJj025432 for ipng-dist; Wed, 7 Nov 2001 14:24: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7MO7QO025425 for ; Wed, 7 Nov 2001 14:24:07 -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 OAA21529 for ; Wed, 7 Nov 2001 14:23:53 -0800 (PST) Received: from fnal.gov (heffalump.fnal.gov [131.225.9.20]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00916 for ; Wed, 7 Nov 2001 14:24:08 -0800 (PST) Received: from gungnir.fnal.gov ([131.225.80.1]) by smtp.fnal.gov (PMDF V6.0-24 #37519) with ESMTP id <0GMG00299BK5E0@smtp.fnal.gov> for ipng@sunroof.eng.sun.com; Wed, 07 Nov 2001 16:24:05 -0600 (CST) Received: from gungnir.fnal.gov (localhost [127.0.0.1]) by gungnir.fnal.gov (8.10.2+Sun/8.10.2) with ESMTP id fA7MO0l12955; Wed, 07 Nov 2001 16:24:00 -0600 (CST) Date: Wed, 07 Nov 2001 16:24:00 -0600 From: Matt Crawford Subject: Re: /127 for P-t-P Considered Harmful In-reply-to: "06 Nov 2001 23:33:44 +0700." <4178.1005064424@brandenburg.cs.mu.OZ.AU> To: Robert Elz Cc: Christian Huitema , Pekka Savola , ipng@sunroof.eng.sun.com Message-id: <200111072224.fA7MO0l12955@gungnir.fnal.gov> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Your message, and Matt's, are both missing the point. The question > isn't whether using a /127 is the right way, or the only way, or > whether a subnet number needs to be allocated at all (Matt - one reason > is for connecting isolated systems, which have the P2P link as their > only network connection - they have no other addresses to use). I still don't see it. That an argument against unnumbered links, but it still doesn't imply any topological relation between the addresses of the endpoints. Kernel tables and routing protocols are both able to cope with a p-p link from A::X to B::Y. But, as I said, there may be operational concerns of which I am innocent. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 7 17:14:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA81E7QO025874 for ; Wed, 7 Nov 2001 17:14:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA81E6Hi025873 for ipng-dist; Wed, 7 Nov 2001 17:14: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA81E5QO025866 for ; Wed, 7 Nov 2001 17:14:05 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id fA81Asg08125 for ipng@sunroof.eng.sun.com; Wed, 7 Nov 2001 17:10:54 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA6IwAQO022232 for ; Tue, 6 Nov 2001 10:58:10 -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 KAA25913 for ; Tue, 6 Nov 2001 10:58:09 -0800 (PST) Received: from mg02.austin.ibm.com (mg02.austin.ibm.com [192.35.232.12]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA16246 for ; Tue, 6 Nov 2001 11:58:07 -0700 (MST) Received: from austin.ibm.com (netmail2.austin.ibm.com [9.3.7.139]) by mg02.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA23432 for ; Tue, 6 Nov 2001 13:05:40 -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 MAA60394 for ; Tue, 6 Nov 2001 12:58:03 -0600 Received: from localhost (lilianf@localhost) by porkchop.austin.ibm.com (AIX5.1/8.11.0/8.11.0-client1.01) with ESMTP id fA6Iw2F32060 for ; Tue, 6 Nov 2001 12:58:02 -0600 Date: Tue, 6 Nov 2001 12:58:02 -0600 (CST) From: Lilian Fernandes To: Subject: Re: TCP and Ancillary data in RFC2292bis 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 Thanks for the quick replies. I have one more question - this time about the setsockopt portion for TCP in 2292bis. If an application does a setsockopt IPV6_PKTINFO on a TCP socket, is the setting of the source address restricted only to an unconnected socket? What should the behavior be once a connection is established? Since we cannot change the local IPv6 address during a connection, I am guessing return an error of some sort. Thanks again, Lilian Fernandes On Wed, 7 Nov 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >>>>> On Tue, 6 Nov 2001 10:46:47 +0100 (CET), > >>>>> Erik Nordmark said: > > > Just being able to capture the "last received" extension headers > > might not be useful either - it depends for what the application is using the > > extension headers. > > For instance, if security depends on it then presumably the TCP needs > > to be able to "latch in" a given content i.e. be able to reject packets > > which do not have the extension header content that was used to create the > > connection. > > And in such a "latch in" case a the "last received" semantics make sense > > because the extension header content can by definition not change during > > the connection. > > That's true, but I think security-conscious applications would want to > check the contents of the extension headers in ack-only segments as > well as in data segments. Thus, the current specification cannot > satisfy such applications. > > > So the problem is that while we have applications using the ancillary data > > for ICMP (and perhaps UDP) to ensure that the hoplimit is 255 > > and that there is no routing header, we do not have similar applications > > that need this ability with TCP. So we are stumbling around in the dark > > a bit. > > Yes, that's the point. And, I tend to feel that (= treat TCP like > UDP/raw-IP6 on this point) is an impossible goal, because applications > essentially cannot get access to TCP data per segment basis (some > segments do not contain actual data, some can be silently discarded in > the kernel due to duplication/overlapping/etc). > > So, IMO, we should admit that this kind of mechanism can only be > provided in lower layer filtering, and the optional information passed > from a TCP stack to an application should be used just as some hints. > > Based on this view, my current feeling is that the best way is to fall > back to a single get-only socket option like RFC2292's IPV6_PKTOPTIONS > (though the option could be "set" in the RFC) with the simple "keep > the last received ones" logic. > > Although this change can cause backward compatibility issues with > existing applications that rely on the former versions of rfc2292-bis, > I personally think it is negligible. We implemented the older > versions of the API almost two years ago, but I've not seen any > TCP applications that rely on the spec. > > What do other implementors think? Does this change make sense? > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > p.s. sine some might be wondering about the current situation of the > spec...I'm now editting a revised version of the spec, which will be > available before the cut-off date for the next IETF 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 7 17:14:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA81EuQO025897 for ; Wed, 7 Nov 2001 17:14:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA81Eu03025896 for ipng-dist; Wed, 7 Nov 2001 17:14:56 -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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA81ErQO025889 for ; Wed, 7 Nov 2001 17:14:53 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id fA81Bh108154 for ipng@sunroof.eng.sun.com; Wed, 7 Nov 2001 17:11:43 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA7MgbQO025474 for ; Wed, 7 Nov 2001 14:42:37 -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 OAA14446 for ; Wed, 7 Nov 2001 14:42:37 -0800 (PST) Received: from tree.custom-access.net (tree.custom-access.net [217.24.128.14]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA12434 for ; Wed, 7 Nov 2001 14:42:36 -0800 (PST) Received: from localhost (benc@localhost) by tree.custom-access.net (8.9.3/8.9.3) with ESMTP id WAA16366; Wed, 7 Nov 2001 22:42:32 GMT Date: Wed, 7 Nov 2001 22:42:31 +0000 (UCT) From: Ben Clifford X-Sender: benc@tree.custom-access.net To: Matt Crawford , ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 7 Nov 2001, Matt Crawford wrote: > I still don't see it. That an argument against unnumbered links, but > it still doesn't imply any topological relation between the addresses > of the endpoints. Kernel tables and routing protocols are both able > to cope with a p-p link from A::X to B::Y. But, as I said, there may > be operational concerns of which I am innocent. I think that there is a routing issue - if I, as an arbitratry host, am going to route packets destined for B::Y via A::X, I have to have a route telling me this. If the two nodes share a common prefix, A, then my route that gets me to A::X will also get me to A::Y. In the worst case with unrelated prefixes, I would need a host route (/128) to get me to B::Y. Ben -- Ben Clifford http://www.hawaga.org.uk/ben/ Telephone: United States 310 443-4485 United Kingdom 0709-227-5268 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 7 19:58:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA83w3QO026209 for ; Wed, 7 Nov 2001 19:58:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA83w2nT026208 for ipng-dist; Wed, 7 Nov 2001 19: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA83vxQO026201 for ; Wed, 7 Nov 2001 19:57:59 -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 TAA15596; Wed, 7 Nov 2001 19:58:01 -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 TAA28742; Wed, 7 Nov 2001 19:58:00 -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 TAA00471; Wed, 7 Nov 2001 19:58:00 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fA83vxw15530; Wed, 7 Nov 2001 19:57:59 -0800 X-mProtect: Wed, 7 Nov 2001 19:57:59 -0800 Nokia Silicon Valley Messaging Protection Received: from Icharliep-1.iprg.nokia.com (205.226.22.18, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdT43V08; Wed, 07 Nov 2001 19:57:57 PST Message-ID: <3BEA028D.99CC0DE4@iprg.nokia.com> Date: Wed, 07 Nov 2001 19:57:01 -0800 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Erik Nordmark CC: ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Erik, Erik Nordmark wrote: > Why couldn't we define the /127 prefixes analogous to that - declaring > that such links don't have a subnet anycast address and no reserved ones > either. Of course you can do that. However, then there will be some applications that try to access anycast addresses (perhaps on the same link) that will instead bother some other computer that may even run the same application as an anycast host might do. > Working the same as IPv4 practice can't be a disadvatage. I'm sure you meant that in the context of this very specific discussion, not as a general design rule. Otherwise we'll have to start building IPv6 NAT boxes right away. Still no one has pointed out any downside on reserving the space by restricting prefix lengths. Robert Elz's point was the best/only one so far, which is that fewer rules are better. But the rest of your note, which I didn't quote, amounts to some more rules. And I don't see why applications should have to know rules about subnet prefix lengths in order to work better: If ((prefix_length > 120) && (destination_address == anycast_foo)) { printf ("Weird error message"); exit(99999999999999); } Plus, why shouldn't a host on a point-to-point link be able to run some nifty applications that anycast is supposed to enable? If you say that there aren't any yet, then that's a strange reason given that IPv6 doesn't exactly have killer apps yet. 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 Nov 8 01:21:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA89LvQO026535 for ; Thu, 8 Nov 2001 01:21:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA89Lvnh026534 for ipng-dist; Thu, 8 Nov 2001 01: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA89LrQO026527 for ; Thu, 8 Nov 2001 01:21: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 BAA16355 for ; Thu, 8 Nov 2001 01:21:55 -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 CAA06435 for ; Thu, 8 Nov 2001 02:21:57 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:1c7e:6a36:46e4:36c0]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fA89Lc345762; Thu, 8 Nov 2001 18:21:39 +0900 (JST) Date: Thu, 08 Nov 2001 18:21:34 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Lilian Fernandes Cc: Subject: Re: TCP and Ancillary data in RFC2292bis In-Reply-To: References: User-Agent: Wanderlust/2.7.5 (Too Funky) 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 980905(IM100) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Tue, 6 Nov 2001 12:58:02 -0600 (CST), >>>>> Lilian Fernandes said: > Thanks for the quick replies. I have one more question - this time about > the setsockopt portion for TCP in 2292bis. > If an application does a setsockopt IPV6_PKTINFO on a TCP socket, is the > setting of the source address restricted only to an unconnected socket? > What should the behavior be once a connection is established? Since we > cannot change the local IPv6 address during a connection, I am guessing > return an error of some sort. Good point. Actually, I was thinking about the issue, too, and I'm going to clarify this so that issuing IPV6_PKTINFO setsockopt on a TCP socket will fail. 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 Nov 8 02:58:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8AwIQO026686 for ; Thu, 8 Nov 2001 02:58:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA8AwIkF026685 for ipng-dist; Thu, 8 Nov 2001 02: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8AwEQO026678 for ; Thu, 8 Nov 2001 02:58: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 CAA25287 for ; Thu, 8 Nov 2001 02:58:16 -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 DAA08489 for ; Thu, 8 Nov 2001 03:57:57 -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 fA8AxxZ01656; Thu, 8 Nov 2001 18:00:00 +0700 (ICT) From: Robert Elz To: Matt Crawford cc: ipng@sunroof.eng.sun.com Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: <200111072224.fA7MO0l12955@gungnir.fnal.gov> References: <200111072224.fA7MO0l12955@gungnir.fnal.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 08 Nov 2001 17:59:59 +0700 Message-ID: <1654.1005217199@brandenburg.cs.mu.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 07 Nov 2001 16:24:00 -0600 From: Matt Crawford Message-ID: <200111072224.fA7MO0l12955@gungnir.fnal.gov> | I still don't see it. That an argument against unnumbered links, but | it still doesn't imply any topological relation between the addresses | of the endpoints. Kernel tables and routing protocols are both able | to cope with a p-p link from A::X to B::Y. But, as I said, there may | be operational concerns of which I am innocent. Matt - this is way off the topic of the original question now, but if I'm the end you're identifying as B::Y, and the p2p link is my only network connection, from where do I get B ?? That is, consider the p2p link being a standalone workstation (PC if you like...) with a ppp dialup to some provider. It gets an address when it connects, and that address comes from the provider's address block. So, the p2p link will be numbered out of the A subnet space. What length prefixes are applied (anything from /128 down I guess) is what has been being discussed. 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 Nov 8 03:22:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8BM2QO026767 for ; Thu, 8 Nov 2001 03:22:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA8BM2oC026766 for ipng-dist; Thu, 8 Nov 2001 03:22: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8BLwQO026759 for ; Thu, 8 Nov 2001 03:21:58 -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 DAA29539 for ; Thu, 8 Nov 2001 03:21:58 -0800 (PST) Received: from nausicaa.coritel.it ([193.205.242.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA13734 for ; Thu, 8 Nov 2001 04:22:00 -0700 (MST) Received: from archimede (archimede [141.137.43.43]) by nausicaa.coritel.it (8.11.2/8.11.2) with SMTP id fA8BRtp12222 for ; Thu, 8 Nov 2001 12:27:56 +0100 Message-ID: <00b201c16847$3dad0340$2b2b898d@coritel.it> From: "Andrea Floris" To: Subject: a question Date: Thu, 8 Nov 2001 12:19:22 +0100 Organization: CoRiTeL MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk May be it isn't the best place to ask this question, but I need your help. Well, I'd like to know if there is any document or paper about the introduction of IPv6 in the UMTS network In particular I'd like to know information about the STATUS of IPv6 deployment in UMTS and possible evolution scenarious. I visited the 3GPP web site (www.3gpp.org) but I couldn't find anything interesting. Best Regards Andrea ----------------------------------------------- Andrea Floris Research Engineer IP Networking Area e-mail: floris@coritel.it tel.: + 39 06 72589168 URL: http://www.coritel.it/ ----------------------------------------------- CoRiTel - Research Center on Telecommunications Ericsson Lab Italy SpA Via Anagnina, 203 00040 Morena - Rome - Italy ----------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 8 05:23:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8DNfQO027075 for ; Thu, 8 Nov 2001 05:23:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA8DNfBS027074 for ipng-dist; Thu, 8 Nov 2001 05:23: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8DNcQO027067 for ; Thu, 8 Nov 2001 05:23: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 FAA19235 for ; Thu, 8 Nov 2001 05:23:22 -0800 (PST) Received: from sun1.spfo.unibo.it (sun1.spfo.unibo.it [137.204.198.2]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA09004 for ; Thu, 8 Nov 2001 06:23:27 -0700 (MST) Received: (from capitani@localhost) by sun1.spfo.unibo.it (8.9.1b+Sun/8.9.3) id OAA18553; Thu, 8 Nov 2001 14:12:28 +0100 (MET) Date: Thu, 8 Nov 2001 14:12:28 +0100 (MET) From: Gianluca Capitani Message-Id: <200111081312.OAA18553@sun1.spfo.unibo.it> To: ipng@sunroof.eng.sun.com, floris@coritel.it Subject: Re: a question Cc: capitani@libero.it X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Maybe can be of interest the following internet-drafts: draft-bradner-3gpp2-collaboration-00.txt draft-wasserman-3gpp-advice-00.txt draft-manyfolks-ipv6-cellular-host-00.txt draft-shelby-seamoby-cellularipv6-00.txt It can be found in: ftp://ftp.ietf.org/internet-drafts I hope this help...... Best Regards, Gianluca C.. > May be it isn't the best place to ask this question, but I need your help. > > Well, I'd like to know if there is any document or paper about the > introduction of IPv6 in the UMTS network > In particular I'd like to know information about the STATUS of IPv6 > deployment in UMTS and possible evolution scenarious. > > I visited the 3GPP web site (www.3gpp.org) but I couldn't find anything > interesting. > > Best Regards > > Andrea > > ----------------------------------------------- > Andrea Floris > Research Engineer > IP Networking Area > e-mail: floris@coritel.it > tel.: + 39 06 72589168 > URL: http://www.coritel.it/ > ----------------------------------------------- > CoRiTel - Research Center on Telecommunications > Ericsson Lab Italy SpA > Via Anagnina, 203 > 00040 Morena - Rome - Italy > ----------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 8 05:29:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8DTeQO027096 for ; Thu, 8 Nov 2001 05:29:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA8DTe8f027095 for ipng-dist; Thu, 8 Nov 2001 05:29:40 -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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8DTYQO027088 for ; Thu, 8 Nov 2001 05:29:34 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fA8DTUq12044; Thu, 8 Nov 2001 14:29:30 +0100 (MET) Date: Thu, 8 Nov 2001 14:29:04 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: TCP and Ancillary data in RFC2292bis To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: Lilian Fernandes , 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 > >>>>> On Tue, 6 Nov 2001 12:58:02 -0600 (CST), > >>>>> Lilian Fernandes said: > > > Thanks for the quick replies. I have one more question - this time about > > the setsockopt portion for TCP in 2292bis. > > > If an application does a setsockopt IPV6_PKTINFO on a TCP socket, is the > > setting of the source address restricted only to an unconnected socket? > > What should the behavior be once a connection is established? Since we > > cannot change the local IPv6 address during a connection, I am guessing > > return an error of some sort. > > Good point. Actually, I was thinking about the issue, too, and I'm > going to clarify this so that issuing IPV6_PKTINFO setsockopt on a TCP > socket will fail. Being able to use IPV6_PKTOPTIONS for TCP to e.g. set the outbound interface when using a global address seems consistent with the intent of the option and the way it is used with UDP. 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 Nov 8 05:46:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8Dk4QO027120 for ; Thu, 8 Nov 2001 05:46:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA8Dk4Mv027119 for ipng-dist; Thu, 8 Nov 2001 05: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8Dk0QO027112 for ; Thu, 8 Nov 2001 05:46:00 -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 FAA21717; Thu, 8 Nov 2001 05:45:44 -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 FAA21927; Thu, 8 Nov 2001 05:45:59 -0800 (PST) Received: from localhost ([3ffe:501:100f:10c1:9dff:ef3e:fefe:fee7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fA8Dju347435; Thu, 8 Nov 2001 22:45:56 +0900 (JST) Date: Thu, 08 Nov 2001 22:45:50 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Erik Nordmark Cc: ipng@sunroof.eng.sun.com Subject: Re: TCP and Ancillary data in RFC2292bis In-Reply-To: References: User-Agent: Wanderlust/2.7.5 (Too Funky) 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 980905(IM100) Lines: 33 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 8 Nov 2001 14:29:04 +0100 (CET), >>>>> Erik Nordmark said: >> > Thanks for the quick replies. I have one more question - this time about >> > the setsockopt portion for TCP in 2292bis. >> >> > If an application does a setsockopt IPV6_PKTINFO on a TCP socket, is the >> > setting of the source address restricted only to an unconnected socket? >> > What should the behavior be once a connection is established? Since we >> > cannot change the local IPv6 address during a connection, I am guessing >> > return an error of some sort. >> >> Good point. Actually, I was thinking about the issue, too, and I'm >> going to clarify this so that issuing IPV6_PKTINFO setsockopt on a TCP >> socket will fail. > Being able to use IPV6_PKTOPTIONS for TCP to e.g. set the outbound interface ^^^^^^^^^^^^^^^should be IPV6_PKTINFO > when using a global address seems consistent with the intent of the option > and the way it is used with UDP. Ah, yes...though I don't see practical usage for the TCP case, I don't see the strong reason to prohibit it either. So a reasonable clarification would be: for a TCP socket, - the address part should be ignored (or must be "::") - the interface index part will be used as the outgoing interface 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 Nov 8 06:12:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8ECBQO027211 for ; Thu, 8 Nov 2001 06:12:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA8ECAoq027210 for ipng-dist; Thu, 8 Nov 2001 06:12: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8EC4QO027195; Thu, 8 Nov 2001 06:12:04 -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 GAA14338; Thu, 8 Nov 2001 06:12:05 -0800 (PST) Received: from nausicaa.coritel.it ([193.205.242.5]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA03826; Thu, 8 Nov 2001 07:12:07 -0700 (MST) Received: from archimede (archimede [141.137.43.43]) by nausicaa.coritel.it (8.11.2/8.11.2) with SMTP id fA8EI1p13457; Thu, 8 Nov 2001 15:18:02 +0100 Message-ID: <003301c1685e$fff75ba0$2b2b898d@coritel.it> From: "Andrea Floris" To: Cc: , References: <245DBCAEEC4F074CB77B3F984FF9834F4CD13D@esebe005.NOE.Nokia.com> Subject: Re: a question Date: Thu, 8 Nov 2001 15:09:26 +0100 Organization: CoRiTeL MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi! Thanks for your suggestions... I've already read these documents and, as you have been participating writing of them, I must say they are very well done (in particular the whitepaper "Introducing Mobile IPv6 in 2G and 3G mobile networks" ). However I'd like some more technical documents related the standardization process inside 3GPP. For example I read the documents 3GPP TR 23.923 about MIP in UMTS CN, but how is it possible that the latest version is v.3.0.0 (05/2000). Isn't the work of standanrdization going on? Isn't there a more recent version? Why isn't there (o may be I'm not able to find it!) a 3GPP document about the use of IPv6 in UMTS Core Network? I'm interested in architectural scenarios about IPv6 employment in both UMTS user plane and transport plane, and possible UMTS core network evolution steps towards IPv6. Can anyone help me? Thanks in advance! Andrea ----- Original Message ----- From: To: Sent: Thursday, November 08, 2001 2:39 PM Subject: RE: a question > Hi! > > I here reply to you offline. Please have a look at these: > > http://search.ietf.org/internet-drafts/draft-manyfolks-ipv6-cellular-host-01 > .txt > > http://www.nokia.com/ipv6/whitepaper_IPv6_10832.pdf > > http://www.nokia.com/ipv6/5downloads.html > > (I have been participating writing of those). > > BR, > Juha Wiljakka > Nokia, Finland > > -----Original Message----- > From: ext Andrea Floris [mailto:floris@coritel.it] > Sent: Thursday, November 08, 2001 1:19 PM > To: ipng@sunroof.eng.sun.com > Subject: a question > > > May be it isn't the best place to ask this question, but I need your help. > > Well, I'd like to know if there is any document or paper about the > introduction of IPv6 in the UMTS network > In particular I'd like to know information about the STATUS of IPv6 > deployment in UMTS and possible evolution scenarious. > > I visited the 3GPP web site (www.3gpp.org) but I couldn't find anything > interesting. > > Best Regards > > Andrea > > ----------------------------------------------- > Andrea Floris > Research Engineer > IP Networking Area > e-mail: floris@coritel.it > tel.: + 39 06 72589168 > URL: http://www.coritel.it/ > ----------------------------------------------- > CoRiTel - Research Center on Telecommunications > Ericsson Lab Italy SpA > Via Anagnina, 203 > 00040 Morena - Rome - Italy > ----------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 8 06:39:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8EduQO027254 for ; Thu, 8 Nov 2001 06:39:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA8EdtkE027253 for ipng-dist; Thu, 8 Nov 2001 06:39: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8EdmQO027237; Thu, 8 Nov 2001 06:39: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 GAA20425; Thu, 8 Nov 2001 06:39:35 -0800 (PST) Received: from smtp.uc3m.es (smtp01.uc3m.es [163.117.136.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA01053; Thu, 8 Nov 2001 07:39:12 -0700 (MST) Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by smtp.uc3m.es (Postfix) with ESMTP id 8E5BE4315F; Thu, 8 Nov 2001 15:39:27 +0100 (CET) Received: from arpa.it.uc3m.es (arpa.it.uc3m.es [163.117.139.120]) by smtp01.uc3m.es (Postfix) with ESMTP id C5CA399E24; Thu, 8 Nov 2001 15:39:26 +0100 (CET) Received: from ampere.iie.edu.uy (nobody@arpa.it.uc3m.es [163.117.139.120]) by arpa.it.uc3m.es (8.9.3/8.9.3) with SMTP id PAA03378; Thu, 8 Nov 2001 15:39:25 +0100 Message-Id: <200111081439.PAA03378@arpa.it.uc3m.es> To: isoto@it.uc3m.es Cc: , From: marcelo@it.uc3m.es Subject: Fwd: Re: a question Date: Thu, 8 Nov 101 14:39:25 +0000 X-Mailer: Endymion MailMan v2.0 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tal vez el white paper que menciona te puede resultar de interes, si es que no lo conoces. Saludos, m Forwarded Message: > To: > From: "Andrea Floris" > Subject: Re: a question > Date: Thu, 8 Nov 2001 15:09:26 +0100 > ----- > Hi! Thanks for your suggestions... > I've already read these documents and, as you have been participating > writing of them, I must say they are very well done (in particular the > whitepaper "Introducing Mobile IPv6 in 2G and 3G mobile networks" ). > > However I'd like some more technical documents related the standardization > process inside 3GPP. > For example I read the documents 3GPP TR 23.923 about MIP in UMTS CN, but > how is it possible that the latest version is v.3.0.0 (05/2000). Isn't the > work of standanrdization going on? Isn't there a more recent version? > Why isn't there (o may be I'm not able to find it!) a 3GPP document about > the use of IPv6 in UMTS Core Network? I'm interested in architectural > scenarios about IPv6 employment in both UMTS user plane and transport plane, > and possible UMTS core network evolution steps towards IPv6. > > Can anyone help me? > > Thanks in advance! > > Andrea > > > ----- Original Message ----- > From: > To: > Sent: Thursday, November 08, 2001 2:39 PM > Subject: RE: a question > > > > Hi! > > > > I here reply to you offline. Please have a look at these: > > > > > http://search.ietf.org/internet-drafts/draft-manyfolks-ipv6-cellular-host-01 > > .txt > > > > http://www.nokia.com/ipv6/whitepaper_IPv6_10832.pdf > > > > http://www.nokia.com/ipv6/5downloads.html > > > > (I have been participating writing of those). > > > > BR, > > Juha Wiljakka > > Nokia, Finland > > > > -----Original Message----- > > From: ext Andrea Floris [mailto:floris@coritel.it] > > Sent: Thursday, November 08, 2001 1:19 PM > > To: ipng@sunroof.eng.sun.com > > Subject: a question > > > > > > May be it isn't the best place to ask this question, but I need your help. > > > > Well, I'd like to know if there is any document or paper about the > > introduction of IPv6 in the UMTS network > > In particular I'd like to know information about the STATUS of IPv6 > > deployment in UMTS and possible evolution scenarious. > > > > I visited the 3GPP web site (www.3gpp.org) but I couldn't find anything > > interesting. > > > > Best Regards > > > > Andrea > > > > ----------------------------------------------- > > Andrea Floris > > Research Engineer > > IP Networking Area > > e-mail: floris@coritel.it > > tel.: + 39 06 72589168 > > URL: http://www.coritel.it/ > > ----------------------------------------------- > > CoRiTel - Research Center on Telecommunications > > Ericsson Lab Italy SpA > > Via Anagnina, 203 > > 00040 Morena - Rome - Italy > > ----------------------------------------------- > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 Nov 8 09:52:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8HqbQO027573 for ; Thu, 8 Nov 2001 09:52:37 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA8HqbvR027572 for ipng-dist; Thu, 8 Nov 2001 09:52: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA8HqWQO027565 for ; Thu, 8 Nov 2001 09:52:32 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fA8HqQq13569; Thu, 8 Nov 2001 18:52:26 +0100 (MET) Date: Thu, 8 Nov 2001 18:51:58 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: /127 for P-t-P Considered Harmful To: Charlie Perkins Cc: Erik Nordmark , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3BEA028D.99CC0DE4@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 > Of course you can do that. However, then there will be some applications > that try to access anycast addresses (perhaps on the same link) that will > instead bother some other computer that may even run the same application > as an anycast host might do. For the currently defined use of anycast (the subnet anycast which isn't used by anything and the home agent anycast) this is not a problem. Even if a HA is attached to such a link you can avoid the problem by not configuring the MNs to have that as their home link. > > Working the same as IPv4 practice can't be a disadvatage. > > I'm sure you meant that in the context of this very specific discussion, > not as a general design rule. > > Otherwise we'll have to start building IPv6 NAT boxes right away. Stated with a bit more detail to clarify what I mean it does make sense as a general design rule. If there is IPv4 designs, protocols, and/or operational practises IPv6 should follow those unless there is a good reason. Thus IPv6 shouldn't choose to do things differently just because it can be done differently but instead look very carefully at the cost of being different than IPv4 (in terms of mindshare, training, etc) and the benefits. > Still no one has pointed out any downside on reserving the space by > restricting prefix lengths. And I don't think anybody has pointed out the benefits and argued that those benefits exceed the cost of training folks that e.g. a /31 in IPv4 corresponding not to a /127 but to something else. > Robert Elz's point was the best/only one so > far, which is that fewer rules are better. But the rest of your note, > which I didn't quote, amounts to some more rules. And I don't see > why applications should have to know rules about subnet prefix > lengths in order to work better: > How many "applications" do we expect to use subnet reserved anycast addresses? (and what is your definition of "application"?) Mobile IPv6 uses them but that is IP infrastructure and not an application in my notion of the meaning of "application". > Plus, why shouldn't a host on a point-to-point link be able to run some > nifty applications that anycast is supposed to enable? If you say that > there aren't any yet, then that's a strange reason given that IPv6 doesn't > exactly have killer apps yet. We are not talking about arbitrary pt-pt links. We are talking about pt-pt links between routers that have been explicitly configured to save on address space. Thus if folks want to run those applications don't configure the pt-pt link that way. 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 Nov 8 20:08:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA948BQO028618 for ; Thu, 8 Nov 2001 20:08:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA948BPV028617 for ipng-dist; Thu, 8 Nov 2001 20:08: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9488QO028610 for ; Thu, 8 Nov 2001 20:08: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 UAA08601 for ; Thu, 8 Nov 2001 20:07:53 -0800 (PST) Received: from web13708.mail.yahoo.com (web13708.mail.yahoo.com [216.136.175.141]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id VAA22653 for ; Thu, 8 Nov 2001 21:07:51 -0700 (MST) Message-ID: <20011109040808.45356.qmail@web13708.mail.yahoo.com> Received: from [203.244.123.254] by web13708.mail.yahoo.com via HTTP; Thu, 08 Nov 2001 20:08:08 PST Date: Thu, 8 Nov 2001 20:08:08 -0800 (PST) From: killyeon kim Subject: How to configure mozilla and apache for IPv6? To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, every one. I have installed apache-1.3.19-5.src.rpm(with apache-1.3.19+IPv6.spec) and mozilla-i686-pc-linux-gnu-0.9.5.tar.gz refer to Peter Bieringer's linux IPv6 beginner's guide in WowLinux 7.1. But I cant't access the apache server with mozilla by IPv6 address, although I can access it with IPv4 address. I don't know the problem is because of mozilla client or apache web server? Shoud I configure the httpd.conf with some IPv6 supporting option? Or, should mozilla be patched with IPv6? If so, where can I get the patch file? And where can I get some detail guide for configuration IPv6 application servers, like apache, Bind, ftpd, etc. Please give me any help... Thanks in advance __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.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 Thu Nov 8 20:44:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA94iLQO028840 for ; Thu, 8 Nov 2001 20:44:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA94iL4c028839 for ipng-dist; Thu, 8 Nov 2001 20:44: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA94iHQO028832 for ; Thu, 8 Nov 2001 20:44:17 -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 UAA12163 for ; Thu, 8 Nov 2001 20:44:02 -0800 (PST) Received: from ALPHA8.CC.MONASH.EDU.AU (alpha8.cc.monash.edu.au [130.194.1.8]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA20845 for ; Thu, 8 Nov 2001 20:44:18 -0800 (PST) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.cc.monash.edu.au (PMDF V5.2-31 #29714) with ESMTP id <01KAI7DVBPJO8YHRDB@vaxh.cc.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 9 Nov 2001 15:42:36 +1100 Received: from localhost (localhost [127.0.0.1]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 666BA2DC00A; Fri, 09 Nov 2001 15:42:35 +1100 (EST) Received: from eng.monash.edu.au (PC00004790.eng.monash.edu.au [130.194.137.189]) by kapow.its.monash.edu.au (Postfix) with ESMTP id 65C5B2DC007; Fri, 09 Nov 2001 15:42:34 +1100 (EST) Date: Fri, 09 Nov 2001 15:47:52 +1100 From: Greg Daley Subject: Re: How to configure mozilla and apache for IPv6? To: killyeon kim Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3BEB5FF8.4DAF43FE@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.10mobile i686) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: <20011109040808.45356.qmail@web13708.mail.yahoo.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk killyeon kim wrote: > > Hello, every one. Hello Killyeon, This list is for IETF Standards discussion, rather than individual implementations. Maybe it would be better to talk to a Linux Mailing list, or a Mozilla or Apache one. Greg Daley -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 8 23:20:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA97KHQO029196 for ; Thu, 8 Nov 2001 23:20:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA97KHM6029195 for ipng-dist; Thu, 8 Nov 2001 23: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA97KDQO029188 for ; Thu, 8 Nov 2001 23:20:14 -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 XAA26153 for ; Thu, 8 Nov 2001 23:20:10 -0800 (PST) Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA17685 for ; Thu, 8 Nov 2001 23:20:07 -0800 (PST) Received: from ecvwall11.wipro.com (ecvwall1.wipro.com [164.164.23.6]) by wiproecmx2.wipro.com (8.11.3/8.11.3) with SMTP id fA97K2529606 for ; Fri, 9 Nov 2001 12:50:03 +0530 (IST) Received: from snrprl104846 ([10.145.2.193]) by arabhi.mail.wipro.com (Netscape Messaging Server 4.15) with ESMTP id GMIUY300.NG6 for ; Fri, 9 Nov 2001 12:48:03 +0530 Message-ID: <003f01c168ef$748f10d0$c102910a@snrprl104846> From: "Arun Kumar Dheena" To: Subject: RSVP - IPv6 Date: Fri, 9 Nov 2001 12:53:37 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" 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 This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01C1691D.8CDBAEE0" ------=_NextPart_000_003C_01C1691D.8CDBAEE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I want to know whether any draft is available for "RSVP for = IPv6"? Is the usage of flow-label mandated for RSVP & IPv6? Thanks in Advance regards arun ------=_NextPart_000_003C_01C1691D.8CDBAEE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
        I = want to=20 know whether any draft is available for "RSVP for = IPv6"?
Is the usage of flow-label mandated for = RSVP &=20 IPv6?
 
Thanks in Advance
 
regards
arun
 
------=_NextPart_000_003C_01C1691D.8CDBAEE0-- --------------InterScan_NT_MIME_Boundary Content-Type: text/plain; name="Wipro_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Wipro_Disclaimer.txt" ----------------------------------------------------------------------------------------------------------------------- Information transmitted by this E-MAIL is proprietary to Wipro and/or its Customers and is intended for use only by the individual or entity to which it is addressed, and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please notify us immediately at mailto:mailadmin@wipro.com and delete this mail from your records. ------------------------------------------------------------------------------------------------------------------------ --------------InterScan_NT_MIME_Boundary-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 9 07:48:32 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9FmWQO029740 for ; Fri, 9 Nov 2001 07:48:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA9FmW1o029739 for ipng-dist; Fri, 9 Nov 2001 07: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9FmTQO029732 for ; Fri, 9 Nov 2001 07:48: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 HAA07629 for ; Fri, 9 Nov 2001 07:48:29 -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 IAA12986 for ; Fri, 9 Nov 2001 08:48:11 -0700 (MST) Received: by zmamail05.zma.compaq.com (Postfix, from userid 12345) id CAC3A3984; Fri, 9 Nov 2001 10:48:28 -0500 (EST) Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id B1F173B81 for ; Fri, 9 Nov 2001 10:48:28 -0500 (EST) Received: by mailrelay01.cac.cpqcorp.net (Postfix, from userid 12345) id 4F1E0EF9; Fri, 9 Nov 2001 07:48:28 -0800 (PST) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id EA54AD39 for ; Fri, 9 Nov 2001 07:48:27 -0800 (PST) Received: by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id KAA0000793432; Fri, 9 Nov 2001 10:48:27 -0500 (EST) Date: Fri, 9 Nov 2001 10:48:27 -0500 (EST) From: Jack McCann Message-Id: <200111091548.KAA0000793432@anw.zk3.dec.com> To: ipng@sunroof.eng.sun.com Subject: Re: draft-hinden-ipv6-host-load-sharing-00.txt Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk draft-hinden-ipv6-host-load-sharing-00.txt states: > An implementation MUST cycle through the router list in a round- > robin fashion while making sure it always returns a reachable or > a probably reachable router when one is available. I can see encouraging implementations to do some sort of load sharing, but why does it have to be round-robin, and why MUST and not SHOULD? - Jack -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 9 07:51:23 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9FpNQO029777 for ; Fri, 9 Nov 2001 07:51:23 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA9FpNpL029776 for ipng-dist; Fri, 9 Nov 2001 07:51: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9FpJQO029769 for ; Fri, 9 Nov 2001 07:51:19 -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 FAA14739 for ; Fri, 9 Nov 2001 05:01:31 -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 GAA25578 for ; Fri, 9 Nov 2001 06:01:33 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:7d0d:ca6a:b3ae:5149]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fA9D1R355143 for ; Fri, 9 Nov 2001 22:01:27 +0900 (JST) Date: Fri, 09 Nov 2001 22:01:23 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: ipng@sunroof.eng.sun.com Subject: Re: 2292bis-02: zero-length setsockopt In-Reply-To: <29837.1004677439@itojun.org> User-Agent: Wanderlust/2.7.5 (Too Funky) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: <29837.1004677439@itojun.org> MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 980905(IM100) Lines: 33 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 02 Nov 2001 14:03:59 +0900, >>>>> itojun@iijlab.net said: >> I guess I stuck that text in there based on some goal of consistency with >> the other IPV6_ options in the spec. >> >> Clearly(?) for IPv6_DSTOPTHDR it makes sense to be able to >> clear the sticky option by setting it to zero length. >> (I think this is consistent with setting IP_OPTIONS to zero length.) >> >> So what about IPV6_HOPLIMIT that is a fixed length quantity? >> Is it more important to be consistent with the other IPv6 options >> (and allow zero length as a way to clear it) or is it more >> important to make the option value always have a fixed length (meaning >> that -1 is the only way to set if to "default"). >> >> I don't have a strong opinion either way. > I don't feel the need for consistensy among 2292bis setsockopts. > -1 should be fine for setting the default value for IPV6_HOPLIMIT > and other integer setsockopt. Okay, so I'd propose the following rule: - if we can find a "magic number" to disable an option, it should be used as the only way to disable the option. (the "magic numbers" include all-zero data for IPV6_PKTINFO). - otherwise, use a zero-length option to disable the option. 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 Nov 9 07:56:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9FuFQO029825 for ; Fri, 9 Nov 2001 07:56:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA9FuFxJ029824 for ipng-dist; Fri, 9 Nov 2001 07:56:15 -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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9FuBQO029817 for ; Fri, 9 Nov 2001 07:56:11 -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 HAA17007 for ; Fri, 9 Nov 2001 07:55:55 -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 IAA19880 for ; Fri, 9 Nov 2001 08:55:53 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fA9Fu7j08509; Fri, 9 Nov 2001 17:56:07 +0200 Date: Fri, 9 Nov 2001 17:56:07 +0200 (EET) From: Pekka Savola To: Jack McCann cc: Subject: Re: draft-hinden-ipv6-host-load-sharing-00.txt In-Reply-To: <200111091548.KAA0000793432@anw.zk3.dec.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, 9 Nov 2001, Jack McCann wrote: > draft-hinden-ipv6-host-load-sharing-00.txt states: > > > An implementation MUST cycle through the router list in a round- > > robin fashion while making sure it always returns a reachable or > > a probably reachable router when one is available. > > I can see encouraging implementations to do some sort of load sharing, > but why does it have to be round-robin, and why MUST and not SHOULD? The idea probably is that if it is MUST, you can rely (up to a certain point) on clients on actually doing load-balancing. Personally, I'm not sure whether this is a right approach. There may be other uses for multiple default routers; for example, fail-over. Some might _not_ want to have forced load sharing 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 Fri Nov 9 10:19:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9IJvQO000968 for ; Fri, 9 Nov 2001 10:19:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA9IJvN3000967 for ipng-dist; Fri, 9 Nov 2001 10:19: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9IJsQO000960 for ; Fri, 9 Nov 2001 10:19:54 -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 KAA12120 for ; Fri, 9 Nov 2001 10:19:56 -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 KAA08676 for ; Fri, 9 Nov 2001 10:19:54 -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 KAA20991; Fri, 9 Nov 2001 10:19:44 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fA9IJhk12652; Fri, 9 Nov 2001 10:19:43 -0800 X-mProtect: Fri, 9 Nov 2001 10:19:43 -0800 Nokia Silicon Valley Messaging Protection Received: from maxdialin31.iprg.nokia.com (205.226.20.225, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdsb1Ktq; Fri, 09 Nov 2001 10:19:41 PST Message-Id: <4.3.2.7.2.20011109101237.027ac770@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Nov 2001 10:18:49 -0800 To: Jack McCann From: Bob Hinden Subject: Re: draft-hinden-ipv6-host-load-sharing-00.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: <200111091548.KAA0000793432@anw.zk3.dec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jack, My thinking that led to the draft was to change the current ND behavior to require spreading the load between multiple default routers. Currently ND does not require this. I noticed the current ND behavior when I wrote the VRRP for IPV6 draft, that there wasn't any mechanism to that required hosts to use more than one default router, even when several existed. I talked about round robin because it was very simple and would do a reasonable job spreading the traffic. Other approaches are possible, but more complex. The draft could be changed to allow other load sharing mechanisms as well. Bob At 07:48 AM 11/9/2001, Jack McCann wrote: >draft-hinden-ipv6-host-load-sharing-00.txt states: > > > An implementation MUST cycle through the router list in a round- > > robin fashion while making sure it always returns a reachable or > > a probably reachable router when one is available. > >I can see encouraging implementations to do some sort of load sharing, >but why does it have to be round-robin, and why MUST and not SHOULD? > >- Jack > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Nov 9 11:17:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9JHZQO001285 for ; Fri, 9 Nov 2001 11:17:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fA9JHZIO001284 for ipng-dist; Fri, 9 Nov 2001 11:17: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9JHVQO001277 for ; Fri, 9 Nov 2001 11:17:31 -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 LAA26206 for ; Fri, 9 Nov 2001 11:17:32 -0800 (PST) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA26339 for ; Fri, 9 Nov 2001 12:17:12 -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.2966); Fri, 9 Nov 2001 11:17:15 -0800 Received: from 157.54.8.109 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 Nov 2001 11:17:15 -0800 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 9 Nov 2001 11:17:14 -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); Fri, 9 Nov 2001 11:17:05 -0800 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3562.0); Fri, 9 Nov 2001 11:16:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6063.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: draft-hinden-ipv6-host-load-sharing-00.txt Date: Fri, 9 Nov 2001 11:16:25 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-hinden-ipv6-host-load-sharing-00.txt Thread-Index: AcFpRIxb91qBQbOIQrOYIX8Z5oi+PAADJDag From: "Christian Huitema" To: "Pekka Savola" , "Jack McCann" Cc: X-OriginalArrivalTime: 09 Nov 2001 19:16:25.0452 (UTC) FILETIME=[067382C0:01C16953] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fA9JHVQO001278 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > > An implementation MUST cycle through the router list in a round- > > > robin fashion while making sure it always returns a reachable or > > > a probably reachable router when one is available. > > > > I can see encouraging implementations to do some sort of > load sharing, > > but why does it have to be round-robin, and why MUST and not SHOULD? > > The idea probably is that if it is MUST, you can rely (up to a certain > point) on clients on actually doing load-balancing. Even if we wanted to somehow mandate load sharing, there are generally issues with mandating a round robin approach, or in fact any specific algorithm. Round robin has two drawbacks: it hypothesizes that all routers are equal, which is very often not the case, and it implies some explicit ordering of the requests, which can lead to synchronizations. The all routers equal hypothesis is fine for dumb hosts, but smart hosts can acquire a knowledge that this or that router usually performs better, which is enough to justify a "SHOULD" instead of "MUST". The way to avoid synchronization is normally randomization, i.e. pick routers in a random order rather than doing round robin. -- Christian Huitema -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 12 16:52:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAD0qfQO008605 for ; Mon, 12 Nov 2001 16:52:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fAD0qfro008604 for ipng-dist; Mon, 12 Nov 2001 16:52:41 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from jurassic.eng.sun.com (jurassic [129.146.86.31] (may be forged)) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAD0qbQO008597 for ; Mon, 12 Nov 2001 16:52:37 -0800 (PST) Received: from marlin.sun.com (vpn-129-150-4-81.EBay.Sun.COM [129.150.4.81]) by jurassic.eng.sun.com (8.12.1+Sun/8.12.1) with ESMTP id fAD0qbei525396 for ; Mon, 12 Nov 2001 16:52:38 -0800 (PST) Message-Id: <5.1.0.14.0.20011112164603.0255fe48@jurassic.eng.sun.com> X-Sender: durand@jurassic.eng.sun.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 12 Nov 2001 16:52:41 -0800 To: ipng@sunroof.eng.sun.com From: Alain Durand Subject: Re: /127 for P-t-P Considered Harmful In-Reply-To: References: <"Your message with ID" <3BEA028D.99CC0DE4@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 => From draft-ietf-ipngwg-addr-arch-v3-06.txt 2.5.1 Interface Identifiers Interface identifiers in IPv6 unicast addresses are used to identify interfaces on a link. [...] 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. => I read this as either P-t-P links do not share a common prefix (i.e. both addresses can come from totally different address space) or if they share a prefix, it MUST be a /64. Any other values like /120, /124, /126, /127 are illegal [except in the 000/3 prefix] - Alain. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 12 17:11:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAD1BSQO008687 for ; Mon, 12 Nov 2001 17:11:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fAD1BShj008686 for ipng-dist; Mon, 12 Nov 2001 17:11: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAD1BQQO008679 for ; Mon, 12 Nov 2001 17:11:26 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id fAD18BT17185 for ipng@sunroof.eng.sun.com; Mon, 12 Nov 2001 17:08:11 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9FktQO029721 for ; Fri, 9 Nov 2001 07:46:55 -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 CAA12266 for ; Fri, 9 Nov 2001 02:08:15 -0800 (PST) Received: from alpha.dante.org.uk (alpha.dante.org.uk [193.63.211.19]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA15707 for ; Fri, 9 Nov 2001 02:08:14 -0800 (PST) Received: from moscow.dante.org.uk ([193.63.211.69]) by alpha.dante.org.uk with esmtp (Exim 3.12 #4) id 1628a5-0006EL-00; Fri, 09 Nov 2001 10:08:13 +0000 Message-Id: <5.1.0.14.0.20011109090129.03a9d530@mail.dante.org.uk> X-Sender: janos@mail.dante.org.uk X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 09 Nov 2001 10:09:35 +0000 To: ipng@sunroof.eng.sun.com, global-v6@lists.apnic.net, ipv6-wg@ripe.net From: Janos Mohacsi Subject: Problem statement for transit/exchange only IPv6 address space Cc: David Harmelin Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fA9FkuQO029722 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear All, Sorry for cross posting this message to more than one IPv6 related mailing list, but I think IPv6 community should prepare with some position to the transit/exchange only providers. I have seen the excellent presentation from Mirjam K|hne from RIPE-39 about IPv6 exchange proviers, but then I have not seen any discussion. My goal with this problem statement to increase the debate and hopefully reach some consensus about the problem. The problem statement is rather long.... Sorry about that. Kind Regards, Janos Mohacsi Problem statement for transit/exchange only IPv6 address space: The current Proposed TLA and NLA Assignment Rules (RFC 2450) and IPv6 Aggregatable Global Unicast Address Format (RFC 2374) is not particularly supporting addressing long haul transit providers or exchange providers. As RFC2374 states: "While this address format is designed to support exchange-based aggregation (in addition to current provider-based aggregation) it is not dependent on exchanges for it's overall route aggregation properties. It will provide efficient route aggregation with only provider-based aggregation." What is the current proposed solution to obtain IPv6 addresses for long-haul IPv6 transit providers or IPv6 exchange providers? To better understand the case I try to explain the problem more thoroughly. Let suppose the following situation: There is a long-haul ipv6 transit provider call it X. X is providing IPv6 transit or exchange service for ISPs Y1, Y2,....Yn. But X provide only IPv6 address assignment service for few customers of Yi, let say only for 4-5 customers, for one of the following reasons: 1. Most Y1,Y2, ... Yn has already production IPv6 subTLA 2. X company profile does not contain running local IP registry. 3. other reason X operates its offices in the area of Yi. For office purpose X can obtain IPv6 address from Yi. For IPv6 transit provision X needs an IPv6 address, but probably not /35 addresses, but /44 is enough, even if the transit network is quite extensive and geographically large. Scenario 1: X request address for its transit network from Yi, since his office is in the area of Yi. They get /44 from Yi (it must be difficult according to the current NLA allocation rules). X is implementing transit service and establishes private or public peering with ISP Z1, Z2, ... Zn and of course ISP Y1, Y2, ... Yn. To help the network management X implement and run some monitoring tools on the network near to monitored equipment. X can access its network, the involved network was network Yi. They are happy with the monitoring tools and X wants to share some results with Zk and Yj. Since the strict aggregation network addresses: of X-transit_network will be reacheable via Yi peering of Zk and Yj, not via peering of X-Zk and X-Yj that would be preferred. X can advertise more specific routes Zk and Yj, but this way X pollutes with non really aggregated entries the routing table of Zk and Yj. If they implement a really strict aggregation scheme then these more specific routes are discarded. How can X solve the problem? What happens if X wants to change provider from Yi to Yj? What happens if X has more than office one near to Yi and the other Yj? Which one should be used? Or some kind of multihoming should be used? Scenario 2: X request address (a subTLA) for its transit network from Regional IP Registry. X implementing IPv6 transit service and also network monitoring as before, but he does not allocate addresses just for few ISP Y. This somehow violates the current registration policy, since X does not fulfill all the 5.1 requirements of RFC 2450 and the corresponding RIR IPv6 allocation policy documents. There is no problem with accessing the services via the preferred peering since aggregation is done in X based on subTLA. Is this the current recommended solution? Scenario 3: X request address for office purpose only from Yi, and for the network they use site local address. The public and private BGP peering is quite problematical in this case, since some routers does not allow using local type IPv6 addresses in BGP peering. Providing the monitoring services can be also difficult, since monitoring tools cannot be reached outside of X transit network. This solution is not really acceptable. Or you have some other idea? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 12 17:11:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAD1BtQO008697 for ; Mon, 12 Nov 2001 17:11:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fAD1BtoO008696 for ipng-dist; Mon, 12 Nov 2001 17:11:55 -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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAD1BrQO008689 for ; Mon, 12 Nov 2001 17:11:53 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id fAD18cu17214 for ipng@sunroof.eng.sun.com; Mon, 12 Nov 2001 17:08:38 -0800 (PST) Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fA9K03QO001390 for ; Fri, 9 Nov 2001 12:00:03 -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 MAA12641 for ; Fri, 9 Nov 2001 12:00:03 -0800 (PST) Received: from pimout1-int.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA17278 for ; Fri, 9 Nov 2001 12:00:03 -0800 (PST) Received: from pc (dialup-63.208.69.146.Dial1.Chicago1.Level3.net [63.208.69.146]) by pimout1-int.prodigy.net (8.11.0/8.11.0) with SMTP id fA9Jxv3105712; Fri, 9 Nov 2001 14:59:57 -0500 Message-ID: <005001c16959$be052aa0$9245d03f@pc> From: "Jim Fleming" To: , , , "Janos Mohacsi" Cc: "David Harmelin" References: <5.1.0.14.0.20011109090129.03a9d530@mail.dante.org.uk> Subject: Re: [GLOBAL-V6] Problem statement for transit/exchange only IPv6 address space Date: Fri, 9 Nov 2001 14:04:24 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: "Janos Mohacsi" Problem statement for transit/exchange only IPv6 address space: The current Proposed TLA and NLA Assignment Rules (RFC 2450) and IPv6 Aggregatable Global Unicast Address Format (RFC 2374) is not particularly supporting addressing long haul transit providers or exchange providers. ... This solution is not really acceptable. Or you have some other idea? The "toy" IPv4 Internet is a sewer. IPv8 is designed to be a swamp to cover the sewer. IPv16 is the "high-ground".... ...here are some links... Jim Fleming http://www.unir.com Mars 128n 128e http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp http://www.ietf.org/mail-archive/ietf/Current/msg12213.html http://www.ietf.org/mail-archive/ietf/Current/msg12223.html -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 13 14:34:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADMYsQO011542 for ; Tue, 13 Nov 2001 14:34:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fADMYsHI011541 for ipng-dist; Tue, 13 Nov 2001 14:34: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADMYoQO011534 for ; Tue, 13 Nov 2001 14:34:50 -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 OAA27785 for ; Tue, 13 Nov 2001 14:34:32 -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 PAA21821 for ; Tue, 13 Nov 2001 15:34:32 -0700 (MST) Received: from kenawang ([192.168.1.19]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA20738 for ; Tue, 13 Nov 2001 14:34:12 -0800 (PST) Message-Id: <4.2.2.20011113173604.01e329e0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 13 Nov 2001 17:40:26 -0500 To: ipng@sunroof.eng.sun.com From: Margaret Wasserman Subject: draft-wasserman-3gpp-advice-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would like to request that the working group consider draft-wasserman-3gpp-advice-00.txt as a working group work item. This draft was written by the IPv6-3GPP design team and offers advice on the use of IPv6 within 3GPP standards. Please let me know if there are any objections to making this document an IPng work item. Thanks, 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 Nov 13 14:48:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADMmtQO011598 for ; Tue, 13 Nov 2001 14:48:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fADMmsgP011597 for ipng-dist; Tue, 13 Nov 2001 14:48: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fADMmpQO011590 for ; Tue, 13 Nov 2001 14:48:51 -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 OAA26547 for ; Tue, 13 Nov 2001 14:48:52 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA26351 for ; Tue, 13 Nov 2001 14:48:52 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fADMmq521391 for ; Tue, 13 Nov 2001 14:48:52 -0800 (PST) Message-ID: <027201c16c95$23f21880$0e02320a@T23KEMPF> From: "James Kempf" To: Subject: New Draft on Security Threats to Multi-access IPv6 Networks Date: Tue, 13 Nov 2001 14:47:15 -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 Nordmark and I have co-authored a draft on security threats to public multi-access IPv6 networks, like, for example, a wired or wireless public access Ethernet. The draft describes a collection of threats and what mechanisms in RFCs 2461 and 2462 the threats attack, but does not specify any solutions. In addition, the draft does not discuss authentication and authorization issues. The name of the draft is draft-kempf-ipng-netaccess-threats-00.txt, and should appear in the drafts directory shortly. We would like to solicit some discussion on the threats, including any new ones that people come up with, and, hopefully, ultimately come up with some solutions once the scope of the problem is well enough understood. 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 Nov 13 17:25:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAE1P9QO012079 for ; Tue, 13 Nov 2001 17:25:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta0+Sun/8.12.2.Beta0/Submit) id fAE1P8vd012078 for ipng-dist; Tue, 13 Nov 2001 17:25: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.Beta0+Sun/8.12.2.Beta0) with ESMTP id fAE1P5QO012071 for ; Tue, 13 Nov 2001 17:25:05 -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 RAA07841 for ; Tue, 13 Nov 2001 17:24:49 -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 SAA06959 for ; Tue, 13 Nov 2001 18:24:49 -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 RAA09749; Tue, 13 Nov 2001 17:25:06 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fAE1P5g24324; Tue, 13 Nov 2001 17:25:05 -0800 X-mProtect: Tue, 13 Nov 2001 17:25:05 -0800 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdVsDgfJ; Tue, 13 Nov 2001 17:25:03 PST Message-Id: <4.3.2.7.2.20011113172017.024fbfc0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Nov 2001 17:25:00 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Summary of W.G. Last Call Comments on IPv6 Addressing Architecture Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The IPng working group last call for Draft Standard for: Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-06.txt Pages : 27 Date : 19-Jul-01 was completed on August 31, 2001. A summary of the comments received on the mailing list and their disposition is attached. Note: Editorial comments are not included in this summary. Once a new version of the draft is issued, the document can be forwarded to the IESG for Draft Standard. Bob Hinden & Steve Deering ------------------------------------------------------------------------ COMMENT 1: Suggestion that it isn't good practice to talk about assigning multicast address to an interface because it may confuse people and they might be assigned directly to interfaces (e.g., via ifconfig command). Text will be changed to clarify this issue. COMMENT 2: Questioned whether the IPv6 addresses with embedded IPv4 address should be included in the document. This was discussed at the interim meeting in Seattle and there was a consensus to keep the mapped and compatible address in this document. Other types of transition addresses can be defined in other documents. COMMENT 3: Suggestion that the anycast usage scenarios in the document are very router centric and restrictions for router only usage be eased. The current text will be revised to clarify that other anycast usage is possible, but that new uses need to be specified. COMMENT 4: Suggestion that there be more clarification on the differences between interface, link, and node in section 2.7 on multicast addresses. Will add a summary description of the multicast scope values to the document. COMMENT 5: Questioned the removal of the format prefix (FP) and detailed FP table, and instead only listing the exceptions to global unicast. This issue was discussed on the mailing list and there was a consensus that the current text is appropriate. The resulting behavior of treating the address space as global unicast, except for the listed exceptions, is correct. COMMENT 6: Suggestion to reserve some part of the IPv6 and have it's usage be unspecified. The discussion on the mailing concluded was this was not a good idea. Past experience with IPv4 indicated that it becomes very hard to utilize "unspecified" address space in the future. COMMENT 7: Suggestion to move IANA considerations to a numbered section instead of an appendix to make clearer it is normative. Document will be updated to make the IANA consideration a numbered section. -------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 14 00:27:07 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAE8R7LS013070 for ; Wed, 14 Nov 2001 00:27:07 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAE8R7cL013069 for ipng-dist; Wed, 14 Nov 2001 00:27: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAE8R4LS013062 for ; Wed, 14 Nov 2001 00:27: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 AAA23805 for ; Wed, 14 Nov 2001 00:26:45 -0800 (PST) Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA28539 for ; Wed, 14 Nov 2001 01:27:11 -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 fAE8Qnq03267; Wed, 14 Nov 2001 09:26:49 +0100 (MET) Received: from alcatel.be ([138.203.67.236]) by Bemail06.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2001111409264778:2069 ; Wed, 14 Nov 2001 09:26:47 +0100 Message-ID: <3BF22AC6.1BB351C7@alcatel.be> Date: Wed, 14 Nov 2001 09:26:46 +0100 From: dirk.ooms@alcatel.be X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Bob Hinden CC: ipng@sunroof.eng.sun.com Subject: Re: Summary of W.G. Last Call Comments on IPv6 Addressing Architecture References: X-MIMETrack: Itemize by SMTP Server on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/14/2001 09:26:47, Serialize by Router on BEMAIL06/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/14/2001 09:26:49, Serialize complete at 11/14/2001 09:26:49 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have another comment/question (bit late, but I thought I could better mention it before people reissue the draft): Section 2.5.5 says: "A second type of IPv6 address which holds an embedded global IPv4 address is also defined. This address type is used to represent the addresses of IPv4 nodes as IPv6 addresses. This type of address is termed an "IPv4-mapped IPv6 address" and ... Why is the definition of ipv4-mapped restricted to global ipv4 addresses? I can imagine applications in which one wants to embed a local ipv4 address in an ipv6 format. Or should one use a variant of ipv4-mapped with a site-local prefix for this case? Maybe this requires another way of defining ipv4-mapped: | 80 bits | 16 | 32 bits | +--------------------------------------+--------------------------+ |prefix|0000.......................0000|FFFF| IPv4 address | +--------------------------------------+----+---------------------+ Prefix could possible also be the multicast prefix in case one wants to map an ipv4 multicast address in an ipv6 format. dirk Bob Hinden wrote: > > The IPng working group last call for Draft Standard for: > > Title : IP Version 6 Addressing Architecture > Author(s) : B. Hinden, S. Deering > Filename : draft-ietf-ipngwg-addr-arch-v3-06.txt > Pages : 27 > Date : 19-Jul-01 > > was completed on August 31, 2001. A summary of the comments received on > the mailing list and their disposition is attached. Note: Editorial > comments are not included in this summary. > > Once a new version of the draft is issued, the document can be forwarded to > the IESG for Draft Standard. > > Bob Hinden & Steve Deering > > ------------------------------------------------------------------------ > > COMMENT 1: Suggestion that it isn't good practice to talk about assigning > multicast address to an interface because it may confuse people and they > might be assigned directly to interfaces (e.g., via ifconfig command). > > Text will be changed to clarify this issue. > > COMMENT 2: Questioned whether the IPv6 addresses with embedded IPv4 address > should be included in the document. > > This was discussed at the interim meeting in Seattle and there was a > consensus to keep the mapped and compatible address in this > document. Other types of transition addresses can be defined in other > documents. > > COMMENT 3: Suggestion that the anycast usage scenarios in the document are > very router centric and restrictions for router only usage be eased. > > The current text will be revised to clarify that other anycast usage is > possible, but that new uses need to be specified. > > COMMENT 4: Suggestion that there be more clarification on the differences > between interface, link, and node in section 2.7 on multicast addresses. > > Will add a summary description of the multicast scope values to the document. > > COMMENT 5: Questioned the removal of the format prefix (FP) and detailed FP > table, and instead only listing the exceptions to global unicast. > > This issue was discussed on the mailing list and there was a consensus that > the current text is appropriate. The resulting behavior of treating the > address space as global unicast, except for the listed exceptions, is correct. > > COMMENT 6: Suggestion to reserve some part of the IPv6 and have it's usage > be unspecified. > > The discussion on the mailing concluded was this was not a good idea. Past > experience with IPv4 indicated that it becomes very hard to utilize > "unspecified" address space in the future. > > COMMENT 7: Suggestion to move IANA considerations to a numbered section > instead of an appendix to make clearer it is normative. > > Document will be updated to make the IANA consideration a numbered section. > > -------------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Dirk Ooms mailto:dirk.ooms@alcatel.be tel:+32 3 2404732 Network Strategy Group (NSG) http://aww.alcatel.com/nsg Alcatel http://www.alcatel.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 Nov 14 01:11:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAE9BhLS013173 for ; Wed, 14 Nov 2001 01:11:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAE9Bh0n013172 for ipng-dist; Wed, 14 Nov 2001 01:11:43 -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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAE9BbLS013165 for ; Wed, 14 Nov 2001 01:11:38 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAE9BZq05166; Wed, 14 Nov 2001 10:11:35 +0100 (MET) Date: Wed, 14 Nov 2001 10:10:56 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Summary of W.G. Last Call Comments on IPv6 Addressing Architecture To: dirk.ooms@alcatel.be Cc: Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: "Your message with ID" <3BF22AC6.1BB351C7@alcatel.be> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I have another comment/question (bit late, but I thought I could better > mention it before people reissue the draft): > > Section 2.5.5 says: > "A second type of IPv6 address which holds an embedded global IPv4 > address is also defined. This address type is used to represent the > addresses of IPv4 nodes as IPv6 addresses. This type of address is > termed an "IPv4-mapped IPv6 address" and ... > > Why is the definition of ipv4-mapped restricted to global ipv4 > addresses? The implementations I know have no way to tell whether the IPv4 address returned by the DNS is a global IPv4 address or something else. So in the API the IPv4-mapped addresses are used to carry any IPv4 address. I think it is sufficient to drop the "global" in the text above to clean this up. 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 Nov 14 04:00:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAEC0gLS013575 for ; Wed, 14 Nov 2001 04:00:42 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAEC0g9a013574 for ipng-dist; Wed, 14 Nov 2001 04:00: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAEC0bLS013567 for ; Wed, 14 Nov 2001 04:00:38 -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 EAA29463 for ; Wed, 14 Nov 2001 04:00:37 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04297 for ; Wed, 14 Nov 2001 05:00:19 -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 HAA18297; Wed, 14 Nov 2001 07:00:33 -0500 (EST) Message-Id: <200111141200.HAA18297@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-park-host-based-mcast-00.txt Date: Wed, 14 Nov 2001 07:00:33 -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 : Host-based IPv6 Multicast Addresses Allocation Author(s) : J. Park et al. Filename : draft-park-host-based-mcast-00.txt Pages : 6 Date : 13-Nov-01 This document specifies an extension to the multicast addressing architecture of the IPv6 protocol. The extension allows for sing interface-ID to allocate multicast addresses. When the link-local unicast address is configured at each interface of host, interface ID is uniquely determined. By delegating multicast addresses at the same time as interface ID, each host can identify their multicast addresses automatically at Layer 1 without needing to run an intra- or inter-domain allocation protocol in the serverless environments. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-park-host-based-mcast-00.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-park-host-based-mcast-00.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-park-host-based-mcast-00.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: <20011113143144.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-park-host-based-mcast-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-park-host-based-mcast-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011113143144.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 Wed Nov 14 07:17:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAEFHKLS013791 for ; Wed, 14 Nov 2001 07:17:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAEFHJTp013790 for ipng-dist; Wed, 14 Nov 2001 07:17: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAEFHGLS013783 for ; Wed, 14 Nov 2001 07:17: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 HAA25845; Wed, 14 Nov 2001 07:17:16 -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 IAA01683; Wed, 14 Nov 2001 08:16:58 -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 HAA11133; Wed, 14 Nov 2001 07:17:15 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fAEFHE718825; Wed, 14 Nov 2001 07:17:14 -0800 X-mProtect: Wed, 14 Nov 2001 07:17:14 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (198.77.202.25, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdk6B1Ua; Wed, 14 Nov 2001 07:17:12 PST Message-Id: <4.3.2.7.2.20011114071533.0257e738@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Nov 2001 07:17:08 -0800 To: Erik Nordmark From: Bob Hinden Subject: Re: Summary of W.G. Last Call Comments on IPv6 Addressing Architecture Cc: dirk.ooms@alcatel.be, Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: References: <"Your message with ID" <3BF22AC6.1BB351C7@alcatel.be> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dirk, Erik, I agree. The IPv4-mapped Ipv6 address does not need to contain a global IPv4 address. Thanks, Bob At 01:10 AM 11/14/2001, Erik Nordmark wrote: > > I have another comment/question (bit late, but I thought I could better > > mention it before people reissue the draft): > > > > Section 2.5.5 says: > > "A second type of IPv6 address which holds an embedded global IPv4 > > address is also defined. This address type is used to represent the > > addresses of IPv4 nodes as IPv6 addresses. This type of address is > > termed an "IPv4-mapped IPv6 address" and ... > > > > Why is the definition of ipv4-mapped restricted to global ipv4 > > addresses? > >The implementations I know have no way to tell whether the >IPv4 address returned by the DNS is a global IPv4 address or something else. >So in the API the IPv4-mapped addresses are used to carry any IPv4 >address. > >I think it is sufficient to drop the "global" in the text above to clean this >up. > > 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 Nov 14 15:23:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAENNlLS014587 for ; Wed, 14 Nov 2001 15:23:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAENNlfn014586 for ipng-dist; Wed, 14 Nov 2001 15:23:47 -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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAENNjLS014579 for ; Wed, 14 Nov 2001 15:23:45 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id fAENKRV22712 for ipng@sunroof.eng.sun.com; Wed, 14 Nov 2001 15:20:27 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAEGPrLS013950 for ; Wed, 14 Nov 2001 08:25:53 -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 IAA14430 for ; Wed, 14 Nov 2001 08:25: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 IAA19521 for ; Wed, 14 Nov 2001 08:25:52 -0800 (PST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id JAA12717 for ; Wed, 14 Nov 2001 09:25:51 -0700 (MST)] Received: [from ont14a-bdc.canada.css.mot.com (ont14a-bdc.canada.css.mot.com [199.1.20.72]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id JAA10445 for ; Wed, 14 Nov 2001 09:25:51 -0700 (MST)] Received: by ont14a-bdc.canada.css.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 14 Nov 2001 11:25:46 -0500 Message-ID: <28F1A76E98BDD31189A1009027DE31CF02619ED7@ont14a-bdc.canada.css.mot.com> From: Hughes John-CJH023 To: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: RE: draft-wasserman-3gpp-advice-00.txt Date: Wed, 14 Nov 2001 11:25:39 -0500 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 Hi Margaret, I have read your draft and have a few questions/comments which you may wish to address before forwarding the document to 3GPP. In the draft, three recommendations are made: > 1. Specify that multiple prefixes may be assigned to each > primary PDP context, > > 2. Require that a given prefix must not be assigned to more > than one primary PDP context, and > > 3. Allow 3GPP nodes to use multiple identifiers within those > prefixes, including randomly generated identifiers. The draft then points out that implementing these recommendations will bring the following benefits: > Laptops that connect to 3GPP handsets will work without any > software changes. Their implementation of standard IPv6 over > PPP, address assignment, and autoconfiguration mechanisms > will work without any modification. This will eliminate the > need for vendors and operators to build and test special 3GPP > drivers and related software. It would be helpful if you could show where these incompatibilities lie ? Are these incompatibilities related to PPPv6 or application implementations ? I believe the 3GPP implementation has been designed to work with standard implementations of PPPv6 (between the MT and TE i.e. between a handset and laptop), so if there are problems it would be good to see them stated explicitly. > IPv6 software implementations could be used in 3GPP handsets > without any modifications to the IPv6 protocol mechanisms. > This will make it easier to build and test 3GPP handsets. Is this really an issue. The IPv6 stack will have to be integrated into the UE in any case and therefore some degree of engineering effort will be required. Will implementation of IPv6 in a 3G UE be much more difficult than in say other small devices (PDAs) as a result of 3GPP design decisions. > Applications in 3GPP handsets will be able to take advantage > of different types of IPv6 addresses (e.g., static addresses, > temporary addresses for privacy, site-scoped addresses for > site only communication, etc.) It would be helpful if you could expand on what is meant here. Static addresses are already supported, privacy (in the form of generating temporary addresses) is not such an issue in the 3GPP environment as each time a context is activated a new "temporary" address is assigned. Site-scoped addresses are not prevented in 3GPP, the prefix assigned at context activation may be limited to site scope. > The GPRS system will be better positioned to take advantage of > new IPv6 features that are built around the current addressing > architecture. Again this needs to be expanded upon. While it is important to ensure the specs do not prevent future enhancement, the benefits need to be weighed against any increased complexity. The draft also lists two problems with the current 3GPP specs: > The GGSN only advertises a single /64 prefix, rather than a > set of prefixes. This will prevent the participation of 3GPP > nodes (e.g. handsets or 3GPP-attached laptops) in IPv6 site > renumbering, or in other mechanisms that expect IPv6 hosts to > create addresses based on multiple advertised prefixes. I do not see how site renumbering is an issue. When site renumbering takes place (i.e. the operator switches to a new ISP hence causing all address prefixes to change), the change must take place over a period of time where both the old and new addresses are supported. In 3GPP, all new PDP contexts will be assigned new addresses. If PDP contexts need to be deactivated by the network in order to force an address to be renewed, then that is also supported. > A 3GPP node is assigned a single identifier and is not allowed > to generate additional identifiers. This will prevent the use > of privacy addresses by 3GPP nodes. This also makes 3GPP > mechanisms not fully compliant with the expected behavior of > IPv6 nodes, which will result in incompatibility with popular > laptop IPv6 stacks. Again I do not think the privacy issue is important in a 3GPP environment as I stated above (by their nature addresses are temporary). In RFC3041 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", it states the following: "The way PPP is used today, however, PPP servers typically unilaterally inform the client what address they are to use (i.e., the client doesn't generate one on its own). This practice, if continued in IPv6, would avoid the concerns that are the focus of this document." This exactly describes the way in which addresses are allocated in the 3GPP specs. So for me, this confirms that Privacy (as described in RFC3041) is not an issue for 3GPP systems. The incompatibility issues need to be clarified - it needs to be explained where there will be problems connecting a UE to IPv6 laptop stacks. One final point, do you really think it is wise to assign /64 to a UE. I am not familiar with how liberally (cheaply) IPv6 addresses will be handed out by the addressing authorities but this seems excessive. Many 3GPP devices may be simple (e.g. telemetry type) devices which will have no use for /64 addresses ? Unless a UE is acting as a router, then /64 seems not to be necessary - in 3GPP the UE is a host not a router. If a UE needs multiple addresses, then it just activates a new PDP context for each address required - this is a good solution, as for each new address required you also specify the QoS capabilities required. Hope these comments are helpful. I think an assessment of how 3GPP implements IPv6 is useful and needed and closer cooperation between the IETF and 3GPP should be encouraged. Best regards, John -----Original Message----- From: Margaret Wasserman [mailto:mrw@windriver.com] Sent: Tuesday, November 13, 2001 2:40 PM To: ipng@sunroof.eng.sun.com Subject: draft-wasserman-3gpp-advice-00.txt I would like to request that the working group consider draft-wasserman-3gpp-advice-00.txt as a working group work item. This draft was written by the IPv6-3GPP design team and offers advice on the use of IPv6 within 3GPP standards. Please let me know if there are any objections to making this document an IPng work item. Thanks, 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 Nov 14 15:24:15 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAENOFLS014598 for ; Wed, 14 Nov 2001 15:24:15 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAENOEpA014597 for ipng-dist; Wed, 14 Nov 2001 15:24:14 -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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAENOCLS014589 for ; Wed, 14 Nov 2001 15:24:12 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.11.4+Sun/8.11.4) id fAENKst22741 for ipng@sunroof.eng.sun.com; Wed, 14 Nov 2001 15:20:54 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAEGcDLS013961 for ; Wed, 14 Nov 2001 08:38:13 -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 IAA02911 for ; Wed, 14 Nov 2001 08:38:13 -0800 (PST) Received: from moebius2.Space.Net (moebius2.Space.Net [195.30.1.100]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id IAA27594 for ; Wed, 14 Nov 2001 08:38:12 -0800 (PST) Received: (qmail 93673 invoked by uid 1007); 14 Nov 2001 16:38:10 -0000 Date: Wed, 14 Nov 2001 17:38:10 +0100 From: Gert Doering To: Janos Mohacsi Cc: ipng@sunroof.eng.sun.com, global-v6@lists.apnic.net, ipv6-wg@ripe.net, David Harmelin Subject: Re: [GLOBAL-V6] Problem statement for transit/exchange only IPv6 address space Message-ID: <20011114173810.X3925@Space.Net> References: <5.1.0.14.0.20011109090129.03a9d530@mail.dante.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <5.1.0.14.0.20011109090129.03a9d530@mail.dante.org.uk>; from Janos.Mohacsi@dante.org.uk on Fri, Nov 09, 2001 at 10:09:35AM +0000 X-NCC-RegID: de.space Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I haven't seen any responses to this, so let me comment... On Fri, Nov 09, 2001 at 10:09:35AM +0000, Janos Mohacsi wrote: [..] > Problem statement for transit/exchange only IPv6 address space: > > The current Proposed TLA and NLA Assignment Rules (RFC 2450) and IPv6 > Aggregatable Global Unicast Address Format (RFC 2374) is not particularly > supporting addressing long haul transit providers or exchange providers. I don't think there is any issue that needs to be addressed. There are three different cases: - the ISP in question is offering IPv6 address space to its customers, that is, will do LIR services. In this case he can get address space from the RIRs, no problem. - the ISP in question is not offering LIR services, but has an upstream provider who *is* offering LIR services. So he can get an /48 from them with no problem. A /48 means "a full /64 for 65000 networks", which is quite some. If /127s are used on point-to-point links (which is legal) it's definitely "enough for ever". If /64s are used, it may be necessary to come back to his upstream provider and get a second /48 - which is possible. No problem here either. - the ISP in question is a Tier-1 provider, has no upstream provider that can provide IPv6 addresses to him, and does not offer LIR services to his customers. (Out of curiosity: does such an ISP exist? I haven't found one.) If such ISPs exist in reality, they could get an /48 from the "Yi" customer that you mentioned - or they could just become a LIR and get address space for their own, which is not impossible, and the costs for becoming a LIR should be neglectible for a Tier-1 provider. No big problem. Conclusion: I do not see the need for a special-case provider who needs IPv6 addresses, has no upstream provider to get a /48 and does not want to become a LIR. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 72980 (73128) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 14 16:04:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAF04wLS014818 for ; Wed, 14 Nov 2001 16:04:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAF04who014817 for ipng-dist; Wed, 14 Nov 2001 16:04: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAF04sLS014810 for ; Wed, 14 Nov 2001 16:04:54 -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 QAA27219 for ; Wed, 14 Nov 2001 16:04: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 QAA12361 for ; Wed, 14 Nov 2001 16:04:54 -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 QAA19408; Wed, 14 Nov 2001 16:04:54 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fAF04r011824; Wed, 14 Nov 2001 16:04:53 -0800 X-mProtect: Wed, 14 Nov 2001 16:04:53 -0800 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdvLqEha; Wed, 14 Nov 2001 16:04:50 PST Message-Id: <4.3.2.7.2.20011114144441.0258ea20@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Nov 2001 16:04:46 -0800 To: "Christian Huitema" From: Bob Hinden Subject: RE: draft-hinden-ipv6-host-load-sharing-00.txt Cc: 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 Christian, >Even if we wanted to somehow mandate load sharing, there are generally >issues with mandating a round robin approach, or in fact any specific >algorithm. Round robin has two drawbacks: it hypothesizes that all >routers are equal, which is very often not the case, and it implies some >explicit ordering of the requests, which can lead to synchronizations. >The all routers equal hypothesis is fine for dumb hosts, but smart hosts >can acquire a knowledge that this or that router usually performs >better, which is enough to justify a "SHOULD" instead of "MUST". The way >to avoid synchronization is normally randomization, i.e. pick routers in >a random order rather than doing round robin. The issue of all routers not being equal is a generic neighbor discovery issue. Currently a host will add to it's default router list any router it receives routing advertisements. Rich Draves "Default Router Preferences and More-Specific Routers" draft addresses this issue and allows a ranking of the default routers. I think load sharing has value when there are multiple (equal preference) default routers. It is very common in the IPv4 world for people to set up parallel paths with two or more routers. In this case it is useful for hosts to spread their traffic among these routers. I will revise the draft to change from round-robin to random order to avoid synchronization, and also change it from a MUST to a SHOULD to allow for hosts with more information. Also, it may make sense to later combine this with Rich's draft as they are both dealing with related default router selection issues. In this case the load sharing would be done when there are multiple default routers with equal preference. 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 Wed Nov 14 16:32:19 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAF0WJLS014945 for ; Wed, 14 Nov 2001 16:32:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAF0WJ64014944 for ipng-dist; Wed, 14 Nov 2001 16:32: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAF0WFLS014937 for ; Wed, 14 Nov 2001 16:32: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 QAA10561 for ; Wed, 14 Nov 2001 16:32:12 -0800 (PST) Received: from cnhon1imr4.i.wcom.com.hk (mailhost3.wcom.com.hk [202.130.178.68]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA27663 for ; Wed, 14 Nov 2001 16:32:07 -0800 (PST) X-Internal-ID: 3BD5388A00083DA0 Received: from cnhon1imr4.i.wcom.com.hk (166.45.172.22) by cnhon1imr4.i.wcom.com.hk (NPlex 3.0.036) for ipng@sunroof.eng.sun.com; Thu, 15 Nov 2001 00:30:55 +0000 Received: from cnhon1gw0.i.wcom.com.hk (cnhon1gw0.i.wcom.com.hk [166.45.172.46]) by cnhon1imr4.i.wcom.com.hk with SMTP (MailShield v2.04 - WIN32 Jul 17 2001 17:12:42); Thu, 15 Nov 2001 00:30:54 -0000 Received: by cnhon1gw0.i.wcom.com.hk with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Nov 2001 08:32:05 +0800 Message-ID: From: "Smith, Mark" To: "'Bob Hinden'" , Christian Huitema Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-hinden-ipv6-host-load-sharing-00.txt Date: Thu, 15 Nov 2001 08:31:53 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-SMTP-HELO: cnhon1gw0.i.wcom.com.hk X-SMTP-MAIL-FROM: smith.r.mark@wcom.com.au X-SMTP-PEER-INFO: cnhon1gw0.i.wcom.com.hk [166.45.172.46] Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, While I haven't read Bob's draft, so my comments may be naive, but RFC 2991 "Multipath Issues in Unicast and Multicast Next-Hop Selection" seems to recommend against round robin loadsharing, and arguably recommend against per packet load sharing at all. While the RFC is about routers performing the loadsharing over multiple paths, I would think the issues it raises would probably also apply to hosts. Regards, Mark. > -----Original Message----- > From: Bob Hinden [mailto:hinden@iprg.nokia.com] > Sent: Thursday, 15 November 2001 11:05 > To: Christian Huitema > Cc: ipng@sunroof.eng.sun.com > Subject: RE: draft-hinden-ipv6-host-load-sharing-00.txt > > > Christian, > > >Even if we wanted to somehow mandate load sharing, there are > generally > >issues with mandating a round robin approach, or in fact any specific > >algorithm. Round robin has two drawbacks: it hypothesizes that all > >routers are equal, which is very often not the case, and it > implies some > >explicit ordering of the requests, which can lead to > synchronizations. > >The all routers equal hypothesis is fine for dumb hosts, but > smart hosts > >can acquire a knowledge that this or that router usually performs > >better, which is enough to justify a "SHOULD" instead of > "MUST". The way > >to avoid synchronization is normally randomization, i.e. > pick routers in > >a random order rather than doing round robin. > > The issue of all routers not being equal is a generic > neighbor discovery > issue. Currently a host will add to it's default router list > any router it > receives routing advertisements. Rich Draves "Default Router > Preferences > and More-Specific Routers" draft addresses this issue and > allows a ranking > of the default routers. > > I think load sharing has value when there are multiple (equal > preference) > default routers. It is very common in the IPv4 world for > people to set up > parallel paths with two or more routers. In this case it is > useful for > hosts to spread their traffic among these routers. > > I will revise the draft to change from round-robin to random > order to avoid > synchronization, and also change it from a MUST to a SHOULD > to allow for > hosts with more information. > > Also, it may make sense to later combine this with Rich's > draft as they are > both dealing with related default router selection issues. > In this case > the load sharing would be done when there are multiple > default routers with > equal preference. > > 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 14 16:49:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAF0nqLS015018 for ; Wed, 14 Nov 2001 16:49:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAF0nqrp015017 for ipng-dist; Wed, 14 Nov 2001 16:49: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAF0nmLS015010 for ; Wed, 14 Nov 2001 16:49: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 QAA14046 for ; Wed, 14 Nov 2001 16:49:50 -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 RAA02437 for ; Wed, 14 Nov 2001 17:49:32 -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 QAA22551; Wed, 14 Nov 2001 16:49:48 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fAF0nmW08000; Wed, 14 Nov 2001 16:49:48 -0800 X-mProtect: Wed, 14 Nov 2001 16:49:48 -0800 Nokia Silicon Valley Messaging Protection Received: from spruce.iprg.nokia.com (205.226.1.63) by darkstar.iprg.nokia.com(P1.5 smtpdhuJ5vl; Wed, 14 Nov 2001 16:49:46 PST Message-Id: <4.3.2.7.2.20011114163730.0258ea20@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Nov 2001 16:49:41 -0800 To: "Smith, Mark" From: Bob Hinden Subject: RE: draft-hinden-ipv6-host-load-sharing-00.txt Cc: ipng@sunroof.eng.sun.com 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 Mark, >While I haven't read Bob's draft, so my comments may be naive, but RFC 2991 Yes, please read the draft! >"Multipath Issues in Unicast and Multicast Next-Hop Selection" seems to >recommend against round robin loadsharing, and arguably recommend against >per packet load sharing at all. The load sharing being proposed here in not per packet. It is invoked when the host needs to send traffic to a destination it has not sent to recently (i.e., when no destination cache entry exists for an off-link destination). This destination approach is part of Neighbor Discover (RFC2461). >While the RFC is about routers performing the loadsharing over multiple >paths, I would think the issues it raises would probably also apply to >hosts. The issues are similar. Load sharing approaches that don't keep flows together are not a good thing. 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 Nov 15 00:25:29 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAF8PSLS015897 for ; Thu, 15 Nov 2001 00:25:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAF8PS9E015896 for ipng-dist; Thu, 15 Nov 2001 00:25: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAF8PPLS015889 for ; Thu, 15 Nov 2001 00:25: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 AAA10171 for ; Thu, 15 Nov 2001 00:25:25 -0800 (PST) Received: from mail.kebne.se (mail.kebne.se [212.209.134.151]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA18330 for ; Thu, 15 Nov 2001 00:25:24 -0800 (PST) Received: by mail.kebne.se with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Nov 2001 09:25:27 +0100 Message-ID: <31A473DBB655D21180850008C71E251A04ECACB9@mail.kebne.se> From: Thomas Eklund To: "'Bob Hinden'" , "Smith, Mark" Cc: ipng@sunroof.eng.sun.com Subject: RE: draft-hinden-ipv6-host-load-sharing-00.txt Date: Thu, 15 Nov 2001 09:25:26 +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 Bob, I agree that if you dont keep your flow together that's a bad thing and you will experience packet re-ordering. I also note that this is a topic where potentially the flow label could be used. Nothing strange really, since the flowlabel identifies a flow. -- thomas >>While the RFC is about routers performing the loadsharing >over multiple >>paths, I would think the issues it raises would probably also apply to >>hosts. > >The issues are similar. Load sharing approaches that don't keep flows >together are not a good thing. > >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 >-------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 02:36:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFAarLS016103 for ; Thu, 15 Nov 2001 02:36:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAFAar86016102 for ipng-dist; Thu, 15 Nov 2001 02: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFAanLS016095 for ; Thu, 15 Nov 2001 02:36:49 -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 CAA21909 for ; Thu, 15 Nov 2001 02:36:50 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA02895 for ; Thu, 15 Nov 2001 02:36:49 -0800 (PST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fAFAaif10718 for ; Thu, 15 Nov 2001 11:36:44 +0100 (MET) Received: FROM esealnt742.al.sw.ericsson.se BY esealnt461 ; Thu Nov 15 11:36:44 2001 +0100 Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 15 Nov 2001 11:28:44 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C05F@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hughes John-CJH023'" , "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: RE: draft-wasserman-3gpp-advice-00.txt Date: Thu, 15 Nov 2001 11:36: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 I have read your draft and have a few questions/comments which you may wish to address before forwarding the document to 3GPP. In the draft, three recommendations are made: > 1. Specify that multiple prefixes may be assigned to each > primary PDP context, > > 2. Require that a given prefix must not be assigned to more > than one primary PDP context, and > > 3. Allow 3GPP nodes to use multiple identifiers within those > prefixes, including randomly generated identifiers. The draft then points out that implementing these recommendations will bring the following benefits: > Laptops that connect to 3GPP handsets will work without any > software changes. Their implementation of standard IPv6 over > PPP, address assignment, and autoconfiguration mechanisms > will work without any modification. This will eliminate the > need for vendors and operators to build and test special 3GPP > drivers and related software. It would be helpful if you could show where these incompatibilities lie ? Are these incompatibilities related to PPPv6 or application implementations ? => Some of the incompatibilities are: - An IPv6 host can have multiple addresses of various scopes assigned to a single interface. The current 3GPP addressing solutions do not allow this. - An IPv6 host can generate many interface ids based on one or more prefixes received in the RA. The current 3GPP addressing solutions do not allow this either. I believe the 3GPP implementation has been designed to work with standard implementations of PPPv6 (between the MT and TE i.e. between a handset and laptop), so if there are problems it would be good to see them stated explicitly. => Another (perhaps not a critical issue to 3GPP right now) is what happens if the link between the TE and MT is not PPP. The solution proposed by the draft allows for this to work. > IPv6 software implementations could be used in 3GPP handsets > without any modifications to the IPv6 protocol mechanisms. > This will make it easier to build and test 3GPP handsets. Is this really an issue. The IPv6 stack will have to be integrated into the UE in any case and therefore some degree of engineering effort will be required. Will implementation of IPv6 in a 3G UE be much more difficult than in say other small devices (PDAs) as a result of 3GPP design decisions. => Sure there are integration issues but the less changes, the better. Also one important issue here is that following the way things are defined in IETF will allow 3GPP to be compatible with future proposals on IPv6 (within IETF). For instance, when IPv6 addressing was first considered in 3GPP, privacy issues may not have come up in IETF, but when they did, the proposed solution was made to work with the existing IETF standards. Evidently it (RFC 3041) doesn't work with the existing 3GPP standard. So it's good to follow the same model as IETF to allow for smooth integration of future features. Of course this is provided that the IETF model meets the 3GPP requirements. In this case I believe it does. > Applications in 3GPP handsets will be able to take advantage > of different types of IPv6 addresses (e.g., static addresses, > temporary addresses for privacy, site-scoped addresses for > site only communication, etc.) Site-scoped addresses are not prevented in 3GPP, the prefix assigned at context activation may be limited to site scope. => Yes but you can't assign both Site-local and Global. I suspect most 3GPP handsets will require global addresses too. Unless people will only talk to other subscribers of the same operator :) Another important issue here is renumbering. To be able to have a smooth renumbering mechanism you need to allow for advertising 2 prefixes at least. > The GPRS system will be better positioned to take advantage of > new IPv6 features that are built around the current addressing > architecture. Again this needs to be expanded upon. While it is important to ensure the specs do not prevent future enhancement, the benefits need to be weighed against any increased complexity. => Actually it seems to me that the solution in the draft is a lot simpler than the one in the current 3GPP specs, but I might have missed something that concerned you ? The draft also lists two problems with the current 3GPP specs: > The GGSN only advertises a single /64 prefix, rather than a > set of prefixes. This will prevent the participation of 3GPP > nodes (e.g. handsets or 3GPP-attached laptops) in IPv6 site > renumbering, or in other mechanisms that expect IPv6 hosts to > create addresses based on multiple advertised prefixes. I do not see how site renumbering is an issue. When site renumbering takes place (i.e. the operator switches to a new ISP hence causing all address prefixes to change), the change must take place over a period of time where both the old and new addresses are supported. In 3GPP, all new PDP contexts will be assigned new addresses. If PDP contexts need to be deactivated by the network in order to force an address to be renewed, then that is also supported. => Interesting point. But since site renumbering will affect several parts of the network (DNS, DHCP (if exists), filters, policies...etc) there is certainly room for error there. So I think it's wise to allow both prefixes for some time. Switching things on and off does not seem to be very flexible. Consider the case where something goes wrong. I think the down time for the network will be significant here. 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 Nov 15 13:55:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFLtSLS018164 for ; Thu, 15 Nov 2001 13:55:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAFLtSFj018163 for ipng-dist; Thu, 15 Nov 2001 13:55:28 -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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAFLtOLS018156 for ; Thu, 15 Nov 2001 13:55:25 -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 NAA20448 for ; Thu, 15 Nov 2001 13:55:26 -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 NAA23972 for ; Thu, 15 Nov 2001 13:55:25 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fAFLtO913679 for ; Thu, 15 Nov 2001 23:55:24 +0200 Date: Thu, 15 Nov 2001 23:55:23 +0200 (EET) From: Pekka Savola To: Subject: Re: I-D ACTION:draft-park-host-based-mcast-00.txt In-Reply-To: <200111141200.HAA18297@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 Wed, 14 Nov 2001 Internet-Drafts@ietf.org wrote: > This document specifies an extension to the multicast addressing > architecture of the IPv6 protocol. The extension allows for sing > interface-ID to allocate multicast addresses. When the link-local > unicast address is configured at each interface of host, interface > ID is uniquely determined. By delegating multicast addresses at > the same time as interface ID, each host can identify their > multicast addresses automatically at Layer 1 without needing to run > an intra- or inter-domain allocation protocol in the serverless > environments. I read the draft cursorily, and I must admit I really don't see much of a point.. or perhaps I missed something. Perhaps it would be good to give a concrete example or two where this would be actually usable. Note: it seems to me that the scope of the resulting multicast address must not be greater than the generating unicast address scope. This is because e.g. 'subnet ID + interface ID' in e.g. global scope could clash from the same values from other sites. GLOP-based allocation seems pointless when you can use unicast prefix-based allocations (useful only if you want to zero-configure so that every node can possibly start generating global multicast traffic without assignments from the _site_ owner). Site- and link -local allocations would only seem to be usable within the respective site, or link. Do we _really_ need an automatic allocation for a single _link_, for example? In short, it seems unlikely that _nodes_ would need automatic multicast addresses, apart from a few standard, defined ones. -- 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 Nov 15 16:53:45 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAG0rjLS018508 for ; Thu, 15 Nov 2001 16:53:45 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAG0riME018507 for ipng-dist; Thu, 15 Nov 2001 16:53: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAG0rfLS018500 for ; Thu, 15 Nov 2001 16:53:41 -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 QAA04478 for ; Thu, 15 Nov 2001 16:53:42 -0800 (PST) Received: from pec.etri.re.kr (pec.etri.re.kr [129.254.164.217]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA11572 for ; Thu, 15 Nov 2001 17:53:23 -0700 (MST) Received: from pec.etri.re.kr (mkshin1.etri.re.kr [129.254.164.86]) by pec.etri.re.kr (8.10.0/8.10.0) with ESMTP id fAG0uqh23254; Fri, 16 Nov 2001 09:56:54 +0900 (KST) Message-ID: <3BF464BA.F0779C0A@pec.etri.re.kr> Date: Fri, 16 Nov 2001 09:58:34 +0900 From: Myung-Ki Shin Organization: ETRI 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: I-D ACTION:draft-park-host-based-mcast-00.txt References: Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > Note: it seems to me that the scope of the resulting multicast address > must not be greater than the generating unicast address scope. This is > because e.g. 'subnet ID + interface ID' in e.g. global scope could clash > from the same values from other sites. Yes, you are right. Properly, our site-local multicast addresses are used when scop <= 5. > GLOP-based allocation seems pointless when you can use unicast > prefix-based allocations (useful only if you want to zero-configure so > that every node can possibly start generating global multicast traffic > without assignments from the _site_ owner). Site- and link -local > allocations would only seem to be usable within the respective site, or > link. Regarding GLOP-based IPv6 multicast addresses, we received some comments from Dave Thaler. He proposed, GLOP-based IPv6 multicast addresses are much less powerful and has no advantages over Unicast-prefix-based addresses. So, we decided to follow his opinion. Instead, in the case of link- or site-local multicast addresses, we and Dave agreed the in order to make the syntax consistent with the Unicast-Prefix-based multicast draft, our 00 draft would be changed as follows : (we will publish revised version soon.) 3.1 Link-local multicast addresses | 8 | 4 | 4 | 16 | 64 | 32 | +--------+----+----+------------+----------------+---------------+ |11111111|flgs|scop| reserved | Interface ID | group ID | +--------+----+----+------------+----------------+---------------+ 3.2 Site-local multicast addresses | 8 | 4 | 4 | 16 | 64 | 32 | +--------+----+----+------------+----------------+---------------+ |11111111|flgs|scop| SLA | Interface ID | group ID | +--------+----+----+------------+----------------+---------------+ In addition, in stead of defining define a new flag, we will use same flag defined in the Unicast-Prefix-based draft. We and dave think we might be able to update the other draft to allow to do this in our draft. I think, our proposal can be used in link- or site-local, harmonizing with Unicast-Prefix-based multicast scheme (while Unicast-Prefix-based multicast addresses are for global.). Thanks, Myung-Ki. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 15 20:50:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAG4ovLS018778 for ; Thu, 15 Nov 2001 20:50:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAG4ovCw018777 for ipng-dist; Thu, 15 Nov 2001 20:50: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAG4osLS018770 for ; Thu, 15 Nov 2001 20:50: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 UAA01353 for ; Thu, 15 Nov 2001 20:50:55 -0800 (PST) Received: from mailweb34.rediffmail.com ([203.199.83.32]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with SMTP id VAA23565 for ; Thu, 15 Nov 2001 21:51:03 -0700 (MST) Received: (qmail 25996 invoked by uid 510); 16 Nov 2001 04:48:56 -0000 Date: 16 Nov 2001 04:48:56 -0000 Message-ID: <20011116044856.25995.qmail@mailweb34.rediffmail.com> Received: from unknown (203.197.138.201) by rediffmail.com via HTTP; 16 Nov 2001 04:48:56 -0000 MIME-Version: 1.0 From: "aridaman kaushik" Reply-To: "aridaman kaushik" To: ipng@sunroof.eng.sun.com Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fAG4osLS018771 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi all, I have a doubt regarding site concept in ipv6. We are implementing isis for ipv6. 1. can we map area to one site. 2. is it possible to have two areas belongs to one site. thanks in advance ari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 16 13:51:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGLpLLS020915 for ; Fri, 16 Nov 2001 13:51:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAGLpLTm020914 for ipng-dist; Fri, 16 Nov 2001 13:51: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGLpILS020907 for ; Fri, 16 Nov 2001 13:51:18 -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 NAA13285 for ; Fri, 16 Nov 2001 13:50:59 -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 OAA01176 for ; Fri, 16 Nov 2001 14:51:27 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA29597 for ; Fri, 16 Nov 2001 14:51:15 -0700 (MST)] Received: [from il06exi01.CORP.MOT.COM (il06exi01.corp.mot.com [199.5.78.78]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id OAA29298 for ; Fri, 16 Nov 2001 14:51:14 -0700 (MST)] Received: by il06exi01.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 16 Nov 2001 15:51:14 -0600 Message-ID: From: Jung Cyndi-ACJ099 To: "'aridaman kaushik'" , ipng@sunroof.eng.sun.com Subject: RE: Date: Fri, 16 Nov 2001 15:51:10 -0600 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 You can have two (or more) areas belonging to one site. You could also serve an entire site with a single area, if it is not too large. You can't have one IS-IS system span beyond a site boundary, since the site-local addresses would not be guaranteed unique. You could certainly have multiple IS-IS systems within the boundary of a single site, with some sort of routing between them - static would work, RIPng, and even BGP (are site-local prefixes allowed in BGP?) Cyndi -----Original Message----- From: aridaman kaushik [mailto:kaushik_ari@rediffmail.com] Sent: Thursday, November 15, 2001 8:49 PM To: ipng@sunroof.eng.sun.com Subject: hi all, I have a doubt regarding site concept in ipv6. We are implementing isis for ipv6. 1. can we map area to one site. 2. is it possible to have two areas belongs to one site. thanks in advance ari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Nov 16 22:55:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAH6twLS021870 for ; Fri, 16 Nov 2001 22:55:58 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAH6twwF021869 for ipng-dist; Fri, 16 Nov 2001 22:55: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAH6tsLS021862 for ; Fri, 16 Nov 2001 22:55: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 WAA09107 for ; Fri, 16 Nov 2001 22:55:54 -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 XAA03314 for ; Fri, 16 Nov 2001 23:56:05 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:8c95:c3c4:b6be:b9ca]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fAH6th321631; Sat, 17 Nov 2001 15:55:44 +0900 (JST) Date: Sat, 17 Nov 2001 15:55:40 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: nov@tahi.org Cc: ipng@sunroof.eng.sun.com Subject: a short comment on draft-okabe-ipv6-lcna-minreq-00.txt User-Agent: Wanderlust/2.7.5 (Too Funky) 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 980905(IM100) Lines: 36 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk (I think the ipng ML is the best place to discuss the issue, but please correct me if this is not appropriate.) I've taken a quick look at draft-okabe-ipv6-lcna-minreq-00.txt and have a short comment (or a question). The draft says 2.3 Multicast Multicast is not treated in this draft, and it is the candidate for further study (RFC 2375[8], RFC 2710[9]). However, the multicast related to neighbor discovery is considered. So the minimum implementation must join some multicast groups for neighbor discovery (e.g. solicited node groups). This means the implementation should perhaps support MLD, because there will be L2 switches that filter multicast packets unless the switches hear MLD reports for the multicast group. This will even be the case for link-local groups, as in IPv4 multicasts. Since MLD needs a hop-by-hop router alert option, the implementation should support the hop-by-hop options header as a consequence. However, this draft also says 3.1.1 Hop-by-Hop Options Header [Sending] Following 3.1, minimum hosts do not send packets with this extension header. This seems to contradict with the fact above. I think the draft should clarify this point. 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 Sat Nov 17 05:06:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAHD65LS022032 for ; Sat, 17 Nov 2001 05:06:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAHD65SL022031 for ipng-dist; Sat, 17 Nov 2001 05:06: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAHD61LS022024 for ; Sat, 17 Nov 2001 05: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 FAA10462 for ; Sat, 17 Nov 2001 05:05:42 -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 GAA00746 for ; Sat, 17 Nov 2001 06:06:13 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fAHD5vR30622 for ; Sat, 17 Nov 2001 15:05:57 +0200 Date: Sat, 17 Nov 2001 15:05:56 +0200 (EET) From: Pekka Savola To: Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The cork is already off the bottle so here I go too :-) On Fri, 16 Nov 2001 Internet-Drafts@ietf.org wrote: > As the always-on network is becoming popular, lots of nodes, not > only ordinary PCs but also various information appliances such as > sensors, home appliances, AV equipments, are to be connected to the > Internet. Note: there isn't much discussion on certain MIPv6-mandated subjects, like Home Address Option processing. One will have to clarify this; however MIPv6 is under much discussion as right now so the situation could change. --8<-- 3.3 Neighbor Discovery for IP Version 6 (IPv6) (RFC2461) [22] Because of IPv6 minimum host definition, the following functions for routers can be omitted. - Sending router advertise messages - Receiving router solicitation messages - Sending redirect messages --8<-- I don't think it's a good idea to suggest router solicitations can be omitted. MinRtrAdvInterval could be rather large, and it might take very long to get the next periodical advertiment. RS is not such a complex matter. --8<-- 4.1 Consideration of security for LCNAs [...] Currently, there are several issues that prevents from realizing security even if IPsec minimum specification is implemented. The first issue is the network environment. In order to deploy minimum hosts on current network environment, we cannot neglect existing IPv4 networks. So, we have to assume NAT or IPv4/IPv6 translators between the minimum host and the correspondent host. Current IPsec cannot handle such a situation, which means the effectiveness of security mechanism relying upon IPsec is very limited. --8<-- The draft didn't want to discuss transition issues (2.2), now you bring them up anyway. I think it's very safe to assume that IPv6 space the application seems is fully global without NAT's or anything. Further, I'm not sure whether there actually much need to be able to use IPSEC (or any connections) past the translator. A picture: Internet --- ISP router --- Home Router --- LCNA box The translation happens either in Internet, ISP router or Home Router. The primary target of the services are home users, that is, those that would never need translation or are pretty safe anyway. If someone would like to use LCNA from the Internet, I'd suggest mandating IPv6; we cannot be held hostage by legacy IPv4/NAT (plus how these affect IPSEC) issues. Therefore I think it might be safe to assume there are no unsurmountable problems w.r.t. IPSEC use. --8<-- 6. Security Consideration RFC3401 --8<-- RFC3041 :-) -- 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 Nov 17 06:48:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAHEmLLS022083 for ; Sat, 17 Nov 2001 06:48:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAHEmLdI022082 for ipng-dist; Sat, 17 Nov 2001 06:48: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAHEmHLS022075 for ; Sat, 17 Nov 2001 06:48: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 GAA18430 for ; Sat, 17 Nov 2001 06:48:19 -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 GAA28914 for ; Sat, 17 Nov 2001 06:48:18 -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 fAHElv309886; Sat, 17 Nov 2001 15:47:57 +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 PAA09183; Sat, 17 Nov 2001 15:47:55 +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 fAHElrD04762; Sat, 17 Nov 2001 15:47:54 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200111171447.fAHElrD04762@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Jung Cyndi-ACJ099 cc: "'aridaman kaushik'" , ipng@sunroof.eng.sun.com Subject: Re: In-reply-to: Your message of Fri, 16 Nov 2001 15:51:10 CST. Date: Sat, 17 Nov 2001 15:47: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: You can't have one IS-IS system span beyond a site boundary, since the site-local addresses would not be guaranteed unique. You could certainly have multiple IS-IS systems within the boundary of a single site, with some sort of routing between them - static would work, RIPng, and even BGP (are site-local prefixes allowed in BGP?) => (about last point) site-local prefixes are allowed in BGP NLRIs if they are not exported outside the site (so be really careful, i.e. this is *not* recommended). Site-local addresses are allowed for next-hops if all iBGP speakers are in the site and : - or eBGP peers are in the site too (a strange site, isn't it? :-) - or self-next-hop feature is used in order to hide addresses of eBGP peers. Note that in the last case the eBGP address/next-hop is very local (my main concern about draft-kato-bgp-ipv6-link-local-00.txt is there is no explanation about the self-next-hop feature) and the global/link-local issue for next-hops reversed. 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 Sat Nov 17 10:30:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAHIU2LS022223 for ; Sat, 17 Nov 2001 10:30:02 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAHIU2kX022222 for ipng-dist; Sat, 17 Nov 2001 10:30: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAHITtLS022207; Sat, 17 Nov 2001 10:29:55 -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 KAA18585; Sat, 17 Nov 2001 10:29:56 -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 LAA21365; Sat, 17 Nov 2001 11:29: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 fAHITr329340; Sat, 17 Nov 2001 19:29:53 +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 TAA12669; Sat, 17 Nov 2001 19:29:53 +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 fAHITqD05856; Sat, 17 Nov 2001 19:29:53 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200111171829.fAHITqD05856@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipng@sunroof.eng.sun.com Cc: mobile-ip@sunroof.eng.sun.com, rohc@cdt.luth.se Subject: IPv6 payload header Date: Sat, 17 Nov 2001 19:29:52 +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 submitted a draft (draft-dupont-ipv6-payload-00.txt) about an IPv6 payload header based on the very old Robert Elz' proposal. My purpose is to know the rough opinion about this kind of general piggy-backing mechanisms. I believe the right working group for discussion is the IPv6 WG but I send this mail to mobile-ip (because this comes from mobile IPv6 threads) and ROHC (because this has consequences for it). I've put in a section some pro & con arguments, we can begin with them. (please don't look at details of the protocol itself before we get a rough consensus in favor of it if this happens) 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 Sat Nov 17 11:32:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAHJWQLS022415 for ; Sat, 17 Nov 2001 11:32:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAHJWPTa022414 for ipng-dist; Sat, 17 Nov 2001 11:32: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAHJWMLS022407 for ; Sat, 17 Nov 2001 11:32: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 LAA22198 for ; Sat, 17 Nov 2001 11:32:22 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA20646 for ; Sat, 17 Nov 2001 12:32:04 -0700 (MST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA21771 for ; Sat, 17 Nov 2001 12:32:21 -0700 (MST)] Received: [from il06exw10.corp.mot.com (il06exw10.corp.mot.com [199.5.78.81]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA11353 for ; Sat, 17 Nov 2001 12:32:21 -0700 (MST)] Received: by il06exw10.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Sat, 17 Nov 2001 13:32:20 -0600 Message-ID: From: Jung Cyndi-ACJ099 To: "'JINMEI Tatuya / ????'" , nov@tahi.org Cc: ipng@sunroof.eng.sun.com Subject: RE: a short comment on draft-okabe-ipv6-lcna-minreq-00.txt Date: Sat, 17 Nov 2001 13:32:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-2022-jp" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jinmei, The link-local groups in IPv4 do not use IGMP, and the IGMP snooping switches take this into consideration, for the most part - those that don't consider it don't work. Those link-local addresses are things like OSPF Hellos and RIPv2 updates. Are you suggesting that MLD become part of the minimum requirements because of as yet unavailable MLD snooping switches? Those switches could check the scope of the IPv6 destination and forward all link-local scope multicast to all ports of the subnet - it is at a fixed offset forever and always. Unless we really expect heavy traffic use of link-local scope multicast, using this as the reason for mandating MLD as a minimum requirement is more of an obstacle than an aid for IPv6, in my opinion. Cyndi -----Original Message----- From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Friday, November 16, 2001 10:56 PM To: nov@tahi.org Cc: ipng@sunroof.eng.sun.com Subject: a short comment on draft-okabe-ipv6-lcna-minreq-00.txt (I think the ipng ML is the best place to discuss the issue, but please correct me if this is not appropriate.) I've taken a quick look at draft-okabe-ipv6-lcna-minreq-00.txt and have a short comment (or a question). The draft says 2.3 Multicast Multicast is not treated in this draft, and it is the candidate for further study (RFC 2375[8], RFC 2710[9]). However, the multicast related to neighbor discovery is considered. So the minimum implementation must join some multicast groups for neighbor discovery (e.g. solicited node groups). This means the implementation should perhaps support MLD, because there will be L2 switches that filter multicast packets unless the switches hear MLD reports for the multicast group. This will even be the case for link-local groups, as in IPv4 multicasts. Since MLD needs a hop-by-hop router alert option, the implementation should support the hop-by-hop options header as a consequence. However, this draft also says 3.1.1 Hop-by-Hop Options Header [Sending] Following 3.1, minimum hosts do not send packets with this extension header. This seems to contradict with the fact above. I think the draft should clarify this point. 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 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 18 06:48:14 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAIEmELS024095 for ; Sun, 18 Nov 2001 06:48:14 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAIEmEpV024094 for ipng-dist; Sun, 18 Nov 2001 06: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAIEmALS024087 for ; Sun, 18 Nov 2001 06:48: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 GAA01300 for ; Sun, 18 Nov 2001 06:47:52 -0800 (PST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id HAA09507 for ; Sun, 18 Nov 2001 07:47:51 -0700 (MST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA17130; Sun, 18 Nov 2001 09:47:56 -0500 Date: Sun, 18 Nov 2001 09:47:55 -0500 (EST) From: Jim Bound To: Hughes John-CJH023 Cc: "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: RE: draft-wasserman-3gpp-advice-00.txt In-Reply-To: <28F1A76E98BDD31189A1009027DE31CF02619ED7@ont14a-bdc.canada.css.mot.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, I agree with John's input. I will have more before the IETF meeting. I think the doc went way overboard specifying how IPv6 is used in a NON IETF standards networking suite. If this is to be a working group item then I want to be very sure the mission is to provide guidance NOT SHOULD MUST type specification. So I am emphatically against any form of MANDATE from the IETF on this and we need to make sure its a suggestion that 3Gxx can incoporate into their specifications process. I also will send input as engineer who is building 3Gxx systems for customers with IPv6 already. I also think the Loughney et all IETF 3GPP Many draft has the appropriate tone for an IETF draft for 3Gxx. Until this and John's issues are resolved I for one do not support this being a working group item just yet. regards, /jim On Wed, 14 Nov 2001, Hughes John-CJH023 wrote: > Hi Margaret, > > I have read your draft and have a few questions/comments which you may wish to address before forwarding the document to 3GPP. > > In the draft, three recommendations are made: > > > > 1. Specify that multiple prefixes may be assigned to each > > primary PDP context, > > > > 2. Require that a given prefix must not be assigned to more > > than one primary PDP context, and > > > > 3. Allow 3GPP nodes to use multiple identifiers within those > > prefixes, including randomly generated identifiers. > > The draft then points out that implementing these recommendations will bring the following benefits: > > > Laptops that connect to 3GPP handsets will work without any > > software changes. Their implementation of standard IPv6 over > > PPP, address assignment, and autoconfiguration mechanisms > > will work without any modification. This will eliminate the > > need for vendors and operators to build and test special 3GPP > > drivers and related software. > > It would be helpful if you could show where these incompatibilities lie ? Are these incompatibilities related to PPPv6 or application implementations ? I believe the 3GPP implementation has been designed to work with standard implementations of PPPv6 (between the MT and TE i.e. between a handset and laptop), so if there are problems it would be good to see them stated explicitly. > > > IPv6 software implementations could be used in 3GPP handsets > > without any modifications to the IPv6 protocol mechanisms. > > This will make it easier to build and test 3GPP handsets. > > Is this really an issue. The IPv6 stack will have to be integrated into the UE in any case and therefore some degree of engineering effort will be required. Will implementation of IPv6 in a 3G UE be much more difficult than in say other small devices (PDAs) as a result of 3GPP design decisions. > > > Applications in 3GPP handsets will be able to take advantage > > of different types of IPv6 addresses (e.g., static addresses, > > temporary addresses for privacy, site-scoped addresses for > > site only communication, etc.) > > It would be helpful if you could expand on what is meant here. Static addresses are already supported, privacy (in the form of generating temporary addresses) is not such an issue in the 3GPP environment as each time a context is activated a new "temporary" address is assigned. Site-scoped addresses are not prevented in 3GPP, the prefix assigned at context activation may be limited to site scope. > > > The GPRS system will be better positioned to take advantage of > > new IPv6 features that are built around the current addressing > > architecture. > > Again this needs to be expanded upon. While it is important to ensure the specs do not prevent future enhancement, the benefits need to be weighed against any increased complexity. > > The draft also lists two problems with the current 3GPP specs: > > > The GGSN only advertises a single /64 prefix, rather than a > > set of prefixes. This will prevent the participation of 3GPP > > nodes (e.g. handsets or 3GPP-attached laptops) in IPv6 site > > renumbering, or in other mechanisms that expect IPv6 hosts to > > create addresses based on multiple advertised prefixes. > > I do not see how site renumbering is an issue. When site renumbering takes place (i.e. the operator switches to a new ISP hence causing all address prefixes to change), the change must take place over a period of time where both the old and new addresses are supported. In 3GPP, all new PDP contexts will be assigned new addresses. If PDP contexts need to be deactivated by the network in order to force an address to be renewed, then that is also supported. > > > A 3GPP node is assigned a single identifier and is not allowed > > to generate additional identifiers. This will prevent the use > > of privacy addresses by 3GPP nodes. This also makes 3GPP > > mechanisms not fully compliant with the expected behavior of > > IPv6 nodes, which will result in incompatibility with popular > > laptop IPv6 stacks. > > Again I do not think the privacy issue is important in a 3GPP environment as I stated above (by their nature addresses are temporary). In RFC3041 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", it states the following: > > "The way PPP is used today, however, PPP servers > typically unilaterally inform the client what address they are to use > (i.e., the client doesn't generate one on its own). This practice, > if continued in IPv6, would avoid the concerns that are the focus of > this document." > > This exactly describes the way in which addresses are allocated in the 3GPP specs. So for me, this confirms that Privacy (as described in RFC3041) is not an issue for 3GPP systems. The incompatibility issues need to be clarified - it needs to be explained where there will be problems connecting a UE to IPv6 laptop stacks. > > One final point, do you really think it is wise to assign /64 to a UE. I am not familiar with how liberally (cheaply) IPv6 addresses will be handed out by the addressing authorities but this seems excessive. Many 3GPP devices may be simple (e.g. telemetry type) devices which will have no use for /64 addresses ? Unless a UE is acting as a router, then /64 seems not to be necessary - in 3GPP the UE is a host not a router. If a UE needs multiple addresses, then it just activates a new PDP context for each address required - this is a good solution, as for each new address required you also specify the QoS capabilities required. > > Hope these comments are helpful. I think an assessment of how 3GPP implements IPv6 is useful and needed and closer cooperation between the IETF and 3GPP should be encouraged. > > Best regards, > John > > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Tuesday, November 13, 2001 2:40 PM > To: ipng@sunroof.eng.sun.com > Subject: draft-wasserman-3gpp-advice-00.txt > > > > I would like to request that the working group consider > draft-wasserman-3gpp-advice-00.txt as a working group > work item. > > This draft was written by the IPv6-3GPP design team and > offers advice on the use of IPv6 within 3GPP standards. > > Please let me know if there are any objections to making > this document an IPng work item. > > Thanks, > 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 Sun Nov 18 17:51:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ1ptLS024781 for ; Sun, 18 Nov 2001 17:51:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJ1ptNh024780 for ipng-dist; Sun, 18 Nov 2001 17:51: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ1pqLS024773 for ; Sun, 18 Nov 2001 17:51:52 -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 RAA07929 for ; Sun, 18 Nov 2001 17:51:54 -0800 (PST) Received: from tkd.att.ne.jp (tkd.att.ne.jp [165.76.16.8]) by patan.sun.com (8.9.3+Sun/8.9.3) with SMTP id SAA14653 for ; Sun, 18 Nov 2001 18:51:35 -0700 (MST) Received: (qmail 2648 invoked from network); 19 Nov 2001 01:51:51 -0000 Received: from unknown (HELO localhost) (133.243.254.248) by tkd.att.ne.jp with SMTP; 19 Nov 2001 01:51:51 -0000 Date: Mon, 19 Nov 2001 10:51:43 +0900 (JST) Message-Id: <20011119.105143.112630302.nov@tahi.org> to: ipng@sunroof.eng.sun.com Subject: Re: a short comment on draft-okabe-ipv6-lcna-minreq-00.txt 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=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk jinmei, Thank you for your comment. The draft assumes that a minimum host sends/receives ND related link-local multicast without MLD, and Hop-by-Hop Options Header is also unnecessary. I'm not aware that L2 switch may drop the packets without MLD as you mentioned. But, how serious the problem is? We developed a kind of minimum host that is almost based on this draft, and ran over a hundred of the hosts on a IPv6 network in N+I Tokyo 2001. However, we have never seen the problem. From: JINMEI Tatuya / $B?@L@C#:H(B Subject: a short comment on draft-okabe-ipv6-lcna-minreq-00.txt Date: Sat, 17 Nov 2001 15:55:40 +0900 > (I think the ipng ML is the best place to discuss the issue, but > please correct me if this is not appropriate.) > > I've taken a quick look at draft-okabe-ipv6-lcna-minreq-00.txt and > have a short comment (or a question). > > The draft says > > 2.3 Multicast > Multicast is not treated in this draft, and it is the candidate for > further study (RFC 2375[8], RFC 2710[9]). However, the multicast > related to neighbor discovery is considered. > > So the minimum implementation must join some multicast groups for > neighbor discovery (e.g. solicited node groups). This means the > implementation should perhaps support MLD, because there will be L2 > switches that filter multicast packets unless the switches hear MLD > reports for the multicast group. This will even be the case for > link-local groups, as in IPv4 multicasts. Since MLD needs a > hop-by-hop router alert option, the implementation should support > the hop-by-hop options header as a consequence. > > However, this draft also says > > 3.1.1 Hop-by-Hop Options Header > [Sending] > Following 3.1, minimum hosts do not send packets with this extension > header. > > This seems to contradict with the fact above. I think the draft > should clarify this point. ---- 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 Sun Nov 18 22:17:24 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ6HOLS025339 for ; Sun, 18 Nov 2001 22:17:24 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJ6HNp7025338 for ipng-dist; Sun, 18 Nov 2001 22:17: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ6HKLS025331 for ; Sun, 18 Nov 2001 22:17:20 -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 WAA04358 for ; Sun, 18 Nov 2001 22:17:00 -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 WAA10986 for ; Sun, 18 Nov 2001 22:17:19 -0800 (PST) Received: (qmail 28442 invoked from network); 19 Nov 2001 06:17:18 -0000 Received: from unknown (HELO localhost) (133.243.254.248) by tkd.att.ne.jp with SMTP; 19 Nov 2001 06:17:18 -0000 Date: Mon, 19 Nov 2001 15:16:47 +0900 (JST) Message-Id: <20011119.151647.71085363.nov@tahi.org> to: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-00.txt 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 thank you for taking your time. From: Pekka Savola Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-00.txt Date: Sat, 17 Nov 2001 15:05:56 +0200 (EET) > > As the always-on network is becoming popular, lots of nodes, not > > only ordinary PCs but also various information appliances such as > > sensors, home appliances, AV equipments, are to be connected to the > > Internet. > Note: there isn't much discussion on certain MIPv6-mandated subjects, like > Home Address Option processing. One will have to clarify this; however > MIPv6 is under much discussion as right now so the situation could change. A kind of munimum host should not have mobility. It means the host does not have to implement MIP6 related functions. This is the reason why this draft does not mandate MIP6. > --8<-- > 3.3 Neighbor Discovery for IP Version 6 (IPv6) (RFC2461) [22] > Because of IPv6 minimum host definition, the following functions for > routers can be omitted. > > - Sending router advertise messages > - Receiving router solicitation messages > - Sending redirect messages > --8<-- > I don't think it's a good idea to suggest router solicitations can be > omitted. MinRtrAdvInterval could be rather large, and it might take very > long to get the next periodical advertiment. RS is not such a complex > matter. This draft assumes that a minimum host is not a route but a host. Therefor, router related ND functionaions should be ommited: - Sending router advertise messages - Receiving router solicitation messages - Sending redirect messages Of course, the host must implement host-related ones: - Receiving RA messages - Sending RS messages - (Receiving REDIRECT messages) > --8<-- > 4.1 Consideration of security for LCNAs > [...] > > Currently, there are several issues that prevents from realizing > security even if IPsec minimum specification is implemented. The > first issue is the network environment. In order to deploy minimum > hosts on current network environment, we cannot neglect existing > IPv4 networks. So, we have to assume NAT or IPv4/IPv6 translators > between the minimum host and the correspondent host. Current IPsec > cannot handle such a situation, which means the effectiveness of > security mechanism relying upon IPsec is very limited. > --8<-- > > The draft didn't want to discuss transition issues (2.2), now you bring > them up anyway. As you pointed it is our weak point as you a Honestley speaking, we don't want to rely on any specific transtion technology. > I think it's very safe to assume that IPv6 space the > application seems is fully global without NAT's or anything. How long time-frame do you assume? Your assumption may not work if someone want to develop a LCNA for "right-now" business. > Further, I'm not sure whether there actually much need to be able to use > IPSEC (or any connections) past the translator. A picture: > > Internet --- ISP router --- Home Router --- LCNA box > > The translation happens either in Internet, ISP router or Home Router. > The primary target of the services are home users, that is, those that > would never need translation or are pretty safe anyway. Please let me clarify the point. Do you mean that almost communication happens between LCNAs behind the home router? > If someone would like to use LCNA from the Internet, I'd suggest mandating > IPv6; we cannot be held hostage by legacy IPv4/NAT (plus how these affect > IPSEC) issues. > Therefore I think it might be safe to assume there are no unsurmountable > problems w.r.t. IPSEC use. It is important for people who thinks LCNAs as a business seriousely to work with legacy network. How should we deal with it? > --8<-- > 6. Security Consideration > RFC3401 > --8<-- > RFC3041 :-) wow.... 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 Sun Nov 18 22:38:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ6cfLS025372 for ; Sun, 18 Nov 2001 22:38:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJ6cfKu025371 for ipng-dist; Sun, 18 Nov 2001 22:38: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ6ccLS025364 for ; Sun, 18 Nov 2001 22:38: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 WAA05974 for ; Sun, 18 Nov 2001 22:38:18 -0800 (PST) Received: from neogw.osaka.iij.ad.jp (neogw.osaka.iij.ad.jp [202.232.14.130]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id XAA09062 for ; Sun, 18 Nov 2001 23:38:50 -0700 (MST) Received: by neogw.osaka.iij.ad.jp; id PAA26500; Mon, 19 Nov 2001 15:38:36 +0900 (JST) Received: from keiichi01.osaka.iij.ad.jp(192.168.65.66) by neogw.osaka.iij.ad.jp via smap (V4.2) id xma026475; Mon, 19 Nov 01 15:38:13 +0900 Received: from keiichi01.osaka.iij.ad.jp (localhost.osaka.iij.ad.jp [127.0.0.1]) by keiichi01.osaka.iij.ad.jp (8.11.6/8.11.6) with ESMTP id fAJ6cC600597; Mon, 19 Nov 2001 15:38:12 +0900 (JST) (envelope-from keiichi@iij.ad.jp) Date: Mon, 19 Nov 2001 15:38:12 +0900 Message-ID: <86herr9sff.wl@keiichi01.osaka.iij.ad.jp> From: Keiichi SHIMA / =?ISO-2022-JP?B?GyRCRWc3RDBsGyhC?= To: OKABE Nobuo Cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-00.txt In-Reply-To: <20011119.151647.71085363.nov@tahi.org> References: <20011119.151647.71085363.nov@tahi.org> User-Agent: Wanderlust/2.6.0 (Twist And Shout) SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-1?Q?Unebigory=F2mae?=) APEL/10.2 MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Internet Initiative Japan Inc. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk OKABE Nobuo wrote: > > > > As the always-on network is becoming popular, lots of nodes, not > > > only ordinary PCs but also various information appliances such as > > > sensors, home appliances, AV equipments, are to be connected to the > > > Internet. > > Note: there isn't much discussion on certain MIPv6-mandated subjects, like > > Home Address Option processing. One will have to clarify this; however > > MIPv6 is under much discussion as right now so the situation could change. > > A kind of munimum host should not have mobility. > It means the host does not have to implement MIP6 related functions. > This is the reason why this draft does not mandate MIP6. The problem is that if a mobile node try to connect the peer with the home address destination option and the peer doesn't support the home address destination option, these two can't communication forever. This is because (at least current) MIP6 requires all the IPv6 nodes to process the home address destination option (means to be mobility aware) even though they are not mobile. But, as Pekka have said already, MIP6 need much discussion and such requirement may change... P.S. KAME/MIP6 fallbacks to using CoA if the destination peer send ICMP paramprob against the home address destination option. Of course this breaks mobility but very useful in transision period or may be for such a minimum host okabe-san said. --- 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 Sun Nov 18 23:15:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ7FpLS025407 for ; Sun, 18 Nov 2001 23:15:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJ7FpuN025406 for ipng-dist; Sun, 18 Nov 2001 23:15: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ7FlLS025399 for ; Sun, 18 Nov 2001 23:15:47 -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 XAA08876 for ; Sun, 18 Nov 2001 23:15:22 -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 XAA12883 for ; Sun, 18 Nov 2001 23:15:36 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fAJ7F9921714; Mon, 19 Nov 2001 09:15:11 +0200 Date: Mon, 19 Nov 2001 09:15:09 +0200 (EET) From: Pekka Savola To: OKABE Nobuo cc: Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-00.txt In-Reply-To: <20011119.151647.71085363.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 On Mon, 19 Nov 2001, OKABE Nobuo wrote: > From: Pekka Savola > Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-00.txt > Date: Sat, 17 Nov 2001 15:05:56 +0200 (EET) > > > > As the always-on network is becoming popular, lots of nodes, not > > > only ordinary PCs but also various information appliances such as > > > sensors, home appliances, AV equipments, are to be connected to the > > > Internet. > > Note: there isn't much discussion on certain MIPv6-mandated subjects, like > > Home Address Option processing. One will have to clarify this; however > > MIPv6 is under much discussion as right now so the situation could change. > > A kind of munimum host should not have mobility. > It means the host does not have to implement MIP6 related functions. > This is the reason why this draft does not mandate MIP6. Certain aspects of MIPv6 are, as currently being specified, a *MUST* for *EVERY* IPv6 node, whether it is mobile or stationary. An example of this is the processing of Home Address Option. There are more. It is possible that this will change, but to which direction, it's difficult to say. > > I don't think it's a good idea to suggest router solicitations can be > > omitted. MinRtrAdvInterval could be rather large, and it might take very > > long to get the next periodical advertiment. RS is not such a complex > > matter. > > This draft assumes that a minimum host is not a route but a host. > Therefor, router related ND functionaions should be ommited: > - Sending router advertise messages > - Receiving router solicitation messages > - Sending redirect messages > > Of course, the host must implement host-related ones: > - Receiving RA messages > - Sending RS messages > - (Receiving REDIRECT messages) Sorry, I didn't read carefully enough. I meant sending RS messages, which are already covered. > > I think it's very safe to assume that IPv6 space the > > application seems is fully global without NAT's or anything. > > How long time-frame do you assume? > Your assumption may not work if someone want to develop > a LCNA for "right-now" business. Note that I said IPv6 space is fully global without [IPv6] NAT's. That is, as long as the other node is speaking native IPv6, there will be no problems wrt. IPSEC. How the other node gets this IPv6 connectivity is irrelevant, be it behind IPv4 NAT (e.g. via Shipworm), 6to4 or whatever. > > Further, I'm not sure whether there actually much need to be able to use > > IPSEC (or any connections) past the translator. A picture: > > > > Internet --- ISP router --- Home Router --- LCNA box > > > > The translation happens either in Internet, ISP router or Home Router. > > The primary target of the services are home users, that is, those that > > would never need translation or are pretty safe anyway. > > Please let me clarify the point. > Do you mean that almost communication happens between LCNAs > behind the home router? Yes, I believe this is the case. In this kind of closed network, IPSEC is not a *huge* problem. There are arguably some uses for to be able to access LCNA boxes from the Internet, but you could mandate that pure IPv6 without translation is used there, so that IPSEC would non-problematic. See below. > > If someone would like to use LCNA from the Internet, I'd suggest mandating > > IPv6; we cannot be held hostage by legacy IPv4/NAT (plus how these affect > > IPSEC) issues. > > Therefore I think it might be safe to assume there are no unsurmountable > > problems w.r.t. IPSEC use. > > It is important for people who thinks LCNAs as a business seriousely > to work with legacy network. How should we deal with it? Let me try to clarify this. In real world, the scenario would currently or in the near future be something like this: (sorry for shoddy User A&B&C, ran out of space :-) .- Home User 1 (IPv4) IPv4/IPv6 / Internet --- ISP router --- Home Router --- LCNA box (IPv6) | | \ \ User A B C '- Home User 2 (IPv6) IPv4/6 4 v6 (IPv6 connectivity can be native, 6to4, Shipworm from behind IPv4 NAT's, whatever, as long as it exists. If Home User 2 wants to access LCNA, it works without problems, with or without IPSEC. If Home User 1 wants to access LCNA, translation will be required. Translation would kill IPSEC, but as Home User 1 is in a "secure" environment" this is not a problem. Only problem is that the translation MUST occur in the Home Router, not upstream. If User A from the Internet wants to access LCNA, IPv6 can be used and IPSEC can be used. If User B from the Internet wants to access LCNA, IPv4 would have to be used, but the packet would have to translated, and IPSEC would not be guaranteed. This scenario will not work because any user from Internet cannot be trusted without IPSEC or similar precautions. If User C from the Internet wants to access LCNA, IPv6 can be used and IPSEC can also be used fine. So, the only issues I see are: - translation would have to occur within the secure domain, that is, home router. Translation is required only if we want to allow access from home IPv4-only nodes. - IPv4-only nodes from the Internet cannot access LCNA. As we're talking about an _IPv6_ LCNA, I believe this is a reasonable assumption. It's rather easy to get IPv6 access if you really want. -- 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 Nov 19 01:35:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ9ZHLS025612 for ; Mon, 19 Nov 2001 01:35:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJ9ZGg6025611 for ipng-dist; Mon, 19 Nov 2001 01:35: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJ9ZDLS025604 for ; Mon, 19 Nov 2001 01:35: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 BAA28469 for ; Mon, 19 Nov 2001 01:35:13 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA10808 for ; Mon, 19 Nov 2001 02:34:55 -0700 (MST) Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id fAJ9ZBf19894 for ; Mon, 19 Nov 2001 10:35:11 +0100 (MET) Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Mon Nov 19 10:35:02 2001 +0100 Received: by esealnt400 with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Nov 2001 10:34:50 +0100 Message-ID: <4DA6EA82906FD511BE2F00508BCF053801C4C083@Esealnt861.al.sw.ericsson.se> From: "Hesham Soliman (ERA)" To: "'Hughes John-CJH023'" , "Hesham Soliman (ERA)" , "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: RE: draft-wasserman-3gpp-advice-00.txt Date: Mon, 19 Nov 2001 10:34:46 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fAJ9ZDLS025605 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk John, Please see my comment below. => Actually it seems to me that the solution in the draft is a lot simpler than the one in the current 3GPP specs, but I might have missed something that concerned you ? I agree. The solution in the draft is simpler however at the expense of what I view as being a wasteful implementation. The draft proposes /64 being allocated to each mobile device at a minimum and problably multiple /64s. This would be perfectly acceptable if each mobile device was a mobile router supporting mobile subnets - but in 3GPP that is not the case, a mobile device is a host and in many cases the hosts may have very basic functionalities. => I understand that it seems wasteful, however, according to the calculations in section 7.3.1 of the draft, we can afford to trade off the efficiency of address allocation for simplicity. To my knowledge, nothing in the 3GPP specifications prohibits a UE from being a router. Granted that currently, it seems that UEs are not heading that way, but why not have a mechanism that allows the UE to be a router _if_needed_ in future. You could probably argue that there might be more efficient mechanisms, but when we consider the limitation of not wanting to significantly impact the 3GPP specs, this solution seems reasonable. The working group should provide guidance on whether such a solution is something they are comfortable with being recommended to 3GPP. => That's what we¨'re doing now :) Regards, 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 Nov 19 04:31:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJCVpLS027246 for ; Mon, 19 Nov 2001 04:31:51 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJCVpkP027245 for ipng-dist; Mon, 19 Nov 2001 04:31: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJCVkLS027238 for ; Mon, 19 Nov 2001 04:31:46 -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 EAA06515 for ; Mon, 19 Nov 2001 04:31:46 -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 FAA02988 for ; Mon, 19 Nov 2001 05:31:28 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:17b:2cf9:e9d5:14ed]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fAJCVd332192; Mon, 19 Nov 2001 21:31:39 +0900 (JST) Date: Mon, 19 Nov 2001 21:31:34 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Jung Cyndi-ACJ099 Cc: nov@tahi.org, ipng@sunroof.eng.sun.com Subject: Re: a short comment on draft-okabe-ipv6-lcna-minreq-00.txt In-Reply-To: References: User-Agent: Wanderlust/2.7.5 (Too Funky) 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 980905(IM100) Lines: 47 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Sat, 17 Nov 2001 13:32:18 -0600, >>>>> Jung Cyndi-ACJ099 said: > The link-local groups in IPv4 do not use IGMP, and the IGMP snooping > switches take this into consideration, for the most part - those that don't > consider it don't work. Those link-local addresses are things like OSPF > Hellos and RIPv2 updates. Hmm, then I misunderstood the current situation. I should also have checked draft-ietf-magma-snoop-00.txt, which says: To avoid this situation, IGMP snooping switches should be less con- servative when forwarding packets to these addresses and flood them to all ports. (2.2. IGMPv2 snooping and 224.0.0.X) > Are you suggesting that MLD become part of the minimum requirements > because of as yet unavailable MLD snooping switches? Those switches > could check the scope of the IPv6 destination and forward all link-local > scope multicast to all ports of the subnet - it is at a fixed offset forever > and always. Unless we really expect heavy traffic use of link-local scope > multicast, using this as the reason for mandating MLD as a minimum > requirement is more of an obstacle than an aid for IPv6, in my opinion. I agree. The previous comment of mine was simply due to my misunderstanding about the current IGMP snooping. I applied the wrong analogy to the "as yet unavailable switches." Please just forget this. However, I have still some concern about the "future" switches. The magma draft only mentions addresses in the form of FF0X:0:0:0:0:0:X:X. It does not directly talk about the link-local multicast. Also, RFC 2710 explicitly says MLD messages are sent for link-local groups: MLD messages ARE sent for multicast addresses whose scope is 2 (link-local), including Solicited-Node multicast addresses [ADDR- ARCH], except for the link-scope, all-nodes address (FF02::1). So I'm still afraid the "future" switches might snoop and filter link-local addresses. We should probably clarify this on the magma 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 Mon Nov 19 04:37:31 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJCbVLS027296 for ; Mon, 19 Nov 2001 04:37:31 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJCbVss027295 for ipng-dist; Mon, 19 Nov 2001 04:37: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJCbQLS027288 for ; Mon, 19 Nov 2001 04:37:26 -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 EAA07117 for ; Mon, 19 Nov 2001 04:37: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 FAA06467 for ; Mon, 19 Nov 2001 05:37:08 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:17b:2cf9:e9d5:14ed]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fAJCbN332218; Mon, 19 Nov 2001 21:37:23 +0900 (JST) Date: Mon, 19 Nov 2001 21:37:19 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: OKABE Nobuo Cc: ipng@sunroof.eng.sun.com Subject: Re: a short comment on draft-okabe-ipv6-lcna-minreq-00.txt In-Reply-To: <20011119.105143.112630302.nov@tahi.org> References: <20011119.105143.112630302.nov@tahi.org> User-Agent: Wanderlust/2.7.5 (Too Funky) 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 980905(IM100) Lines: 28 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Mon, 19 Nov 2001 10:51:43 +0900 (JST), >>>>> OKABE Nobuo said: > The draft assumes that a minimum host sends/receives > ND related link-local multicast without MLD, > and Hop-by-Hop Options Header is also unnecessary. > I'm not aware that L2 switch may drop the packets > without MLD as you mentioned. > But, how serious the problem is? Please read my response to Cyndi. I'm talking about future implementation of L2 switches that support MLD snooping. My concern was partly (or 80%) wrong, which was due to a misunderstanding of mine, but I'm still have a concern based on the current specification. > We developed a kind of minimum host > that is almost based on this draft, and > ran over a hundred of the hosts on a IPv6 network in N+I Tokyo 2001. > However, we have never seen the problem. Of course. As far as I know, there is no L2 switch that support MLD snooping at this moment. 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 Mon Nov 19 05:30:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJDUfLS027463 for ; Mon, 19 Nov 2001 05:30:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJDUfKd027462 for ipng-dist; Mon, 19 Nov 2001 05:30: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJDUaLS027448 for ; Mon, 19 Nov 2001 05:30:36 -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 FAA21561 for ; Mon, 19 Nov 2001 05:30:37 -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 FAA09014 for ; Mon, 19 Nov 2001 05:30:36 -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 IAA27039; Mon, 19 Nov 2001 08:30:34 -0500 (EST) Message-Id: <200111191330.IAA27039@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-huitema-ipngwg-dialondemand-00.txt Date: Mon, 19 Nov 2001 08:30:33 -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 : IPv6 Dial-up on Demand Author(s) : C. Huitema Filename : draft-huitema-ipngwg-dialondemand-00.txt Pages : 12 Date : 16-Nov-01 In an IPv6 home network, there is a possibility that the residential gateway, learns a different IPv6 prefix after each dial-up; attempts to communicate using old address would thus fail. This implies that we should not attempt to trigger dial-up by simply sending the first packet of a connection. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-huitema-ipngwg-dialondemand-00.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-huitema-ipngwg-dialondemand-00.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-huitema-ipngwg-dialondemand-00.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: <20011116142236.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-huitema-ipngwg-dialondemand-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-huitema-ipngwg-dialondemand-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011116142236.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 Mon Nov 19 05:51:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJDp0LS027631 for ; Mon, 19 Nov 2001 05:51:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJDp0nE027630 for ipng-dist; Mon, 19 Nov 2001 05:51: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJDouLS027623 for ; Mon, 19 Nov 2001 05:50: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 FAA12954 for ; Mon, 19 Nov 2001 05:50:57 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA21468 for ; Mon, 19 Nov 2001 06:51:09 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id OAA08880; Mon, 19 Nov 2001 14:50:53 +0100 Received: from dhcp22-51.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA39034 from ; Mon, 19 Nov 2001 14:50:40 +0100 Message-Id: <3BF90E87.1AB4A77D@hursley.ibm.com> Date: Mon, 19 Nov 2001 14:52:07 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: "Hesham Soliman (ERA)" Cc: "'Hughes John-CJH023'" , "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: Re: draft-wasserman-3gpp-advice-00.txt References: <4DA6EA82906FD511BE2F00508BCF053801C4C083@Esealnt861.al.sw.ericsson.se> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fAJDovLS027624 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It's short-sighted *not* to think of the 3G (or 4G) devices as routers - we certainly need to recommend an approach for 3G that will also work for 4G - in 4G, surely we will get a solution in which the cellular terminal will act as a router for the personal area network Just give them each a /64. Anything else is fiddling with details. (Also see RFC 3177, section 3) Brian "Hesham Soliman (ERA)" wrote: > > John, > > Please see my comment below. > > => Actually it seems to me that the solution in the draft > is a lot simpler than the one in the current 3GPP specs, but > I might have missed something that concerned you ? > > I agree. The solution in the draft is simpler however at the expense of what I view as being a wasteful implementation. The draft proposes /64 being allocated to each mobile device at a minimum and problably multiple /64s. This would be perfectly acceptable if each mobile device was a mobile router supporting mobile subnets - but in 3GPP that is not the case, a mobile device is a host and in many cases the hosts may have very basic functionalities. > > => I understand that it seems wasteful, however, according > to the calculations in section 7.3.1 of the draft, we > can afford to trade off the efficiency of address allocation > for simplicity. > To my knowledge, nothing in the 3GPP specifications prohibits > a UE from being a router. Granted that currently, it seems > that UEs are not heading that way, but why not have a > mechanism that allows the UE to be a router _if_needed_ > in future. > You could probably argue that there might be more efficient > mechanisms, but when we consider the limitation of not wanting > to significantly impact the 3GPP specs, this solution > seems reasonable. > > The working group should provide guidance on whether such a solution is something they are comfortable with being recommended to 3GPP. > > => That's what we¨'re doing now :) > > Regards, > 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 > -------------------------------------------------------------------- -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland Board Chairman, Internet Society http://www.isoc.org -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon Nov 19 06:30:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJEURLS027859 for ; Mon, 19 Nov 2001 06:30:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJEURpq027858 for ipng-dist; Mon, 19 Nov 2001 06: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJEUNLS027851 for ; Mon, 19 Nov 2001 06:30:23 -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 GAA17476 for ; Mon, 19 Nov 2001 06:30:24 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA17854 for ; Mon, 19 Nov 2001 07:30:39 -0700 (MST) Received: from pamela (as1b-141.chi.il.dial.anet.com [198.92.157.141]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id IAA01336; Mon, 19 Nov 2001 08:29:26 -0600 (CST) Message-ID: <006d01c17108$5f0c4040$3200a8c0@pamela> From: "Jim Fleming" To: "Brian E Carpenter" , "Hesham Soliman \(ERA\)" Cc: "'Hughes John-CJH023'" , "'Margaret Wasserman'" , References: <4DA6EA82906FD511BE2F00508BCF053801C4C083@Esealnt861.al.sw.ericsson.se> <3BF90E87.1AB4A77D@hursley.ibm.com> Subject: Re: draft-wasserman-3gpp-advice-00.txt Date: Mon, 19 Nov 2001 08:42:08 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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 Don't forget to include the IAB/IETF Architecture diagram, it helps people navigate. http://unfix.org/projects/ipv6/IPv6andIPv4.gif Jim Fleming http://www.IPv8.info IPv16....One Better !! ----- Original Message ----- From: "Brian E Carpenter" To: "Hesham Soliman (ERA)" Cc: "'Hughes John-CJH023'" ; "'Margaret Wasserman'" ; Sent: Monday, November 19, 2001 7:52 AM Subject: Re: draft-wasserman-3gpp-advice-00.txt > It's short-sighted *not* to think of the 3G (or 4G) devices as routers > - we certainly need to recommend an approach for 3G that will also work for 4G > - in 4G, surely we will get a solution in which the cellular terminal will > act as a router for the personal area network > > Just give them each a /64. Anything else is fiddling with details. > > (Also see RFC 3177, section 3) > > Brian > > "Hesham Soliman (ERA)" wrote: > > > > John, > > > > Please see my comment below. > > > > => Actually it seems to me that the solution in the draft > > is a lot simpler than the one in the current 3GPP specs, but > > I might have missed something that concerned you ? > > > > I agree. The solution in the draft is simpler however at the expense of what I view as being a wasteful implementation. The draft proposes /64 being allocated to each mobile device at a minimum and problably multiple /64s. This would be perfectly acceptable if each mobile device was a mobile router supporting mobile subnets - but in 3GPP that is not the case, a mobile device is a host and in many cases the hosts may have very basic functionalities. > > > > => I understand that it seems wasteful, however, according > > to the calculations in section 7.3.1 of the draft, we > > can afford to trade off the efficiency of address allocation > > for simplicity. > > To my knowledge, nothing in the 3GPP specifications prohibits > > a UE from being a router. Granted that currently, it seems > > that UEs are not heading that way, but why not have a > > mechanism that allows the UE to be a router _if_needed_ > > in future. > > You could probably argue that there might be more efficient > > mechanisms, but when we consider the limitation of not wanting > > to significantly impact the 3GPP specs, this solution > > seems reasonable. > > > > The working group should provide guidance on whether such a solution is something they are comfortable with being recommended to 3GPP. > > > > => That's what we¨'re doing now :) > > > > Regards, > > 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 > > -------------------------------------------------------------------- > > -- > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > Brian E Carpenter > Distinguished Engineer, Internet Standards & Technology, IBM > On assignment at the IBM Zurich Laboratory, Switzerland > Board Chairman, Internet Society http://www.isoc.org > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 19 06:43:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJEh0LS027891 for ; Mon, 19 Nov 2001 06:43:00 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJEh0dO027890 for ipng-dist; Mon, 19 Nov 2001 06:43: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJEgvLS027883 for ; Mon, 19 Nov 2001 06:42:57 -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 GAA29985 for ; Mon, 19 Nov 2001 06:42:58 -0800 (PST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA25464 for ; Mon, 19 Nov 2001 07:43:13 -0700 (MST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA204242 for ; Mon, 19 Nov 2001 08:40:01 -0600 Received: from d04nm200.raleigh.ibm.com (d04nm200.raleigh.ibm.com [9.67.226.57]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAJEgqk109756 for ; Mon, 19 Nov 2001 09:42:52 -0500 Importance: Normal Sensitivity: Subject: IPv6 MIBs To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: "Kristine Adamson" Date: Mon, 19 Nov 2001 09:42:50 -0500 X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 11/19/2001 09:42:51 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We are looking into implementing the draft IPv6 MIBs in the near future and wondered about the current state of the drafts - I noticed that there is no current Compliance statement (ipv6Compliance??) in draft-ietf-ipngwg-rfc2011-update-00.txt. Will this be updated soon? - On the IPv6 MIB Design Team site, it appears that the draft-ietf-ipngwg-rfc2012-update-00.txt and draft-ietf-ipngwg-rfc2013-update-00.txt drafts have been updated to remove some of the IP address type MIB objects (e.g. tcpConnectionRemAddrType). Is this going to be applied to any of the other MIB drafts? I also had a question about the InetAddressType TC in draft-ietf-ops-rfc2851-update-05.txt. If I want to represent a global IPv4-mapped IPv6 address with this textual convention, do I use a value of ipv4(1) and set the corresponding InetAddress object to the IPv4 portion of the IPv4-mapped address? Thanks, Kristine Adamson IBM Communications Server for MVS: TCP/IP Development Internet e-mail:adamson@us.ibm.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 Nov 19 10:16:38 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJIGcLS028373 for ; Mon, 19 Nov 2001 10:16:38 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJIGcp3028372 for ipng-dist; Mon, 19 Nov 2001 10:16: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJIGYLS028365 for ; Mon, 19 Nov 2001 10:16: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 KAA03947 for ; Mon, 19 Nov 2001 10:16:36 -0800 (PST) From: jarno.rajahalme@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 KAA20937 for ; Mon, 19 Nov 2001 10:16:34 -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 fAJIHFA23920 for ; Mon, 19 Nov 2001 20:17:15 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 19 Nov 2001 20:16:29 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 19 Nov 2001 20:16:30 +0200 Message-ID: <009CA59D1752DD448E07F8EB2F911757198077@esebe004.NOE.Nokia.com> To: ipng@sunroof.eng.sun.com Subject: FW: I-D ACTION:draft-rajahalme-ipv6-flow-label-00.txt Date: Mon, 19 Nov 2001 20:16:23 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI, Comments? Jarno > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : An IPv6 Flow Label Specification Proposal > Author(s) : J. Rajahalme, A. Conta > Filename : draft-rajahalme-ipv6-flow-label-00.txt > Pages : 18 > Date : 15-Nov-01 > > The IPv6 flow label field has been designed to allow eliminating > protocol layer violations and the related problems from flow specific > packet classifiers. > This document provides an analysis of the current state of the IPv6 > flow label field definition and proposes new text to be included in > the next revision of the IPv6 specification. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-rajahalme-ipv6-flow-label-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 Mon Nov 19 11:51:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJJpRLS028508 for ; Mon, 19 Nov 2001 11:51:27 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAJJpQvl028507 for ipng-dist; Mon, 19 Nov 2001 11:51:26 -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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAJJpOLS028500 for ; Mon, 19 Nov 2001 11:51:25 -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 fAJJpKYN008380 for ; Mon, 19 Nov 2001 11:51:20 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fAJJpKYh008379 for ipng@sunroof.eng.sun.com; Mon, 19 Nov 2001 11:51:20 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAGITaLS020577 for ; Fri, 16 Nov 2001 10:29:36 -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 KAA29543 for ; Fri, 16 Nov 2001 10:29:19 -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 KAA13220 for ; Fri, 16 Nov 2001 10:29:36 -0800 (PST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id LAA17931 for ; Fri, 16 Nov 2001 11:29:34 -0700 (MST)] Received: [from ont14a-bdc.canada.css.mot.com (ont14a-bdc.canada.css.mot.com [199.1.20.72]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id LAA05945 for ; Fri, 16 Nov 2001 11:29:34 -0700 (MST)] Received: by ont14a-bdc.canada.css.mot.com with Internet Mail Service (5.5.2654.52) id ; Fri, 16 Nov 2001 13:29:28 -0500 Message-ID: <28F1A76E98BDD31189A1009027DE31CF02619EDF@ont14a-bdc.canada.css.mot.com> From: Hughes John-CJH023 To: "'Hesham Soliman (ERA)'" , Hughes John-CJH023 , "'Margaret Wasserman'" , ipng@sunroof.eng.sun.com Subject: RE: draft-wasserman-3gpp-advice-00.txt Date: Fri, 16 Nov 2001 13:29:28 -0500 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 Hesham, Thanks for the response. I will address just one of the points you made as it seems to be the most important in relation to this draft: => Actually it seems to me that the solution in the draft is a lot simpler than the one in the current 3GPP specs, but I might have missed something that concerned you ? I agree. The solution in the draft is simpler however at the expense of what I view as being a wasteful implementation. The draft proposes /64 being allocated to each mobile device at a minimum and problably multiple /64s. This would be perfectly acceptable if each mobile device was a mobile router supporting mobile subnets - but in 3GPP that is not the case, a mobile device is a host and in many cases the hosts may have very basic functionalities. The working group should provide guidance on whether such a solution is something they are comfortable with being recommended to 3GPP. Best Regards, John -----Original Message----- From: Hesham Soliman (ERA) [mailto:hesham.soliman@era.ericsson.se] Sent: Thursday, November 15, 2001 2:36 AM To: 'Hughes John-CJH023'; 'Margaret Wasserman'; ipng@sunroof.eng.sun.com Subject: RE: draft-wasserman-3gpp-advice-00.txt I have read your draft and have a few questions/comments which you may wish to address before forwarding the document to 3GPP. In the draft, three recommendations are made: > 1. Specify that multiple prefixes may be assigned to each > primary PDP context, > > 2. Require that a given prefix must not be assigned to more > than one primary PDP context, and > > 3. Allow 3GPP nodes to use multiple identifiers within those > prefixes, including randomly generated identifiers. The draft then points out that implementing these recommendations will bring the following benefits: > Laptops that connect to 3GPP handsets will work without any > software changes. Their implementation of standard IPv6 over > PPP, address assignment, and autoconfiguration mechanisms > will work without any modification. This will eliminate the > need for vendors and operators to build and test special 3GPP > drivers and related software. It would be helpful if you could show where these incompatibilities lie ? Are these incompatibilities related to PPPv6 or application implementations ? => Some of the incompatibilities are: - An IPv6 host can have multiple addresses of various scopes assigned to a single interface. The current 3GPP addressing solutions do not allow this. - An IPv6 host can generate many interface ids based on one or more prefixes received in the RA. The current 3GPP addressing solutions do not allow this either. I believe the 3GPP implementation has been designed to work with standard implementations of PPPv6 (between the MT and TE i.e. between a handset and laptop), so if there are problems it would be good to see them stated explicitly. => Another (perhaps not a critical issue to 3GPP right now) is what happens if the link between the TE and MT is not PPP. The solution proposed by the draft allows for this to work. > IPv6 software implementations could be used in 3GPP handsets > without any modifications to the IPv6 protocol mechanisms. > This will make it easier to build and test 3GPP handsets. Is this really an issue. The IPv6 stack will have to be integrated into the UE in any case and therefore some degree of engineering effort will be required. Will implementation of IPv6 in a 3G UE be much more difficult than in say other small devices (PDAs) as a result of 3GPP design decisions. => Sure there are integration issues but the less changes, the better. Also one important issue here is that following the way things are defined in IETF will allow 3GPP to be compatible with future proposals on IPv6 (within IETF). For instance, when IPv6 addressing was first considered in 3GPP, privacy issues may not have come up in IETF, but when they did, the proposed solution was made to work with the existing IETF standards. Evidently it (RFC 3041) doesn't work with the existing 3GPP standard. So it's good to follow the same model as IETF to allow for smooth integration of future features. Of course this is provided that the IETF model meets the 3GPP requirements. In this case I believe it does. > Applications in 3GPP handsets will be able to take advantage > of different types of IPv6 addresses (e.g., static addresses, > temporary addresses for privacy, site-scoped addresses for > site only communication, etc.) Site-scoped addresses are not prevented in 3GPP, the prefix assigned at context activation may be limited to site scope. => Yes but you can't assign both Site-local and Global. I suspect most 3GPP handsets will require global addresses too. Unless people will only talk to other subscribers of the same operator :) Another important issue here is renumbering. To be able to have a smooth renumbering mechanism you need to allow for advertising 2 prefixes at least. > The GPRS system will be better positioned to take advantage of > new IPv6 features that are built around the current addressing > architecture. Again this needs to be expanded upon. While it is important to ensure the specs do not prevent future enhancement, the benefits need to be weighed against any increased complexity. => Actually it seems to me that the solution in the draft is a lot simpler than the one in the current 3GPP specs, but I might have missed something that concerned you ? The draft also lists two problems with the current 3GPP specs: > The GGSN only advertises a single /64 prefix, rather than a > set of prefixes. This will prevent the participation of 3GPP > nodes (e.g. handsets or 3GPP-attached laptops) in IPv6 site > renumbering, or in other mechanisms that expect IPv6 hosts to > create addresses based on multiple advertised prefixes. I do not see how site renumbering is an issue. When site renumbering takes place (i.e. the operator switches to a new ISP hence causing all address prefixes to change), the change must take place over a period of time where both the old and new addresses are supported. In 3GPP, all new PDP contexts will be assigned new addresses. If PDP contexts need to be deactivated by the network in order to force an address to be renewed, then that is also supported. => Interesting point. But since site renumbering will affect several parts of the network (DNS, DHCP (if exists), filters, policies...etc) there is certainly room for error there. So I think it's wise to allow both prefixes for some time. Switching things on and off does not seem to be very flexible. Consider the case where something goes wrong. I think the down time for the network will be significant here. 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 Tue Nov 20 01:14:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAK9EULS000224 for ; Tue, 20 Nov 2001 01:14:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAK9EUs3000223 for ipng-dist; Tue, 20 Nov 2001 01: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAK9EQLS000215 for ; Tue, 20 Nov 2001 01:14:26 -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 BAA14026 for ; Tue, 20 Nov 2001 01:14:06 -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 BAA04314 for ; Tue, 20 Nov 2001 01:14:25 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fAK9ENt00951 for ; Tue, 20 Nov 2001 11:14:24 +0200 Date: Tue, 20 Nov 2001 11:14:23 +0200 (EET) From: Pekka Savola To: Subject: Re: I-D ACTION:draft-huitema-ipngwg-dialondemand-00.txt In-Reply-To: <200111191330.IAA27039@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 Mon, 19 Nov 2001 Internet-Drafts@ietf.org wrote: > In an IPv6 home network, there is a possibility that the residential > gateway, learns a different IPv6 prefix after each dial-up; attempts > to communicate using old address would thus fail. This implies that > we should not attempt to trigger dial-up by simply sending the first > packet of a connection. Just read this quickly.. I may have missed something, but why exactly is this necessary? It seems way too complex to me. Also, it is unclear why there would be a need for new ICMP types; why Echos wouldn't be enough? All in all, dialups (especially for whole subnets) might be getting rarer in the years to come. Wouldn't it just be sufficient that when a dial-up link goes down, the router advertises default router lifetime=0. Hosts have no longer a default route, and all packets they send will be assumed to be on-link. Router can see these on-link messages (or rather, neighbour discovery attempts for foreign addresses like the DNS server), and decide to open the dial-up link based on some heuristics. Then router would advertise the default route and new addresses, which would immediately be used for re-trying DNS queries and the real communications. If link is brought up and down quickly so that the prefix changes, ingress filtering could prevent old addresses from being used. (there are probably some bugs in my above thinking, but it was just a rough idea..) -- 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 Nov 20 10:18:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKIIlLS001853 for ; Tue, 20 Nov 2001 10:18:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAKIIlbf001852 for ipng-dist; Tue, 20 Nov 2001 10: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAKIIhLS001845 for ; Tue, 20 Nov 2001 10:18: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 KAA15764 for ; Tue, 20 Nov 2001 10:18:46 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22983 for ; Tue, 20 Nov 2001 10:18:45 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fAKIIj526226 for ; Tue, 20 Nov 2001 10:18:45 -0800 (PST) Message-ID: <012601c171ef$90e08440$0e02320a@T23KEMPF> From: "James Kempf" To: Subject: draft-kempf-ipng-netaccess-threats-00.txt Date: Tue, 20 Nov 2001 10:17:08 -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 submitted draft-kempf-ipng-netaccess-threats-00.txt last week on Tues. but got email from odin.isi.edu on Wed. that the mail had been delayed, so I am not sure whether it got in on time. The actual email from the Internet Drafts saying it was received arrived on Thurs. I have not seen an announcement of the draft yet. In any event, I put the draft on my Geocities web site. Here is the URL: http://www.geocities.com/kempf42/draft-kempf-ipng-netaccess-threats-00.t xt I still hope we can get some discussion prior to the meeting. 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 Nov 20 16:55:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL0tXLS004174 for ; Tue, 20 Nov 2001 16:55:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAL0tXiV004173 for ipng-dist; Tue, 20 Nov 2001 16:55: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL0tTLS004166 for ; Tue, 20 Nov 2001 16:55:29 -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 QAA09402 for ; Tue, 20 Nov 2001 16:55:10 -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 QAA09118 for ; Tue, 20 Nov 2001 16:55:30 -0800 (PST) Received: (qmail 17643 invoked from network); 21 Nov 2001 00:55:29 -0000 Received: from unknown (HELO localhost) (133.243.254.217) by tkd.att.ne.jp with SMTP; 21 Nov 2001 00:55:29 -0000 Date: Wed, 21 Nov 2001 09:54:52 +0900 (JST) Message-Id: <20011121.095452.104029825.nov@tahi.org> To: pekkas@netcore.fi Cc: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-00.txt From: OKABE Nobuo In-Reply-To: References: <20011119.151647.71085363.nov@tahi.org> 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: I-D ACTION:draft-okabe-ipv6-lcna-minreq-00.txt Date: Mon, 19 Nov 2001 09:15:09 +0200 (EET) > > > > As the always-on network is becoming popular, lots of nodes, not > > > > only ordinary PCs but also various information appliances such as > > > > sensors, home appliances, AV equipments, are to be connected to the > > > > Internet. > > > Note: there isn't much discussion on certain MIPv6-mandated subjects, like > > > Home Address Option processing. One will have to clarify this; however > > > MIPv6 is under much discussion as right now so the situation could change. > > > > A kind of munimum host should not have mobility. > > It means the host does not have to implement MIP6 related functions. > > This is the reason why this draft does not mandate MIP6. > > Certain aspects of MIPv6 are, as currently being specified, a *MUST* for > *EVERY* IPv6 node, whether it is mobile or stationary. An example of this > is the processing of Home Address Option. There are more. It is possible > that this will change, but to which direction, it's difficult to say. "a *MUST* for *EVERY* IPv6 node" is very strong requirement. LCNA also will have to process Home Address Option if the above requirement is a consensus of IPNG (or IPNG and Mobileip?). Have the consensus already been reached? We also have to examine impacts on LCNA's specification, code size or so when enabling to process Home Address Option. > > > I think it's very safe to assume that IPv6 space the > > > application seems is fully global without NAT's or anything. > > > > How long time-frame do you assume? > > Your assumption may not work if someone want to develop > > a LCNA for "right-now" business. > > Note that I said IPv6 space is fully global without [IPv6] NAT's. Sorry, I did not intend to say so. I agree with you. > That is, as long as the other node is speaking native IPv6, there will be > no problems wrt. IPSEC. How the other node gets this IPv6 connectivity is > irrelevant, be it behind IPv4 NAT (e.g. via Shipworm), 6to4 or whatever. > > > > Further, I'm not sure whether there actually much need to be able to use > > > IPSEC (or any connections) past the translator. A picture: > > > > > > Internet --- ISP router --- Home Router --- LCNA box > > > > > > The translation happens either in Internet, ISP router or Home Router. > > > The primary target of the services are home users, that is, those that > > > would never need translation or are pretty safe anyway. > > > > Please let me clarify the point. > > Do you mean that almost communication happens between LCNAs > > behind the home router? > > Yes, I believe this is the case. In this kind of closed network, IPSEC is > not a *huge* problem. > > There are arguably some uses for to be able to access LCNA boxes from the > Internet, but you could mandate that pure IPv6 without translation is used > there, so that IPSEC would non-problematic. > > See below. > > > > If someone would like to use LCNA from the Internet, I'd suggest mandating > > > IPv6; we cannot be held hostage by legacy IPv4/NAT (plus how these affect > > > IPSEC) issues. > > > Therefore I think it might be safe to assume there are no unsurmountable > > > problems w.r.t. IPSEC use. > > > > It is important for people who thinks LCNAs as a business seriousely > > to work with legacy network. How should we deal with it? > > Let me try to clarify this. > > In real world, the scenario would currently or in the near future be > something like this: > > (sorry for shoddy User A&B&C, ran out of space :-) > > .- Home User 1 (IPv4) > IPv4/IPv6 / > Internet --- ISP router --- Home Router --- LCNA box (IPv6) > | | \ \ > User A B C '- Home User 2 (IPv6) > IPv4/6 4 v6 > > (IPv6 connectivity can be native, 6to4, Shipworm from behind IPv4 NAT's, > whatever, as long as it exists. > > If Home User 2 wants to access LCNA, it works without problems, with or > without IPSEC. > > If Home User 1 wants to access LCNA, translation will be required. > Translation would kill IPSEC, but as Home User 1 is in a "secure" > environment" this is not a problem. Only problem is that the translation > MUST occur in the Home Router, not upstream. > > If User A from the Internet wants to access LCNA, IPv6 can be used and > IPSEC can be used. > > If User B from the Internet wants to access LCNA, IPv4 would have to be > used, but the packet would have to translated, and IPSEC would not be > guaranteed. This scenario will not work because any user from Internet > cannot be trusted without IPSEC or similar precautions. > > If User C from the Internet wants to access LCNA, IPv6 can be used and > IPSEC can also be used fine. Thank you for your clarification. That is very usefull for us. > So, the only issues I see are: > - translation would have to occur within the secure domain, that is, home > router. Translation is required only if we want to allow access from home > IPv4-only nodes. It depends upon the specification of the home router. But the discussion of home route is out of our scope. So I would like to push it aside or another discussion. > - IPv4-only nodes from the Internet cannot access LCNA. As we're talking > about an _IPv6_ LCNA, I believe this is a reasonable assumption. It's > rather easy to get IPv6 access if you really want. This might be an issue of LCNA deployment. But it is out of the draft's scope. so, I agree. 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 Wed Nov 21 01:06:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL96ZLS005373 for ; Wed, 21 Nov 2001 01:06:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAL96Zn8005372 for ipng-dist; Wed, 21 Nov 2001 01:06: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAL96VLS005365 for ; Wed, 21 Nov 2001 01:06:31 -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 BAA07349 for ; Wed, 21 Nov 2001 01:06:10 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA01619 for ; Wed, 21 Nov 2001 02:06:12 -0700 (MST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fAL96Sf11347; Wed, 21 Nov 2001 10:06:28 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id fAL96Rh27108; Wed, 21 Nov 2001 11:06:27 +0200 (EET) Message-ID: <3BFB6E93.4AC97FFA@lmf.ericsson.se> Date: Wed, 21 Nov 2001 11:06:27 +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: OKABE Nobuo CC: pekkas@netcore.fi, ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-okabe-ipv6-lcna-minreq-00.txt References: <20011119.151647.71085363.nov@tahi.org> <20011121.095452.104029825.nov@tahi.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >"a *MUST* for *EVERY* IPv6 node" is very strong requirement. > >LCNA also will have to process Home Address Option >if the above requirement is a consensus of IPNG (or IPNG and Mobileip?). >Have the consensus already been reached? I think the situation is that the HOA has been stable and there has been consensus, but recent discussions and drafts have cast some doubt on the issue. I would say the fate of the HOA is currently unclear and there is no consensus. I think the possible outcomes are (1) we decide the HOA is good and should stay as it is, (2) we decide the HOA can be used, but only in the context of doing Route Optimization (which would make the HOA optional in IPv6), and (3) we decide to use something else than HOAs, such as some tunneling scheme. For further information, see http://search.ietf.org/internet-drafts/draft-nordmark-mobileip-mipv6-hindsight-00.txt http://search.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-00.txt http://search.ietf.org/internet-drafts/draft-arkko-mipv6ro-secframework-00.txt 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 Nov 22 22:30:28 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN6USLS001176 for ; Thu, 22 Nov 2001 22:30:28 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAN6USe0001175 for ipng-dist; Thu, 22 Nov 2001 22: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN6UOLS001168 for ; Thu, 22 Nov 2001 22:30: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 WAA08612 for ; Thu, 22 Nov 2001 22:30:25 -0800 (PST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by saturn.sun.com (8.9.3+Sun/8.9.3) with SMTP id WAA07689 for ; Thu, 22 Nov 2001 22:30:24 -0800 (PST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA25604; Fri, 23 Nov 2001 01:30:21 -0500 Date: Fri, 23 Nov 2001 01:30:21 -0500 (EST) From: Jim Bound To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-wasserman-3gpp-advice-00.txt In-Reply-To: <4.2.2.20011113173604.01e329e0@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 Hi Margaret, Had time to read this spec in more detail. Very well written and good integration of IP with 3GPP details for recommendations. Design team should be proud of this spec and it is very useful to both the IP and 3GPP implementation communities which will overlap. I do think this should be working group item per all the health warnings in the spec that this is a **recommendation** but should be on BCP track not standards track is my feeling. Specific comments: 1. I support ALL recommendations of feature supports for IPv6 in handsets and UE's. It is imperative that the principle of a cohesive code base for IPv6 from non-3GPP implementation be useful and as bug for bug compatible with wireline IPv6 implementations. This will also permit 3GPP implementations to use expediently the future IPv6 extensions as they are developed and permit a better sharing of implementation and interoperability between IPv6 wireline services with 3GPP services. 2. On /64 I support this. 3GPP implementations should be able to suppo0rt /64 and IMO /128 if necessary not doing so is short sighted for 3GPP implementations. 3. I do not think we should spend time in the IPv6 WG discussing how, what, or why 3GPP should support our indirect IPv6 policies (e.g. Site Local, Privacy, Use Models) for IPv6. This will be counter productive for the working group and hold up forwarding a technical recommendation. The policy used and supported by the 3GPP standards process and implementation community is their business and not ous here in the IETF standards process. For individuals or social views here that have policy input for 3GPP please go directly to 3GPP with that input is my suggestion. This will permit us to wrap this up quickly and not spend years working on it in the IETF. I think we need to do same work for 3GPP2 in addition to 3GPP. I have no issue with the technical recommendations and they should be sent to 3GPP as soon as possible from this community. Again go BCP route not standards track. Good job and thanks /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 22 23:20:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN7K9LS001204 for ; Thu, 22 Nov 2001 23:20:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAN7K9Nf001203 for ipng-dist; Thu, 22 Nov 2001 23:20: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN7K5LS001196 for ; Thu, 22 Nov 2001 23:20: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 XAA12088 for ; Thu, 22 Nov 2001 23:19:44 -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 XAA22208 for ; Thu, 22 Nov 2001 23:20:06 -0800 (PST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fAN7K0m00762; Fri, 23 Nov 2001 09:20:01 +0200 Date: Fri, 23 Nov 2001 09:20:00 +0200 (EET) From: Pekka Savola To: James Kempf cc: Subject: Re: draft-kempf-ipng-netaccess-threats-00.txt In-Reply-To: <012601c171ef$90e08440$0e02320a@T23KEMPF> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 20 Nov 2001, James Kempf wrote: > I submitted draft-kempf-ipng-netaccess-threats-00.txt last week on Tues. > but got email from odin.isi.edu on Wed. that the mail had been delayed, > so I am not sure whether it got in on time. The actual email from the > Internet Drafts saying it was received arrived on Thurs. I have not seen > an announcement of the draft yet. > > In any event, I put the draft on my Geocities web site. Here is the URL: > > http://www.geocities.com/kempf42/draft-kempf-ipng-netaccess-threats-00.t > xt > > I still hope we can get some discussion prior to the meeting. I believe this is a very important document. As with IPv4 and ARP (e.g. gratuituous ARP), it may be that the most issues cannot be solved, at least without resorting to IPSEC. But that is perhaps not necessary -- in my book, it's good to identify problems even though no proper "solution" can be found. Comment on 3.3 Neighbor Solicitation/Advertisement Spoofing --8<-- An attacking node can cause packets for legitimate nodes, both hosts and routers, to be sent to some other link-layer address. This can be done by either sending a Neighbor Solicitation with a different source link-layer address option, or sending a Neighbor Advertisement with a different target link-layer address option. If the spoofed link-layer address is a valid one, as long as the attacker responds to the unicast Neighbor Solicitation messages sent as part of the Neighbor Unreachability Detection, packets will continue to be redirected. This is a redirect attack. [...] --8<-- Here, it could be elaborated that NS messages with different link-local source address should overwrite the cached one [RFC2461 7.2.3]; the mechanism on how this attack works may not be self-evident. Comment on 3.5 Bogus On-Link Prefix: --8<-- An attacking node can send a Router Advertisement message specifying that some prefix of arbitrary length is on-link. If a sending host thinks the prefix is on-link, it will never send a packet for that prefix to the router. Instead, the host will try to perform address resolution by sending Neighbor Solicitations, but the Neighbor Solicitations will not result in a response, denying service to the attacked host. This is a DoS attack. The attacker can use an arbitrary lifetime on the bogus prefix advertisement. If the lifetime is infinity, the sending host will be denied service until it loses the state in its prefix list e.g. by rebooting, or the same prefix is advertised with a zero lifetime. The attack could also be perpetrated selectively for packets destined to a particular prefix by using 128 bit prefixes, i.e. full addresses. This threat involves Router Advertisement messages. --8<-- It appears to me this is more than DoS. This could be extremely evil -- what prevents the attacker from listening to all on-link traffic and responding posivitely to Neighbour Solicitations? That way, it could act as a man-in-the-middle attacker for all destinations.. Scary.. Possible additional threat: - attacker assigns the subnet-router anycast address to itself. With various methods (like 3.3) it could capture the traffic meant to the address to itself. Depending whether the anycast address is used for e.g. selecting the exit router, or being contacted by outside parties wishing to talk to the router of the subnet. -- 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 Nov 23 00:02:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN82YLS001669 for ; Fri, 23 Nov 2001 00:02:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAN82Xt3001668 for ipng-dist; Fri, 23 Nov 2001 00: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN82ULS001661 for ; Fri, 23 Nov 2001 00: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 AAA10948 for ; Fri, 23 Nov 2001 00:02:29 -0800 (PST) Received: from internet-gateway2.zurich.ibm.com (internet-gateway2-x.zurich.ibm.com [195.212.119.243]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA19580 for ; Fri, 23 Nov 2001 01:02:47 -0700 (MST) Received: from collon.zurich.ibm.com (collon.zurich.ibm.com [9.4.16.143]) by internet-gateway2.zurich.ibm.com (AIX4.3/8.9.3/8.8.8) with SMTP id JAA09708; Fri, 23 Nov 2001 09:02:26 +0100 Received: from dhcp23-10.zurich.ibm.com by collon.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA75176 from ; Fri, 23 Nov 2001 09:02:24 +0100 Message-Id: <3BFE02B4.B23143EC@hursley.ibm.com> Date: Fri, 23 Nov 2001 09:03:00 +0100 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en,fr Mime-Version: 1.0 To: Jim Bound Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: draft-wasserman-3gpp-advice-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk JIm, First I agree with you technically. This is the right direction and matches the keep-it-simple approach that is needed. I'm not sure it should even be BCP. Effectively this is a liaison document to another organisation - I think we would normally publish it as Informational. Of course if 3GPP indicated that they want to cite it as a normative reference, we might reclassify it. So it is a good idea to write it in the style of a BCP, in any case. Brian Jim Bound wrote: > > Hi Margaret, > > Had time to read this spec in more detail. Very well written and good > integration of IP with 3GPP details for recommendations. Design team > should be proud of this spec and it is very useful to both the IP and 3GPP > implementation communities which will overlap. > > I do think this should be working group item per all the health warnings > in the spec that this is a **recommendation** but should be on BCP track > not standards track is my feeling. > > Specific comments: > > 1. I support ALL recommendations of feature supports for IPv6 in handsets > and UE's. It is imperative that the principle of a cohesive code base for > IPv6 from non-3GPP implementation be useful and as bug for bug compatible > with wireline IPv6 implementations. This will also permit 3GPP > implementations to use expediently the future IPv6 extensions as they are > developed and permit a better sharing of implementation and > interoperability between IPv6 wireline services with 3GPP services. > > 2. On /64 I support this. 3GPP implementations should be able to > suppo0rt /64 and IMO /128 if necessary not doing so is short sighted for > 3GPP implementations. > > 3. I do not think we should spend time in the IPv6 WG discussing how, > what, or why 3GPP should support our indirect IPv6 policies (e.g. Site > Local, Privacy, Use Models) for IPv6. This will be counter productive > for the working group and hold up forwarding a technical recommendation. > The policy used and supported by the 3GPP standards process and > implementation community is their business and not ous here in the IETF > standards process. For individuals or social views here that have policy > input for 3GPP please go directly to 3GPP with that input is my > suggestion. This will permit us to wrap this up quickly and not spend > years working on it in the IETF. > > I think we need to do same work for 3GPP2 in addition to 3GPP. > > I have no issue with the technical recommendations and they should be sent > to 3GPP as soon as possible from this community. > > Again go BCP route not standards track. > > Good job and thanks > > /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 23 01:54:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN9srLS002182 for ; Fri, 23 Nov 2001 01:54:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAN9sr5J002181 for ipng-dist; Fri, 23 Nov 2001 01:54: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAN9slLS002174 for ; Fri, 23 Nov 2001 01:54:48 -0800 (PST) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.10.2+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id fAN9sjq04727; Fri, 23 Nov 2001 10:54:45 +0100 (MET) Date: Fri, 23 Nov 2001 10:53:45 +0100 (CET) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: draft-kempf-ipng-netaccess-threats-00.txt To: Pekka Savola Cc: James Kempf , 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 > As with IPv4 and ARP (e.g. gratuituous ARP), it may be that the most > issues cannot be solved, at least without resorting to IPSEC. But that is > perhaps not necessary -- in my book, it's good to identify problems even > though no proper "solution" can be found. I think we have existence proof that IPsec pixie dust does't work well in practise... If somebody wants to build a network where anybody can walk up and connect yet want to limit the damage one "visitor" can do to another, it seems like assuming pre-configured IPsec SAs for the multicast addresses used by Neighbor Discovery is a non-starter. > Comment on 3.3 Neighbor Solicitation/Advertisement Spoofing > --8<-- > An attacking node can cause packets for legitimate nodes, both hosts > and routers, to be sent to some other link-layer address. This can > be done by either sending a Neighbor Solicitation with a different > source link-layer address option, or sending a Neighbor > Advertisement with a different target link-layer address option. > If the spoofed link-layer address is a valid one, as long as the > attacker responds to the unicast Neighbor Solicitation messages sent > as part of the Neighbor Unreachability Detection, packets will > continue to be redirected. This is a redirect attack. > [...] > --8<-- > Here, it could be elaborated that NS messages with different link-local > source address should overwrite the cached one [RFC2461 7.2.3]; the > mechanism on how this attack works may not be self-evident. OK. > Comment on 3.5 Bogus On-Link Prefix: > --8<-- > An attacking node can send a Router Advertisement message specifying > that some prefix of arbitrary length is on-link. If a sending host > thinks the prefix is on-link, it will never send a packet for that > prefix to the router. Instead, the host will try to perform address > resolution by sending Neighbor Solicitations, but the Neighbor > Solicitations will not result in a response, denying service to the > attacked host. This is a DoS attack. > > The attacker can use an arbitrary lifetime on the bogus prefix > advertisement. If the lifetime is infinity, the sending host will be > denied service until it loses the state in its prefix list e.g. by > rebooting, or the same prefix is advertised with a zero lifetime. > The attack could also be perpetrated selectively for packets > destined to a particular prefix by using 128 bit prefixes, i.e. full > addresses. > > This threat involves Router Advertisement messages. > --8<-- > > It appears to me this is more than DoS. This could be extremely evil -- > what prevents the attacker from listening to all on-link traffic and > responding posivitely to Neighbour Solicitations? That way, it could act > as a man-in-the-middle attacker for all destinations.. Scary.. I agree that this combined with NA spoofing can be used as a redirect attack. We should make that clear I think (but I'm a bit concerned about there being lots of possible combinations to mention in general.) > Possible additional threat: > > - attacker assigns the subnet-router anycast address to itself. With > various methods (like 3.3) it could capture the traffic meant to the > address to itself. Depending whether the anycast address is used for e.g. > selecting the exit router, or being contacted by outside parties wishing > to talk to the router of the subnet. For packets sent from the outside to the subnet anycast address one router at the endge of the subnet will receive it thus it will not be forwarded onto the link. So this is only an issue for subnet anycast packets sent from nodes on the link. Currently there is no protocol that does this I think but it makes sense adding the threat. 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 Fri Nov 23 03:49:40 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fANBndLS002439 for ; Fri, 23 Nov 2001 03:49:40 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fANBndRs002438 for ipng-dist; Fri, 23 Nov 2001 03:49: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fANBnaLS002431 for ; Fri, 23 Nov 2001 03:49:36 -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 DAA04196; Fri, 23 Nov 2001 03:49:35 -0800 (PST) Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id EAA20819; Fri, 23 Nov 2001 04:49:50 -0700 (MST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fANBnVf05432; Fri, 23 Nov 2001 12:49:31 +0100 (MET) Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.38.50]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id fANBnUh28358; Fri, 23 Nov 2001 13:49:30 +0200 (EET) Message-ID: <3BFE37CA.F4E27673@lmf.ericsson.se> Date: Fri, 23 Nov 2001 13:49:30 +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: Erik Nordmark , James Kempf CC: ipng@sunroof.eng.sun.com Subject: Re: draft-kempf-ipng-netaccess-threats-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >If somebody wants to build a network where anybody can walk up and connect >yet want to limit the damage one "visitor" can do to another, it seems >like assuming pre-configured IPsec SAs for the multicast addresses used >by Neighbor Discovery is a non-starter. Yes. (It could be a non-starter even if the network wasn't public.) Also, in your draft you write: >In addition, Neighbor Discovery and Address Autoconfiguration use a >few fixed multicast addresses plus a range of 4 billion "solicited >node" multicast addresses. A naive application of pre-configured >SAs would require pre-configuring an unmanagable number of SAs on >each host and router just in case a given solicited node multicast >address is used. Preconfigured SAs are impractical for securing such >a large potential address range. FYI: An old I-D dealing with the problems of preconfiguring SAs for IPv6 'infrastructure' messages can be found from the following URL. It includes a discussion of the kinds of attacks the IPv6 ND and other 'link' functionality has. http://www.arkko.com/publications/draft-arkko-manual-icmpv6-sas-00.txt 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 Fri Nov 23 07:24:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fANFO3LS002827 for ; Fri, 23 Nov 2001 07:24:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fANFO2Kr002826 for ipng-dist; Fri, 23 Nov 2001 07:24: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fANFNwLS002819 for ; Fri, 23 Nov 2001 07:23:58 -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 HAA21237 for ; Fri, 23 Nov 2001 07:23:58 -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 IAA10726 for ; Fri, 23 Nov 2001 08:23:40 -0700 (MST) Received: from kenawang ([192.168.1.76]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA02083; Fri, 23 Nov 2001 07:22:42 -0800 (PST) Message-Id: <4.2.2.20011123101909.01f14b40@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 23 Nov 2001 10:26:37 -0500 To: Jim Bound From: Margaret Wasserman Subject: Re: draft-wasserman-3gpp-advice-00.txt Cc: ipng@sunroof.eng.sun.com In-Reply-To: References: <4.2.2.20011113173604.01e329e0@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, Thanks for your support. >I do think this should be working group item per all the health warnings >in the spec that this is a **recommendation** but should be on BCP track >not standards track is my feeling. The design team has discussed this, and we think that this document should be published as an informational RFC. It is important that this be published as an RFC, so that it can live longer than six months, but the document itself does not contain any standards or practices -- just informational recommendations to another standards body. >3. I do not think we should spend time in the IPv6 WG discussing how, >what, or why 3GPP should support our indirect IPv6 policies (e.g. Site >Local, Privacy, Use Models) for IPv6. This will be counter productive >for the working group and hold up forwarding a technical recommendation. I agree that we should not make any specific recommendations regarding 3GPP supporting these things. However, the 3GPP standards should allow laptops that do support these things to be attached via 3GPP handsets. As the 3GPP standards exist today, a laptop that uses privacy addresses for web connections may not be able to access the web when attached via a 3GPP handset. We tried to make this distinction clear in the document, but it may not be clear enough. 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 Nov 26 15:11:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNB53d002668 for ; Mon, 26 Nov 2001 15:11:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQN5oug001952 for ipng-dist; Mon, 26 Nov 2001 15: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN3u3f001409 for ; Mon, 26 Nov 2001 15:05:13 -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 IAA26250 for ; Sun, 25 Nov 2001 08:10:53 -0800 (PST) Received: from marduk.litech.org (marduk.cs.cornell.edu [128.84.154.54]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA00369 for ; Sun, 25 Nov 2001 08:11:15 -0800 (PST) Received: from lutchann by marduk.litech.org with local (Exim 3.22 #1) id 1681sA-00008R-00 for ipng@sunroof.eng.sun.com; Sun, 25 Nov 2001 11:11:14 -0500 Date: Sun, 25 Nov 2001 11:11:14 -0500 From: Nathan Lutchansky To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-huitema-ipngwg-dialondemand-00.txt Message-ID: <20011125111114.A30248@litech.org> References: <200111191330.IAA27039@ietf.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="AhhlLboLdkugWU4S" Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200111191330.IAA27039@ietf.org>; from Internet-Drafts@ietf.org on Mon, Nov 19, 2001 at 08:30:33AM -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 19, 2001 at 08:30:33AM -0500, Internet-Drafts@ietf.org wrote: >=20 > Title : IPv6 Dial-up on Demand I don't think it's a good idea to rely on ICMP replies from a remote host, considering how many sites filter even ICMP echos right now. A feature such as this should not require support from hosts outside the site. Why not require the border router to reply to these messages, with either a "connectivity OK" reply or a "wait for dialup" reply? The "wait for=20 dialup" reply could contain useful information like "expect a connection=20 in 30 seconds" or "dialup disallowed". This draft is worthwhile since dial-on-demand functionality would benefit from coordination between hosts within a site and the dialup router, but it would be unnecessary for hosts outside the site to take part. -Nathan --=20 +-------------------+---------------------+------------------------+ | 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 | +------------------------------------------------------------------+ --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8ARgiTviDkW8mhycRAoDcAKCcnM0RujnqcGXdSo+MO90JCXGgsQCdH9fk 1jId1tX1S/VDv/bLxiWkI9s= =dGKs -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 26 15:11:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNB53f002668 for ; Mon, 26 Nov 2001 15:11:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQN1w3b000815 for ipng-dist; Mon, 26 Nov 2001 15: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN0u1Z000527 for ; Mon, 26 Nov 2001 15:00:58 -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 IAA25934 for ; Mon, 26 Nov 2001 08:58:27 -0800 (PST) Received: from ns0.fh-sbg.ac.at (ns01.fh-sbg.ac.at [193.170.110.16]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA19034 for ; Mon, 26 Nov 2001 08:58:25 -0800 (PST) Received: from mx0.int.fh-sbg.ac.at (mx0.fh-sbg.ac.at [193.170.110.3]) by ns0.fh-sbg.ac.at (8.11.3/8.11.3) with ESMTP id fAQGlhM11098 for ; Mon, 26 Nov 2001 17:47:43 +0100 (CET) Received: from fh-sbg.ac.at (schamane.int.fh-sbg.ac.at [192.168.2.171]) by mx0.int.fh-sbg.ac.at (8.9.3/8.9.3) with ESMTP id RAA25015 for ; Mon, 26 Nov 2001 17:58:13 +0100 (MET) Message-ID: <3C0274A5.5DFAF665@fh-sbg.ac.at> Date: Mon, 26 Nov 2001 17:58:13 +0100 From: Werner Pomwenger X-Mailer: Mozilla 4.78 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: ipv6 & wlan Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk some newbie questions: has anybody an idea if ipv6 over ipv4 tunneling works with normal access points and in this context mobile ipv6 ? when packets are encapsulated in ipv4 it should.... theoretically. what about firewalls ? when tunneling ipv6 packets in an encapsulated ipv4 there should not be a problem, right ? maybe anybody has already some experience with wlan and ipv6. advice would be much appreciated cheers, werny -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 26 15:11:37 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNB53l002668 for ; Mon, 26 Nov 2001 15:11:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQN3J0p001223 for ipng-dist; Mon, 26 Nov 2001 15:03: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN0u4Y000527 for ; Mon, 26 Nov 2001 15:02:48 -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 LAA25547 for ; Sat, 24 Nov 2001 11:24:06 -0800 (PST) Received: from ws130.nomadiclab.com (ws130.nomadiclab.com [195.165.196.130]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA15206 for ; Sat, 24 Nov 2001 11:24:05 -0800 (PST) Received: from ws34.nomadiclab.com (ws34.nomadiclab.com [195.165.196.34]) by ws130.nomadiclab.com (Postfix) with ESMTP id 24E1274403; Sat, 24 Nov 2001 21:29:06 +0200 (EET) Received: from nomadiclab.com (localhost [127.0.0.1]) by ws34.nomadiclab.com (Postfix) with ESMTP id 0C6ECBA21; Sat, 24 Nov 2001 21:23:46 +0200 (EET) Message-ID: <3BFFF3BF.90909@nomadiclab.com> Date: Sat, 24 Nov 2001 21:23:43 +0200 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:0.9.6) Gecko/20011120 X-Accept-Language: en-us MIME-Version: 1.0 To: Jari Arkko Cc: Erik Nordmark , James Kempf , ipng@sunroof.eng.sun.com Subject: Re: draft-kempf-ipng-netaccess-threats-00.txt References: <3BFE37CA.F4E27673@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>If somebody wants to build a network where anybody can walk up and connect >>yet want to limit the damage one "visitor" can do to another, it seems >>like assuming pre-configured IPsec SAs for the multicast addresses used >>by Neighbor Discovery is a non-starter. I completely argree. You may also want to have a look at my Cambridge Security Protocols Workshop 2001 paper. 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. http://www.tml.hut.fi/~pnr/publications/cam2001.pdf --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 Mon Nov 26 15:11:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNB53j002668 for ; Mon, 26 Nov 2001 15:11:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQN2Uel000954 for ipng-dist; Mon, 26 Nov 2001 15:02: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN0u2d000527 for ; Mon, 26 Nov 2001 15:01:52 -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 DAA19945 for ; Mon, 26 Nov 2001 03:53:25 -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 DAA21074 for ; Mon, 26 Nov 2001 03: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 fAQBs5A19068 for ; Mon, 26 Nov 2001 13:54:05 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 26 Nov 2001 13:53:23 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Mon, 26 Nov 2001 13:53:21 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BC2C@esebe004.NOE.Nokia.com> To: mrw@windriver.com Cc: ipng@sunroof.eng.sun.com Subject: Quick comments on draft-wasserman-3gpp-advice-00.txt Date: Mon, 26 Nov 2001 13:53:11 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I have some very general comments on the document. They are mostly editorial / layout type of comments. It seems that there are 3 main recommendations made in the document: 1. Specify that multiple prefixes may be assigned to each primary PDP context, 2. Require that a given prefix must not be assigned to more than one primary PDP context, and 3. Allow 3GPP nodes to use multiple identifiers within those prefixes, including randomly generated identifiers. It might be useful for each recommendation to have some subsections such as: - Pros - Cons - Impact upon architecture / implementation I think that by more clearly listing what advantages & disadvantages the recommendations bring, it will be easier to address the recommendations (no pun intended). The 3rd bullet (Impact ...) is a purely practical point - as some service providers / manufacturers may be dis-inclined to support the changes unless they are relatively modest. Additionally, if the changes are minor, it might be possible for service providers to update their networks ... I do think you have most all of the text currently in the document, but a slight reformating would help to bring out the issues. 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 Nov 26 15:11:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNB53V002668 for ; Mon, 26 Nov 2001 15:11:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQN2N0l000918 for ipng-dist; Mon, 26 Nov 2001 15: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN0U30000424 for ; Mon, 26 Nov 2001 15:01:17 -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 DAA14656 for ; Mon, 26 Nov 2001 03:17:28 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA08085 for ; Mon, 26 Nov 2001 04:17:10 -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 GAA19433; Mon, 26 Nov 2001 06:17:25 -0500 (EST) Message-Id: <200111261117.GAA19433@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-kempf-ipng-netaccess-threats-00.txt Date: Mon, 26 Nov 2001 06:17:25 -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 : Threat Analysis for IPv6 Public Multi-Access Links Author(s) : J. Kempf, E. Nordmark Filename : draft-kempf-ipng-netaccess-threats-00.txt Pages : 7 Date : 21-Nov-01 The Mobile IP Working Group has been conducting a threat analysis for the purpose of securing specific Mobile IPv6 mechanisms. In the process of conducting the analysis, threats were identified that are not specific to Mobile IP but that are amplified by the nature of mobility. These threats are likely to be more or less of an issue within any Public Multi-Access network, regardless of whether mobility is involved. This document discusses threats associated with Public Multi-Access links in IPv6. The document covers non- Mobile IP specific threats uncovered by the Mobile IPv6 study, threats raised in the IPv6 Neighbor Discovery and Stateless Address Autoconfiguration RFCs that have yet to be adequately addressed, and new threats that have not previously been identified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-kempf-ipng-netaccess-threats-00.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-kempf-ipng-netaccess-threats-00.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-kempf-ipng-netaccess-threats-00.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: <20011121141727.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-kempf-ipng-netaccess-threats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-kempf-ipng-netaccess-threats-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011121141727.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 Mon Nov 26 15:11:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNB53b002668 for ; Mon, 26 Nov 2001 15:11:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQN1wh3000812 for ipng-dist; Mon, 26 Nov 2001 15: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQN0u1b000527 for ; Mon, 26 Nov 2001 15:01:00 -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 JAA28182 for ; Mon, 26 Nov 2001 09:08:24 -0800 (PST) Received: from ebene.inrialpes.fr (ebene.inrialpes.fr [194.199.18.70]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13817; Mon, 26 Nov 2001 10:07:28 -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 fAQH3Ki26741; Mon, 26 Nov 2001 18:03:20 +0100 (MET) Message-ID: <3C0275D9.484A2A4@inrialpes.fr> Date: Mon, 26 Nov 2001 18:03:21 +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: msec@securemulticast.org, ipng@sunroof.eng.sun.com, smug@cs.umass.edu, gab@sun.com Subject: Securing Group Management in IPv6 Content-Type: multipart/alternative; boundary="------------BD75A96D98BC6F2A58B220B2" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --------------BD75A96D98BC6F2A58B220B2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, We have just released a new draft entitled "Securing Group Management in IPv6". Unfortunatly we've missed the IETF submission deadline but we'll submit it asap. This draft can be downloaded at: http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-sgmv6-00.txt We are looking forward your comments/feedbacks.... Thanks in advance... Regards, Claude. ====== Abstract Currently, group membership management in IP multicast and anycast lacks sufficient security. It can be abused by malicious hosts in order to launch denial-of-service (DoS) attacks. The root of the problem is that routers cannot determine if a given host is authorized to join a group, sometimes referred to as the Proof-of-Membership Problem We propose a solution for IPv6 based on new types of multicast and anycast group addresses which we respectively call SUCV-M and SUCV-A addresses. Their statistical and cryptographic characteristics lend themselves to severely limiting certain classes of attacks. Our scheme is fully distributed and does not require any third trusted party or pre-established security association between the routers and the hosts. This is not only a huge gain in terms of scalability, reliability and overhead, but also in terms of privacy. -- ---------------------------------------- Claude CASTELLUCCIA, INRIA Rhone-Alpes ph: +33 4.76.61.52.15 (fax: 52.52) http://www.inrialpes.fr/planete/ --------------BD75A96D98BC6F2A58B220B2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
Dear all,

We have just released a new draft  entitled "Securing Group Management in IPv6".
Unfortunatly we've missed the IETF submission deadline but we'll submit it
asap.

This draft can be downloaded at:
http://www.inrialpes.fr/planete/people/ccastel/draft-castelluccia-sgmv6-00.txt

We are looking forward your comments/feedbacks....

Thanks in advance...
Regards,
Claude.

======

  Abstract

   Currently, group membership management in IP multicast and
   anycast lacks sufficient security.  It can be abused by
   malicious hosts in order to launch denial-of-service (DoS)
   attacks.  The root of the problem is that routers cannot
   determine if a given host is authorized to join a group,
   sometimes referred to as the  Proof-of-Membership Problem
    We propose a solution for IPv6 based on new types of
   multicast and anycast group addresses which we respectively call
   SUCV-M and SUCV-A addresses. Their statistical and cryptographic
   characteristics lend themselves to severely limiting certain
   classes of attacks.  Our scheme is fully distributed and does
   not require any third trusted party or pre-established security
   association between the routers and the hosts.  This is not only
   a huge gain in terms of scalability, reliability and overhead,
   but also in terms of privacy. 

-- 

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes  
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/
  --------------BD75A96D98BC6F2A58B220B2-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 26 15:52:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNqs1V004439 for ; Mon, 26 Nov 2001 15:52:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQNqsqw004437 for ipng-dist; Mon, 26 Nov 2001 15:52: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNql1X004423 for ; Mon, 26 Nov 2001 15:52:47 -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 DAA19757 for ; Mon, 26 Nov 2001 03:14:24 -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 DAA07579 for ; Mon, 26 Nov 2001 03:14:23 -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 GAA18999; Mon, 26 Nov 2001 06:14:19 -0500 (EST) Message-Id: <200111261114.GAA18999@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-rfc2012-update-01.txt Date: Mon, 26 Nov 2001 06:14:18 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Management Information Base for the Transmission Control Protocol (TCP) Author(s) : B. Fenner et al. Filename : draft-ietf-ipngwg-rfc2012-update-01.txt Pages : 26 Date : 21-Nov-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Transmission Control Protocol (TCP) [5] in an IP version independent manner. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2012-update-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-ipngwg-rfc2012-update-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-ipngwg-rfc2012-update-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: <20011121141031.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2012-update-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2012-update-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011121141031.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 Mon Nov 26 15:52:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNqs1V004438 for ; Mon, 26 Nov 2001 15:52:54 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAQNqs4o004436 for ipng-dist; Mon, 26 Nov 2001 15:52: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAQNql1V004423 for ; Mon, 26 Nov 2001 15:52:47 -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 DAA19765 for ; Mon, 26 Nov 2001 03:14:30 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA06056 for ; Mon, 26 Nov 2001 04:14:12 -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 GAA19011; Mon, 26 Nov 2001 06:14:25 -0500 (EST) Message-Id: <200111261114.GAA19011@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-rfc2013-update-01.txt Date: Mon, 26 Nov 2001 06:14:24 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Management Information Base for the User Datagram Protocol (UDP) Author(s) : B. Fenner et al. Filename : draft-ietf-ipngwg-rfc2013-update-01.txt Pages : 22 Date : 21-Nov-01 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the User Datagram Protocol (UDP) [4] in an IP version independent manner A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2013-update-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-ipngwg-rfc2013-update-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-ipngwg-rfc2013-update-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: <20011121141043.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2013-update-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2013-update-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011121141043.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 Nov 27 06:37:51 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAREbo1V006321 for ; Tue, 27 Nov 2001 06:37:50 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAREboaV006320 for ipng-dist; Tue, 27 Nov 2001 06:37: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAREbl1V006313 for ; Tue, 27 Nov 2001 06:37:47 -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 GAA27882 for ; Tue, 27 Nov 2001 06:37:34 -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 HAA04106 for ; Tue, 27 Nov 2001 07:37:52 -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 fAREbBh03888; Tue, 27 Nov 2001 15:37: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 PAA13911; Tue, 27 Nov 2001 15:37:11 +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 fAREb7D49549; Tue, 27 Nov 2001 15:37:11 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200111271437.fAREb7D49549@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Werner Pomwenger cc: ipng@sunroof.eng.sun.com Subject: Re: ipv6 & wlan In-reply-to: Your message of Mon, 26 Nov 2001 17:58:13 +0100. <3C0274A5.5DFAF665@fh-sbg.ac.at> Date: Tue, 27 Nov 2001 15:37:07 +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: some newbie questions: has anybody an idea if ipv6 over ipv4 tunneling works with normal access => this works well points and in this context mobile ipv6 ? when packets are encapsulated in ipv4 it should.... theoretically. => in the context of mobility the best is to change the end of the IPv6 over IPv4 tunnel. This is transparent (i.e. you get mobility for free if you consider the whole IPv4 as a single IPv6 subnet). what about firewalls ? when tunneling ipv6 packets in an encapsulated ipv4 there should not be a problem, right ? => firewalls have the choice between: - to be fooled (the usual answer but this has some drawbacks) - to block everything (the stupid answer to the previous proposal) - to be smart, i.e. to inspect the IPv6 payload (of course the firewall has to support IPv6 too). maybe anybody has already some experience with wlan and ipv6. => IETF meetings use wireless LAN with a far from zero part in IPv6 without reported trouble. 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 Tue Nov 27 06:54:55 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAREst1V006472 for ; Tue, 27 Nov 2001 06:54:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAREssiw006471 for ipng-dist; Tue, 27 Nov 2001 06:54: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAREsp1V006464 for ; Tue, 27 Nov 2001 06:54:51 -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 GAA16280 for ; Tue, 27 Nov 2001 06:54:51 -0800 (PST) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA12142 for ; Tue, 27 Nov 2001 07:55:12 -0700 (MST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA25813 for ; Tue, 27 Nov 2001 07:54:49 -0700 (MST)] Received: [from il06exi01.CORP.MOT.COM (il06exi01.corp.mot.com [199.5.78.78]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id HAA09601 for ; Tue, 27 Nov 2001 07:44:58 -0700 (MST)] Received: by il06exi01.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Tue, 27 Nov 2001 08:54:48 -0600 Message-ID: From: Jung Cyndi-ACJ099 To: "'Francis Dupont'" , Werner Pomwenger Cc: ipng@sunroof.eng.sun.com Subject: RE: ipv6 & wlan Date: Tue, 27 Nov 2001 08:54:48 -0600 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 I have seen wlan systems having trouble with multicast and ipv6 nodes unable to receive RAs, resulting in no global prefix at the ipv6 node. But that was a couple of years ago, and the wlan APs are getting much better (and cheaper). However, that is a difference between IPv4 and IPv6 that might be overlooked by some wlan APs and NICs - that multicast is fundamental to IPv6 operation and still optional for IPv4. > > maybe anybody has already some experience with wlan and ipv6. > >=> IETF meetings use wireless LAN with a far from zero part in IPv6 >without reported trouble. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 27 07:04:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARF4D1V006507 for ; Tue, 27 Nov 2001 07:04:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARF4Dw1006506 for ipng-dist; Tue, 27 Nov 2001 07: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARF491V006499 for ; Tue, 27 Nov 2001 07:04:09 -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 HAA02128 for ; Tue, 27 Nov 2001 07:03:56 -0800 (PST) From: Martin.Stiemerling@ccrle.nec.de Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA09899 for ; Tue, 27 Nov 2001 08:03:55 -0700 (MST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id fARF3kk64206; Tue, 27 Nov 2001 16:03:46 +0100 (CET) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id C66E8C055; Tue, 27 Nov 2001 16:03:52 +0100 (CET) To: Jung Cyndi-ACJ099 Subject: RE: ipv6 & wlan Message-ID: <1006873432.3c03ab58b81c5@citadel.mobility.ccrle.nec.de> Date: Tue, 27 Nov 2001 16:03:52 +0100 (CET) Cc: Werner Pomwenger , ipng@sunroof.eng.sun.com References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.180 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk There is presently now trouble with wlan cards and multicast from Lucent and Cisco. These are the cards I use. Quoting Jung Cyndi-ACJ099 : > I have seen wlan systems having trouble with multicast and ipv6 nodes > unable to receive RAs, resulting in no global prefix at the ipv6 node. > But that was a couple of years ago, and the wlan APs are getting much > better (and cheaper). However, that is a difference between IPv4 and > IPv6 > that might be overlooked by some wlan APs and NICs - that multicast is > fundamental to IPv6 operation and still optional 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 Tue Nov 27 09:45:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARHjB1V007084 for ; Tue, 27 Nov 2001 09:45:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARHjBVA007083 for ipng-dist; Tue, 27 Nov 2001 09: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARHj81V007076 for ; Tue, 27 Nov 2001 09:45: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 JAA19176 for ; Tue, 27 Nov 2001 09:45:10 -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 KAA08609 for ; Tue, 27 Nov 2001 10:45:09 -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 JAA23877; Tue, 27 Nov 2001 09:45:09 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fARHj8X11250; Tue, 27 Nov 2001 09:45:08 -0800 X-mProtect: Tue, 27 Nov 2001 09:45:08 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdTuhhCZ; Tue, 27 Nov 2001 09:45:06 PST Message-Id: <4.3.2.7.2.20011127094142.024fa500@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 Nov 2001 09:44:45 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: REMINDER: Request for Agenda Items for Salt Lake City IPv6 Sessions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We are close to publishing a draft agenda for the Salt Lake City IPv6 meeting. If you forgot to request a slot previously, this would be a good time. Thanks, Bob >Date: Sun, 04 Nov 2001 21:59:18 -0800 >To: IPng List >From: Bob Hinden >Subject: Request for Agenda Items for Salt Lake City IPv6 Sessions >Cc: hinden@iprg.nokia.com, deering@cisco.com >Sender: owner-ipng@sunroof.eng.sun.com > >The IPv6 working group has been scheduled for two sessions at the Salt >Lake City IETF. They are: > > TUESDAY, December 11, 2001, 0900-1130 > THURSDAY, December 13, 2001, 0900-1130 > >Note that these date and times are tentative and subject to change by the >IETF secretariat. > >Please send us requests for agenda items. > >When we put together the agenda we plan to give priority to current >working group activities and documents, new individual submissions, and >last to status reports. > >Thanks, > >Bob Hinden / Steve Deering >IPv6 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 Tue Nov 27 09:54:03 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARHs31V007213 for ; Tue, 27 Nov 2001 09:54:03 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARHs33O007212 for ipng-dist; Tue, 27 Nov 2001 09:54: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARHrx1V007205 for ; Tue, 27 Nov 2001 09:53:59 -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 JAA03551 for ; Tue, 27 Nov 2001 09:54:01 -0800 (PST) Received: from mailout6-0.nyroc.rr.com (mailout6-0.nyroc.rr.com [24.92.226.125]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA06187 for ; Tue, 27 Nov 2001 10:53:44 -0700 (MST) Received: from LocalHost (cm-24-25-152-174.nycap.rr.com [24.25.152.174]) by mailout6-0.nyroc.rr.com (8.11.6/Road Runner 1.12) with SMTP id fARHrt615844; Tue, 27 Nov 2001 12:53:56 -0500 (EST) Message-ID: <00dc01c1776c$860607c0$0200a8c0@nycap.rr.com> From: "Patrick Nolan" To: "Werner Pomwenger" Cc: References: <3C0274A5.5DFAF665@fh-sbg.ac.at> Subject: Re: ipv6 & wlan Date: Tue, 27 Nov 2001 12:54:11 -0500 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 quoted-printable to 8bit by sunroof.eng.sun.com id fARHs01V007206 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Werner, > > what about firewalls ? when tunneling ipv6 packets in an encapsulated > ipv4 there should not be a problem, right ? Depends on the type/locationof the firewall. Not much specific firewall and IDS work is available that I've found, and I've looked hard. Any list pointers to info would be appreciated. After reading this: "Internet Connection Firewall Does Not Block Internet Protocol Version 6 Traffic" http://support.microsoft.com/support/kb/articles/q306/2/03.asp " I contacted MS for further info and received this: "Hi Patrick, Thanks for your note. I heard back from the devs and learned that if IPv6 is installed and the machine receives an IPv6 packet encapsulated in IPv4, then ICF WILL intercept the packet before it is handed to the IPv6 stack. I hope this answers your question sufficiently. If you have any other questions or concerns, don't hesitate to contact me. We appreciate your interest and feedback." So many questions are unanswered at this point. Pat -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 27 10:12:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARICn1V007387 for ; Tue, 27 Nov 2001 10:12:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARICntb007386 for ipng-dist; Tue, 27 Nov 2001 10: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 engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARICk1V007379 for ; Tue, 27 Nov 2001 10:12:46 -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 KAA28141 for ; Tue, 27 Nov 2001 10:12:46 -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 LAA22356 for ; Tue, 27 Nov 2001 11:13: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 fARICUh14311; Tue, 27 Nov 2001 19:12:30 +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 TAA21024; Tue, 27 Nov 2001 19:12:30 +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 fARICUD50905; Tue, 27 Nov 2001 19:12:30 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200111271812.fARICUD50905@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Martin.Stiemerling@ccrle.nec.de cc: Jung Cyndi-ACJ099 , Werner Pomwenger , ipng@sunroof.eng.sun.com Subject: Re: ipv6 & wlan In-reply-to: Your message of Tue, 27 Nov 2001 16:03:52 +0100. <1006873432.3c03ab58b81c5@citadel.mobility.ccrle.nec.de> Date: Tue, 27 Nov 2001 19:12:30 +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: There is presently now trouble with wlan cards and multicast from Lucent and ^^^ => I believe you mean "no" ? Cisco. These are the cards I use. > I have seen wlan systems having trouble with multicast and ipv6 nodes > unable to receive RAs, resulting in no global prefix at the ipv6 node. > But that was a couple of years ago, and the wlan APs are getting much > better (and cheaper). However, that is a difference between IPv4 and > IPv6 > that might be overlooked by some wlan APs and NICs - that multicast is > fundamental to IPv6 operation and still optional for IPv4. => I saw this some years ago but today multicast works well and equipments are 5 time cheaper. BTW I never got multicast problems at IETF, even using old Lucent WaveLANs (Digital RoamAbout lent by Matt Thomas). Does somebody know whether/which IEEE 802.11b cards will be available at Salt Lake City? 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 Nov 27 10:46:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARIkH1V007538 for ; Tue, 27 Nov 2001 10:46:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARIkHTG007537 for ipng-dist; Tue, 27 Nov 2001 10:46: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARIkA1V007522; Tue, 27 Nov 2001 10:46: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 KAA05022; Tue, 27 Nov 2001 10:45:46 -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 LAA23682; Tue, 27 Nov 2001 11:45:51 -0700 (MST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id fARIk7i19024; Tue, 27 Nov 2001 20:46:08 +0200 Date: Tue, 27 Nov 2001 20:46:07 +0200 (EET) From: Pekka Savola Reply-To: To: cc: Subject: I-D ACTION:draft-savola-ipv6-rh-ha-security-01.txt (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, Here's the revised edition of my draft on the security concerns of routing header and home address option. These could potentially concern *every* IPv6 node. Unless comments are very ipng related, I think most followups should go on mobile-ip. -- 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 ---------- Forwarded message ---------- Date: Tue, 27 Nov 2001 06:00:32 -0500 From: Internet-Drafts@ietf.org To: IETF-Announce: ; Subject: I-D ACTION:draft-savola-ipv6-rh-ha-security-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Security of IPv6 Routing Header and Home Address Options Author(s) : P. Savola Filename : draft-savola-ipv6-rh-ha-security-01.txt Pages : 17 Date : 26-Nov-01 All IPv6 nodes must be able to process Routing Header [IPV6] and Home Address [MIPV6] Options. With these, packet filter access lists can be tricked (among other things) as the destination and source addresses, respectively, are being rewritten as the packet traverses the network. Some of the security considerations of these features are analyzed, and a few possible solutions presented. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-ipv6-rh-ha-security-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-savola-ipv6-rh-ha-security-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-savola-ipv6-rh-ha-security-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. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 27 12:21:42 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARKLf1V007907 for ; Tue, 27 Nov 2001 12:21:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARKLfPK007906 for ipng-dist; Tue, 27 Nov 2001 12:21: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARKLc1V007899 for ; Tue, 27 Nov 2001 12:21: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 MAA13623 for ; Tue, 27 Nov 2001 12:21:39 -0800 (PST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by venus.sun.com (8.9.3+Sun/8.9.3) with SMTP id MAA14347 for ; Tue, 27 Nov 2001 12:21:38 -0800 (PST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA24947; Tue, 27 Nov 2001 15:21:29 -0500 Date: Tue, 27 Nov 2001 15:21:29 -0500 (EST) From: Jim Bound To: Brian E Carpenter Cc: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: draft-wasserman-3gpp-advice-00.txt In-Reply-To: <3BFE02B4.B23143EC@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, I see. Info or BCP all the same to me. But thanks for the edu. /jim On Fri, 23 Nov 2001, Brian E Carpenter wrote: > JIm, > > First I agree with you technically. This is the right direction and matches > the keep-it-simple approach that is needed. > > I'm not sure it should even be BCP. Effectively this is a liaison document > to another organisation - I think we would normally publish it as Informational. > Of course if 3GPP indicated that they want to cite it as a normative > reference, we might reclassify it. So it is a good idea to write it in > the style of a BCP, in any case. > > Brian > > Jim Bound wrote: > > > > Hi Margaret, > > > > Had time to read this spec in more detail. Very well written and good > > integration of IP with 3GPP details for recommendations. Design team > > should be proud of this spec and it is very useful to both the IP and 3GPP > > implementation communities which will overlap. > > > > I do think this should be working group item per all the health warnings > > in the spec that this is a **recommendation** but should be on BCP track > > not standards track is my feeling. > > > > Specific comments: > > > > 1. I support ALL recommendations of feature supports for IPv6 in handsets > > and UE's. It is imperative that the principle of a cohesive code base for > > IPv6 from non-3GPP implementation be useful and as bug for bug compatible > > with wireline IPv6 implementations. This will also permit 3GPP > > implementations to use expediently the future IPv6 extensions as they are > > developed and permit a better sharing of implementation and > > interoperability between IPv6 wireline services with 3GPP services. > > > > 2. On /64 I support this. 3GPP implementations should be able to > > suppo0rt /64 and IMO /128 if necessary not doing so is short sighted for > > 3GPP implementations. > > > > 3. I do not think we should spend time in the IPv6 WG discussing how, > > what, or why 3GPP should support our indirect IPv6 policies (e.g. Site > > Local, Privacy, Use Models) for IPv6. This will be counter productive > > for the working group and hold up forwarding a technical recommendation. > > The policy used and supported by the 3GPP standards process and > > implementation community is their business and not ous here in the IETF > > standards process. For individuals or social views here that have policy > > input for 3GPP please go directly to 3GPP with that input is my > > suggestion. This will permit us to wrap this up quickly and not spend > > years working on it in the IETF. > > > > I think we need to do same work for 3GPP2 in addition to 3GPP. > > > > I have no issue with the technical recommendations and they should be sent > > to 3GPP as soon as possible from this community. > > > > Again go BCP route not standards track. > > > > Good job and thanks > > > > /jim > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue Nov 27 12:23:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARKNU1V007924 for ; Tue, 27 Nov 2001 12:23:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARKNUVS007923 for ipng-dist; Tue, 27 Nov 2001 12: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARKNQ1V007916 for ; Tue, 27 Nov 2001 12:23: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 MAA06651 for ; Tue, 27 Nov 2001 12:23:24 -0800 (PST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA02176 for ; Tue, 27 Nov 2001 13:23:22 -0700 (MST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA24581; Tue, 27 Nov 2001 15:23:18 -0500 Date: Tue, 27 Nov 2001 15:23:18 -0500 (EST) From: Jim Bound To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: draft-wasserman-3gpp-advice-00.txt In-Reply-To: <4.2.2.20011123101909.01f14b40@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 Hi Margaret, ACK on RFC. On clarity. Yep that would help. thanks /jim On Fri, 23 Nov 2001, Margaret Wasserman wrote: > > Hi Jim, > > Thanks for your support. > > >I do think this should be working group item per all the health warnings > >in the spec that this is a **recommendation** but should be on BCP track > >not standards track is my feeling. > > The design team has discussed this, and we think that this document > should be published as an informational RFC. It is important that > this be published as an RFC, so that it can live longer than six months, > but the document itself does not contain any standards or practices -- > just informational recommendations to another standards body. > > >3. I do not think we should spend time in the IPv6 WG discussing how, > >what, or why 3GPP should support our indirect IPv6 policies (e.g. Site > >Local, Privacy, Use Models) for IPv6. This will be counter productive > >for the working group and hold up forwarding a technical recommendation. > > I agree that we should not make any specific recommendations regarding > 3GPP supporting these things. However, the 3GPP standards should allow > laptops that do support these things to be attached via 3GPP handsets. > As the 3GPP standards exist today, a laptop that uses privacy addresses > for web connections may not be able to access the web when attached via > a 3GPP handset. > > We tried to make this distinction clear in the document, but it may > not be clear enough. > > 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 Nov 27 12:29:39 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARKTd1V007969 for ; Tue, 27 Nov 2001 12:29:39 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARKTd04007968 for ipng-dist; Tue, 27 Nov 2001 12:29: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARKTZ1V007961 for ; Tue, 27 Nov 2001 12:29: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 MAA02456 for ; Tue, 27 Nov 2001 12:29:37 -0800 (PST) Received: from docomolabs-usa.com (fridge.docomo-usa.com [216.98.102.228]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA18451 for ; Tue, 27 Nov 2001 12:29:36 -0800 (PST) Received: from T23KEMPF (dhcp126.docomo-usa.com [172.21.96.126]) by docomolabs-usa.com (8.11.3/8.11.3) with SMTP id fARKTA526351; Tue, 27 Nov 2001 12:29:10 -0800 (PST) Message-ID: <023101c17781$f1f5f840$0e02320a@T23KEMPF> From: "James Kempf" To: "Pekka Nikander" , "Jari Arkko" Cc: "Erik Nordmark" , References: <3BFE37CA.F4E27673@lmf.ericsson.se> <3BFFF3BF.90909@nomadiclab.com> Subject: Re: draft-kempf-ipng-netaccess-threats-00.txt Date: Tue, 27 Nov 2001 12:27:33 -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/Jari, Thanx for the additional threats and the references. I will fold them into the document on the next revision. With regard to: >As with IPv4 and ARP (e.g. gratuituous ARP), it may be that the most >issues cannot be solved, at least without resorting to IPSEC. But that is >perhaps not necessary -- in my book, it's good to identify problems even >though no proper "solution" can be found. I sincerely hope that we can find an acceptable solution. Right now, the preferred solution seems to be to make the link look like a point-to-point link as much as possible because the access control problems associated with point to point links are well understood in public access networks. It would be a shame to have to propogate this forward, especially for wireless networks where multi-access links are likely to become more common. 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 Nov 27 12:33:53 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARKXq1V007986 for ; Tue, 27 Nov 2001 12:33:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fARKXqv0007985 for ipng-dist; Tue, 27 Nov 2001 12:33: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fARKXm1V007978 for ; Tue, 27 Nov 2001 12:33: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 MAA04898 for ; Tue, 27 Nov 2001 12:33:26 -0800 (PST) Received: from gate.alliedtelesyn.co.nz ([202.49.72.33]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with SMTP id NAA05290 for ; Tue, 27 Nov 2001 13:33:48 -0700 (MST) Received: (qmail 9289 invoked from network); 27 Nov 2001 21:11:56 -0000 Received: from aslan.alliedtelesyn.co.nz (HELO alliedtelesyn.co.nz) (202.49.74.92) by gate-int.alliedtelesyn.co.nz with SMTP; 27 Nov 2001 21:11:56 -0000 Received: from ASLAN/SpoolDir by alliedtelesyn.co.nz (Mercury 1.47); 28 Nov 01 09:33:12 +1300 Received: from SpoolDir by ASLAN (Mercury 1.47); 28 Nov 01 09:33:05 +1300 From: "Sean Lin" Organization: Allied Telesyn Research, Chch, NZ To: ipng@sunroof.eng.sun.com Date: Wed, 28 Nov 2001 09:33:00 +1300 (NZDST) MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: prefix lifetimes Reply-to: sean.lin@alliedtelesyn.co.nz Message-ID: <3C04AF43.1779.F463468@localhost> X-mailer: Pegasus Mail for Win32 (v3.12c) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, There's something I'm pondering about. If this has been discussed before please forgive my ignorance. In RFC2461 it mentions of the prefix list kept by routers. Prefixes can be added to this list with specified lifetimes. Do these prefixes have valid and preferred lifetimes that do not decrement or do they? So if a router has similar prefixes that it uses as interface addresses which its lifetime does decrement, wouldn't this be bad? Since the prefix lifetime stays the same and gets advertised. Or is the administrator suppose to prevent this from happening? 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 Tue Nov 27 20:48:57 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS4mv1V010280 for ; Tue, 27 Nov 2001 20:48:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAS4mvNX010279 for ipng-dist; Tue, 27 Nov 2001 20:48: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS4mr1V010272 for ; Tue, 27 Nov 2001 20:48:53 -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 UAA23553 for ; Tue, 27 Nov 2001 20:48:54 -0800 (PST) Received: from maze.mcdecom.net (maze.mcdecom.net [202.170.128.34]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id VAA03524 for ; Tue, 27 Nov 2001 21:48:34 -0700 (MST) Received: from mcdmhp.mcdecom.net by maze.mcdecom.net with ESMTP for ipng@sunroof.eng.sun.com; Wed, 28 Nov 2001 10:18:00 -0500 Received: from [172.16.2.26] by mcdmhp.mcdecom.net with ESMTP for ipng@sunroof.eng.sun.com; Wed, 28 Nov 2001 10:05:30 +0530 Received: from jagan [107.108.204.227] by ltitlblr.com [107.108.204.249] with SMTP (MDaemon.v3.0.2.R) for ; Tue, 27 Nov 2001 22:05:45 +0530 From: "Jagan" To: Subject: Hop Limit in IPv6 Hdr. Date: Wed, 28 Nov 2001 10:08:57 +0530 Message-Id: <001f01c177c6$984d5780$e3cc6c6b@jagan> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C177F4.B2059380" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Disposition-Notification-To: "Jagan" X-MDaemon-Deliver-To: ipng@sunroof.eng.sun.com X-Return-Path: jagan@ltitlblr.com X-MDRcpt-To: ipng@sunroof.eng.sun.com X-MDRemoteIP: 107.108.204.227 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C177F4.B2059380 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi all, I am new member to this group. Just forget me, if my queries are too fundamental but try to answer them. The Hop limit in IPv6 hdr is decrimented by every intermediate node in the journey of the packet. Does it mean the packet can only tranverse through 256 intermediate nodes ( 2^8 )? Thanks & with warm regards ````````````````````````````````````````` Jagan S Nathan L&T Infotech, Bangalore. ------=_NextPart_000_0020_01C177F4.B2059380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi=20 all,
 
I am new member to this group. Just = forget me, if=20 my queries are too fundamental but try to answer = them.
 
The Hop limit in IPv6 hdr is decrimented by=20 every intermediate node in the = journey of = the=20 packet. Does it mean the packet can only tranverse through=20 256 intermediate nodes ( 2^8 = )?
 
 
Thanks & with warm=20 regards
 
`````````````````````````````````````````
Jagan  = S =20 Nathan
L&T Infotech,=20 Bangalore.
 
------=_NextPart_000_0020_01C177F4.B2059380-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 00:13:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS8Dt1V010665 for ; Wed, 28 Nov 2001 00:13:55 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAS8Dtd5010664 for ipng-dist; Wed, 28 Nov 2001 00:13: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS8Dp1V010657 for ; Wed, 28 Nov 2001 00:13:52 -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 AAA14362 for ; Wed, 28 Nov 2001 00:13:26 -0800 (PST) From: Martin.Stiemerling@ccrle.nec.de Received: from yamato.ccrle.nec.de (yamato.netlab.nec.de [195.37.70.1] (may be forged)) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA05816 for ; Wed, 28 Nov 2001 00:13:25 -0800 (PST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id fAS8DFk67865; Wed, 28 Nov 2001 09:13:15 +0100 (CET) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id 6AD46C040; Wed, 28 Nov 2001 09:13:21 +0100 (CET) To: Francis Dupont Subject: Re: ipv6 & wlan Message-ID: <1006935201.3c049ca15c514@citadel.mobility.ccrle.nec.de> Date: Wed, 28 Nov 2001 09:13:21 +0100 (CET) Cc: Martin.Stiemerling@ccrle.nec.de, Jung Cyndi-ACJ099 , Werner Pomwenger , ipng@sunroof.eng.sun.com References: <200111271812.fARICUD50905@givry.rennes.enst-bretagne.fr> In-Reply-To: <200111271812.fARICUD50905@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.180 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Quoting Francis Dupont : > In your previous mail you wrote: > > There is presently now trouble with wlan cards and multicast from > Lucent and > ^^^ > > => I believe you mean "no" ? > Yes, thanks for the correction. Martin -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 00:34:12 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS8YC1V010877 for ; Wed, 28 Nov 2001 00:34:12 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAS8YBqM010876 for ipng-dist; Wed, 28 Nov 2001 00: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 engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS8Y81V010869 for ; Wed, 28 Nov 2001 00:34:08 -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 AAA17875 for ; Wed, 28 Nov 2001 00:34:08 -0800 (PST) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA14078 for ; Wed, 28 Nov 2001 00:34:07 -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 fAS8Y1010395; Wed, 28 Nov 2001 00:34:01 -0800 (PST) Received: from [10.34.255.54] ([10.34.255.54]) by mira-sjcd-4.cisco.com (Mirapoint) with ESMTP id ABZ78555; Wed, 28 Nov 2001 00:33:54 -0800 (PST) Mime-Version: 1.0 X-Sender: deering@mira-sjcd-4.cisco.com Message-Id: In-Reply-To: <001f01c177c6$984d5780$e3cc6c6b@jagan> References: <001f01c177c6$984d5780$e3cc6c6b@jagan> Date: Wed, 28 Nov 2001 00:34:04 -0800 To: "Jagan" From: Steve Deering Subject: Re: Hop Limit in IPv6 Hdr. Cc: Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 10:08 AM +0530 11/28/01, Jagan wrote: >The Hop limit in IPv6 hdr is decrimented by every intermediate node in >the journey of the packet. Does it mean the packet can only tranverse >through 256 intermediate nodes ( 2^8 )? Yes, it is limited to 255 IP hops (where a single IP hop may span multiple layer 2 switches, or even multiple IP routers if there are IP-in-IP tunnels along the delivery path). 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 Nov 28 00:43:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS8hn1V011004 for ; Wed, 28 Nov 2001 00:43:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAS8hnEm011003 for ipng-dist; Wed, 28 Nov 2001 00:43: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS8hk1V010996 for ; Wed, 28 Nov 2001 00:43:46 -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 AAA09967 for ; Wed, 28 Nov 2001 00:43:45 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA09001 for ; Wed, 28 Nov 2001 01:43:45 -0700 (MST) Received: from ipv16 (as1-98.chi.il.dial.anet.com [198.92.156.98]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id CAA00364; Wed, 28 Nov 2001 02:43:34 -0600 (CST) Message-ID: <00b201c177ea$9ff0de20$a300a8c0@ipv16> From: "Jim Fleming" To: "Jagan" , "Steve Deering" Cc: References: <001f01c177c6$984d5780$e3cc6c6b@jagan> Subject: Re: Hop Limit in IPv6 Hdr. Date: Wed, 28 Nov 2001 02:56:51 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Unless someone has an iptables module that mangles the TTL count in a "non-standard" manner... This may help... http://www.dot-biz.com/IPv4/Tutorial/ The Netfilter Project: Packet Mangling for Linux 2.4 http://netfilter.samba.org Jim Fleming http://www.IPv8.info IPv16....One Better !! ----- Original Message ----- From: "Steve Deering" To: "Jagan" Cc: Sent: Wednesday, November 28, 2001 2:34 AM Subject: Re: Hop Limit in IPv6 Hdr. > At 10:08 AM +0530 11/28/01, Jagan wrote: > >The Hop limit in IPv6 hdr is decrimented by every intermediate node in > >the journey of the packet. Does it mean the packet can only tranverse > >through 256 intermediate nodes ( 2^8 )? > > Yes, it is limited to 255 IP hops (where a single IP hop may span > multiple layer 2 switches, or even multiple IP routers if there are > IP-in-IP tunnels along the delivery path). > > 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 Nov 28 02:55:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASAtQ1V011388 for ; Wed, 28 Nov 2001 02:55:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASAtQa7011387 for ipng-dist; Wed, 28 Nov 2001 02:55: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASAtM1V011380 for ; Wed, 28 Nov 2001 02:55: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 CAA02629 for ; Wed, 28 Nov 2001 02:55:24 -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 CAA03929 for ; Wed, 28 Nov 2001 02:55:23 -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 FAA28356; Wed, 28 Nov 2001 05:55:18 -0500 (EST) Message-Id: <200111281055.FAA28356@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-dns-discovery-03.txt Date: Wed, 28 Nov 2001 05:55:18 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IPv6 Stateless DNS Discovery Author(s) : D. Thaler, J. Hagino Filename : draft-ietf-ipngwg-dns-discovery-03.txt Pages : 12 Date : 27-Nov-01 This document specifies the steps a host takes in deciding how to autoconfigure information (other than the host's name itself) 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-dns-discovery-03.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-dns-discovery-03.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-dns-discovery-03.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: <20011127134612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-dns-discovery-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-dns-discovery-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011127134612.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 Wed Nov 28 02:55:21 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASAtL1V011378 for ; Wed, 28 Nov 2001 02:55:21 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASAtLQ0011377 for ipng-dist; Wed, 28 Nov 2001 02:55: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASAtH1V011370 for ; Wed, 28 Nov 2001 02:55:17 -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 CAA02625 for ; Wed, 28 Nov 2001 02:55:19 -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 CAA11186 for ; Wed, 28 Nov 2001 02:55:18 -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 FAA28325; Wed, 28 Nov 2001 05:55:12 -0500 (EST) Message-Id: <200111281055.FAA28325@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-addr-arch-v3-07.txt Date: Wed, 28 Nov 2001 05:55:12 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-07.txt Pages : 27 Date : 27-Nov-01 This specification defines the addressing architecture of the IP Version 6 protocol [IPV6]. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-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-ipngwg-addr-arch-v3-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-ipngwg-addr-arch-v3-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: <20011127134600.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-addr-arch-v3-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011127134600.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 Wed Nov 28 02:57:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASAv81V011414 for ; Wed, 28 Nov 2001 02:57:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASAv8xN011413 for ipng-dist; Wed, 28 Nov 2001 02:57: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASAv41V011406 for ; Wed, 28 Nov 2001 02:57:05 -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 CAA04120 for ; Wed, 28 Nov 2001 02:57:06 -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 DAA20568 for ; Wed, 28 Nov 2001 03:57:04 -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 fASAvmA00693 for ; Wed, 28 Nov 2001 12:57:48 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 28 Nov 2001 12:57:03 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Wed, 28 Nov 2001 12:57:03 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D91D4@esebe004.NOE.Nokia.com> To: ipng@sunroof.eng.sun.com Subject: Update of "Minimum IPv6 Functionality for a Cellular Host" draft Date: Wed, 28 Nov 2001 12:56:53 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi All, We have submitted an update to the "Minimum IPv6 Functionality for a Cellular Host" draft on Tuesday November 20th. It looks like it has not yet been announced. In the meantime, the draft can be found here: http://www-nrc.nokia.com/sua/draft-manyfolks-ipv6-cellular-host-02.txt The authors would be very happy to get feedback on this version. We have included an revision history, which I will paste below for your convinience. Thanks, John Loughney Appendix A Revision History Changes from draft-manyfolks-ipv6-cellular-host-01.txt: - Minor editorial changes. - Section 3 - Security: Removed SSL from recommended security protocols. - Section 3.10 - Internet Key Exchange: Added recommendation on interaction between ICMPv6 and IPsec Policy. - Section 4.1 - Mobility support in IPv6: added a discussion on whether or not the cellular host should support the Home Address Option. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 03:01:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASB191V011450 for ; Wed, 28 Nov 2001 03:01:09 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASB18D3011449 for ipng-dist; Wed, 28 Nov 2001 03:01: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASB141V011442 for ; Wed, 28 Nov 2001 03:01:05 -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 DAA04610 for ; Wed, 28 Nov 2001 03:01:05 -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 EAA27451 for ; Wed, 28 Nov 2001 04:01:28 -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 GAA29410; Wed, 28 Nov 2001 06:00:59 -0500 (EST) Message-Id: <200111281100.GAA29410@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-rfc2553bis-04.txt Date: Wed, 28 Nov 2001 06:00: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. This draft is a work item of the IPNG Working Group of the IETF. Title : Basic Socket Interface Extensions for IPv6 Author(s) : R. Gilligan, S. Thomson, J. Bound, W. Stevens Filename : draft-ietf-ipngwg-rfc2553bis-04.txt Pages : 32 Date : 27-Nov-01 The de facto standard application program interface (API) for TCP/IP applications is the 'sockets' interface. Although this API was developed for Unix in the early 1980s it has also been implemented on a wide variety of non-Unix systems. TCP/IP applications written using the sockets API have in the past enjoyed a high degree of portability and we would like the same portability with IPv6 applications. But changes are required to the sockets API to support IPv6 and this memo describes these changes. These include a new socket address structure to carry IPv6 addresses, new address conversion functions, and some new socket options. These extensions are designed to provide access to the basic IPv6 features required by TCP and UDP applications, including multicasting, while introducing a minimum of change into the system and providing complete compatibility for existing IPv4 applications. Additional extensions for advanced IPv6 features (raw sockets and access to the IPv6 extension headers) are defined in another document [4]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2553bis-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-ipngwg-rfc2553bis-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-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: <20011127140106.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2553bis-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2553bis-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011127140106.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 Wed Nov 28 03:22:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASBMJ1V011470 for ; Wed, 28 Nov 2001 03:22:19 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASBMJ3u011469 for ipng-dist; Wed, 28 Nov 2001 03:22: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASBMG1V011462 for ; Wed, 28 Nov 2001 03:22:16 -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 DAA05472 for ; Wed, 28 Nov 2001 03:22:16 -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 EAA06051 for ; Wed, 28 Nov 2001 04:22:38 -0700 (MST) Received: (from ignatios@localhost) by theory.cs.uni-bonn.de (8.9.1a/8.9.1) id MAA15587 for ipng@sunroof.eng.sun.com; Wed, 28 Nov 2001 12:22:13 +0100 (MET) Date: Wed, 28 Nov 2001 12:22:13 +0100 From: Ignatios Souvatzis Cc: ipng@sunroof.eng.sun.com Subject: Re: Hop Limit in IPv6 Hdr. Message-ID: <20011128122213.A13707@theory.cs.uni-bonn.de> References: <001f01c177c6$984d5780$e3cc6c6b@jagan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" X-Mailer: Mutt 1.0i In-Reply-To: ; from deering@cisco.com on Wed, Nov 28, 2001 at 12:34:04AM -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Wed, Nov 28, 2001 at 12:34:04AM -0800, Steve Deering wrote: > At 10:08 AM +0530 11/28/01, Jagan wrote: > >The Hop limit in IPv6 hdr is decrimented by every intermediate node in > >the journey of the packet. Does it mean the packet can only tranverse > >through 256 intermediate nodes ( 2^8 )? >=20 > Yes, it is limited to 255 IP hops (where a single IP hop may span > multiple layer 2 switches, or even multiple IP routers if there are > IP-in-IP tunnels along the delivery path). Given purely hierarchical routing, this would be more than enough.=20 Regards, -is --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.i iQEVAgUBPATI2jCn4om+4LhpAQGhzQgArv9zhXfFmnbW76Jlm+kOJVFVssq5JVAm m5FiU9Zrcle4jVpSzqnO4rd8rZya8xUDq6Zlxv9d0y8ZFCSYsI+wyDkHmvOkiUMy EXmxquNM/iH32HspBNqPobeEV8a+CVvUs+ibPN9VbAqN6Qcyj+jKN8EPsJzkbwzW blfvfwaQJHL5UNRLf5JuuARfh9A3+FWR27a9hpGZ/+bEa4EBiGeapw2R0e0hAgZs iqJJiYDhY1/aqEWoKBQOkEbSkTzbEXT/hqTnHDUIphl7PzMkLz7X2/Isph1ZY7OZ F2XwiYkmpqrGb1xiu1TmCvFkTTswUt/xUPXGAhrSwmVjtwMYmJ9EAQ== =DQ6C -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 06:36:43 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASEah1V012441 for ; Wed, 28 Nov 2001 06:36:43 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASEagP0012440 for ipng-dist; Wed, 28 Nov 2001 06:36: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASEad1V012433 for ; Wed, 28 Nov 2001 06:36: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 GAA08115 for ; Wed, 28 Nov 2001 06:36:29 -0800 (PST) Received: from intens2.pdcint ([194.90.167.40]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA16399 for ; Wed, 28 Nov 2001 06:36:27 -0800 (PST) Received: by INTENS2 with Internet Mail Service (5.5.2650.21) id ; Wed, 28 Nov 2001 16:38:46 +0200 Message-ID: <8B578C8302B3D411811200D0B7B64CD112DCC1@INTENS2> From: Merav Haran To: "'ipng@sunroof.eng.sun.com.'" Subject: IPv6 support Date: Wed, 28 Nov 2001 16:38:42 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fASEad1V012434 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I need your help with the following questions for host IPv6 support: 1. Does IPv6 fragmentation occur in TCP/IP applications? Since the sending host should know the path MTU and there is no fragmentation by intermediate routers, is there a reason for the TCP to send bigger segments than the path MTU? Can we assume that for TCP applications there is no fragmentation in IPv6? 2. Regarding Hop-by-hop, routing, and destination extension headers that are not of interest for us – is it allowed to skip over these extension headers (i.e. just to read the ‘next header’ and ‘length’ fields and to go to the next extension header, without looking inside these headers)? 3. When multiple IPv6 unicast addresses are assigned to the same physical Ethernet port, is it possible that these addresses will differ in their 64 MSB bits? 4. Is it acceptable not to send back ICMP ‘parameter problem’ massages? Thanks, Merav Haran -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 07:53:26 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASFrQ1V012551 for ; Wed, 28 Nov 2001 07:53:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASFrPMI012550 for ipng-dist; Wed, 28 Nov 2001 07:53: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASFrM1V012543 for ; Wed, 28 Nov 2001 07:53: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 HAA08256 for ; Wed, 28 Nov 2001 07:53:23 -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 HAA16398 for ; Wed, 28 Nov 2001 07:53:23 -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 HAA28837; Wed, 28 Nov 2001 07:53:23 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fASFrMk30169; Wed, 28 Nov 2001 07:53:22 -0800 X-mProtect: Wed, 28 Nov 2001 07:53:22 -0800 Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (198.77.202.25, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdd3GzZW; Wed, 28 Nov 2001 07:53:19 PST Message-Id: <4.3.2.7.2.20011128074458.025b7110@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 Nov 2001 07:52:57 -0800 To: Erik.Nordmark@eng.sun.com, narten@us.ibm.com From: Bob Hinden Subject: Request to Advance "IP Version 6 Addressing Architecture" Cc: scoya@ietf.org, 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 Erik, Thomas, The chairs of the IP Next Generation working group, on behalf of the working group, request that the following document be published as an Draft Standard: Title : IP Version 6 Addressing Architecture Author(s) : B. Hinden, S. Deering Filename : draft-ietf-ipngwg-addr-arch-v3-07.txt Pages : 27 Date : 27-Nov-01 A working group last call for this document was completed on August 31, 2001. The -07 version of the draft resolves issues raised during the working group last call and subsequent discussion. A summary of the comments received on the mailing list and their disposition is attached. This document will obsolete RFC2373. Changes from RFC2373 are listed in Appendix B. Bob Hinden / Steve Deering IPng Working Group Co-Chairs ------------------------------------------------------------------------ COMMENT 1: Suggestion that it isn't good practice to talk about assigning multicast address to an interface because it may confuse people and they might be assigned directly to interfaces (e.g., via ifconfig command). Text will be changed to clarify this issue. COMMENT 2: Questioned whether the IPv6 addresses with embedded IPv4 address should be included in the document. This was discussed at the interim meeting in Seattle and there was a consensus to keep the mapped and compatible address in this document. Other types of transition addresses can be defined in other documents. COMMENT 3: Suggestion that the anycast usage scenarios in the document are very router centric and restrictions for router only usage be eased. The current text will be revised to clarify that other anycast usage is possible, but that new uses need to be specified. COMMENT 4: Suggestion that there be more clarification on the differences between interface, link, and node in section 2.7 on multicast addresses. Will add a summary description of the multicast scope values to the document. COMMENT 5: Questioned the removal of the format prefix (FP) and detailed FP table, and instead only listing the exceptions to global unicast. This issue was discussed on the mailing list and there was a consensus that the current text is appropriate. The resulting behavior of treating the address space as global unicast, except for the listed exceptions, is correct. COMMENT 6: Suggestion to reserve some part of the IPv6 and have it's usage be unspecified. The discussion on the mailing concluded was this was not a good idea. Past experience with IPv4 indicated that it becomes very hard to utilize "unspecified" address space in the future. COMMENT 7: Suggestion to move IANA considerations to a numbered section instead of an appendix to make clearer it is normative. Document will be updated to make the IANA consideration a numbered section. -------------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 08:10:08 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASGA81V012651 for ; Wed, 28 Nov 2001 08:10:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASGA8TU012650 for ipng-dist; Wed, 28 Nov 2001 08:10: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASGA41V012643 for ; Wed, 28 Nov 2001 08:10:04 -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 IAA11297 for ; Wed, 28 Nov 2001 08:10:05 -0800 (PST) Received: from suniut1.iutv.univ-paris13.fr (suniut1.iutv.univ-paris13.fr [194.254.173.4]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA07423 for ; Wed, 28 Nov 2001 09:09:42 -0700 (MST) Received: from free.fr (border.iutv.univ-paris13.fr [194.254.173.3]) by suniut1.iutv.univ-paris13.fr (Postfix) with ESMTP id 7044926C5B; Wed, 28 Nov 2001 18:12:12 +0100 (CET) Message-ID: <3C050C4A.1020008@free.fr> Date: Wed, 28 Nov 2001 17:09:46 +0100 From: Damien =?windows-1255?Q?Mascre=27?= User-Agent: Mozilla/5.0 (Windows; U; Win95; fr-FR; rv:0.9.4) Gecko/20011019 Netscape6/6.2 X-Accept-Language: fr-fr, en MIME-Version: 1.0 To: Merav Haran Cc: "'ipng@sunroof.eng.sun.com.'" Subject: Re: IPv6 support References: <8B578C8302B3D411811200D0B7B64CD112DCC1@INTENS2> Content-Type: text/plain; charset=windows-1255; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Merav Haran wrote: > Hi, > > I need your help with the following questions for host IPv6 support: > > 1. Does IPv6 fragmentation occur in TCP/IP applications? Since the > sending host should know the path MTU and there is no fragmentation by > intermediate routers, is there a reason for the TCP to send bigger segments > than the path MTU? Can we assume that for TCP applications there is no > fragmentation in IPv6? fragmentation is done only by the sending host, after having determine the path mtu. TCP applications should not assume that no fragmentation occurs, but it can assume that there will be no fragmentation during the journey of your tcp segment. > > 2. Regarding Hop-by-hop, routing, and destination extension headers > that are not of interest for us – is it allowed to skip over these extension > headers (i.e. just to read the ‘next header’ and ‘length’ fields and to go > to the next extension header, without looking inside these headers)? yes > 3. When multiple IPv6 unicast addresses are assigned to the same > physical Ethernet port, is it possible that these addresses will differ in > their 64 MSB bits? yes, it is the predefined behavior. > 4. Is it acceptable not to send back ICMP ‘parameter problem’ massages? why not ?? > Thanks, > > Merav Haran > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 10:14:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASIEW1V013865 for ; Wed, 28 Nov 2001 10:14:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASIEWeY013864 for ipng-dist; Wed, 28 Nov 2001 10:14: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASIES1V013857 for ; Wed, 28 Nov 2001 10:14: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 KAA10917 for ; Wed, 28 Nov 2001 10:14:29 -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 KAA21623 for ; Wed, 28 Nov 2001 10:14:27 -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 fASIELC01815; Wed, 28 Nov 2001 19:14:22 +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 TAA21273; Wed, 28 Nov 2001 19:14:22 +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 fASIEMD56633; Wed, 28 Nov 2001 19:14:22 +0100 (CET) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200111281814.fASIEMD56633@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden cc: ipng@sunroof.eng.sun.com Subject: Re: Request to Advance "IP Version 6 Addressing Architecture" In-reply-to: Your message of Wed, 28 Nov 2001 07:52:57 PST. <4.3.2.7.2.20011128074458.025b7110@mailhost.iprg.nokia.com> Date: Wed, 28 Nov 2001 19:14:22 +0100 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just a comment, not about the document itself. At the last ETSI IPv6 plugtest I did some tests about anycast support: - source routing with a subnet anycast (something like please go through this routing domain / sub-network) - source routing with multiple anycasts (the same one) - ping to an anycast address - telnet to an anycast address Without more details, I can say I am very unhappy of the results! Perhaps anycasts are toys but when you see how they are supported you should not propose them for real things... Please be a bit more serious boys (:-)! 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 Nov 28 14:10:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASMAD1V014389 for ; Wed, 28 Nov 2001 14:10:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fASMADcN014388 for ipng-dist; Wed, 28 Nov 2001 14: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 engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASMA91V014381 for ; Wed, 28 Nov 2001 14:10:09 -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 OAA13795; Wed, 28 Nov 2001 14:10:10 -0800 (PST) Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA18717; Wed, 28 Nov 2001 14:10:09 -0800 (PST) Received: from ipv16 (as1-98.chi.il.dial.anet.com [198.92.156.98]) by zeus.anet-chi.com (8.9.3/spamfix) with SMTP id QAA01942; Wed, 28 Nov 2001 16:09:41 -0600 (CST) Message-ID: <024301c1785b$3f9263c0$a300a8c0@ipv16> From: "Jim Fleming" To: , , "Bob Hinden" Cc: , References: <4.3.2.7.2.20011128074458.025b7110@mailhost.iprg.nokia.com> Subject: Re: Request to Advance "IP Version 6 Addressing Architecture" Date: Wed, 28 Nov 2001 16:23:01 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk http://www.dot-biz.com/IPv4/Tutorial C@t-32-BitOID:UnirVerse0QQQQGGGWWWXXXXX32-Bit Managed Address0000000000000000 Jim Fleming http://www.ddj.com/articles/search/search.cgi?q=fleming Oct93: The C+@ Programming Language ----- Original Message ----- From: "Bob Hinden" To: ; Cc: ; Sent: Wednesday, November 28, 2001 9:52 AM Subject: Request to Advance "IP Version 6 Addressing Architecture" > Erik, Thomas, > > The chairs of the IP Next Generation working group, on behalf of the > working group, request that the following document be published as an Draft > Standard: > > Title : IP Version 6 Addressing Architecture > Author(s) : B. Hinden, S. Deering > Filename : draft-ietf-ipngwg-addr-arch-v3-07.txt > Pages : 27 > Date : 27-Nov-01 > > A working group last call for this document was completed on August 31, > 2001. The -07 version of the draft resolves issues raised during the > working group last call and subsequent discussion. A summary of the > comments received on the mailing list and their disposition is attached. > > This document will obsolete RFC2373. Changes from RFC2373 are listed in > Appendix B. > > Bob Hinden / Steve Deering > IPng Working Group Co-Chairs > > > ------------------------------------------------------------------------ > > COMMENT 1: Suggestion that it isn't good practice to talk about assigning > multicast address to an interface because it may confuse people and they > might be assigned directly to interfaces (e.g., via ifconfig command). > > Text will be changed to clarify this issue. > > > COMMENT 2: Questioned whether the IPv6 addresses with embedded IPv4 address > should be included in the document. > > This was discussed at the interim meeting in Seattle and there was a > consensus to keep the mapped and compatible address in this > document. Other types of transition addresses can be defined in other > documents. > > > COMMENT 3: Suggestion that the anycast usage scenarios in the document are > very router centric and restrictions for router only usage be eased. > > The current text will be revised to clarify that other anycast usage is > possible, but that new uses need to be specified. > > > COMMENT 4: Suggestion that there be more clarification on the differences > between interface, link, and node in section 2.7 on multicast addresses. > > Will add a summary description of the multicast scope values to the document. > > > COMMENT 5: Questioned the removal of the format prefix (FP) and detailed FP > table, and instead only listing the exceptions to global unicast. > > This issue was discussed on the mailing list and there was a consensus that > the current text is appropriate. The resulting behavior of treating the > address space as global unicast, except for the listed exceptions, is correct. > > > COMMENT 6: Suggestion to reserve some part of the IPv6 and have it's usage > be unspecified. > > The discussion on the mailing concluded was this was not a good idea. Past > experience with IPv4 indicated that it becomes very hard to utilize > "unspecified" address space in the future. > > > COMMENT 7: Suggestion to move IANA considerations to a numbered section > instead of an appendix to make clearer it is normative. > > Document will be updated to make the IANA consideration a numbered section. > > -------------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 28 17:43:00 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT1gx1V015000 for ; Wed, 28 Nov 2001 17:42:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAT1gxLo014999 for ipng-dist; Wed, 28 Nov 2001 17:42: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT1gv1V014992 for ; Wed, 28 Nov 2001 17:42: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 fAT1gkAf008251 for ; Wed, 28 Nov 2001 17:42:46 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fAT1gjbX008250 for ipng@sunroof.eng.sun.com; Wed, 28 Nov 2001 17:42:45 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAS8Zx1V010962 for ; Wed, 28 Nov 2001 00:35:59 -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 AAA18175 for ; Wed, 28 Nov 2001 00:35:59 -0800 (PST) Received: from postfix1.uni-muenster.de (POSTFIX1.UNI-MUENSTER.DE [128.176.188.57]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA17961 for ; Wed, 28 Nov 2001 00:35:58 -0800 (PST) Received: from there (LEMY.UNI-MUENSTER.DE [128.176.184.113]) by postfix1.uni-muenster.de (Postfix) with SMTP id C4C631090 for ; Wed, 28 Nov 2001 09:35:31 +0100 (MEZ) Content-Type: text/plain; charset="iso-8859-15" From: JOIN Project Team Reply-To: schild@uni-muenster.de Organization: Westfaelische Wilhelms-Universitaet To: ipng@sunroof.eng.sun.com Subject: reverse delegation under ip6.arpa.? Date: Wed, 28 Nov 2001 09:35:53 +0100 X-Mailer: KMail [version 1.3.1] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20011128083531.C4C631090@postfix1.uni-muenster.de> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, recently I was very surprised, when I found that there is an existing ip6.arpa. domain, where the reverse IPv6 nibble format is delegated to the registries. I found no mail or announcement anywhere that from now on ip6.arpa should be used for the reverse nibble format. Is that a fact, or is ip6.arpa just a global testing scenario that is confusing me? I know that ip6.arpa should be used instead of ip6.int for political reasons, but I always expected to stay the nibble format in ip6.int and the bit-string labels to appear in ip6.arpa someday. Well, ok, now that the bit-string labels are to be changed to experimental, that might be not possible anymore. But I'm not sure if it such a good idea to just change the zones. Right now there is a well established and well working tree under ip6.int. If there will grow a second tree under ip6.arpa now, things might become very confusing. As a resolver, I don't know if I have to lookup the name for my IPv6 address starting with .arpa or starting .int. If I lookup in the wrong tree, I might get no answer, while the correct one is in the other tree. Yes, I could lookup in both trees, but if the answers differ, which one is the correct one? Is there a solution for this? What is the current policy? Maybe I am confused because I missed something? So long, Christian -- JOIN - IP Version 6 in the WiN Christian Schild A DFN project Westfaelische Wilhelms-Universitaet Muenster Project Team email: Zentrum fuer Informationsverarbeitung join@uni-muenster.de Roentgenstrasse 9-13 http://www.join.uni-muenster.de D-48149 Muenster / Germany email: schild@uni-muenster.de,phone: +49 251 83 31638, fax: +49 251 83 31653 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 17:43:30 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT1hU1V015010 for ; Wed, 28 Nov 2001 17:43:30 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAT1hUod015009 for ipng-dist; Wed, 28 Nov 2001 17:43: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT1hS1V015002 for ; Wed, 28 Nov 2001 17:43:28 -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 fAT1hGAf008281 for ; Wed, 28 Nov 2001 17:43:16 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fAT1hGhE008280 for ipng@sunroof.eng.sun.com; Wed, 28 Nov 2001 17:43:16 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASDnD1V012254 for ; Wed, 28 Nov 2001 05:49: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 FAA21256 for ; Wed, 28 Nov 2001 05:49:15 -0800 (PST) Received: from beamer.mchh.siemens.de (beamer.mchh.siemens.de [194.138.158.163]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA17211 for ; Wed, 28 Nov 2001 06:48:56 -0700 (MST) Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by beamer.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id OAA08204; Wed, 28 Nov 2001 14:49:06 +0100 (MET) Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id OAA16684; Wed, 28 Nov 2001 14:49:05 +0100 (MET) Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id ; Wed, 28 Nov 2001 14:48:36 +0100 Message-ID: <7B1735C6A971D311BB020008C71E8F9F0140B298@MCHH228E> From: Huber Matthias To: "'ipng@sunroof.eng.sun.com'" Cc: "'deering@cisco.com'" Subject: Address Resolution with ND verus MAC address from the EUI-64 form at Date: Wed, 28 Nov 2001 14:48:34 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fASDnD1V012255 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello all, I've read already a couple of RFCs and books to familiarize myself with IPv6. I'm struggling with the following: Neighbor discovery is used to find out the corresponding Layer-2 address to a given IPv6 unicast address ( similar to the ARP process in IPv4). On the other hand I have learned that all global aggregatable unicast addresses have to use the EUI-64 format for the interface ID. At least in a Ethernet (I think this is the majority of the LANs today) this EUI-64 ID is derived from the MAC address in an reversible way. (Simply adding/removing 0xFFFE in the "middle"). So my question is why do I need the ND in a LAN in order to do the address resolution ??? I know that there must be a simple reason, but I don't know it. Is anyone able to sched some light into this ? Thanks very much Matt Mit freundlichen Grüssen / with kind regards Matthias Huber Siemens AG I&C Training Institute CCSI CCNA ICM CA VZ TI A5 Phone +49 89-722-34051 Baierbrunnerstrasse 28 Fax +49 89-722-61684 81359 Munich/Germany Mail mailto:matthias.huber@icn.siemens.de -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 17:44:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT1i51V015020 for ; Wed, 28 Nov 2001 17:44:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAT1i4e5015019 for ipng-dist; Wed, 28 Nov 2001 17:44: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT1i31V015012 for ; Wed, 28 Nov 2001 17:44: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 fAT1hpAf008311 for ; Wed, 28 Nov 2001 17:43:51 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fAT1ho2A008310 for ipng@sunroof.eng.sun.com; Wed, 28 Nov 2001 17:43:50 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASE941V012286 for ; Wed, 28 Nov 2001 06:09:04 -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 GAA23477 for ; Wed, 28 Nov 2001 06:09:06 -0800 (PST) Received: from ural2.hszk.bme.hu (ural2.hszk.bme.hu [152.66.130.2]) by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA06647 for ; Wed, 28 Nov 2001 06:09:05 -0800 (PST) Received: (from nd202@localhost) by ural2.hszk.bme.hu (8.11.3/8.11.3) id fASE94u08259; Wed, 28 Nov 2001 15:09:04 +0100 (MET) Date: Wed, 28 Nov 2001 15:09:04 +0100 (MET) From: Nemeth Daniel X-X-Sender: nd202@ural2 To: ipng@sunroof.eng.sun.com Subject: address autoconfiguration Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear IPNGWG Members! My name is Daniel Nemeth, and I'm a student at Budapest University of Technology and Economics, Faculty of Electrical Engineering and Informatics. The subject of my Project Laboratory is examination of IP micromobility protocols. At the moment I've got some questions related to this topic, and I hope some of you can help me. The first thing I'd like to ask: where can I find any doucumentation of IPv6 Stateful Address Autoconfiguration (I'm thinking about something like RFC 2462 for the stateless autoconf.). The other thing: where can I find statistics, mesurement results about address autoconfiguration methods (I'm interested in both of stateless and stateful methods), I mean how much time does it take to get an address using these methods (with some variable parameters of the tested network). I hope that you can help me in the above things. I'm waiting for your answers. Yours sincerely, Daniel Nemeth ____________________________________________________________________________ Nemeth Daniel 9030 Gyor, Dinnyes u. 26. T:96/332-233 nd202@hszk.bme.hu SCH 1106 T:1/372-51-00/1106 ____________________________________________________________________________ -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 17:45:18 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT1jI1V015030 for ; Wed, 28 Nov 2001 17:45:18 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAT1jIcJ015029 for ipng-dist; Wed, 28 Nov 2001 17:45:18 -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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT1jF1V015022 for ; Wed, 28 Nov 2001 17:45: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 fAT1j4Af008341 for ; Wed, 28 Nov 2001 17:45:04 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fAT1j4pX008340 for ipng@sunroof.eng.sun.com; Wed, 28 Nov 2001 17:45:04 -0800 (PST) Received: from engmail2.Eng.Sun.COM (engmail2 [129.146.1.25]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fASHOK1V013410 for ; Wed, 28 Nov 2001 09:24:20 -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 JAA09634 for ; Wed, 28 Nov 2001 09:24:22 -0800 (PST) Received: from eesun1.tamu.edu (eesun1.tamu.edu [165.91.243.35]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA05029 for ; Wed, 28 Nov 2001 10:24:21 -0700 (MST) Received: from localhost (dkm@localhost) by eesun1.tamu.edu (8.11.2/8.11.2) with ESMTP id fASHO9R18034 for ; Wed, 28 Nov 2001 11:24:09 -0600 (CST) X-Authentication-Warning: eesun1.tamu.edu: dkm owned process doing -bs Date: Wed, 28 Nov 2001 11:24:09 -0600 (CST) From: Krishna Mohan Doddappaneni X-Sender: dkm@eesun1.tamu.edu To: ipng@sunroof.eng.sun.com Subject: Question on Site local address forwarding Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk HI Guys, If The DA of the packet is site local i would not forward the packet outside the scope.But if the SA of the packet is site local and the DA is global,would i forward the packet outside the site? Thanks in Advance, Krishna -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 28 18:13:35 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT2DZ1V015215 for ; Wed, 28 Nov 2001 18:13:35 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAT2DZRt015214 for ipng-dist; Wed, 28 Nov 2001 18:13: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT2DV1V015207 for ; Wed, 28 Nov 2001 18:13: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 SAA21059 for ; Wed, 28 Nov 2001 18:13:33 -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 SAA29663 for ; Wed, 28 Nov 2001 18:13:32 -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 SAA14594; Wed, 28 Nov 2001 18:13:24 -0800 (PST) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id fAT2DOk24339; Wed, 28 Nov 2001 18:13:24 -0800 X-mProtect: Wed, 28 Nov 2001 18:13:24 -0800 Nokia Silicon Valley Messaging Protection Received: from hinden.iprg.nokia.com (4.22.78.78, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdmEks66; Wed, 28 Nov 2001 18:13:22 PST Message-Id: <4.3.2.7.2.20011128181212.020708c0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 28 Nov 2001 18:13:21 -0800 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: DRAFT IPv6 working group agenda for Salt Lake City IETF Cc: hinden@iprg.nokia.com, deering@cisco.com 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 current working group activities and documents, new individual submissions, and last to status reports. Please send us comments, corrections, additions, and deletions. Thanks, Bob Hinden & Steve Deering ------------------------------------------------------------------------- TUESDAY, December 11, 2001, 0900-1130 Introduction, Steve Deering, 5 min. Review Agenda, Steve Deering, 5 min. Document Status, Bob Hinden, 15 min. Default Address Selection for IPv6, Rich Draves, 15 min. Default Router Preferences and More-Specific Routes, Rich Draves, 15 min. IPv6 Host to Router Load Sharing, Bob Hinden, 15 min. Redundant Address Deletion when Encapsulating IPv6 in IPv6, Steve Deering, 15 min. The IPv6 Payload Header, Francis Dupont, 10 min. An IPv6 Flow Label Specification Proposal, Jarno Rajahalme, 45 min. THURSDAY, December 13, 2001, 0900-1130 DNS Discovery Update, Dave Thaler, 20 min. Using DHCPv6 for DNS Configuration in Hosts, Ralph Droms, 10 min. Recommendations for IPv6 in 3GPP Standards, Margaret Wasserman, 30 min. Minimum IPv6 Functionality for a Cellular Host, John Loughney, 30 min. IPv6 minimum host requirement for low cost network appliances, Nobuo Okabe, 15 min. Threat Analysis for IPv6 Public Multi-Access Links, James Kempf, 20 min. Host-based IPv6 Multicast Addresses Allocation , Jung-Soo Park, 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 Nov 28 19:20:04 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT3K31V015316 for ; Wed, 28 Nov 2001 19:20:04 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAT3K3pX015315 for ipng-dist; Wed, 28 Nov 2001 19:20: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT3Jx1V015308 for ; Wed, 28 Nov 2001 19:19: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 TAA29452 for ; Wed, 28 Nov 2001 19:20:01 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA15750 for ; Wed, 28 Nov 2001 20:20:00 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 19BAB4B22 for ; Thu, 29 Nov 2001 12:19:50 +0900 (JST) To: ipng@sunroof.eng.sun.com Subject: a comment on draft-droms-dnsconfig-dhcpv6-00.txt 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: itojun@iijlab.net Date: Thu, 29 Nov 2001 12:19:50 +0900 Message-ID: <5290.1007003990@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk a comment on draft-droms-dnsconfig-dhcpv6-00.txt. quoting section 3: > 1. Multicast a DHCPv6 Inform message to a well-known multicast > address requesting DNS configuration information, including: > * IPv6 addresses of DNS server(s) > * Domain name > * Domain search list (domain names to search during name > resolution) > 2. Wait for the corresponding DHCPv6 Reply message. Here the use of "DHCPv6 Inform message" is discussed. However, such a message type has never been defined in DHCPv6 specs (I've checked from draft-ietf-dhc-dhcpv6-11.txt to 20). 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 Wed Nov 28 19:30:05 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT3U51V015336 for ; Wed, 28 Nov 2001 19:30:05 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAT3U5cv015335 for ipng-dist; Wed, 28 Nov 2001 19:30: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT3U01V015328 for ; Wed, 28 Nov 2001 19:30:00 -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 TAA13925 for ; Wed, 28 Nov 2001 19:29:57 -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 TAA07365 for ; Wed, 28 Nov 2001 19:29:57 -0800 (PST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fAT3R2c25313; Wed, 28 Nov 2001 19:27:02 -0800 (PST) Date: Wed, 28 Nov 2001 22:27:01 -0500 (EST) From: Ralph Droms To: cc: Subject: Re: a comment on draft-droms-dnsconfig-dhcpv6-00.txt In-Reply-To: <5290.1007003990@itojun.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The Inform message is defined in the -21 rev of the DHCPv6 spec, which was submitted before the publication deadline last week but has not yet been published at www.ietf.org. You can get a copy from www.dhcp.org now... - Ralph On Thu, 29 Nov 2001 itojun@iijlab.net wrote: > a comment on draft-droms-dnsconfig-dhcpv6-00.txt. > > quoting section 3: > > > 1. Multicast a DHCPv6 Inform message to a well-known multicast > > address requesting DNS configuration information, including: > > * IPv6 addresses of DNS server(s) > > * Domain name > > * Domain search list (domain names to search during name > > resolution) > > 2. Wait for the corresponding DHCPv6 Reply message. > > Here the use of "DHCPv6 Inform message" is discussed. However, such a > message type has never been defined in DHCPv6 specs (I've checked > from draft-ietf-dhc-dhcpv6-11.txt to 20). > > 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 Wed Nov 28 20:16:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT4Gl1V015527 for ; Wed, 28 Nov 2001 20:16:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAT4GljC015526 for ipng-dist; Wed, 28 Nov 2001 20:16: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT4Gh1V015519 for ; Wed, 28 Nov 2001 20:16:43 -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 UAA06711 for ; Wed, 28 Nov 2001 20:16:46 -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 VAA27658 for ; Wed, 28 Nov 2001 21:16:45 -0700 (MST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id VAA29210 for ; Wed, 28 Nov 2001 21:16:45 -0700 (MST)] Received: [from il06exb01.corp.mot.com (il06exb01.corp.mot.com [199.5.78.83]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id VAA18586 for ; Wed, 28 Nov 2001 21:16:44 -0700 (MST)] Received: by il06exb01.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 28 Nov 2001 22:16:44 -0600 Message-ID: From: Jung Cyndi-ACJ099 To: "'Huber Matthias'" , ipng@sunroof.eng.sun.com Cc: deering@cisco.com Subject: RE: Address Resolution with ND verus MAC address from the EUI-64 form at Date: Wed, 28 Nov 2001 22:16:33 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id fAT4Gi1V015520 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The EUI-64 ID is just one way to build the 64-bit interface ID, and is the way specified for auto-address configuration. The 64-bits may also be manually configured - simple numbers that might be easier to organize than a seemingly random number, or even intentionally random numbers that change periodically to keep network traffic analysts off your trail. DHCPv6 can also be used - one day. When you use the EUI-64 to self-configure the addresses, you get to set the "global" bit in the interface ID, but you still need to run Duplicate Address Detection. Also, for a server that lists it's IPv6 address in a directory, it is still desireable to make that address independent of the hardware address - just as it has always been for IPv4. The client system derives the benefit from auto-addressing, and from the privacy extensions, neither of which is all that compelling for a server. Keep reading :-) Cyndi -----Original Message----- From: Huber Matthias [mailto:Matthias.Huber@icn.siemens.de] Sent: Wednesday, November 28, 2001 5:49 AM To: ipng@sunroof.eng.sun.com Cc: deering@cisco.com Subject: Address Resolution with ND verus MAC address from the EUI-64 form at Hello all, I've read already a couple of RFCs and books to familiarize myself with IPv6. I'm struggling with the following: Neighbor discovery is used to find out the corresponding Layer-2 address to a given IPv6 unicast address ( similar to the ARP process in IPv4). On the other hand I have learned that all global aggregatable unicast addresses have to use the EUI-64 format for the interface ID. At least in a Ethernet (I think this is the majority of the LANs today) this EUI-64 ID is derived from the MAC address in an reversible way. (Simply adding/removing 0xFFFE in the "middle"). So my question is why do I need the ND in a LAN in order to do the address resolution ??? I know that there must be a simple reason, but I don't know it. Is anyone able to sched some light into this ? Thanks very much Matt Mit freundlichen Grüssen / with kind regards Matthias Huber Siemens AG I&C Training Institute CCSI CCNA ICM CA VZ TI A5 Phone +49 89-722-34051 Baierbrunnerstrasse 28 Fax +49 89-722-61684 81359 Munich/Germany Mail mailto:matthias.huber@icn.siemens.de -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 Nov 29 02:07:11 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATA7B1V015793 for ; Thu, 29 Nov 2001 02:07:11 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATA7BTZ015792 for ipng-dist; Thu, 29 Nov 2001 02:07: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATA771V015785 for ; Thu, 29 Nov 2001 02:07: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 CAA13138 for ; Thu, 29 Nov 2001 02:07:09 -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 CAA11117 for ; Thu, 29 Nov 2001 02:07:07 -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 fATA7iA03915 for ; Thu, 29 Nov 2001 12:07:45 +0200 (EET) Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 29 Nov 2001 12:06:19 +0200 Received: by esebh25nok with Internet Mail Service (5.5.2652.78) id ; Thu, 29 Nov 2001 12:06:19 +0200 Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF5D91E9@esebe004.NOE.Nokia.com> To: ipng@sunroof.eng.sun.com Subject: FW: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt Date: Thu, 29 Nov 2001 12:06:14 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C178BD.7A79DF6B" 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_000_01C178BD.7A79DF6B Content-Type: text/plain; charset="iso-8859-1" Hi all, Here is the official announcement, and one small comment on the mail I sent yesterday: Updates include: - Section 3 - Security: Removed SSL from recommended security protocols. This actually means that mention of 'SSL' was replaced by 'TLS.' This is not to imply we removed SSL/TLS from the specification. br, John -----Original Message----- From: ext Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 28 November, 2001 12:57 Subject: I-D ACTION:draft-manyfolks-ipv6-cellular-host-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Minimum IPv6 Functionality for a Cellular Host Author(s) : J. Arkko et al. Filename : draft-manyfolks-ipv6-cellular-host-02.txt Pages : 26 Date : 27-Nov-01 As an increasing number of cellular hosts are being connected to the Internet, IPv6 becomes necessary. Examples of such hosts are GPRS, UMTS, and CDMA2000 terminals. Standardization organizations are also making IPv6 mandatory in their newest specifications, such as the IP multimedia terminals specified for UMTS. However, the concept of IPv6 covers many aspects, numerous RFCs, a number of different situations, and is also partly still evolving. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-manyfolks-ipv6-cellular-host-02.tx t 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-manyfolks-ipv6-cellular-host-02.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-manyfolks-ipv6-cellular-host-02.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_000_01C178BD.7A79DF6B Content-Type: message/rfc822; name="Untitled Attachment" Content-Disposition: attachment; filename="Untitled Attachment" To: Subject: Date: Thu, 29 Nov 2001 12:06:19 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C178BD.7A79DF6B" ------_=_NextPart_002_01C178BD.7A79DF6B Content-Type: text/plain ------_=_NextPart_002_01C178BD.7A79DF6B Content-Type: application/octet-stream; name="ATT79276" Content-Disposition: attachment; filename="ATT79276" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011127135028.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-manyfolks-ipv6-cellular-host-02.txt ------_=_NextPart_002_01C178BD.7A79DF6B Content-Type: message/external-body; site="internet-drafts"; dir="draft-manyfolks-ipv6-cellular-host-02.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C178BD.7A79DF6B-- ------_=_NextPart_000_01C178BD.7A79DF6B-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 03:06:41 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATB6f1V015897 for ; Thu, 29 Nov 2001 03:06:41 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATB6eOn015896 for ipng-dist; Thu, 29 Nov 2001 03:06: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATB6X1V015882 for ; Thu, 29 Nov 2001 03:06:33 -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 DAA01403 for ; Thu, 29 Nov 2001 03:06: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 EAA02176 for ; Thu, 29 Nov 2001 04:06:32 -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 GAA20394; Thu, 29 Nov 2001 06:06:28 -0500 (EST) Message-Id: <200111291106.GAA20394@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-03.txt Date: Thu, 29 Nov 2001 06:06:28 -0500 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPNG Working Group of the IETF. Title : Advanced Sockets API for IPv6 Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei Filename : draft-ietf-ipngwg-rfc2292bis-03.txt Pages : 79 Date : 28-Nov-01 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 and will support most end-user applications in use today: Telnet and FTP clients and servers, HTTP clients and servers, and the like. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-03.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-03.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-03.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: <20011128143657.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-rfc2292bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-rfc2292bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011128143657.I-D@ietf.org> --OtherAccess-- --NextPart-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu Nov 29 06:09:25 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATE9P1V016603 for ; Thu, 29 Nov 2001 06:09:25 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATE9OYA016602 for ipng-dist; Thu, 29 Nov 2001 06: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATE9K1V016595 for ; Thu, 29 Nov 2001 06:09:20 -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 GAA26883 for ; Thu, 29 Nov 2001 06:09:22 -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 GAA18870 for ; Thu, 29 Nov 2001 06:09:21 -0800 (PST) Received: from kenawang ([192.168.1.28]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA09229; Thu, 29 Nov 2001 06:08:15 -0800 (PST) Message-Id: <4.2.2.20011129090457.01f0a740@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 29 Nov 2001 09:07:38 -0500 To: Krishna Mohan Doddappaneni From: Margaret Wasserman Subject: Re: Question on Site local address forwarding 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 Krishna, No, you do not forward a packet with a site local SA outside of the scope, either. There is a draft available which explains the rules for the use and forwarding of scoped addresses: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping-arch-02.txt Margaret At 12:24 PM 11/28/01 , Krishna Mohan Doddappaneni wrote: >HI Guys, >If The DA of the packet is site local i would not forward the packet >outside the scope.But if the SA of the packet is site local and the DA is >global,would i forward the packet outside the site? >Thanks in Advance, >Krishna > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 Nov 29 06:44:16 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATEiG1V016634 for ; Thu, 29 Nov 2001 06:44:16 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATEiGbD016633 for ipng-dist; Thu, 29 Nov 2001 06:44: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATEiC1V016626 for ; Thu, 29 Nov 2001 06:44: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 GAA23718 for ; Thu, 29 Nov 2001 06:44:12 -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 HAA26530 for ; Thu, 29 Nov 2001 07:44:11 -0700 (MST) Received: by zmamail04.zma.compaq.com (Postfix, from userid 12345) id CFC2258E7; Thu, 29 Nov 2001 09:44:10 -0500 (EST) Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 8F7385B55; Thu, 29 Nov 2001 09:44:10 -0500 (EST) Received: by mailrelay01.cce.cpqcorp.net (Postfix, from userid 12345) id 198401FA8; Thu, 29 Nov 2001 08:44:10 -0600 (CST) Received: from oflume.zk3.dec.com (flambe.zk3.dec.com [16.140.96.19]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 8FAA61C1C; Thu, 29 Nov 2001 08:44:09 -0600 (CST) Received: from whitestar.zk3.dec.com by oflume.zk3.dec.com (8.8.8/1.1.22.3/03Mar00-0551AM) id JAA0000010569; Thu, 29 Nov 2001 09:44:08 -0500 (EST) Received: from zk3.dec.com by whitestar.zk3.dec.com (8.9.3/1.1.29.3/09Nov01-0546PM) id JAA0000077492; Thu, 29 Nov 2001 09:43:22 -0500 (EST) Message-ID: <3C064989.A73083C2@zk3.dec.com> Date: Thu, 29 Nov 2001 09:43:21 -0500 From: Vladislav Yasevich X-Mailer: Mozilla 4.76 [en] (X11; U; OSF1 V5.1 alpha) X-Accept-Language: en MIME-Version: 1.0 To: IPNG Working Group Cc: Erik Nordmark Subject: Re: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-03.txt References: <200111291106.GAA20394@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk So far, all my attempts to see this draft resulted in a "This draft has been deleted" message. Did they new draft get submitted? Thanks -vlad Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IPNG Working Group of the IETF. > > Title : Advanced Sockets API for IPv6 > Author(s) : R. Stevens, M. Thomas, E. Nordmark, T. Jinmei > Filename : draft-ietf-ipngwg-rfc2292bis-03.txt > Pages : 79 > Date : 28-Nov-01 > > 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 and will support most end-user applications in use > today: Telnet and FTP clients and servers, HTTP clients and servers, > and the like. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-rfc2292bis-03.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-03.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-03.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. > > ------------------------------------------------------------------------------ > > Access-Type: anon-ftp > Site: ftp.ietf.org > Link to Document Directory: internet-drafts > Name: draft-ietf-ipngwg-rfc2292bis-03.txt > Type: text/plain -- ++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tel: (603) 884-1079 Compaq Computer Corp. Fax: (435) 514-6884 110 Spit Brook Rd ZK03-3/T07 Nashua, NH 03062 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 07:01:47 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATF1k1V016740 for ; Thu, 29 Nov 2001 07:01:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATF1kpv016739 for ipng-dist; Thu, 29 Nov 2001 07:01: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATF1f1V016732 for ; Thu, 29 Nov 2001 07:01:41 -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 HAA26601 for ; Thu, 29 Nov 2001 07:01: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 IAA22890 for ; Thu, 29 Nov 2001 08:01:23 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:f81c:ddea:dbd:1155]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fATF1Z304775; Fri, 30 Nov 2001 00:01:35 +0900 (JST) Date: Fri, 30 Nov 2001 00:01:32 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Vladislav Yasevich Cc: IPNG Working Group Subject: Re: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-03.txt In-Reply-To: <3C064989.A73083C2@zk3.dec.com> References: <200111291106.GAA20394@ietf.org> <3C064989.A73083C2@zk3.dec.com> User-Agent: Wanderlust/2.7.5 (Too Funky) 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 980905(IM100) Lines: 20 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 29 Nov 2001 09:43:21 -0500, >>>>> Vladislav Yasevich said: > So far, all my attempts to see this draft resulted in a "This > draft has been deleted" message. > Did they new draft get submitted? Since the file of the URL does not seem to have been updated and I've got a couple of questions about the latest version, I've put the version that I submitted at the following URL: http://www.kame.net/~jinmei/draft-ietf-ipngwg-rfc2292bis-03.txt Please refer to this version until the official file is ready. 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 Nov 29 07:37:13 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATFbD1V016907 for ; Thu, 29 Nov 2001 07:37:13 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATFbC17016906 for ipng-dist; Thu, 29 Nov 2001 07:37:12 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATFb91V016899 for ; Thu, 29 Nov 2001 07:37:09 -0800 (PST) Received: from hogwart.Central.Sun.COM (hogwart.Central.Sun.COM [129.153.128.110]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA17414; Thu, 29 Nov 2001 08:37:08 -0700 (MST) Received: from hogwart.Central.Sun.COM (localhost [IPv6:::1]) by hogwart.Central.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id fATFb5Sh068311; Thu, 29 Nov 2001 09:37:06 -0600 (CST) Received: (from davemq@localhost) by hogwart.Central.Sun.COM (8.12.1+Sun/8.12.1/Submit) id fATFb49D068308; Thu, 29 Nov 2001 09:37:04 -0600 (CST) X-Authentication-Warning: hogwart.Central.Sun.COM: davemq set sender to Dave.Marquardt@Sun.COM using -f To: Huber Matthias Cc: "'ipng@sunroof.eng.sun.com'" , "'deering@cisco.com'" Subject: Re: Address Resolution with ND verus MAC address from the EUI-64 form at References: <7B1735C6A971D311BB020008C71E8F9F0140B298@MCHH228E> From: Dave Marquardt Date: 29 Nov 2001 09:37:04 -0600 In-Reply-To: <7B1735C6A971D311BB020008C71E8F9F0140B298@MCHH228E> Message-ID: Lines: 20 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Huber" == Huber Matthias writes: Huber> On the other hand I have learned that all global aggregatable Huber> unicast addresses have to use the EUI-64 format for the Huber> interface ID. At least in a Ethernet (I think this is the Huber> majority of the LANs today) this EUI-64 ID is derived from the Huber> MAC address in an reversible way. (Simply adding/removing Huber> 0xFFFE in the "middle"). So my question is why do I need the ND Huber> in a LAN in order to do the address resolution ??? I know that Huber> there must be a simple reason, but I don't know it. No, this isn't correct. There is no requirement (that I'm aware of) "that all global aggregatable unicast addresses have to use the EUI-64 format for the interface ID." Not at all. So the rest of your argument, I think, falls apart. -- Dave Marquardt Sun Microsystems, Inc. Austin, TX +1 512 401-1077 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 07:41:27 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATFfQ1V016925 for ; Thu, 29 Nov 2001 07:41:26 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATFfQGU016924 for ipng-dist; Thu, 29 Nov 2001 07:41:26 -0800 (PST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Received: from centralmail1.Central.Sun.COM (centralmail1.Central.Sun.COM [129.147.62.10]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATFfM1V016917 for ; Thu, 29 Nov 2001 07:41:22 -0800 (PST) Received: from hogwart.Central.Sun.COM (hogwart.Central.Sun.COM [129.153.128.110]) by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19194; Thu, 29 Nov 2001 08:41:23 -0700 (MST) Received: from hogwart.Central.Sun.COM (localhost [IPv6:::1]) by hogwart.Central.Sun.COM (8.12.1+Sun/8.12.1) with ESMTP id fATFfMSh068433; Thu, 29 Nov 2001 09:41:22 -0600 (CST) Received: (from davemq@localhost) by hogwart.Central.Sun.COM (8.12.1+Sun/8.12.1/Submit) id fATFfMt9068430; Thu, 29 Nov 2001 09:41:22 -0600 (CST) X-Authentication-Warning: hogwart.Central.Sun.COM: davemq set sender to Dave.Marquardt@Sun.COM using -f To: Nemeth Daniel Cc: ipng@sunroof.eng.sun.com Subject: Re: address autoconfiguration References: From: Dave Marquardt Date: 29 Nov 2001 09:41:22 -0600 In-Reply-To: Message-ID: Lines: 15 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Daniel" == Nemeth Daniel writes: Daniel> The first thing I'd like to ask: where can I find any Daniel> doucumentation of IPv6 Stateful Address Autoconfiguration (I'm Daniel> thinking about something like RFC 2462 for the stateless Daniel> autoconf.). You might be interested in DHCPv6. Try the DHCPv6 Internet Draft. One location is -- Dave Marquardt Sun Microsystems, Inc. Austin, TX +1 512 401-1077 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 12:46:48 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATKkl1V018838 for ; Thu, 29 Nov 2001 12:46:47 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATKklKO018837 for ipng-dist; Thu, 29 Nov 2001 12:46: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATKkd1V018830 for ; Thu, 29 Nov 2001 12:46: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 MAA10049 for ; Thu, 29 Nov 2001 12:46:31 -0800 (PST) Received: from mg02.austin.ibm.com (mg02.austin.ibm.com [192.35.232.12]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA29695 for ; Thu, 29 Nov 2001 13:46:30 -0700 (MST) Received: from austin.ibm.com (netmail2.austin.ibm.com [9.3.7.139]) by mg02.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA33560; Thu, 29 Nov 2001 14:53:07 -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 OAA26316; Thu, 29 Nov 2001 14:45:10 -0600 Received: from localhost (lilianf@localhost) by porkchop.austin.ibm.com (AIX5.1/8.11.0/8.11.0-client1.01) with ESMTP id fATKj9F38114; Thu, 29 Nov 2001 14:45:09 -0600 Date: Thu, 29 Nov 2001 14:45:09 -0600 (CST) From: Lilian Fernandes To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= cc: IPNG Working Group Subject: Re: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-03.txt 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 Is this draft going to RFC status anytime soon? A lot of the basic behavior has changed between versions 02 and 03. Would you say that version 03 is a fairly stabilized draft? Thanks, Lilian On Fri, 30 Nov 2001, JINMEI Tatuya / [ISO-2022-JP] $B?@L@C#:H(B wrote: > >>>>> On Thu, 29 Nov 2001 09:43:21 -0500, > >>>>> Vladislav Yasevich said: > > > So far, all my attempts to see this draft resulted in a "This > > draft has been deleted" message. > > > Did they new draft get submitted? > > Since the file of the URL does not seem to have been updated and I've > got a couple of questions about the latest version, I've put the > version that I submitted at the following URL: > > http://www.kame.net/~jinmei/draft-ietf-ipngwg-rfc2292bis-03.txt > > Please refer to this version until the official file is ready. > > 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 > -------------------------------------------------------------------- > _____________________________________________________________________ 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 Thu Nov 29 14:03:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATM3a1V018983 for ; Thu, 29 Nov 2001 14:03:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATM3a1Z018982 for ipng-dist; Thu, 29 Nov 2001 14:03: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATM3W1V018975 for ; Thu, 29 Nov 2001 14:03:32 -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 OAA24138 for ; Thu, 29 Nov 2001 14:03:32 -0800 (PST) Received: from seralph10.essex.ac.uk (seralph10.essex.ac.uk [155.245.240.160]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA28644 for ; Thu, 29 Nov 2001 15:03:14 -0700 (MST) Received: from so-19242-x0.essex.ac.uk ([155.245.126.11] helo=SO19242X0) by seralph10.essex.ac.uk with smtp (Exim 3.13 #1) id 169ZHH-0001V5-00 for ipng@sunroof.eng.sun.com; Thu, 29 Nov 2001 22:03:31 +0000 Message-ID: <002801c17921$f42a9e80$0b7ef59b@essex.ac.uk> From: "Kaitatzis Anastasios" To: Subject: ipv6 Date: Thu, 29 Nov 2001 22:05:26 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01C17921.F362BAA0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0025_01C17921.F362BAA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am an MSc student at the University of essex in Computer and = information Networks.I have a project about Convergence of IPv6 and IPv4 = networks.I want to set up two machines using these protocols.I would = like to set up the first machine using IPv6 and the second machine = IPv4.My question is "which operating system is better (Linux or win2000) = in order to implement this experiment")=20 I look forward to hearing from you Your Sincerely Kaitatzis Anastasios=20 Email: akaita@essex.ac.uk Tel: +44(0)1206538858 Address: University of Essex, Alresford Court, H3 F3 ROOM E Wivenhoe park Colchester CO4 3SQ ------=_NextPart_000_0025_01C17921.F362BAA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am an MSc student at the University = of essex in=20 Computer and information Networks.I have a project about Convergence of = IPv6 and=20 IPv4 networks.I want to set up two machines using these protocols.I = would like=20 to set up the first machine using IPv6 and the second machine IPv4.My = question=20 is "which operating system is better (Linux or win2000) in order to = implement=20 this experiment")
 
I look forward to hearing from = you
 
Your Sincerely
 
Kaitatzis Anastasios=20
Email:      akaita@essex.ac.uk
Tel: &n= bsp;      =20 +44(0)1206538858
Address:  University of=20 Essex,
          &nb= sp;    =20 Alresford=20 Court,
          &nb= sp;    =20 H3 F3 ROOM=20 E
           &n= bsp;   =20 Wivenhoe=20 park
           = ;    =20 Colchester CO4 3SQ
------=_NextPart_000_0025_01C17921.F362BAA0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 14:08:17 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATM8H1V019089 for ; Thu, 29 Nov 2001 14:08:17 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATM8HiG019088 for ipng-dist; Thu, 29 Nov 2001 14:08: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATM8D1V019081 for ; Thu, 29 Nov 2001 14:08:13 -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 OAA27362 for ; Thu, 29 Nov 2001 14:08:14 -0800 (PST) Received: from seralph10.essex.ac.uk (seralph10.essex.ac.uk [155.245.240.160]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA24786 for ; Thu, 29 Nov 2001 15:08:13 -0700 (MST) Received: from so-19242-x0.essex.ac.uk ([155.245.126.11] helo=SO19242X0) by seralph10.essex.ac.uk with smtp (Exim 3.13 #1) id 169ZLo-0001iL-00 for ipng@sunroof.eng.sun.com; Thu, 29 Nov 2001 22:08:12 +0000 Message-ID: <003d01c17922$9ba02fe0$0b7ef59b@essex.ac.uk> From: "Kaitatzis Anastasios" To: Subject: ipv6 Date: Thu, 29 Nov 2001 22:10:07 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C17922.9AB533A0" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C17922.9AB533A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am an MSc student at the University of essex in Computer and = information Networks.I have a project about Convergence of IPv6 and IPv4 = networks.I want to set up two machines using these protocols.I would = like to set up the first machine using IPv6 and the second machine = IPv4.My question is "which operating system is better (Linux or win2000) = in order to implement this experiment")=20 I look forward to hearing from you Your Sincerely Kaitatzis Anastasios=20 Email: akaita@essex.ac.uk Tel: +44(0)1206538858 Address: University of Essex, Alresford Court, H3 F3 ROOM E Wivenhoe park Colchester CO4 3SQ ------=_NextPart_000_003A_01C17922.9AB533A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am an MSc student at the University = of essex in=20 Computer and information Networks.I have a project about Convergence of = IPv6 and=20 IPv4 networks.I want to set up two machines using these protocols.I = would like=20 to set up the first machine using IPv6 and the second machine IPv4.My = question=20 is "which operating system is better (Linux or win2000) in order to = implement=20 this experiment")
 
I look forward to hearing from = you
 
Your Sincerely
Kaitatzis Anastasios=20
Email:      akaita@essex.ac.uk
Tel: &n= bsp;      =20 +44(0)1206538858
Address:  University of=20 Essex,
          &nb= sp;    =20 Alresford=20 Court,
          &nb= sp;    =20 H3 F3 ROOM=20 E
           &n= bsp;   =20 Wivenhoe=20 park
           = ;    =20 Colchester CO4 3SQ
------=_NextPart_000_003A_01C17922.9AB533A0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 15:03:34 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATN3Y1V019219 for ; Thu, 29 Nov 2001 15:03:34 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATN3Y8j019218 for ipng-dist; Thu, 29 Nov 2001 15:03:34 -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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATN3U1V019211 for ; Thu, 29 Nov 2001 15:03:30 -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 PAA17761 for ; Thu, 29 Nov 2001 15:03:31 -0800 (PST) Received: from seralph10.essex.ac.uk (seralph10.essex.ac.uk [155.245.240.160]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11698 for ; Thu, 29 Nov 2001 16:03:13 -0700 (MST) Received: from so-19242-x0.essex.ac.uk ([155.245.126.11] helo=SO19242X0) by seralph10.essex.ac.uk with smtp (Exim 3.13 #1) id 169aDJ-00025N-00 for ipng@sunroof.eng.sun.com; Thu, 29 Nov 2001 23:03:29 +0000 Message-ID: <009101c1792a$56523520$0b7ef59b@essex.ac.uk> From: "Kaitatzis Anastasios" To: "IPv6" Subject: ipv6-ipv4 Date: Thu, 29 Nov 2001 23:05:26 -0000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008E_01C1792A.555E1120" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_008E_01C1792A.555E1120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am an MSc student in Computer and Information Networks.I have a = project about "convergence of IPv6 and IPv4 networks".I would like to = inform me which is the appropriate RFC to read in order to implement = this project. I look forward to hearing from you=20 Your Sincerely Kaitatzis Anastasios=20 Email: akaita@essex.ac.uk Tel: +44(0)1206538858 Address: University of Essex, Alresford Court, H3 F3 ROOM E Wivenhoe park Colchester CO4 3SQ ------=_NextPart_000_008E_01C1792A.555E1120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am an MSc student in Computer and = Information=20 Networks.I have a project about "convergence of IPv6 and IPv4 = networks".I would=20 like to inform me which is the appropriate RFC to read in order to = implement=20 this project.
 
I look forward to hearing from you =
 
Your Sincerely
 
Kaitatzis Anastasios=20
Email:      akaita@essex.ac.uk
Tel: &n= bsp;      =20 +44(0)1206538858
Address:  University of=20 Essex,
          &nb= sp;    =20 Alresford=20 Court,
          &nb= sp;    =20 H3 F3 ROOM=20 E
           &n= bsp;   =20 Wivenhoe=20 park
           = ;    =20 Colchester CO4 3SQ
------=_NextPart_000_008E_01C1792A.555E1120-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 15:15:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATNFX1V019256 for ; Thu, 29 Nov 2001 15:15:33 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATNFWmr019255 for ipng-dist; Thu, 29 Nov 2001 15:15:32 -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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATNFV1V019248 for ; Thu, 29 Nov 2001 15:15:31 -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 fATNFIAf009017 for ; Thu, 29 Nov 2001 15:15:18 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fATNFIUX009016 for ipng@sunroof.eng.sun.com; Thu, 29 Nov 2001 15:15:18 -0800 (PST) Received: from engmail3.Eng.Sun.COM (engmail3 [129.144.170.5]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAT87S1V015661 for ; Thu, 29 Nov 2001 00:07: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 AAA19880 for ; Thu, 29 Nov 2001 00:07:28 -0800 (PST) From: kimyj@etri.re.kr Received: from cms1.etri.re.kr (cms1.etri.re.kr [129.254.16.11]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id AAA25085 for ; Thu, 29 Nov 2001 00:07:27 -0800 (PST) Received: by cms1.etri.re.kr with Internet Mail Service (5.5.2653.19) id ; Thu, 29 Nov 2001 17:08:57 +0900 Message-ID: <54A1DDB4ACD5D511B0F900D0B7A8DC08317F4A@cms1.etri.re.kr> To: ipng@sunroof.eng.sun.com Subject: Update of "Host-based IPv6 Multicast Addresses Allocation" draft Date: Thu, 29 Nov 2001 17:08:50 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C178AD.13E7ACB0" 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_01C178AD.13E7ACB0 Content-Type: text/plain; charset="euc-kr" Hi All, We have updated the "Host-based IPv6 Multicast Addresses Allocation" draft and you can find the draft here: http://www.ipv6.or.kr/english/draft-park-host-based-mcast-01.txt The authors would be very happy to get feedback on this updated version. For your convenience, we have included below an revision history. Regards, Yong Jin Appendix : Revision History Changes from draft-park-host-based-mcast-00.txt: - Section 3.1 & 3.2 : group ID field length was changed from 8 bits to 32 bits scope is restricted to not greater than 5 - Section 3.3 - GLOP-based global multicast address : Removed - Minor editorial changes. ------_=_NextPart_001_01C178AD.13E7ACB0 Content-Type: text/html; charset="euc-kr" Content-Transfer-Encoding: quoted-printable Update of "Host-based IPv6 Multicast Addresses = Allocation" draft

Hi All,

We have updated  the "Host-based IPv6 = Multicast Addresses Allocation"
draft  and  you can find the draft here: =

http://www.ipv6.or.kr/english/draft-park-host-based-mc= ast-01.txt

The authors would be very happy to get feedback on = this updated version.
For your convenience, we have included below an = revision history.

Regards,
Yong Jin

Appendix :  Revision History

  Changes from = draft-park-host-based-mcast-00.txt:


     - Section 3.1 & 3.2 : = group ID field length was changed from 8 bits to 32 bits 
          &nb= sp;           &nb= sp;           &nb= sp;  scope is restricted to not greater than 5
     - Section 3.3 - GLOP-based = global multicast address : Removed
     - Minor editorial = changes.=20

------_=_NextPart_001_01C178AD.13E7ACB0-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 29 15:16:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATNGx1V019276 for ; Thu, 29 Nov 2001 15:16:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fATNGxw3019275 for ipng-dist; Thu, 29 Nov 2001 15:16: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATNGv1V019268 for ; Thu, 29 Nov 2001 15:16: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 fATNGjAf009054 for ; Thu, 29 Nov 2001 15:16:45 -0800 (PST) Received: (from jrh@localhost) by stinker.eng.sun.com (8.12.1+Sun/8.12.1/Submit) id fATNGju6009053 for ipng@sunroof.eng.sun.com; Thu, 29 Nov 2001 15:16:45 -0800 (PST) Received: from engmail4.Eng.Sun.COM (engmail4 [129.144.134.6]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fATCtp1V016409 for ; Thu, 29 Nov 2001 04:55:51 -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 EAA17365 for ; Thu, 29 Nov 2001 04:55:52 -0800 (PST) Received: from Mail6.nc.rr.com (fe6.southeast.rr.com [24.93.67.53]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA03488 for ; Thu, 29 Nov 2001 05:55:34 -0700 (MST) Received: from innovationslab.net ([24.162.252.183]) by Mail6.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Thu, 29 Nov 2001 07:55:43 -0500 Message-ID: <3C063060.B5F63B32@innovationslab.net> Date: Thu, 29 Nov 2001 07:56:00 -0500 From: Brian Haberman Reply-To: haberman@innovationslab.net X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Krishna Mohan Doddappaneni CC: ipng@sunroof.eng.sun.com Subject: Re: Question on Site local address forwarding References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Krishna, Section 9 of draft-ietf-ipngwg-scoping-arch-02.txt discusses this very issue. The specific text is: If transmitting the packet on the chosen next-hop interface would cause the packet to leave the zone of the source address, i.e., cross a zone boundary of the scope of the source address, then the packet is discarded and an ICMP Destination Unreachable message [RFC 2463] with Code 2 ("beyond scope of source address") is sent to the source of the packet. This eliminates problems in forwarding the response to this packet when the site-local SA would become the DA. Regards, Brian Krishna Mohan Doddappaneni wrote: > > HI Guys, > If The DA of the packet is site local i would not forward the packet > outside the scope.But if the SA of the packet is site local and the DA is > global,would i forward the packet outside the site? > Thanks in Advance, > Krishna > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 29 17:57:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAU1vu1V020117 for ; Thu, 29 Nov 2001 17:57:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAU1vuOB020116 for ipng-dist; Thu, 29 Nov 2001 17:57: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAU1vq1V020109 for ; Thu, 29 Nov 2001 17:57:53 -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 RAA24670 for ; Thu, 29 Nov 2001 17:57:54 -0800 (PST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA08739 for ; Thu, 29 Nov 2001 17:57:46 -0800 (PST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA174538 for ; Thu, 29 Nov 2001 19:54:36 -0600 Received: from d04nm300.raleigh.ibm.com (d04nm300.raleigh.ibm.com [9.67.226.185]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAU1viH72804 for ; Thu, 29 Nov 2001 20:57:45 -0500 Importance: Normal Sensitivity: Subject: GETNAMEINFO questions ............... To: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Lori Napoli" Date: Thu, 29 Nov 2001 20:55:48 -0500 X-MIMETrack: Serialize by Router on D04NM300/04/M/IBM(Build M9_05202001 Beta 2|May 20, 2001) at 11/29/2001 08:57:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk draft-ietf-ipngwg-rfc2553bis-04.txt section 6.2 states: The flags argument is a flag that changes the default actions of the function. By default the fully-qualified domain name (FQDN) for the host shall be returned, but: - If the flag bit NI_NOFQDN is set, only the node name portion of the FQDN shall be returned for local hosts. - If the flag bit NI_NUMERICHOST is set, the numeric form of the host's address shall be returned instead of its name, under all circumstances. - If the flag bit NI_NAMEREQD is set, an error shall be returned if the host's name cannot be located. - If the flag bit NI_NUMERICSERV is set, the numeric form of the service address shall be returned (for example, its port number) instead of its name, under all circumstances. - If the flag bit NI_NUMERICSCOPE is set, the numeric form of the scope identifier shall be returned (for example, interface index) instead of its name. This flag is ignored if the sa argument is not an IPv6 address. - If the flag bit NI_DGRAM is set, this indicates that the service is a datagram service (SOCK_DGRAM). The default behavior shall assume that the service is a stream service (SOCK_STREAM). So what if NI_NUMERICHOST is not set and NI_NAMEREQD is not set. Getnameinfo attempts to resolve the name via DNS query and scan of the local files. If the host name is not resolved, do we return the numeric form or an error? Also, if NI_NUMERICSERV is not set, getnameinfo calls getservbyport to scan the local service name file and if the service name is not resolved we return the numeric form. So, how can the application calling getnameinfo determine that the resolution of the service name failed since it can receive the numeric form regardless of NI_NUMERICSERV setting. It would have to determine that numeric form was returned and NI_NUMERICSERV had not been specified. There doesn't seem to be a service name equivalent of NI_NAMEREQD. Should getnameinfo return the numeric form of the service name if name resolution fails or should we return an error? Lori 919-254-6146 T/L 8-444-6146 E-mail: lanapoli@us.ibm.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 Nov 29 22:13:54 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAU6Dr1V020387 for ; Thu, 29 Nov 2001 22:13:53 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAU6Dr4e020386 for ipng-dist; Thu, 29 Nov 2001 22:13: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAU6Dn1V020379 for ; Thu, 29 Nov 2001 22:13:49 -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 WAA14469 for ; Thu, 29 Nov 2001 22:13:50 -0800 (PST) Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id XAA00022 for ; Thu, 29 Nov 2001 23:13:49 -0700 (MST) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id C45674B22; Fri, 30 Nov 2001 15:13:41 +0900 (JST) To: Bob Hinden , Steve Deering Cc: ipng@sunroof.eng.sun.com Subject: draft-itojun-ipv6-dialup-requirement-02.txt 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: itojun@iijlab.net Date: Fri, 30 Nov 2001 15:13:41 +0900 Message-ID: <108.1007100821@itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [I did not ask for presentation slot at IETF52] Here's summary of discussion we had at IETF51 for 01 revision of the draft, from meeting minutes. 02 is submitted with reference updates and minor clarifications. If my memory is correct the "action item" portion (the last 2 lines) is not handled yet. Let me know how to proceed. We had a couple of meetings among Japanese operators, both before and after 01 draft. Preferred options are: - /48 assignment, with ICMPv6 prefix delegation obstacle: ICMPv6 prefix delegation is still a draft, and ICMPv6 type/code is not assigned yet - /64 assignment, with RA (and possibly multilink subnet - from upstream operators the use of multilink subnet router won't be visible) The preference is already reflected in 02 drafts. 02 draft still tries to keep the operational option wide open, and documents a set of options operators can take (rather than presenting single scenario). There are a couple of reasons fo this: - different ISPs would have different operational requirement. - there's no real operational experiences gathered yet, due to the lack of usable equipments. At this moment most of the IPv6 ISPs are doing manual assignment on leased lines, or tunnels. I do think it is useful for us to pick a common (single) service model that works for multiple ISPs. itojun --- Requirements for IPv6 dialup operation / Jun-ichiro itojun Hagino ----------------------------------------------------------------- [Slides available at http://playground.sun.com/ipng/meetings.html] What is experience so far with dialup support in IIJ? Problem is that can not deploy dialup nationwide in IIJ. What are speakers preference of different options? Five different options. Not sure what is best. There are different scenarios that are appropriate. Deering: Good to get feedback from operational folks. Itojun: Has asked Japan operators forum. Can this be a w.g. item. Chairs thought it should be standards track. Not sure it should be IPv6. Need to discuss. ACTION: Chairs to talk to area directors to see what is best w.g. to take dialup operation requirements and move it forward onto standards track. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 30 01:42:59 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAU9gx1V020667 for ; Fri, 30 Nov 2001 01:42:59 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAU9gwe5020666 for ipng-dist; Fri, 30 Nov 2001 01: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAU9gt1V020659 for ; Fri, 30 Nov 2001 01:42:55 -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 BAA16716 for ; Fri, 30 Nov 2001 01:42:54 -0800 (PST) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA16531 for ; Fri, 30 Nov 2001 02:42:53 -0700 (MST) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.6/8.10.1) with ESMTP id fAU9gRk79219; Fri, 30 Nov 2001 10:42:27 +0100 (CET) Received: from elgar (elgar.heidelberg.ccrle.nec.de [192.168.102.180]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 84F71C040; Fri, 30 Nov 2001 10:42:33 +0100 (CET) Date: Fri, 30 Nov 2001 10:42:32 +0100 From: Martin Stiemerling To: Dave Marquardt , Nemeth Daniel Cc: ipng@sunroof.eng.sun.com Subject: Re: address autoconfiguration Message-ID: <24740000.1007113352@elgar> In-Reply-To: References: X-Mailer: Mulberry/2.1.1 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > You might be interested in DHCPv6. Try the DHCPv6 Internet Draft. > One location is This is outdated! The newest version is -21. > > > -- > Dave Marquardt > Sun Microsystems, Inc. > Austin, TX > +1 512 401-1077 > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 Nov 30 02:58:09 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUAw81V020891 for ; Fri, 30 Nov 2001 02:58:08 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAUAw8om020890 for ipng-dist; Fri, 30 Nov 2001 02:58: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUAw41V020883 for ; Fri, 30 Nov 2001 02:58: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 CAA13943 for ; Fri, 30 Nov 2001 02:58:05 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id DAA17803 for ; Fri, 30 Nov 2001 03:57:47 -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 FAA02142; Fri, 30 Nov 2001 05:57:59 -0500 (EST) Message-Id: <200111301057.FAA02142@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-icmp-v3-02.txt Date: Fri, 30 Nov 2001 05:57: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. This draft is a work item of the IPNG Working Group of the IETF. Title : Internet Control Message Protocol (ICMPv6)for the Internet Protocol Version 6 (IPv6) Specification Author(s) : A. Conta, S. Deering Filename : draft-ietf-ipngwg-icmp-v3-02.txt Pages : 23 Date : 29-Nov-01 This document specifies a set of Internet Control Message Protocol (ICMP) messages for use with version 6 of the Internet Protocol (IPv6). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-icmp-v3-02.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-icmp-v3-02.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-icmp-v3-02.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: <20011129143823.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipngwg-icmp-v3-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipngwg-icmp-v3-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011129143823.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 Nov 30 03:06:33 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUB6W1V020921 for ; Fri, 30 Nov 2001 03:06:32 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAUB6WjT020920 for ipng-dist; Fri, 30 Nov 2001 03:06: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUB6T1V020913 for ; Fri, 30 Nov 2001 03:06:29 -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 DAA15083 for ; Fri, 30 Nov 2001 03:06:28 -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 DAA23521 for ; Fri, 30 Nov 2001 03:06:27 -0800 (PST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-51.cisco.com [10.82.224.51]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA27625; Fri, 30 Nov 2001 06:05:49 -0500 (EST) Message-Id: <4.3.2.7.2.20011130055930.00bbcc68@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Nov 2001 06:00:23 -0500 To: Martin Stiemerling From: Ralph Droms Subject: Re: address autoconfiguration Cc: Dave Marquardt , Nemeth Daniel , ipng@sunroof.eng.sun.com In-Reply-To: <24740000.1007113352@elgar> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Until the -21 version is published at ftp.ietf.org, you can get the latest DHCPv6 draft at www.dhcp.org - Ralph Droms At 10:42 AM 11/30/2001 +0100, Martin Stiemerling wrote: >>You might be interested in DHCPv6. Try the DHCPv6 Internet Draft. >>One location is > >This is outdated! The newest version is -21. > >> >> >>-- >>Dave Marquardt >>Sun Microsystems, Inc. >>Austin, TX >>+1 512 401-1077 >>-------------------------------------------------------------------- >>IETF IPng Working Group Mailing List >>IPng Home 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 Nov 30 06:21:20 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUELK1V021305 for ; Fri, 30 Nov 2001 06:21:20 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAUELKI9021304 for ipng-dist; Fri, 30 Nov 2001 06:21: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUELF1V021294 for ; Fri, 30 Nov 2001 06:21:15 -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 GAA07463 for ; Fri, 30 Nov 2001 06:21:16 -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 GAA22812 for ; Fri, 30 Nov 2001 06:21:15 -0800 (PST) Received: from localhost ([3ffe:501:100f:10c1:f99f:ffff:1dbd:11ff]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fAUEL5314041; Fri, 30 Nov 2001 23:21:06 +0900 (JST) Date: Fri, 30 Nov 2001 23:21:03 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: schild@uni-muenster.de Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: reverse delegation under ip6.arpa.? In-Reply-To: <20011128083531.C4C631090@postfix1.uni-muenster.de> References: <20011128083531.C4C631090@postfix1.uni-muenster.de> User-Agent: Wanderlust/2.7.5 (Too Funky) 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 980905(IM100) Lines: 45 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've cc'ed this reply to namedroppers, which might be a better place to discuss this issue. >>>>> On Wed, 28 Nov 2001 09:35:53 +0100, >>>>> JOIN Project Team said: > recently I was very surprised, when I found that there is an existing > ip6.arpa. domain, where the reverse IPv6 nibble format is delegated to > the registries. > I found no mail or announcement anywhere that from now on ip6.arpa should be > used for the reverse nibble format. Is that a fact, or is ip6.arpa just a > global testing scenario that is confusing me? > I know that ip6.arpa should be used instead of ip6.int for political reasons, > but I always expected to stay the nibble format in ip6.int and the bit-string > labels to appear in ip6.arpa someday. > Well, ok, now that the bit-string labels are to be changed to experimental, > that might be not possible anymore. But I'm not sure if it such a good idea > to just change the zones. > Right now there is a well established and well working tree under ip6.int. > If there will grow a second tree under ip6.arpa now, things might become > very confusing. > As a resolver, I don't know if I have to lookup the name for my IPv6 address > starting with .arpa or starting .int. If I lookup in the wrong tree, I might > get no answer, while the correct one is in the other tree. Yes, I could > lookup in both trees, but if the answers differ, which one is the correct one? > Is there a solution for this? What is the current policy? Maybe I am confused > because I missed something? I'd also like to know the current policy on this. The current status is really confusing and can be a serious barrier to deploy IPv6. Honestly, if we are allowed to live with the current spec (i.e. ip6.int. with the nibble format), I'll be really happy. However, the transition to ip6.arpa is inevitable, we should be ready for this as soon as possible, both in operation and in implementation. 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 Nov 30 06:42:56 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUEgu1V021445 for ; Fri, 30 Nov 2001 06:42:56 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAUEguUd021444 for ipng-dist; Fri, 30 Nov 2001 06:42: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUEgq1V021437 for ; Fri, 30 Nov 2001 06:42:52 -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 GAA24936 for ; Fri, 30 Nov 2001 06:42:52 -0800 (PST) Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA16955 for ; Fri, 30 Nov 2001 07:42:34 -0700 (MST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id IAA24070 for ; Fri, 30 Nov 2001 08:40:06 -0600 Received: from d04mc200.raleigh.ibm.com (d04mc200.raleigh.ibm.com [9.67.228.62]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fAUEgmL116524 for ; Fri, 30 Nov 2001 09:42:48 -0500 Subject: Re: GETNAMEINFO questions ............... To: "Lori Napoli" Cc: ipng@sunroof.eng.sun.com X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Roy Brabson" Date: Fri, 30 Nov 2001 09:42:25 -0500 X-MIMETrack: Serialize by Router on D04MC200/04/M/IBM(Release 5.0.8 |June 18, 2001) at 11/30/2001 09:42:47 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thursday, 11/29/2001 at 08:55 EST, Lori Napoli/Raleigh/IBM@IBMUS wrote: > draft-ietf-ipngwg-rfc2553bis-04.txt section 6.2 states: > > The flags argument is a flag that changes the default actions of the > function. By default the fully-qualified domain name (FQDN) for the host > shall be returned, but: > > - If the flag bit NI_NOFQDN is set, only the node name portion of the > FQDN shall be returned for local hosts. > > - If the flag bit NI_NUMERICHOST is set, the numeric form of the > host's address shall be returned instead of its name, under all > circumstances. > > - If the flag bit NI_NAMEREQD is set, an error shall be returned if the > host's name cannot be located. > > - If the flag bit NI_NUMERICSERV is set, the numeric form of the > service address shall be returned (for example, its port number) > instead of > its name, under all circumstances. > > - If the flag bit NI_NUMERICSCOPE is set, the numeric form of the > scope identifier shall be returned (for example, interface index) > instead of its name. This flag is ignored if the sa argument is > not an IPv6 address. > > - If the flag bit NI_DGRAM is set, this indicates that the service is > a datagram service (SOCK_DGRAM). The default behavior shall assume that > the service is a stream service (SOCK_STREAM). > > So what if NI_NUMERICHOST is not set and NI_NAMEREQD is not set. > Getnameinfo attempts to resolve the name via DNS query and scan of the > local files. If the host name is not resolved, do we return the numeric > form or an error? You should return the numeric form. The pertinent text which describes this situation appears just prior to the flags you included above. > Also, if NI_NUMERICSERV is not set, getnameinfo calls getservbyport to scan > the local service name file and if the service name is not resolved we > return the numeric form. So, how can the application calling getnameinfo > determine that the resolution of the service name failed since it can > receive the numeric form regardless of NI_NUMERICSERV setting. It would > have to determine that numeric form was returned and NI_NUMERICSERV had not > been specified. There doesn't seem to be a service name equivalent of > NI_NAMEREQD. Should getnameinfo return the numeric form of the service > name if name resolution fails or should we return an error? Again, the draft specifies that the numeric form be returned. And you seem to be correct - there isn't an equivalent to NI_NAMEREQD for the service name. I guess any application which was really interested whether the port number could be found in the service name file would need to use strcmp() to compare value returned to the value which was input, and if they are the same and NI_NUMERICSERV was not coded infer (possibly incorrectly if someone coded a numeric service name in the local file) that the name could not be located. Roy Brabson -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 Nov 30 07:09:44 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUF9i1V021514 for ; Fri, 30 Nov 2001 07:09:44 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAUF9iLC021513 for ipng-dist; Fri, 30 Nov 2001 07:09: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUF9d1V021506 for ; Fri, 30 Nov 2001 07:09: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 HAA22532 for ; Fri, 30 Nov 2001 07:09:39 -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 IAA27550 for ; Fri, 30 Nov 2001 08:09:37 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:f99f:ffff:1dbd:11ff]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fAUF9U314429; Sat, 1 Dec 2001 00:09:30 +0900 (JST) Date: Sat, 01 Dec 2001 00:09:28 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Lilian Fernandes Cc: IPNG Working Group Subject: Re: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-03.txt In-Reply-To: References: User-Agent: Wanderlust/2.7.5 (Too Funky) 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 980905(IM100) Lines: 38 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 29 Nov 2001 14:45:09 -0600 (CST), >>>>> Lilian Fernandes said: > Is this draft going to RFC status anytime soon? A lot of the basic > behavior has changed between versions 02 and 03. Most of them are clarifications on obscure stuff in the former drafts and results of solving open issues. I believe the current spec is still quite compatible with the former behavior in practical point of view. I admit, however, that some of the changes are controversial and that some of them surely break the backward compatibility. I'd like to discuss the issues in the ML and (if we have time) in Salt Lake City. > Would you say that version 03 is a fairly stabilized draft? I'm not sure how I can answer the question, but at least I don't think this can be the last version to the RFC status due to the controversial points above. But, the basic concept in this revision is: - clarify all obscure points in the former spec - remove all definitions and descriptions related to on-going stuff (since they can delay the fix of this API) - no new stuff is not included (nor will be in the future versions) - fix/change the behaviors which were known to be suitable to the other standard specs and implementation experiences (this part should be the most controversial point, and thus I tried to keep the effect of the changes as small as possible) My plan is to concentrate on the controversial stuff, to reach consensus, and to fix the API, 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 Fri Nov 30 07:14:36 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUFEa1V021535 for ; Fri, 30 Nov 2001 07:14:36 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAUFEa4Y021534 for ipng-dist; Fri, 30 Nov 2001 07:14: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUFEV1V021527 for ; Fri, 30 Nov 2001 07:14:31 -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 HAA22283 for ; Fri, 30 Nov 2001 07:14:31 -0800 (PST) Received: from berkshire.research.att.com (union1UBR1-5-hfc-0252-40e84946.rdc1.nj.comcastatwork.com [64.232.73.70]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA14620 for ; Fri, 30 Nov 2001 08:14:30 -0700 (MST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id A11B17B55; Fri, 30 Nov 2001 10:14:24 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: schild@uni-muenster.de, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: reverse delegation under ip6.arpa.? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Nov 2001 10:14:24 -0500 Message-Id: <20011130151424.A11B17B55@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , JINMEI Tatuya / =?ISO-2022-JP?B? GyRCP0BMQEMjOkgbKEI=?= writes: >I've cc'ed this reply to namedroppers, which might be a better place >to discuss this issue. > >>>>>> On Wed, 28 Nov 2001 09:35:53 +0100, >>>>>> JOIN Project Team said: > >> recently I was very surprised, when I found that there is an existing >> ip6.arpa. domain, where the reverse IPv6 nibble format is delegated to >> the registries. > >> I found no mail or announcement anywhere that from now on ip6.arpa should be > >> used for the reverse nibble format. Is that a fact, or is ip6.arpa just a >> global testing scenario that is confusing me? > >> I know that ip6.arpa should be used instead of ip6.int for political reasons >, >> but I always expected to stay the nibble format in ip6.int and the bit-strin >g >> labels to appear in ip6.arpa someday. > >> Well, ok, now that the bit-string labels are to be changed to experimental, >> that might be not possible anymore. But I'm not sure if it such a good idea >> to just change the zones. > >> Right now there is a well established and well working tree under ip6.int. >> If there will grow a second tree under ip6.arpa now, things might become >> very confusing. >> As a resolver, I don't know if I have to lookup the name for my IPv6 address > >> starting with .arpa or starting .int. If I lookup in the wrong tree, I might > >> get no answer, while the correct one is in the other tree. Yes, I could >> lookup in both trees, but if the answers differ, which one is the correct on >e? > >> Is there a solution for this? What is the current policy? Maybe I am confuse >d >> because I missed something? > >I'd also like to know the current policy on this. The current status >is really confusing and can be a serious barrier to deploy IPv6. > >Honestly, if we are allowed to live with the current spec >(i.e. ip6.int. with the nibble format), I'll be really happy. >However, the transition to ip6.arpa is inevitable, we should be ready >for this as soon as possible, both in operation and in implementation. See RFC 3152, aka BCP 49. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.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 Nov 30 07:25:58 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUFPv1V021567 for ; Fri, 30 Nov 2001 07:25:57 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAUFPunq021566 for ipng-dist; Fri, 30 Nov 2001 07:25: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUFPq1V021559 for ; Fri, 30 Nov 2001 07:25: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 HAA00417 for ; Fri, 30 Nov 2001 07:25:52 -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 IAA02446 for ; Fri, 30 Nov 2001 08:25:50 -0700 (MST) Received: from localhost ([3ffe:501:100f:10c1:f99f:ffff:1dbd:11ff]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id fAUFPi314591; Sat, 1 Dec 2001 00:25:44 +0900 (JST) Date: Sat, 01 Dec 2001 00:25:41 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Steven M. Bellovin" Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: reverse delegation under ip6.arpa.? In-Reply-To: <20011130151424.A11B17B55@berkshire.research.att.com> References: <20011130151424.A11B17B55@berkshire.research.att.com> User-Agent: Wanderlust/2.7.5 (Too Funky) 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 980905(IM100) Lines: 27 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Fri, 30 Nov 2001 10:14:24 -0500, >>>>> "Steven M. Bellovin" said: >> I'd also like to know the current policy on this. The current status >> is really confusing and can be a serious barrier to deploy IPv6. >> >> Honestly, if we are allowed to live with the current spec >> (i.e. ip6.int. with the nibble format), I'll be really happy. >> However, the transition to ip6.arpa is inevitable, we should be ready >> for this as soon as possible, both in operation and in implementation. > See RFC 3152, aka BCP 49. I should have been clearer in the previous message...I know the RFC, so my question is does the RFC force us to obsolete ip6.arpa and migrate to ip6.arpa.? and is this the only way to go? I'm not making an objection, I'm just asking. If the answer is yes, I'm just okay with it. 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 Nov 30 07:29:52 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUFTq1V021589 for ; Fri, 30 Nov 2001 07:29:52 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAUFTqTT021588 for ipng-dist; Fri, 30 Nov 2001 07: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 engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUFTl1V021581 for ; Fri, 30 Nov 2001 07:29: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 HAA24777 for ; Fri, 30 Nov 2001 07:29:47 -0800 (PST) Received: from berkshire.research.att.com (union1UBR1-5-hfc-0252-40e84946.rdc1.nj.comcastatwork.com [64.232.73.70]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03707 for ; Fri, 30 Nov 2001 08:29:46 -0700 (MST) Received: from research.att.com (localhost [127.0.0.1]) by berkshire.research.att.com (Postfix) with ESMTP id 8B9527B55; Fri, 30 Nov 2001 10:29:45 -0500 (EST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: "Steven M. Bellovin" To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org Subject: Re: reverse delegation under ip6.arpa.? Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Nov 2001 10:29:45 -0500 Message-Id: <20011130152945.8B9527B55@berkshire.research.att.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In message , JINMEI Tatuya / =?ISO-2022-JP?B? GyRCP0BMQEMjOkgbKEI=?= writes: >>>>>> On Fri, 30 Nov 2001 10:14:24 -0500, >>>>>> "Steven M. Bellovin" said: > >>> I'd also like to know the current policy on this. The current status >>> is really confusing and can be a serious barrier to deploy IPv6. >>> >>> Honestly, if we are allowed to live with the current spec >>> (i.e. ip6.int. with the nibble format), I'll be really happy. >>> However, the transition to ip6.arpa is inevitable, we should be ready >>> for this as soon as possible, both in operation and in implementation. > >> See RFC 3152, aka BCP 49. > >I should have been clearer in the previous message...I know the RFC, >so my question is > > does the RFC force us to obsolete ip6.arpa and migrate to ip6.arpa.? > and > is this the only way to go? > >I'm not making an objection, I'm just asking. If the answer is yes, >I'm just okay with it. Here's the relevant text from the RFC: > 2. Obsoleted Usage This document deprecates references to IP6.INT in [RFC1886] section 2.5, [RFC2553] section 6.2.3, [RFC2766] section 4.1, [RFC2772] section 7.1.c, and [RFC2874] section 2.5. In this context, 'deprecate' means that the old usage is not appropriate for new implementations, and IP6.INT will likely be phased out in an orderly fashion. So I'd say that the answer to your question is yes, we should move to ip6.arpa for all new work, and we should convert old systems as best we can. --Steve Bellovin, http://www.research.att.com/~smb Full text of "Firewalls" book now at http://www.wilyhacker.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 Nov 30 08:07:02 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUG711V021668 for ; Fri, 30 Nov 2001 08:07:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAUG71Et021667 for ipng-dist; Fri, 30 Nov 2001 08:07: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUG6w1V021660 for ; Fri, 30 Nov 2001 08:06: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 IAA01788 for ; Fri, 30 Nov 2001 08:06:57 -0800 (PST) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA04136 for ; Fri, 30 Nov 2001 09:07:23 -0700 (MST) Received: from randy by rip.psg.com with local (Exim 3.33 #1) id 169qAQ-0008WF-00; Fri, 30 Nov 2001 08:05:34 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= Cc: schild@uni-muenster.de, ipng@sunroof.eng.sun.com, dns op wg Subject: Re: reverse delegation under ip6.arpa.? References: <20011128083531.C4C631090@postfix1.uni-muenster.de> Message-Id: Date: Fri, 30 Nov 2001 08:05:34 -0800 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I've cc'ed this reply to namedroppers, which might be a better place > to discuss this issue. try dnsop, as this is not a protocol issue. have a look at rfc 3152. also look at mailing list archives on the subject of educating folk that the bit boundary and label type issues have nothing to do with the parent sld name. 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 Fri Nov 30 10:55:01 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUIt11V022022 for ; Fri, 30 Nov 2001 10:55:01 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fAUIt1Mq022021 for ipng-dist; Fri, 30 Nov 2001 10:55: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fAUIsu1V022014 for ; Fri, 30 Nov 2001 10:54:56 -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 KAA05538 for ; Fri, 30 Nov 2001 10:54:56 -0800 (PST) Received: from roll.mentat.com ([192.88.122.129]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA26073 for ; Fri, 30 Nov 2001 11:54:55 -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 KAA24060; Fri, 30 Nov 2001 10:51:15 -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 KAA09992; Fri, 30 Nov 2001 10:51:15 -0800 (PST) Received: (from tim@localhost) by feller.mentat.com (8.9.3+Sun/8.9.3) id KAA29712; Fri, 30 Nov 2001 10:56:21 -0800 (PST) Date: Fri, 30 Nov 2001 10:56:21 -0800 (PST) From: Tim Hartrick Message-Id: <200111301856.KAA29712@feller.mentat.com> To: lilianf@austin.ibm.com, jinmei@isl.rdc.toshiba.co.jp Subject: Re: I-D ACTION:draft-ietf-ipngwg-rfc2292bis-03.txt Cc: ipng@sunroof.eng.sun.com X-Sun-Charset: US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Lilian, Jinmei, > > > Is this draft going to RFC status anytime soon? A lot of the basic > > behavior has changed between versions 02 and 03. > No kidding. I have pretty strong feelings that the changes related to section 4.1 are bad. Primarily because this behavior was specified more that two years ago. It has been implemented by multiple vendors. The previous definition of how ancillary data was to be received by TCP applications was workable as written, given some clarifications. A Wholesale discarding of the mechanism was unnecessary. I regret that I missed the discussion which resulted in the "consensus" to change this. It should be changed back to its previous behavior. > Most of them are clarifications on obscure stuff in the former drafts > and results of solving open issues. I believe the current spec is > still quite compatible with the former behavior in practical point of > view. > > I admit, however, that some of the changes are controversial and that > some of them surely break the backward compatibility. I'd like to > discuss the issues in the ML and (if we have time) in Salt Lake City. > > > Would you say that version 03 is a fairly stabilized draft? > Hopefully not, in my opinion. tim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri Nov 30 16:45:50 2001 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB10jn1V022850 for ; Fri, 30 Nov 2001 16:45:49 -0800 (PST) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.2.Beta1+Sun/8.12.2.Beta1/Submit) id fB10jnbV022849 for ipng-dist; Fri, 30 Nov 2001 16:45: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.Beta1+Sun/8.12.2.Beta1) with ESMTP id fB10jj1V022842 for ; Fri, 30 Nov 2001 16:45: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 QAA24591 for ; Fri, 30 Nov 2001 16:45:47 -0800 (PST) Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA03429 for ; Fri, 30 Nov 2001 17:45:46 -0700 (MST) Received: from zed.isi.edu (zed.isi.edu [128.9.160.57]) by tnt.isi.edu (8.11.6/8.11.2) with ESMTP id fB10jig15277; Fri, 30 Nov 2001 16:45:44 -0800 (PST) From: Bill Manning Received: (from bmanning@localhost) by zed.isi.edu (8.11.0/8.8.6) id fB10jiQ03409; Fri, 30 Nov 2001 16:45:44 -0800 Message-Id: <200112010045.fB10jiQ03409@zed.isi.edu> Subject: Re: reverse delegation under ip6.arpa.? To: jinmei@isl.rdc.toshiba.co.jp (JINMEITatuya/=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=) Date: Fri, 30 Nov 2001 16:45:44 -0800 (PST) Cc: schild@uni-muenster.de, ipng@sunroof.eng.sun.com, namedroppers@ops.ietf.org In-Reply-To: from "JINMEITatuya/=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=" at Nov 30, 2001 11:21:03 PM X-Mailer: ELM [version 2.5 PL3] 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'd also like to know the current policy on this. The current status % is really confusing and can be a serious barrier to deploy IPv6. % % Honestly, if we are allowed to live with the current spec % (i.e. ip6.int. with the nibble format), I'll be really happy. % However, the transition to ip6.arpa is inevitable, we should be ready % for this as soon as possible, both in operation and in implementation. % % JINMEI, Tatuya % Communication Platform Lab. % Corporate R&D Center, Toshiba Corp. % jinmei@isl.rdc.toshiba.co.jp The IETF policy is clear. ip6.arpa. It is also true that this policy was not based on any technical grounds. That said, the IETF has also depricated RIP. And there are still some questions about the bitstring format vs nibble format. So I intend to continue to use the proven format for now, at least until there are strong technical reasons to migrate. -- --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 --------------------------------------------------------------------