From owner-ipng@sunroof.eng.sun.com Thu May 1 00:34:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h417YYhs001011; Thu, 1 May 2003 00:34:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h417YY8O001010; Thu, 1 May 2003 00:34:34 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h417YUhs001003 for ; Thu, 1 May 2003 00:34:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h417XIuc017768 for ; Thu, 1 May 2003 00:33:18 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id AAA07543 for ; Thu, 1 May 2003 00:33:12 -0700 (PDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 4871893; Thu, 1 May 2003 16:33:09 +0900 (JST) To: George Michaelson Cc: Jun Murai , ipng@sunroof.eng.sun.com In-reply-to: ggm's message of Thu, 01 May 2003 11:30:24 +1000. <20030501113024.53beed26.ggm@apnic.net> 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: RFID in V6? From: itojun@iijlab.net Date: Thu, 01 May 2003 16:33:09 +0900 Message-Id: <20030501073309.4871893@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >Good to hear an architecture/planning process is in progress. > >For the dumb ic-tags, having a mapping could still be useful for some people. In >a previous work context, they discussed the 'tag all cans of soup' model, and >wanted to present a view where these tagged devices asserted as IP addressable >objects via some other box. This means you can know the RFID for a class of >objects, and effectively 'ping' them to find where there is a smarter box which >knows about them. Doing it in applications space implies restricting yourself to >that application-space model of what behaviours you want, while doing it in an >IP address namespace might be more general > >I didn't realize the tags now exceeded 128bits. That also implies the reverse >mapping function: embed all IPv6 128bit addresses as a sub-set of the bigger >footprint RFID. Then, you can make more complex RF equipment which is a computer >but it responds for a legal RFID on an RFID scanner in that RF space. That might >require IANA or somebody to ask the RFID agencies for a prefix in 256bit space >which can reserve the 128bits under there for IPv6. it seems that there has to be much debates, but anyways... i don't think it wise to make direct mapping between RFID and IPv6. using RFID for random-number-cookie for IPv6 address (like EUI64) is okay, but anything beyond that looks unwise to me. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 1 07:38:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41Ecphs002114; Thu, 1 May 2003 07:38:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h41EcpwZ002113; Thu, 1 May 2003 07:38:51 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41Ecmhs002106 for ; Thu, 1 May 2003 07:38:48 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h41EbZKw025139 for ; Thu, 1 May 2003 07:37:35 -0700 (PDT) Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id HAA24745 for ; Thu, 1 May 2003 07:37:29 -0700 (PDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by rtp-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h41EakWS018401; Thu, 1 May 2003 10:36:47 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-797.cisco.com [10.82.243.29]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA01118; Thu, 1 May 2003 10:36:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20030501095907.00b99538@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 May 2003 10:07:10 -0400 To: dhcwg@ietf.org, ipng@sunroof.eng.sun.com From: Ralph Droms Subject: Stateless DHCPv6 == "Other stateful configuration"? In-Reply-To: References: <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> <4.3.2.7.2.20030411113053.042c1cb0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The following comment was posted to the dhcwg mailing list during the WG last call on draft-ietf-dhc-dhcpv6-stateless-00.txt Because the issue touches on RFC 2461 and RFC 2462, I've cross-posted to both the ipv6 and dhc WG mailing lists. Please respond to the dhcwg@ietf.org mailing list - RD At 12:10 AM 4/15/2003 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >4. interaction/consistency with RFC 246[12] > >How the stateless usage is related to the "Other stateful >configuration" of router advertisements defined in RFC 2461 and 2462? >Is the client (host) expected to start the stateless DHCPv6 when it >receives a router advertisement with the "Other stateful >configuration" flag being set? If so, how can we interpret the >"inconsistency" between the "stateless" DHCPv6 usage and the >"stateful" router advertisement flag? Perhaps this is just a matter >of wording. But, if RFC 2461 really intended a "stateful" protocol >(i.e., where a server maintains lease state for the other >configuration parameters), we may need to consider the gap as a >fundamental architecture issue. Well, I guess we first need to agree that draft-ietf-dhc-dhcpv6-stateless-00.txt meets the expectation of "Other stateful configuration" in RFC 2461. I intended draft-ietf-dhc-dhcpv6-stateless-00.txt to be the configuration protocol used when the "Other stateful configuration" flag is set. Is there any objection to explicitly specifying draft-ietf-dhc-dhcpv6-stateless-00.txt for this use? If there is no objection, we'll need to adjust the words to make the connection explicit and avoid confusion... - Ralph -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 1 10:34:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41HYehs002832; Thu, 1 May 2003 10:34:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h41HYece002831; Thu, 1 May 2003 10:34:40 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41HYahs002824 for ; Thu, 1 May 2003 10:34:36 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h41HXNKw028465 for ; Thu, 1 May 2003 10:33:23 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA15659 for ; Thu, 1 May 2003 10:33:18 -0700 (PDT) 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 KAA17692; Thu, 1 May 2003 10:32:30 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h41HWST14284; Thu, 1 May 2003 10:32:28 -0700 X-mProtect: <200305011732> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.159, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdTPVnpr; Thu, 01 May 2003 10:32:26 PDT Message-Id: <4.3.2.7.2.20030501101050.037b17e0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 01 May 2003 10:20:52 -0700 To: Erik.Nordmark@Sun.COM, Thomas Narten From: Bob Hinden Subject: Request to Advance "IPv6 Flow Label Specification" Cc: ipng@sunroof.eng.sun.com, iesg-secretary@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Erik, Thomas, The chairs of the IPv6 working group, on behalf of the working group, request that the following document be published as a Proposed Standard: Title : IPv6 Flow Label Specification Author(s) : J. Rajahalme, A. Conta, B. Carpenter, S. Deering Filename : draft-ietf-ipv6-flow-label-07.txt Pages : 9 Date : 2003-4-11 A working group last call for this document was completed on 11 March 2003. This draft resolves issues raised during the last call. Bob Hinden / Margaret Wasserman IPv6 Working Group Chairs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 1 10:49:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41HnLhs003381; Thu, 1 May 2003 10:49:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h41HnLKP003378; Thu, 1 May 2003 10:49:21 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41HnHhs003364 for ; Thu, 1 May 2003 10:49:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h41Hm3uc015808 for ; Thu, 1 May 2003 10:48:03 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA25158 for ; Thu, 1 May 2003 10:47:58 -0700 (PDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 01 May 2003 10:47:56 -0700 Reply-To: From: "Tony Hain" To: "'Thomas Narten'" , "'Erik Nordmark'" Cc: , Subject: My point about the ambiguity of the question Date: Thu, 1 May 2003 10:47:55 -0700 Message-ID: <086001c31009$cc4e9d00$261e4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h41HnHhs003366 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thomas & Erik, These notes illustrate my point about the ambiguity of the question. First, one has to question how well Ted and others were informed if their issue is all about ambiguity. We have several proposals to remove the ambiguity in the FEC0::/10 prefix that are compatible with existing implementations, so were their votes really about completing that work to remove ambiguity? If so, deprecating the prefix would not be a step toward completing that. But to my point. As the second note shows, part of the goal of some votes is to disallow a network manager the ability to limit access or visibility to some of their nodes. The IETF is not in the role of designing networks, and limiting access and visibility is an operational issue that the IETF doesn't get to decide. The question was ambiguous. Individual interpretations of the outcome drove YES votes for architecturally divergent goals, some of which are not in the IETFs purview to decide. Tony Theodore Ts'o wrote: > I certainly agree that it's all about ambiguous addresses and > not about about reachability. And it's why I have to agree > with Keith that Site Local addresses are a bad idea, and why > ditching them is absolutely the right thing. Keith Moore wrote: > > My point was that there are topology locators that are only viable > > within a scope defined by the local network manager. > > yes, we know this. it's a bad idea, and we need to stop > pretending it's a legitimate thing to do. that way, when the > network manager does this, it's his fault when things break. > > network managers do have legitimate needs that must be > respected. this is not one of them. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 1 12:27:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41JRmhs005001; Thu, 1 May 2003 12:27:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h41JRmHp005000; Thu, 1 May 2003 12:27:48 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41JRihs004993 for ; Thu, 1 May 2003 12:27:44 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h41JQUuc018321 for ; Thu, 1 May 2003 12:26:31 -0700 (PDT) Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA17160 for ; Thu, 1 May 2003 13:26:25 -0600 (MDT) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h41JLY011481; Thu, 1 May 2003 12:21:34 -0700 (PDT) Message-Id: <200305011921.h41JLY011481@gamma.isi.edu> To: IETF-Announce: ; Subject: RFC 3316 on Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts Cc: rfc-editor@rfc-editor.org, ipng@sunroof.eng.sun.com From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Thu, 01 May 2003 12:21:33 -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3316 Title: Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts Author(s): J. Arkko, G. Kuijpers, H. Soliman, J. Loughney, J. Wiljakka Status: Informational Date: April 2003 Mailbox: jari.arkko@ericsson.com, gerben.a.kuijpers@ted.ericsson.se, john.loughney@nokia.com, hesham.soliman@era.ericsson.se, juha.wiljakka@nokia.com Pages: 22 Characters: 48741 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipv6-cellular-host-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3316.txt As the deployment of second and third generation cellular networks progresses, a large number of cellular hosts are being connected to the Internet. Standardization organizations are making Internet Protocol version 6 (IPv6) mandatory in their specifications. However, the concept of IPv6 covers many aspects and numerous specifications. In addition, the characteristics of cellular links in terms of bandwidth, cost and delay put special requirements on how IPv6 is used. This document considers IPv6 for cellular hosts that attach to the General Packet Radio Service (GPRS), or Universal Mobile Telecommunications System (UMTS) networks. This document also lists basic components of IPv6 functionality and discusses some issues relating to the use of these components when operating in these networks. This document is a product of the IP Version 6 Working Group Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030501121947.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3316 --OtherAccess Content-Type: Message/External-body; name="rfc3316.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030501121947.RFC@RFC-EDITOR.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 May 1 13:54:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41Ksnhs006186; Thu, 1 May 2003 13:54:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h41KsnjH006185; Thu, 1 May 2003 13:54:49 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41Ksjhs006178 for ; Thu, 1 May 2003 13:54:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h41KrWKw009740 for ; Thu, 1 May 2003 13:53:32 -0700 (PDT) Received: from defiant.dfw.nostrum.com (adsl-65-67-187-82.dsl.rcsntx.swbell.net [65.67.187.82]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id OAA02009 for ; Thu, 1 May 2003 14:53:19 -0600 (MDT) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h41KppL15747; Thu, 1 May 2003 15:51:52 -0500 Message-ID: <000801c31023$818f5560$93b58742@ssprunk> From: "Stephen Sprunk" To: , Cc: "'Margaret Wasserman'" , "'Michael Thomas'" , "'Randy Bush'" , "'Keith Moore'" , , , References: <07f301c30f6b$87a28c00$261e4104@eagleswings> <200305011608.h41G8Dxj004081@turing-police.cc.vt.edu> Subject: Re: site-local != NAT Date: Thu, 1 May 2003 15:48:28 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk [ Note to all: can we please take all of these IPv6 threads off the main IETF list? Anyone interested can join the IPNG list ] Thus spake > Right - and the entire problem with "site local" addresses is that they > are almost by definition ambiguous if they ever escape. The host > sending the opaque blob has no a priori way of knowing if the blob > will be in the *right* scope when you get there. So if what we call a "site local" address is always unique, even between sites, that would pacify you? There is no inherent requirement that SL addresses be ambiguous, and there are several drafts out there on how to ensure they're not. "Site local" just means the address is only _reachable_ from its local site. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 1 14:00:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41L0Qhs006372; Thu, 1 May 2003 14:00:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h41L0QIc006371; Thu, 1 May 2003 14:00:26 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41L0Lhs006364 for ; Thu, 1 May 2003 14:00:21 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h41Kx8Kw011738 for ; Thu, 1 May 2003 13:59:08 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA09977 for ; Thu, 1 May 2003 14:59:02 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h41Ksvv16007; Thu, 1 May 2003 16:54:58 -0400 (EDT) Date: Thu, 1 May 2003 16:54:57 -0400 From: Keith Moore To: "Stephen Sprunk" Cc: moore@cs.utk.edu, Valdis.Kletnieks@vt.edu, alh-ietf@tndh.net, mrw@windriver.com, mat@cisco.com, randy@psg.com, cos@aaaaa.org, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: site-local != NAT Message-Id: <20030501165457.55ad6555.moore@cs.utk.edu> In-Reply-To: <000801c31023$818f5560$93b58742@ssprunk> References: <07f301c30f6b$87a28c00$261e4104@eagleswings> <200305011608.h41G8Dxj004081@turing-police.cc.vt.edu> <000801c31023$818f5560$93b58742@ssprunk> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > There is no inherent requirement that SL addresses be ambiguous, and > there are several drafts out there on how to ensure they're not. for that matter, there's no inherent requirement that there be any set of addresses that is defined in the architecture to be filtered at some arbitrary boundary. in other words, there's no inherent requirement for SLs at all. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 1 14:04:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41L4Whs006572; Thu, 1 May 2003 14:04:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h41L4V4l006571; Thu, 1 May 2003 14:04:31 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41L4Rhs006558 for ; Thu, 1 May 2003 14:04:28 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h41L3EKw013237 for ; Thu, 1 May 2003 14:03:14 -0700 (PDT) Received: from defiant.dfw.nostrum.com (adsl-65-67-187-82.dsl.rcsntx.swbell.net [65.67.187.82]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h41L39rZ003309 for ; Thu, 1 May 2003 14:03:09 -0700 (PDT) Received: from ssprunk (IDENT:sprunk@localhost [127.0.0.1]) by defiant.dfw.nostrum.com (8.11.3/8.11.3) with SMTP id h41L2mL16073; Thu, 1 May 2003 16:02:48 -0500 Message-ID: <004001c31025$08661cd0$93b58742@ssprunk> From: "Stephen Sprunk" To: "Keith Moore" , Cc: , , , References: <20030430225812.481e47f4.moore@cs.utk.edu><086301c31009$d3251a00$261e4104@eagleswings> <20030501143643.3c6418f7.moore@cs.utk.edu> Subject: Re: what the "scope" disagreement is about Date: Thu, 1 May 2003 15:58:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake "Keith Moore" > being able to distinguish an ambiguous address from a global address > doesn't solve the problem of requiring hosts or apps to be aware of > topology in order to make address selection. A host/app needs to be similarly aware of topology (and security policy) to make any reasonable selection between multiple global addresses. Adding non-globals to the mix doesn't make things significantly worse. > > Yes, we need to complete the work on making the 38 bits globally > > unique, but that can't happen if we start by eliminating the first 10. > > If we can agree on how to make the first 48 bits globally unique, does > it really matter what values are assigned to the first 10 bits? Yes, it does. Having a common prefix for non-global addresses makes the job of network managers much simpler, and thus reduces the likelihood of leaks. Does it need to be a 10-bit prefix? Not really, but FEC0::/10 is already there. > (yes, GUPIs, NOT SLs. they WILL be routed between sites, for good > reasons, and we shouldn't try to stop this) Since this is the first time I've seen "GUPI" used, should I assume that means a globally unique provider-independent prefix which isn't globally routed? If so, I think you're using that term in the same sense Tony uses SL. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 1 14:34:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41LYwhs007675; Thu, 1 May 2003 14:34:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h41LYwYm007674; Thu, 1 May 2003 14:34:58 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h41LYrhs007664 for ; Thu, 1 May 2003 14:34:53 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h41LXeKw024537 for ; Thu, 1 May 2003 14:33:40 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA04828 for ; Thu, 1 May 2003 15:33:34 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h41LXFv16473; Thu, 1 May 2003 17:33:15 -0400 (EDT) Date: Thu, 1 May 2003 17:33:15 -0400 From: Keith Moore To: "Stephen Sprunk" Cc: moore@cs.utk.edu, alh-ietf@tndh.net, cos@aaaaa.org, ietf@ietf.org, ipng@sunroof.eng.sun.com Subject: Re: what the "scope" disagreement is about Message-Id: <20030501173315.6daa9fec.moore@cs.utk.edu> In-Reply-To: <004001c31025$08661cd0$93b58742@ssprunk> References: <20030430225812.481e47f4.moore@cs.utk.edu> <086301c31009$d3251a00$261e4104@eagleswings> <20030501143643.3c6418f7.moore@cs.utk.edu> <004001c31025$08661cd0$93b58742@ssprunk> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 1 May 2003 15:58:25 -0500 "Stephen Sprunk" wrote: > Thus spake "Keith Moore" > > being able to distinguish an ambiguous address from a global address > > doesn't solve the problem of requiring hosts or apps to be aware of > > topology in order to make address selection. > > A host/app needs to be similarly aware of topology (and security > policy) to make any reasonable selection between multiple global > addresses. agree. > Adding non-globals to the mix doesn't make things significantly worse. Disagree. First, it immediately reduces the available choices, and thus, the potential for poor choices (since SLs are more often poor choices than not). Second, it pushes the burden of routing back into the network where it belongs. Third, while it's possible (though unattractive) for the network to supply some topology information to hosts in a world where identifiers for points in the topology are all are taken from the same name space, having ambiguous addresses makes this completely infeasible. > > If we can agree on how to make the first 48 bits globally unique, > > does it really matter what values are assigned to the first 10 bits? > > Yes, it does. Having a common prefix for non-global addresses makes > the job of network managers much simpler Not clear; since it doesn't necessarily give them the flexibility they need. The idea that a network has only one boundary of interest is of fairly limited applicability; it's certainly not something that is general enough to be wired into the addressing architecture. however, I was referring specifically to the prefix FEC0://10. Yes, it's already allocated, but it's also defined in such a way as to be dysfunctional, and too many broken assumptions are wired into existing code. So for the sake of compatibility it seems better to allocate another prefix for GUPIs. > > (yes, GUPIs, NOT SLs. they WILL be routed between sites, for good > > reasons, and we shouldn't try to stop this) > > Since this is the first time I've seen "GUPI" used, should I assume > that means a globally unique provider-independent prefix which isn't > globally routed? yes. > If so, I think you're using that term in the same sense Tony uses SL. IMHO, they shouldn't have any "site" or filtering assumptions wired into them, they're just a set of prefixes that are not dependent on a provider and can't be assumed to be globally routable. But to make them work we'll need a way to transparently map/forward them to routable prefixes. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 2 04:20:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42BKNhs010565; Fri, 2 May 2003 04:20:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h42BKN0i010564; Fri, 2 May 2003 04:20:23 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42BKKhs010557 for ; Fri, 2 May 2003 04:20:20 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h42BJ6uc009239 for ; Fri, 2 May 2003 04:19:07 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA17682 for ; Fri, 2 May 2003 05:19:01 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 7FE7354A9; Fri, 2 May 2003 07:19:00 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 2 May 2003 07:19:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Fri, 2 May 2003 07:18:59 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD614@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Thread-Index: AcMN8UkY9arhQ8O5QJiYdnXzIW7BawCqzZGA From: "Bound, Jim" To: , "Thomas Narten" , "Erik Nordmark" Cc: , "Bob Hinden" , "Margaret Wasserman" X-OriginalArrivalTime: 02 May 2003 11:19:00.0252 (UTC) FILETIME=[A13C1DC0:01C3109C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h42BKKhs010558 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The entire working group did decide this is not going to be resolved and we cannot agree hence they should be deprecated for now and that is the consensus. Your view is invalid here not the Chairs. /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Monday, April 28, 2003 9:44 PM > To: 'Thomas Narten'; 'Erik Nordmark' > Cc: ipng@sunroof.eng.sun.com; 'Bob Hinden'; 'Margaret Wasserman' > Subject: RE: Your Appeal Regarding Site-Local Deprecation > (Was: Consensus on Site-Local Addressing) > > > Thomas & Erik, > > I trust that you will take a more objective view of this, > because any outsider who needs to watch that video will be > rolling in the isles with laughter at the absurdity of the > process abuse in this case. At least 5 long-time IETF > participants (including yourself) felt the need to state what > they meant by 'deprecate SL'. One has to assume they bothered > to assert their interpretation because the YES/NO question > was unclear to them, or that their need to explain which > question they were answering is an implicit statement that > the original question was unclear. Even though the question > never changed, none of the (amazingly vague) clarifying > remarks in SF were sent to the list version of the consensus call. > > If a legal professional were to watch the proceedings here, > they would comment that the WG gave the chairs the freedom to > interpret the meaning of the question any way they choose. In > fact we have examples of that already on the mail list and in > this response. > 3/30 chair email claimed > > As part of deprecating site-local addressing, we > > agreed in the meeting that, in addition to deprecating > > site-local addressing in the addressing architecture > > and removing it from other places (scoped addressing > > architecture, address selection rules, etc.), a document > > would be written that would do two things: > > > > - Explain why site-local addressing was deprecated > > - Outline alternative means to address some of the > > problems that could have been solved by > > site-local addressing. > > That question was never asked of the room, and those > statements were not made by the chairs in SF. How could there > be an agreement? > > > The decision to deprecate site-local addressing, > > rather than simply removing it, was made to avoid > > harm to IPv6. > > There was nothing more to this than vague conversations > between Margaret & Keith, and Margaret & Thomas. There was no > decision by the WG, just a chair proclamation that one had > occurred. We can't allow the WG process to degenerate to the > point that a chair can call an ambiguous YES/NO question, > then make up anything they choose to have it mean later. In > particular, when the chair explicitly states '... if we > eliminate it we will also have multiple choices about what > exactly that means ...', and '... may have to hand wave ...' > there is not a clear indication about what question is being asked. > > I put specific rebuttal comments to the chair's rejection in > a list response to the chairs. In summary I believe the > chairs have declared a consensus when there really wasn't one > due to the ambiguity of the question. Specifically the YES > votes for removing addresses with local scope from the > architecture or consideration by applications are void, as > that is not something the IETF gets to decide. Had the chairs > asked Keith's original question about finding an alternate > way forward through replacement technologies, we would not be > going through this process. > > As for a path forward, I would expect you to invalidate the > consensus, then have the WG stop the pronouncements that SL > is dead, and work on finding appropriate replacements. This > effort must begin with identification of the requirements for > addresses of local scope, and under local network manager > control. With requirements in hand, the scoped address > architecture document needs to specifically deal with > handling mixed scope addresses, both between and for > simultaneous use on a singe node. That document in particular > is hopelessly gutted and meaningless without such a > discussion. IF we get to the point were all requirements are > met by alternatives, the current SL definition should > appropriately be moved to historic. If not, it will likely > end up in the corner case use that Keith was trying to > achieve. Either way, the entire WG must decide exactly what > happens. We must not allow the 'ambiguous YES/NO question - > chairs subsequently decide what it means', process to set a precedent. > > Tony > > > > > Margaret Wasserman wrote: > > Hi Tony, > > > > We have considered your appeal regarding the IPv6 WG > > consensus to deprecate site-locals. Based on our analysis, > > we believe that your appeal makes the following points: > > > > (1) You believe that deprecating IPv6 site-local unicast > > addressing is an incorrect technical choice that places > > the work output of the IPv6 WG in jeopardy. > > > > (2) You believe that the question asked by the chairs > > was insufficiently clear to be understood properly > > by the WG. > > > > (3) You do not believe that there is rough consensus to > > deprecate IPv6 site-local addressing, because people > > provided different reasons for why they believe that > > IPv6 site-local addressing should be deprecated. In > > particular, some people want to deprecate the particular > > model of site-local addressing defined in the scoped > > addressing architecture (ambiguous, scoped addresses), > > while others do not believe that we need a local > > addressing mechanism at all. > > > > (4) You believe that it is invalid for the IPv6 WG to > > deprecate site-local addressing without publishing an > > IPv6 WG document that analyzes the operational requirements > > for local addressing. Without this analysis document, you > > believe that the IPv6 WG has made an uninformed choice. > > > > We will now respond to each of your points. > > > > -- > > > > Point (1): > > > > The chairs do not believe that deprecating IPv6 site-local > > addressing is an incorrect technical decision that will place > > the work output of the IPv6 WG in jeopardy. > > > > The consensus was to "deprecate" the usage of site-local > > addressing instead of simply removing it. This was done > > purposely to avoid interference with any current > > implementations or deployments that might use site-local > > addressing. In addition to the time it will take to formally > > deprecate site-local addressing by publishing an RFC, the WG > > understands that it will take some time after the publication > > of an RFC for implementations to change. The decision to > > deprecate site-local addressing, rather than simply removing > > it, was made to avoid harm to IPv6. > > > > In fact, we believe that the previous disagreement over the > > usage of IPv6 site-local addressing was damaging to the WG, > > and that our lack of consensus was delaying our work, > > particularly on the IPv6 scoped addressing architecture. The > > consensus to deprecate site-local addressing will allow us to > > move forward and complete our work. > > > > --- > > Point (2): > > > > The question was: > > > > "Should we deprecate IPv6 site-local unicast > > addressing?" Possible answers were YES or NO. > > > > The chairs believe that this question was sufficiently clear to be > > understood by the WG. This is supported by the following > > points: > > > > - Over 200 people responded to the question. > > > > - Many of the responses on the list (both YES and NO > > responses) included reasons or comments that > > followed from the question in a way that indicated > > that the responders understood the question. > > > > - There were only three requests for clarification of > > this consensus call on the mailing list, two of which > > were procedural. All of these requests were answered > > promptly by the chairs. > > > > - The chairs sent the consensus results to the list > > over two weeks ago, including a course of action for > > the deprecation of site-local addressing. There > > have been no objections from people who originally > > expressed YES opinions that the chairs' course of > > action fails to match their expectations. > > > > --- > > > > Point (3): > > > > The chairs do not believe that consensus on an issue is > > invalidated by the fact that people have multiple reasons for > > coming to the same conclusion. We suspect that this happens > > in most WG consensus calls, and this is not a reason to > > invalidate the consensus. > > > > All of the groups that you mentioned in your message agreed > > that IPv6 site-local unicast addressing should be deprecated. > > They may disagree on what we should do after deprecating > > site- local addressing, but that does not invalidate the > > consensus on this point. > > > > --- > > > > Point (4): > > > > It is true that the IPv6 WG has not produced a WG document > > that analyzes the operational requirements for local > > addressing. However, we do not believe that this is a reason > > to invalidate the IPv6 WG consensus to deprecate IPv6 > > site-local unicast addressing. > > > > There has been considerable discussion and analysis of site- > > local addressing performed over the past year, including > > extensive discussions during three IETF sessions. There have > > also been several drafts published on the subject, including > > one draft that attempts to analyze the cost/benefit > > trade-offs of site-local addressing. > > > > This period of discussion has offered sufficient time for > > anyone who has an operational need for any of the > > currently-defined usage models of site-local addressing to > > document those requirements in an Internet-Draft and/or to > > discuss those requirements on the IPv6 mailing list. > > > > During our discussions, several operational benefits of > > site-local addressing have been raised on the IPv6 WG mailing > > list, including benefits for disconnected sites, > > intermittently- connected sites, renumbered sites, etc. We > > have also uncovered several issues and complexities caused by > > the current model of ambiguous, scoped site-local addressing, > > and we have determined that this particular model places > > burdens on other parts of the TCP/IP protocol suite, > > particularly routing protocols and applications. > > > > In a recent phone discussion and in your appeal > > clarification, you have indicated that the chairs should void > > responses from people who do not think that the IPv6 WG > > should specify any type of local addressing mechanism, > > because you believe that those responders are uninformed > > about the operational conditions that require the use of > > local addressing. > > > > While operational necessity is certainly an appropriate > > argument to raise in support of your position that the IPv6 > > WG should specify some mechanism for local addressing, the > > fact that you disagree with the reasons that some people > > offered for why they want to deprecate the current IPv6 > > site-local unicast addressing mechanism does not invalidate > > their contribution to this consensus call. > > > > It is the opinion of the chairs that the IPv6 WG did have > > sufficient information to make an informed decision regarding > > whether or not to deprecate IPv6 site-local unicast addressing. > > > > --- > > > > So, to summarize, the chairs do not agree with the points > > that you have raised in your appeal, and we do not agree to > > overturn the consensus of the IPv6 WG based on the issues > > that you have raised. > > > > Tony, while we disagree with your position on this particular > > issue, we do respect your contributions to the IPv6 effort > > and we realize that your appeal is motivated by your desire > > to do the right thing for IPv6. We hope that you will accept > > our response to your appeal and focus on working to define > > the local addressing problem and solutions as we outlined in > > our email to the list. We think it is important for the > > working group to move forward on this issue. > > > > Best Regards, > > > > Bob Hinden & Margaret Wasserman > > IPv6 WG 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 > > -------------------------------------------------------------------- > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 2 08:41:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42Ffphs011561; Fri, 2 May 2003 08:41:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h42FfoEY011560; Fri, 2 May 2003 08:41:50 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42Ffkhs011553 for ; Fri, 2 May 2003 08:41:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h42FeXKw010675 for ; Fri, 2 May 2003 08:40:33 -0700 (PDT) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA14069 for ; Fri, 2 May 2003 09:40:28 -0600 (MDT) Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by pintail.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Bce3-0007kc-00; Fri, 02 May 2003 08:40:19 -0700 Date: Fri, 2 May 2003 11:39:14 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, narten@us.ibm.com, Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: My point about the ambiguity of the question Message-Id: <20030502113914.16b18c95.moore@cs.utk.edu> In-Reply-To: <086001c31009$cc4e9d00$261e4104@eagleswings> References: <086001c31009$cc4e9d00$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Thomas & Erik, > > These notes illustrate my point about the ambiguity of the question. What they illustrate is your persistent efforts to misconstrue and misinterpret what other people are saying. > First, one has to question how well Ted and others were informed if > their issue is all about ambiguity. "it" depends on the context of that particular discussion, which is not necessarily site-local as a whole. Ambiguity is one of the issues associated with site local, not the only one. Even if Ted is only concerned about ambiguity, that doesn't invalidate Ted's opinion. Different people will place different values on different aspects of a proposal, so they'll have different reasons for voting yes or no on a question such as this. > As the second note shows, part of the goal of some > votes is to disallow a network manager the ability to limit access or > visibility to some of their nodes. As the author of the second note, I can authoritatively say that this is a misinterpretation. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 2 08:56:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42FuOhs011780; Fri, 2 May 2003 08:56:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h42FuNiX011779; Fri, 2 May 2003 08:56:23 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42FuKhs011772 for ; Fri, 2 May 2003 08:56:20 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h42Ft7uc028041 for ; Fri, 2 May 2003 08:55:07 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id JAA08444 for ; Fri, 2 May 2003 09:54:59 -0600 (MDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 02 May 2003 08:54:53 -0700 Reply-To: From: "Tony Hain" To: "'Bound, Jim'" , "'Thomas Narten'" , "'Erik Nordmark'" Cc: , "'Bob Hinden'" , "'Margaret Wasserman'" Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Fri, 2 May 2003 08:54:48 -0700 Message-ID: <09c401c310c3$28c25f40$261e4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD614@tayexc13.americas.cpqcorp.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h42FuKhs011773 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bound, Jim wrote: > The entire working group did decide this is not going to be > resolved and we cannot agree hence they should be deprecated > for now and that is the consensus. Your view is invalid here > not the Chairs. /jim I have a hard time believing that you of all people would have agreed that 'somewhere to the left ...' and 'have to hand wave ...' were adequate definitions of the question. Exactly what is the plan to replace non-provider controlled address space, since the working group has never been able to agree on any other approach? Forcing all sites into provider-only space will guarantee that they deploy nat to isolate themselves from the whims of the provider. Tony > > > -----Original Message----- > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > Sent: Monday, April 28, 2003 9:44 PM > > To: 'Thomas Narten'; 'Erik Nordmark' > > Cc: ipng@sunroof.eng.sun.com; 'Bob Hinden'; 'Margaret Wasserman' > > Subject: RE: Your Appeal Regarding Site-Local Deprecation > > (Was: Consensus on Site-Local Addressing) > > > > > > Thomas & Erik, > > > > I trust that you will take a more objective view of this, > > because any outsider who needs to watch that video will be > > rolling in the isles with laughter at the absurdity of the > > process abuse in this case. At least 5 long-time IETF > > participants (including yourself) felt the need to state what > > they meant by 'deprecate SL'. One has to assume they bothered > > to assert their interpretation because the YES/NO question > > was unclear to them, or that their need to explain which > > question they were answering is an implicit statement that > > the original question was unclear. Even though the question > > never changed, none of the (amazingly vague) clarifying > > remarks in SF were sent to the list version of the consensus call. > > > > If a legal professional were to watch the proceedings here, > > they would comment that the WG gave the chairs the freedom to > > interpret the meaning of the question any way they choose. In > > fact we have examples of that already on the mail list and in > > this response. > > 3/30 chair email claimed > > > As part of deprecating site-local addressing, we > > > agreed in the meeting that, in addition to deprecating > > > site-local addressing in the addressing architecture > > > and removing it from other places (scoped addressing > > > architecture, address selection rules, etc.), a document > > > would be written that would do two things: > > > > > > - Explain why site-local addressing was deprecated > > > - Outline alternative means to address some of the > > > problems that could have been solved by > > > site-local addressing. > > > > That question was never asked of the room, and those > > statements were not made by the chairs in SF. How could there > > be an agreement? > > > > > The decision to deprecate site-local addressing, > > > rather than simply removing it, was made to avoid > > > harm to IPv6. > > > > There was nothing more to this than vague conversations > > between Margaret & Keith, and Margaret & Thomas. There was no > > decision by the WG, just a chair proclamation that one had > > occurred. We can't allow the WG process to degenerate to the > > point that a chair can call an ambiguous YES/NO question, > > then make up anything they choose to have it mean later. In > > particular, when the chair explicitly states '... if we > > eliminate it we will also have multiple choices about what > > exactly that means ...', and '... may have to hand wave ...' > > there is not a clear indication about what question is being asked. > > > > I put specific rebuttal comments to the chair's rejection in > > a list response to the chairs. In summary I believe the > > chairs have declared a consensus when there really wasn't one > > due to the ambiguity of the question. Specifically the YES > > votes for removing addresses with local scope from the > > architecture or consideration by applications are void, as > > that is not something the IETF gets to decide. Had the chairs > > asked Keith's original question about finding an alternate > > way forward through replacement technologies, we would not be > > going through this process. > > > > As for a path forward, I would expect you to invalidate the > > consensus, then have the WG stop the pronouncements that SL > > is dead, and work on finding appropriate replacements. This > > effort must begin with identification of the requirements for > > addresses of local scope, and under local network manager > > control. With requirements in hand, the scoped address > > architecture document needs to specifically deal with > > handling mixed scope addresses, both between and for > > simultaneous use on a singe node. That document in particular > > is hopelessly gutted and meaningless without such a > > discussion. IF we get to the point were all requirements are > > met by alternatives, the current SL definition should > > appropriately be moved to historic. If not, it will likely > > end up in the corner case use that Keith was trying to > > achieve. Either way, the entire WG must decide exactly what > > happens. We must not allow the 'ambiguous YES/NO question - > > chairs subsequently decide what it means', process to set a > precedent. > > > > Tony > > > > > > > > > > Margaret Wasserman wrote: > > > Hi Tony, > > > > > > We have considered your appeal regarding the IPv6 WG consensus to > > > deprecate site-locals. Based on our analysis, we believe > that your > > > appeal makes the following points: > > > > > > (1) You believe that deprecating IPv6 site-local unicast > > > addressing is an incorrect technical choice that places > > > the work output of the IPv6 WG in jeopardy. > > > > > > (2) You believe that the question asked by the chairs > > > was insufficiently clear to be understood properly > > > by the WG. > > > > > > (3) You do not believe that there is rough consensus to > > > deprecate IPv6 site-local addressing, because people > > > provided different reasons for why they believe that > > > IPv6 site-local addressing should be deprecated. In > > > particular, some people want to deprecate the particular > > > model of site-local addressing defined in the scoped > > > addressing architecture (ambiguous, scoped addresses), > > > while others do not believe that we need a local > > > addressing mechanism at all. > > > > > > (4) You believe that it is invalid for the IPv6 WG to > > > deprecate site-local addressing without publishing an > > > IPv6 WG document that analyzes the operational requirements > > > for local addressing. Without this analysis document, you > > > believe that the IPv6 WG has made an uninformed choice. > > > > > > We will now respond to each of your points. > > > > > > -- > > > > > > Point (1): > > > > > > The chairs do not believe that deprecating IPv6 site-local > > > addressing is an incorrect technical decision that will place the > > > work output of the IPv6 WG in jeopardy. > > > > > > The consensus was to "deprecate" the usage of site-local > addressing > > > instead of simply removing it. This was done purposely to avoid > > > interference with any current implementations or deployments that > > > might use site-local addressing. In addition to the time it will > > > take to formally deprecate site-local addressing by publishing an > > > RFC, the WG understands that it will take some time after the > > > publication of an RFC for implementations to change. The > decision > > > to deprecate site-local addressing, rather than simply removing > > > it, was made to avoid harm to IPv6. > > > > > > In fact, we believe that the previous disagreement over > the usage of > > > IPv6 site-local addressing was damaging to the WG, and > that our lack > > > of consensus was delaying our work, particularly on the > IPv6 scoped > > > addressing architecture. The consensus to deprecate site-local > > > addressing will allow us to move forward and complete our work. > > > > > > --- > > > Point (2): > > > > > > The question was: > > > > > > "Should we deprecate IPv6 site-local unicast > > > addressing?" Possible answers were YES or NO. > > > > > > The chairs believe that this question was sufficiently clear to be > > > understood by the WG. This is supported by the following > > > points: > > > > > > - Over 200 people responded to the question. > > > > > > - Many of the responses on the list (both YES and NO > > > responses) included reasons or comments that > > > followed from the question in a way that indicated > > > that the responders understood the question. > > > > > > - There were only three requests for clarification of > > > this consensus call on the mailing list, two of which > > > were procedural. All of these requests were answered > > > promptly by the chairs. > > > > > > - The chairs sent the consensus results to the list > > > over two weeks ago, including a course of action for > > > the deprecation of site-local addressing. There > > > have been no objections from people who originally > > > expressed YES opinions that the chairs' course of > > > action fails to match their expectations. > > > > > > --- > > > > > > Point (3): > > > > > > The chairs do not believe that consensus on an issue is > invalidated > > > by the fact that people have multiple reasons for coming > to the same > > > conclusion. We suspect that this happens in most WG consensus > > > calls, and this is not a reason to invalidate the consensus. > > > > > > All of the groups that you mentioned in your message agreed that > > > IPv6 site-local unicast addressing should be deprecated. They may > > > disagree on what we should do after deprecating > > > site- local addressing, but that does not invalidate the > > > consensus on this point. > > > > > > --- > > > > > > Point (4): > > > > > > It is true that the IPv6 WG has not produced a WG document that > > > analyzes the operational requirements for local addressing. > > > However, we do not believe that this is a reason to > invalidate the > > > IPv6 WG consensus to deprecate IPv6 site-local unicast addressing. > > > > > > There has been considerable discussion and analysis of > site- local > > > addressing performed over the past year, including extensive > > > discussions during three IETF sessions. There have also been > > > several drafts published on the subject, including one draft that > > > attempts to analyze the cost/benefit trade-offs of site-local > > > addressing. > > > > > > This period of discussion has offered sufficient time for > anyone who > > > has an operational need for any of the currently-defined usage > > > models of site-local addressing to document those > requirements in an > > > Internet-Draft and/or to discuss those requirements on the IPv6 > > > mailing list. > > > > > > During our discussions, several operational benefits of > site-local > > > addressing have been raised on the IPv6 WG mailing list, > including > > > benefits for disconnected sites, > > > intermittently- connected sites, renumbered sites, etc. We > > > have also uncovered several issues and complexities caused by > > > the current model of ambiguous, scoped site-local addressing, > > > and we have determined that this particular model places > > > burdens on other parts of the TCP/IP protocol suite, > > > particularly routing protocols and applications. > > > > > > In a recent phone discussion and in your appeal > clarification, you > > > have indicated that the chairs should void responses from > people who > > > do not think that the IPv6 WG should specify any type of local > > > addressing mechanism, because you believe that those > responders are > > > uninformed about the operational conditions that require > the use of > > > local addressing. > > > > > > While operational necessity is certainly an appropriate > argument to > > > raise in support of your position that the IPv6 WG should specify > > > some mechanism for local addressing, the fact that you > disagree with > > > the reasons that some people offered for why they want to > deprecate > > > the current IPv6 site-local unicast addressing mechanism does not > > > invalidate their contribution to this consensus call. > > > > > > It is the opinion of the chairs that the IPv6 WG did have > sufficient > > > information to make an informed decision regarding > whether or not to > > > deprecate IPv6 site-local unicast addressing. > > > > > > --- > > > > > > So, to summarize, the chairs do not agree with the points > that you > > > have raised in your appeal, and we do not agree to overturn the > > > consensus of the IPv6 WG based on the issues that you have raised. > > > > > > Tony, while we disagree with your position on this > particular issue, > > > we do respect your contributions to the IPv6 effort and > we realize > > > that your appeal is motivated by your desire to do the > right thing > > > for IPv6. We hope that you will accept our response to > your appeal > > > and focus on working to define the local addressing problem and > > > solutions as we outlined in our email to the list. We think it is > > > important for the working group to move forward on this issue. > > > > > > Best Regards, > > > > > > Bob Hinden & Margaret Wasserman > > > IPv6 WG 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 > > > > -------------------------------------------------------------------- > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home 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 May 2 10:34:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42HYShs012514; Fri, 2 May 2003 10:34:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h42HYSYO012513; Fri, 2 May 2003 10:34:28 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42HYPhs012506 for ; Fri, 2 May 2003 10:34:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h42HXCKw017543 for ; Fri, 2 May 2003 10:33:12 -0700 (PDT) Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h42HX7Tl005650 for ; Fri, 2 May 2003 10:33:07 -0700 (PDT) Received: from mira-sjc5-f.cisco.com (IDENT:mirapoint@mira-sjc5-f.cisco.com [171.71.163.13]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h42HX5ua014552 for ; Fri, 2 May 2003 10:33:05 -0700 (PDT) Received: from cds-w2k02.cisco.com (dhcp-171-71-58-87.cisco.com [171.71.58.87]) by mira-sjc5-f.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFU87812; Fri, 2 May 2003 10:40:17 -0700 (PDT) Message-Id: <4.3.2.7.2.20030502103026.030e3428@andiamo.com> X-Sender: cds@mira-sjcd-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 02 May 2003 10:33:04 -0700 To: ipng@sunroof.eng.sun.com From: Claudio DeSanti Subject: I-D ACTION:draft-desanti-ipv6-over-fibre-channel-01.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk An update to the IPv6 over Fibre Channel draft is available, incorporating the comments received at the last IPv6 WG meeting. Please send me any further feedback. Thanks, Claudio. ---------- A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 over Fibre Channel Author(s) : C. Desanti Filename : draft-desanti-ipv6-over-fibre-channel-01.txt Pages : 21 Date : 2003-5-1 Fibre Channel (FC) is a high speed serial interface technology that supports several higher layer protocols including Small Computer System Interface (SCSI) and IPv4, as specified in [IP-FC]. The purpose of this document is to specify a way of encapsulating IP version 6 [IPv6] over Fibre Channel and to describe a method of forming IPv6 link-local addresses [AARCH] and statelessly autoconfigured addresses on Fibre Channel networks. This document also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on a Fibre Channel network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-desanti-ipv6-over-fibre-channel-01.txt -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 2 11:34:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42IYmhs013452; Fri, 2 May 2003 11:34:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h42IYmAi013451; Fri, 2 May 2003 11:34:48 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42IYjhs013444 for ; Fri, 2 May 2003 11:34:45 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h42IXWKw007613 for ; Fri, 2 May 2003 11:33:32 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA05157 for ; Fri, 2 May 2003 11:33:26 -0700 (PDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 02 May 2003 11:33:24 -0700 Reply-To: From: "Tony Hain" To: "'Keith Moore'" Cc: , , , Subject: RE: My point about the ambiguity of the question Date: Fri, 2 May 2003 11:33:13 -0700 Message-ID: <09d301c310d9$4a99b1c0$261e4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030502113914.16b18c95.moore@cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h42IYjhs013445 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > Ambiguity is one of the issues associated with site local, > not the only one. > ... > > As the second note shows, part of the goal of some > > votes is to disallow a network manager the ability to limit > access or > > visibility to some of their nodes. > > As the author of the second note, I can authoritatively say > that this is a misinterpretation. So please explain how I misinterpreted. Everything that is not about ambiguity is about the simple ability to consistently limit access or visibility, and identify when that is being done. We don't need to deprecate SL to fix the ambiguity, so the insistence that deprecating SL fixes other things only leads to the conclusion that this is about limiting a network manager's ability to define how his network is run. That is not the IETF's call, so those votes are not valid. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 2 11:43:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42Ihnhs013749; Fri, 2 May 2003 11:43:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h42IhnY3013748; Fri, 2 May 2003 11:43:49 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42Ihjhs013741 for ; Fri, 2 May 2003 11:43:45 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h42IgVKw010473 for ; Fri, 2 May 2003 11:42:31 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA06498 for ; Fri, 2 May 2003 12:42:26 -0600 (MDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h42Ig1v06366; Fri, 2 May 2003 14:42:01 -0400 (EDT) Date: Fri, 2 May 2003 14:42:01 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, narten@us.ibm.com, Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: My point about the ambiguity of the question Message-Id: <20030502144201.3dfc58c1.moore@cs.utk.edu> In-Reply-To: <09d301c310d9$4a99b1c0$261e4104@eagleswings> References: <20030502113914.16b18c95.moore@cs.utk.edu> <09d301c310d9$4a99b1c0$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 2 May 2003 11:33:13 -0700 "Tony Hain" wrote: > Keith Moore wrote: > > Ambiguity is one of the issues associated with site local, > > not the only one. > > ... > > > As the second note shows, part of the goal of some > > > votes is to disallow a network manager the ability to limit > > access or > > > visibility to some of their nodes. > > > > As the author of the second note, I can authoritatively say > > that this is a misinterpretation. > > So please explain how I misinterpreted. Everything that is not about > ambiguity is about the simple ability to consistently limit access or > visibility, and identify when that is being done. False. Forcing hosts or apps to do routing is about neither of these. Forcing applications to be aware of topology is about neither of these. Keith -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 2 12:37:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42Jb7hs014126; Fri, 2 May 2003 12:37:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h42Jb7Pa014125; Fri, 2 May 2003 12:37:07 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42Jb4hs014118 for ; Fri, 2 May 2003 12:37:04 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h42JZpuc006379 for ; Fri, 2 May 2003 12:35:51 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA10023 for ; Fri, 2 May 2003 12:35:45 -0700 (PDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Fri, 02 May 2003 12:35:44 -0700 Reply-To: From: "Tony Hain" To: "'Keith Moore'" Cc: , , , Subject: RE: My point about the ambiguity of the question Date: Fri, 2 May 2003 12:35:44 -0700 Message-ID: <0a0801c310e2$060d63e0$261e4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <20030502144201.3dfc58c1.moore@cs.utk.edu> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h42Jb4hs014119 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Keith Moore wrote: > > So please explain how I misinterpreted. Everything that is > not about > > ambiguity is about the simple ability to consistently limit > access or > > visibility, and identify when that is being done. > > False. Forcing hosts or apps to do routing is about neither > of these. Forcing applications to be aware of topology is > about neither of these. The existence of a prefix does not force host or apps to do routing or be aware of topology. The only way to come to that conclusion is if you mean that network managers expect apps they deploy to behave correctly in the presence of limited access or visibility, and the defined prefix shows there is a mechanism to do so. Nothing is forcing the app to do anything, after all it could rely on a service. Eliminating a defined prefix does not remove the expectation of the network manager that apps will behave correctly on the deployed network. Voting to eliminate a defined prefix with the expectation that the application will then see a flat routing space is an indirect effort to prevent the network manager from deploying local scopes through routing or access controls. The IETF does not design networks, or make operational decisions. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 2 12:50:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42Jokhs014554; Fri, 2 May 2003 12:50:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h42JokR3014553; Fri, 2 May 2003 12:50:46 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h42Joghs014546 for ; Fri, 2 May 2003 12:50:42 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h42JnTuc010267 for ; Fri, 2 May 2003 12:49:29 -0700 (PDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h42JnNTl004943 for ; Fri, 2 May 2003 12:49:23 -0700 (PDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h42JnHv06611; Fri, 2 May 2003 15:49:17 -0400 (EDT) Date: Fri, 2 May 2003 15:49:17 -0400 From: Keith Moore To: Cc: moore@cs.utk.edu, narten@us.ibm.com, Erik.Nordmark@Sun.COM, ipng@sunroof.eng.sun.com, ietf@ietf.org Subject: Re: My point about the ambiguity of the question Message-Id: <20030502154917.69c3d2d3.moore@cs.utk.edu> In-Reply-To: <0a0801c310e2$060d63e0$261e4104@eagleswings> References: <20030502144201.3dfc58c1.moore@cs.utk.edu> <0a0801c310e2$060d63e0$261e4104@eagleswings> X-Mailer: Sylpheed version 0.8.11 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > False. Forcing hosts or apps to do routing is about neither > > of these. Forcing applications to be aware of topology is > > about neither of these. > > The existence of a prefix does not force host or apps to do routing or > be aware of topology. as long as the prefix is never used, you're entirely correct. > The only way to come to that conclusion is if > you mean that network managers expect apps they deploy to behave > correctly in the presence of limited access or visibility, and the > defined prefix shows there is a mechanism to do so. the prefix doesn't help apps do that. and the very assumptions behind use of the prefix are what force apps to do that. > Nothing is forcing the app to do anything, after all it could rely on > a service. in other words, we could create magic pixie dust if we only had magic pixie dust... -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 3 20:49:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h443n7hs020329; Sat, 3 May 2003 20:49:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h443n7TV020328; Sat, 3 May 2003 20:49:07 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h443n3hs020321 for ; Sat, 3 May 2003 20:49:03 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h443lmKw025964 for ; Sat, 3 May 2003 20:47:48 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id VAA09851 for ; Sat, 3 May 2003 21:47:42 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id A807F829B; Sat, 3 May 2003 23:47:41 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 3 May 2003 23:47:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Sat, 3 May 2003 23:47:40 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B032411DF@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Thread-Index: AcMQwzbkr6EEF4u+Rrae3KjGfR1b+QBKqdPQ From: "Bound, Jim" To: , "Thomas Narten" , "Erik Nordmark" Cc: , "Bob Hinden" , "Margaret Wasserman" X-OriginalArrivalTime: 04 May 2003 03:47:41.0476 (UTC) FILETIME=[E9DA4E40:01C311EF] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h443n4hs020322 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Bound, Jim wrote: > > The entire working group did decide this is not going to be > > resolved and we cannot agree hence they should be deprecated > > for now and that is the consensus. Your view is invalid here > > not the Chairs. /jim > > I have a hard time believing that you of all people would > have agreed that 'somewhere to the left ...' and 'have to > hand wave ...' were adequate definitions of the question. > Exactly what is the plan to replace non-provider controlled > address space, since the working group has never been able to > agree on any other approach? Forcing all sites into > provider-only space will guarantee that they deploy nat to > isolate themselves from the whims of the provider. On the contrary. Until we can define their use, their limitations, I advise all customers for IPv6 to use Global Addresses for all communications and that Link-Local are for systems link node infrastructure only really. Get in the habit of using Global Addresses again. The illusions propogated by the IPv4 NAT bandaid should be destroyed and I intend to keep doing that and that was caused by IPv4 private address space because IPv6 was not deployed fast enough. That being said I also discuss clearly and in depth the future potential of IPv6 multi-scoped address potential architecturally, from implementing a stack I can tell them exactly the complexities the developers face and then the use of that benefit on a node and within a routing system. The "yes" vote for me was very clear from the Chairs question. My yes vote was for the following. I believe we cannot resolve the issue of site-local addresses today (in part because we do not have our minds around the entire implementation of scoping) and because of that for NOW (not forever) the IETF standards process should deprecate their use. Bottom line is users should not use them. I don't agree with you that customers will do as you say. The reason is that most vendors now are well equipped and well educated on the absurdity of using private address space without rules and in particular that their limitation be known. NAT was evil and that is clear to all now who advise and becoming more clear to users. That will cause them much hesitation for private address use. Our consensus here will put the nail in the coffin for site-locals TODAY not forever. You have lost this battle and should give it up and go work with those who believe we need this and bring us a proposal that will make it safe for them to be deployed on the Internet. If the WG buys into the proposal and we can move forward with many wanting to work on it again then we revisit it again. But for now they are dead and filerbusting is not going to change anything in the IETF is my strong hope here. All the arguments have been heard and we have nothing that is nailed down or agreed to. Respectfully, /jim > > Tony > > > > > > -----Original Message----- > > > From: Tony Hain [mailto:alh-ietf@tndh.net] > > > Sent: Monday, April 28, 2003 9:44 PM > > > To: 'Thomas Narten'; 'Erik Nordmark' > > > Cc: ipng@sunroof.eng.sun.com; 'Bob Hinden'; 'Margaret Wasserman' > > > Subject: RE: Your Appeal Regarding Site-Local Deprecation > > > (Was: Consensus on Site-Local Addressing) > > > > > > > > > Thomas & Erik, > > > > > > I trust that you will take a more objective view of this, because > > > any outsider who needs to watch that video will be rolling in the > > > isles with laughter at the absurdity of the process abuse in this > > > case. At least 5 long-time IETF participants (including yourself) > > > felt the need to state what they meant by 'deprecate SL'. > One has to > > > assume they bothered to assert their interpretation because the > > > YES/NO question was unclear to them, or that their need > to explain > > > which question they were answering is an implicit statement that > > > the original question was unclear. Even though the question > > > never changed, none of the (amazingly vague) clarifying > > > remarks in SF were sent to the list version of the consensus call. > > > > > > If a legal professional were to watch the proceedings here, they > > > would comment that the WG gave the chairs the freedom to > interpret > > > the meaning of the question any way they choose. In fact we have > > > examples of that already on the mail list and in this response. > > > 3/30 chair email claimed > > > > As part of deprecating site-local addressing, we > > > > agreed in the meeting that, in addition to deprecating > site-local > > > > addressing in the addressing architecture and removing it from > > > > other places (scoped addressing architecture, address > selection > > > > rules, etc.), a document would be written that would do two > > > > things: > > > > > > > > - Explain why site-local addressing was deprecated > > > > - Outline alternative means to address some of the > > > > problems that could have been solved by > > > > site-local addressing. > > > > > > That question was never asked of the room, and those > statements were > > > not made by the chairs in SF. How could there be an agreement? > > > > > > > The decision to deprecate site-local addressing, > > > > rather than simply removing it, was made to avoid > > > > harm to IPv6. > > > > > > There was nothing more to this than vague conversations between > > > Margaret & Keith, and Margaret & Thomas. There was no decision by > > > the WG, just a chair proclamation that one had occurred. We can't > > > allow the WG process to degenerate to the point that a chair can > > > call an ambiguous YES/NO question, then make up anything > they choose > > > to have it mean later. In particular, when the chair explicitly > > > states '... if we eliminate it we will also have multiple choices > > > about what exactly that means ...', and '... may have to > hand wave > > > ...' there is not a clear indication about what question is being > > > asked. > > > > > > I put specific rebuttal comments to the chair's rejection > in a list > > > response to the chairs. In summary I believe the chairs have > > > declared a consensus when there really wasn't one due to the > > > ambiguity of the question. Specifically the YES votes for > removing > > > addresses with local scope from the architecture or > consideration by > > > applications are void, as that is not something the IETF gets to > > > decide. Had the chairs asked Keith's original question > about finding > > > an alternate way forward through replacement > technologies, we would > > > not be going through this process. > > > > > > As for a path forward, I would expect you to invalidate the > > > consensus, then have the WG stop the pronouncements that > SL is dead, > > > and work on finding appropriate replacements. This effort > must begin > > > with identification of the requirements for addresses of local > > > scope, and under local network manager control. With > requirements in > > > hand, the scoped address architecture document needs to > specifically > > > deal with handling mixed scope addresses, both between and for > > > simultaneous use on a singe node. That document in particular > > > is hopelessly gutted and meaningless without such a > > > discussion. IF we get to the point were all requirements are > > > met by alternatives, the current SL definition should > > > appropriately be moved to historic. If not, it will likely > > > end up in the corner case use that Keith was trying to > > > achieve. Either way, the entire WG must decide exactly what > > > happens. We must not allow the 'ambiguous YES/NO question - > > > chairs subsequently decide what it means', process to set a > > precedent. > > > > > > Tony > > > > > > > > > > > > > > > Margaret Wasserman wrote: > > > > Hi Tony, > > > > > > > > We have considered your appeal regarding the IPv6 WG > consensus to > > > > deprecate site-locals. Based on our analysis, we believe > > that your > > > > appeal makes the following points: > > > > > > > > (1) You believe that deprecating IPv6 site-local unicast > > > > addressing is an incorrect technical choice that places > > > > the work output of the IPv6 WG in jeopardy. > > > > > > > > (2) You believe that the question asked by the chairs > > > > was insufficiently clear to be understood properly > > > > by the WG. > > > > > > > > (3) You do not believe that there is rough consensus to > > > > deprecate IPv6 site-local addressing, because people > > > > provided different reasons for why they believe that > > > > IPv6 site-local addressing should be deprecated. In > > > > particular, some people want to deprecate the particular > > > > model of site-local addressing defined in the scoped > > > > addressing architecture (ambiguous, scoped addresses), > > > > while others do not believe that we need a local > > > > addressing mechanism at all. > > > > > > > > (4) You believe that it is invalid for the IPv6 WG to > > > > deprecate site-local addressing without publishing an > > > > IPv6 WG document that analyzes the operational > requirements > > > > for local addressing. Without this analysis > document, you > > > > believe that the IPv6 WG has made an uninformed choice. > > > > > > > > We will now respond to each of your points. > > > > > > > > -- > > > > > > > > Point (1): > > > > > > > > The chairs do not believe that deprecating IPv6 site-local > > > > addressing is an incorrect technical decision that will > place the > > > > work output of the IPv6 WG in jeopardy. > > > > > > > > The consensus was to "deprecate" the usage of site-local > > addressing > > > > instead of simply removing it. This was done purposely to avoid > > > > interference with any current implementations or > deployments that > > > > might use site-local addressing. In addition to the > time it will > > > > take to formally deprecate site-local addressing by > publishing an > > > > RFC, the WG understands that it will take some time after the > > > > publication of an RFC for implementations to change. The > > decision > > > > to deprecate site-local addressing, rather than simply removing > > > > it, was made to avoid harm to IPv6. > > > > > > > > In fact, we believe that the previous disagreement over > > the usage of > > > > IPv6 site-local addressing was damaging to the WG, and > > that our lack > > > > of consensus was delaying our work, particularly on the > > IPv6 scoped > > > > addressing architecture. The consensus to deprecate site-local > > > > addressing will allow us to move forward and complete our work. > > > > > > > > --- > > > > Point (2): > > > > > > > > The question was: > > > > > > > > "Should we deprecate IPv6 site-local unicast > > > > addressing?" Possible answers were YES or NO. > > > > > > > > The chairs believe that this question was sufficiently > clear to be > > > > understood by the WG. This is supported by the following > > > > points: > > > > > > > > - Over 200 people responded to the question. > > > > > > > > - Many of the responses on the list (both YES and NO > > > > responses) included reasons or comments that > > > > followed from the question in a way that indicated > > > > that the responders understood the question. > > > > > > > > - There were only three requests for clarification of > > > > this consensus call on the mailing list, two of which > > > > were procedural. All of these requests were answered > > > > promptly by the chairs. > > > > > > > > - The chairs sent the consensus results to the list > > > > over two weeks ago, including a course of action for > > > > the deprecation of site-local addressing. There > > > > have been no objections from people who originally > > > > expressed YES opinions that the chairs' course of > > > > action fails to match their expectations. > > > > > > > > --- > > > > > > > > Point (3): > > > > > > > > The chairs do not believe that consensus on an issue is > > invalidated > > > > by the fact that people have multiple reasons for coming > > to the same > > > > conclusion. We suspect that this happens in most WG consensus > > > > calls, and this is not a reason to invalidate the consensus. > > > > > > > > All of the groups that you mentioned in your message > agreed that > > > > IPv6 site-local unicast addressing should be > deprecated. They may > > > > disagree on what we should do after deprecating > > > > site- local addressing, but that does not invalidate the > > > > consensus on this point. > > > > > > > > --- > > > > > > > > Point (4): > > > > > > > > It is true that the IPv6 WG has not produced a WG document that > > > > analyzes the operational requirements for local addressing. > > > > However, we do not believe that this is a reason to > > invalidate the > > > > IPv6 WG consensus to deprecate IPv6 site-local unicast > addressing. > > > > > > > > There has been considerable discussion and analysis of > > site- local > > > > addressing performed over the past year, including extensive > > > > discussions during three IETF sessions. There have also been > > > > several drafts published on the subject, including one > draft that > > > > attempts to analyze the cost/benefit trade-offs of site-local > > > > addressing. > > > > > > > > This period of discussion has offered sufficient time for > > anyone who > > > > has an operational need for any of the currently-defined usage > > > > models of site-local addressing to document those > > requirements in an > > > > Internet-Draft and/or to discuss those requirements on the IPv6 > > > > mailing list. > > > > > > > > During our discussions, several operational benefits of > > site-local > > > > addressing have been raised on the IPv6 WG mailing list, > > including > > > > benefits for disconnected sites, > > > > intermittently- connected sites, renumbered sites, etc. We > > > > have also uncovered several issues and complexities caused by > > > > the current model of ambiguous, scoped site-local addressing, > > > > and we have determined that this particular model places > > > > burdens on other parts of the TCP/IP protocol suite, > > > > particularly routing protocols and applications. > > > > > > > > In a recent phone discussion and in your appeal > > clarification, you > > > > have indicated that the chairs should void responses from > > people who > > > > do not think that the IPv6 WG should specify any type of local > > > > addressing mechanism, because you believe that those > > responders are > > > > uninformed about the operational conditions that require > > the use of > > > > local addressing. > > > > > > > > While operational necessity is certainly an appropriate > > argument to > > > > raise in support of your position that the IPv6 WG > should specify > > > > some mechanism for local addressing, the fact that you > > disagree with > > > > the reasons that some people offered for why they want to > > deprecate > > > > the current IPv6 site-local unicast addressing > mechanism does not > > > > invalidate their contribution to this consensus call. > > > > > > > > It is the opinion of the chairs that the IPv6 WG did have > > sufficient > > > > information to make an informed decision regarding > > whether or not to > > > > deprecate IPv6 site-local unicast addressing. > > > > > > > > --- > > > > > > > > So, to summarize, the chairs do not agree with the points > > that you > > > > have raised in your appeal, and we do not agree to overturn the > > > > consensus of the IPv6 WG based on the issues that you > have raised. > > > > > > > > Tony, while we disagree with your position on this > > particular issue, > > > > we do respect your contributions to the IPv6 effort and > > we realize > > > > that your appeal is motivated by your desire to do the > > right thing > > > > for IPv6. We hope that you will accept our response to > > your appeal > > > > and focus on working to define the local addressing problem and > > > > solutions as we outlined in our email to the list. We > think it is > > > > important for the working group to move forward on this issue. > > > > > > > > Best Regards, > > > > > > > > Bob Hinden & Margaret Wasserman > > > > IPv6 WG 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 > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: > http://playground.sun.com/ipng > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 3 20:51:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h443pAhs020350; Sat, 3 May 2003 20:51:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h443pAcm020349; Sat, 3 May 2003 20:51:10 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h443p6hs020342 for ; Sat, 3 May 2003 20:51:07 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h443npKw026214 for ; Sat, 3 May 2003 20:49:51 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id VAA28661 for ; Sat, 3 May 2003 21:49:45 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D48594239; Sat, 3 May 2003 23:49:44 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 3 May 2003 23:49:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: My point about the ambiguity of the question Date: Sat, 3 May 2003 23:49:44 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD648@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: My point about the ambiguity of the question Thread-Index: AcMQ2agE3XRdqsc5RiqgYvZODIFj0QBFleOw From: "Bound, Jim" To: , "Keith Moore" Cc: , , , X-OriginalArrivalTime: 04 May 2003 03:49:44.0726 (UTC) FILETIME=[3350C360:01C311F0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h443p7hs020343 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk For unicast it makes it clear all we are supporting as a standards body are globals and link-local TODAY, not forever. That is an important message and prudent act by the IETF. Deprecating SLs reduces ambiguity clearly from the above premises. /jim > -----Original Message----- > From: Tony Hain [mailto:alh-ietf@tndh.net] > Sent: Friday, May 02, 2003 2:33 PM > To: 'Keith Moore' > Cc: narten@us.ibm.com; Erik.Nordmark@Sun.COM; > ipng@sunroof.eng.sun.com; ietf@ietf.org > Subject: RE: My point about the ambiguity of the question > > > Keith Moore wrote: > > Ambiguity is one of the issues associated with site local, > > not the only one. > > ... > > > As the second note shows, part of the goal of some > > > votes is to disallow a network manager the ability to limit > > access or > > > visibility to some of their nodes. > > > > As the author of the second note, I can authoritatively say > > that this is a misinterpretation. > > So please explain how I misinterpreted. Everything that is > not about ambiguity is about the simple ability to > consistently limit access or visibility, and identify when > that is being done. > > We don't need to deprecate SL to fix the ambiguity, so the > insistence that deprecating SL fixes other things only leads > to the conclusion that this is about limiting a network > manager's ability to define how his network is run. That is > not the IETF's call, so those votes are not valid. > > Tony > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 3 21:14:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h444ELhs020757; Sat, 3 May 2003 21:14:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h444EL4E020756; Sat, 3 May 2003 21:14:21 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h444EHhs020749 for ; Sat, 3 May 2003 21:14:17 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h444D2uc011818 for ; Sat, 3 May 2003 21:13:02 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id VAA25057 for ; Sat, 3 May 2003 21:12:57 -0700 (PDT) Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Sat, 3 May 2003 21:13:02 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F50457E6@server2000.arneill-py.sacramento.ca.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Content-class: urn:content-classes:message Thread-Index: AcMQwzbkr6EEF4u+Rrae3KjGfR1b+QBKqdPQAAFM6xA= X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 From: "Michel Py" To: "Jim Bound" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h444EIhs020750 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim, > Jim Bound wrote: > [using private addresses] > Bottom line is users should not use them. Bottom line is that nobody tells me what to do on my network and certainly not the IETF. > I don't agree with you that customers will do as you say. Maybe you should listen more to customers, because the have, they are and they will. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 3 21:52:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h444q6hs021035; Sat, 3 May 2003 21:52:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h444q5af021034; Sat, 3 May 2003 21:52:05 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h444q2hs021027 for ; Sat, 3 May 2003 21:52:02 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h444oluc016526 for ; Sat, 3 May 2003 21:50:47 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id WAA03789 for ; Sat, 3 May 2003 22:50:41 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 54B108FEB; Sun, 4 May 2003 00:50:41 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 4 May 2003 00:50:41 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Sun, 4 May 2003 00:50:40 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B032411E1@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Thread-Index: AcMQwzbkr6EEF4u+Rrae3KjGfR1b+QBKqdPQAAFM6xAAAHnzUA== From: "Bound, Jim" To: "Michel Py" Cc: X-OriginalArrivalTime: 04 May 2003 04:50:41.0225 (UTC) FILETIME=[B6C23B90:01C311F8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h444q2hs021028 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, > Bottom line is that nobody tells me what to do on my network > and certainly not the IETF. I completely agree. The IETF is in the business of defining standards that may or may not be used in the real world. For the effort of defining the standard for SLs we are at an impasse and for many years, thus we have decided to deprecate them for now until a proposal/plan exists. That is a prudent and logical action. Users can do whatever they want and vendors too. 100% agree. That is not the issue or has anything to do with this decision in the IETF, as standards body. If I did not like the decision and believed it was important for users I would tell them to ignore the IETF. I have done that in a few very rare cases and will do it again if necessary. If you believe that you should do the same and that's fine. But we have made a decision and we should stand by it and move on here. That is more imporant than SLs to this IETF at this time. We cannot continue to debate what has clear consensus and this one does. It is going to kill the IETF and a major large problem with this standards body that has to be fixed and this discussion is prime example of the problem. > > > > I don't agree with you that customers will do as you say. > > Maybe you should listen more to customers, because the have, > they are and they will. I do daily and about IPv6. They want to never deal with NAT again. They also want real security which private address space does not give them unless they have no links to the outside Internet anywhere within their network. I advise any user I speak with not to use them, except at their own risk. They will not just blindly use SLs I simply do not agree. They are well aware of our indecisive conclusions and their use within this effort in the IETF if not directly then indirectly. Until we define their use and scope within an IPv6 network there is no logical use for them by any user. Other than a false belief in securing their network. Once that belief is shown to be false (and it has by many now) the reasons for private addresses become illogical and only emotional. And emotion is not a good plan for a business decision. Any user that sees that will not decide in favor of emotion. We should be talking about scoping of network link partitions not SLs and once we have that understood address scoping besides LLs and Globals will be clearer. Why not have Org-Locals, or Dept-Locals. Etc? The reason is we do not technically understand their use or limitations within the IPv6 architecture, there has been no running code at one bake off to verify they do not break network connectivity for multisited nodes or cause security faults as just two examples. With Globals and LLs we have a clue. We have no real clue for IPv6 only a few theories and cannot get consensus on that so we deprecate them for now. Private addresses in IPv4 are NOT the same as Private Addresses in IPv6. In IPv6 it creates an address and network partition scoping abstraction we simply have not completed our thought processes on and why I believe it prudent technically to deprecate them for now. Can you point me to a public test bed (not private vendor) that has made extensive use of SLs with IPv6 and verified their use as we have for Globals and LLs in any IPv6 test bed in Asia, Europe, or North America? Or if you know of stuff going on out of our intra-planetary system that is fair too :--) /jim > > Michel. > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 3 21:55:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h444tkhs021127; Sat, 3 May 2003 21:55:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h444tj4s021126; Sat, 3 May 2003 21:55:45 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h444tdhs021110 for ; Sat, 3 May 2003 21:55:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h444sOKw004671 for ; Sat, 3 May 2003 21:54:24 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h444sJTl000066 for ; Sat, 3 May 2003 21:54:19 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 89699A6AE; Sun, 4 May 2003 00:54:18 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 4 May 2003 00:54:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Sun, 4 May 2003 00:54:17 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD64E@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Thread-Index: AcMQwzbkr6EEF4u+Rrae3KjGfR1b+QBKqdPQAAFM6xAAAHnzUAABDZbA From: "Bound, Jim" To: "Bound, Jim" , "Michel Py" Cc: X-OriginalArrivalTime: 04 May 2003 04:54:18.0429 (UTC) FILETIME=[3838EED0:01C311F9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h444tdhs021114 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Below we have no real clue for IPv6 SLs :--) /jim > -----Original Message----- > From: Bound, Jim > Sent: Sunday, May 04, 2003 12:51 AM > To: 'Michel Py' > Cc: ipng@sunroof.eng.sun.com > Subject: RE: Your Appeal Regarding Site-Local Deprecation > (Was: Consensus on Site-Local Addressing) > > > Michel, > > > Bottom line is that nobody tells me what to do on my network > > and certainly not the IETF. > > I completely agree. The IETF is in the business of defining > standards that may or may not be used in the real world. For > the effort of defining the standard for SLs we are at an > impasse and for many years, thus we have decided to deprecate > them for now until a proposal/plan exists. That is a prudent > and logical action. > > Users can do whatever they want and vendors too. 100% agree. > That is not the issue or has anything to do with this > decision in the IETF, as standards body. > > If I did not like the decision and believed it was important > for users I would tell them to ignore the IETF. I have done > that in a few very rare cases and will do it again if > necessary. If you believe that you should do the same and > that's fine. > > But we have made a decision and we should stand by it and > move on here. That is more imporant than SLs to this IETF at > this time. We cannot continue to debate what has clear > consensus and this one does. It is going to kill the IETF > and a major large problem with this standards body that has > to be fixed and this discussion is prime example of the problem. > > > > > > > > I don't agree with you that customers will do as you say. > > > > Maybe you should listen more to customers, because the have, > > they are and they will. > > I do daily and about IPv6. They want to never deal with NAT > again. They also want real security which private address > space does not give them unless they have no links to the > outside Internet anywhere within their network. > > I advise any user I speak with not to use them, except at > their own risk. They will not just blindly use SLs I simply > do not agree. They are well aware of our indecisive > conclusions and their use within this effort in the IETF if > not directly then indirectly. > > Until we define their use and scope within an IPv6 network > there is no logical use for them by any user. Other than a > false belief in securing their network. Once that belief is > shown to be false (and it has by many now) the reasons for > private addresses become illogical and only emotional. And > emotion is not a good plan for a business decision. Any user > that sees that will not decide in favor of emotion. > > We should be talking about scoping of network link partitions > not SLs and once we have that understood address scoping > besides LLs and Globals will be clearer. Why not have > Org-Locals, or Dept-Locals. Etc? The reason is we do not > technically understand their use or limitations within the > IPv6 architecture, there has been no running code at one bake > off to verify they do not break network connectivity for > multisited nodes or cause security faults as just two > examples. With Globals and LLs we have a clue. We have no > real clue for IPv6 only a few theories and cannot get > consensus on that so we deprecate them for now. > > Private addresses in IPv4 are NOT the same as Private > Addresses in IPv6. In IPv6 it creates an address and network > partition scoping abstraction we simply have not completed > our thought processes on and why I believe it prudent > technically to deprecate them for now. > > Can you point me to a public test bed (not private vendor) > that has made extensive use of SLs with IPv6 and verified > their use as we have for Globals and LLs in any IPv6 test bed > in Asia, Europe, or North America? > > Or if you know of stuff going on out of our intra-planetary > system that is fair too :--) > > /jim > > > > > > Michel. > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 3 22:34:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h445Y4hs021562; Sat, 3 May 2003 22:34:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h445Y40a021561; Sat, 3 May 2003 22:34:04 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h445Y1hs021554 for ; Sat, 3 May 2003 22:34:01 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h445WkKw009785 for ; Sat, 3 May 2003 22:32:46 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id XAA07192 for ; Sat, 3 May 2003 23:32:40 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h445WV816527; Sun, 4 May 2003 08:32:31 +0300 Date: Sun, 4 May 2003 08:32:30 +0300 (EEST) From: Pekka Savola To: Michel Py cc: Jim Bound , Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F50457E6@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sat, 3 May 2003, Michel Py wrote: > > Jim Bound wrote: > > [using private addresses] > > Bottom line is users should not use them. > > Bottom line is that nobody tells me what to do on my network and > certainly not the IETF. Sure. You're free to shoot yourself in the foot if you wish. Or if you're really confident that you can hit between your toes and not harm, that's fine too. Just don't expect the IETF to "support" every model the network is run. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 3 22:41:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h445fEhs021730; Sat, 3 May 2003 22:41:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h445fEiV021729; Sat, 3 May 2003 22:41:14 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h445fBhs021722 for ; Sat, 3 May 2003 22:41:11 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h445duKw010747 for ; Sat, 3 May 2003 22:39:56 -0700 (PDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id WAA18414 for ; Sat, 3 May 2003 22:39:51 -0700 (PDT) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h445bmXp019215; Sat, 3 May 2003 22:39:47 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADV03521; Sat, 3 May 2003 22:37:48 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id WAA01702; Sat, 3 May 2003 22:37:48 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16052.42795.930239.415136@thomasm-u1.cisco.com> Date: Sat, 3 May 2003 22:37:47 -0700 (PDT) To: "Michel Py" Cc: "Jim Bound" , Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F50457E6@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F50457E6@server2000.arneill-py.sacramento.ca.us> 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 Michel Py writes: > Jim, > > > Jim Bound wrote: > > [using private addresses] > > Bottom line is users should not use them. > > Bottom line is that nobody tells me what to do on my network and > certainly not the IETF. I hear that Ted Kaczynski's shack is for sale. Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 5 01:13:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h458Djhs024958; Mon, 5 May 2003 01:13:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h458DjOR024957; Mon, 5 May 2003 01:13:45 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h458Dghs024950 for ; Mon, 5 May 2003 01:13:42 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h458CQKw028414 for ; Mon, 5 May 2003 01:12:27 -0700 (PDT) Received: from bt0rjw.god.bel.alcatel.be (alc240.alcatel.be [195.207.101.240]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id CAA16208 for ; Mon, 5 May 2003 02:12:20 -0600 (MDT) From: Robert.Peschi@alcatel.be Received: from bemail01.net.alcatel.be (bemail01.net.alcatel.be [138.203.145.85]) by bt0rjw.god.bel.alcatel.be (8.12.9/8.11.4) with ESMTP id h458CELt009399 for ; Mon, 5 May 2003 10:12:15 +0200 (MEST) Sensitivity: Subject: Re: May one configure IID= "0" for an address ? To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Date: Mon, 5 May 2003 10:12:11 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/05/2003 10:12:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, Thanks for your reply. It is pretty much clear: "normal" unicast addresses must keep off from IID=0. Robert Bob Hinden on 30/04/2003 19:27:56 To: Robert PESCHI/BE/ALCATEL@ALCATEL cc: ipng@sunroof.eng.sun.com Subject: Re: May one configure IID= "0" for an address ? Robert, At 05:14 AM 4/30/2003, Robert.Peschi@alcatel.be wrote: >Hi, >I have found nowhere in (draft)-RFCs a restriction on the value >an Interface ID can take. So in principle any values in [0, 2**64-1] could >be configured as IID for an IPv6 address. Zero is a legitimate address for any field in an IPv6 address. >However, RFC 3513, section 2.6.1 defines the "Subnet-Router Anycast >address" as being :: As you noted that RFC3513 (and it's predecessors) defines the "subnet=router anycast address" as any prefix with the remaining bits of the address set to zero. >Does that mean that configuring IID = 0 might interfere or conflict with >some anycast mechanism ? and consequently that configuring IID=0 >for an address should be avoided ? ...or what do I miss there ? Using a IID of zero does conflict with the subnet anycast address. So zero IID's are legal, but are reserved for the "subnet=router anycast address". Does that help? Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 5 02:24:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h459Oqhs025359; Mon, 5 May 2003 02:24:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h459Oqxi025358; Mon, 5 May 2003 02:24:52 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h459Omhs025351 for ; Mon, 5 May 2003 02:24:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h459NXuc019079 for ; Mon, 5 May 2003 02:23:33 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with SMTP id DAA08547 for ; Mon, 5 May 2003 03:23:27 -0600 (MDT) Received: (qmail 24414 invoked by uid 65534); 5 May 2003 09:23:26 -0000 Received: from e48-2-web.dtrd.de (EHLO JUPITER) (192.166.62.143) by mail.gmx.net (mp010-rz3) with SMTP; 05 May 2003 11:23:26 +0200 From: "Nico Bayer" To: Subject: test - please ignore Date: Mon, 5 May 2003 11:23:11 +0200 Message-ID: <004b01c312e7$f2ae7250$8f3ea6c0@JUPITER> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004C_01C312F8.B6374250" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_004C_01C312F8.B6374250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ------=_NextPart_000_004C_01C312F8.B6374250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

------=_NextPart_000_004C_01C312F8.B6374250-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 5 05:59:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h45CxBhs026562; Mon, 5 May 2003 05:59:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h45CxBGX026561; Mon, 5 May 2003 05:59:11 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h45Cx8hs026554 for ; Mon, 5 May 2003 05:59:08 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h45Cvquc018789 for ; Mon, 5 May 2003 05:57:52 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA21512 for ; Mon, 5 May 2003 06:57:46 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id A00806A903; Mon, 5 May 2003 15:57:38 +0300 (EEST) Message-ID: <3EB65F73.30901@kolumbus.fi> Date: Mon, 05 May 2003 15:56:19 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Cc: Erik Nordmark Subject: Avoiding interface failure upon DAD failure Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, This is something that came up in the IESG review of Mobile IPv6 base specification (draft-ietf-mobileip-ipv6-21.txt). Erik asked us to get an opinion from the IPv6 WG on this. As you know, upon failing Duplicate Address Detection, RFC 2462 requires IPv6 nodes to stop using the address and wait for reconfiguration (Section 4). In addition, if the failed address was a link-local address formed from an interface identifier, the interface should be disabled (Section 5.4.5). The second action is relatively drastic in situations where a host visits a large number of networks and is therefore more likely to get into this situation either by accident or by a malicious act. (SEND WG will eventually solve the latter issue, though.) In Mobile IPv6, we've recommended that if the mobile node wishes to avoid disabling its interface, it can generate link-local addresses in an RFC 3041 fashion and use them. Therefore, the addresses will not be based on an interface identifier and the interface will not have to be disabled per RFC 2462. (Existing rules in the ND RFCs are followed.) Here's the text we have on this: 7.6 Avoiding Failures from Duplicate Addresses Upon failing Duplicate Address Detection, [13] requires IPv6 nodes to stop using the address and wait for reconfiguration. In addition, if the failed address was a link-local address formed from an interface identifier, the interface should be disabled. Mobile nodes that wish to avoid this situation MAY use temporary link-local addresses as follows. The mobile node SHOULD generate a random interface identifier and use it for assigning itself a link-local address for use on this link. In order to do this, the mobile node applies to the link-local address the procedure described in RFC 3041 [18] for global addresses. At most 5 consecutive attempts SHOULD be performed to generate such addresses and test them through Duplicate Address Detection. If after these attempts no unique address was found, the mobile node SHOULD log a system error and give up attempting to find a link-local address on that interface, until the node moves to a new link. And now to the questions for the IPv6 WG: Is this (a) appropriate and (b) in line with RFC 2462 and other possible RFCs? --Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 5 09:50:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h45GoBhs027436; Mon, 5 May 2003 09:50:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h45GoBuq027435; Mon, 5 May 2003 09:50:11 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h45Go7hs027423 for ; Mon, 5 May 2003 09:50:07 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h45GmpKw000793 for ; Mon, 5 May 2003 09:48:51 -0700 (PDT) Received: from web41804.mail.yahoo.com (web41804.mail.yahoo.com [66.218.93.138]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with SMTP id KAA23763 for ; Mon, 5 May 2003 10:48:46 -0600 (MDT) Message-ID: <20030505164845.14254.qmail@web41804.mail.yahoo.com> Received: from [65.213.193.49] by web41804.mail.yahoo.com via HTTP; Mon, 05 May 2003 09:48:45 PDT Date: Mon, 5 May 2003 09:48:45 -0700 (PDT) From: CAITR Reply-To: info@caitr.org Subject: Internetworking 2003: Call for Participation To: ipng@sunroof.eng.sun.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-479845920-1052153325=:13835" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --0-479845920-1052153325=:13835 Content-Type: text/plain; charset=us-ascii Internetworking 2003 International Conference Hilton San Jose & Towers Hotel, California June 22-June 24, 2003 http://www.caitr.org/internetworking03/index.htm You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.Registration for the conference is underway. Please visit http://www.caitr.org/internetworking03/registration.htm and follow instructions for registration. The early registration discounts are extremely attractive and are valid till June 1, 2003.Important Dates: --------------------- - Early Registration Rates Cut-Off Date: Sept 30 - Tutorials: Oct 27, 1:00-6:00 pm - Conference sessions: October 28-29 8:30am-6:00pmProgram: ------------- (visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)Sunday June 22 Tutorial-1: MPLS VPNs Tutorial-2: IPv6 Tutorial-3: Mobile Wireless Internet Architecture and Protocols Tutorial-4: Voice over Packet Monday June 23 Welcome and Keynote Session: Network Technology Trends - Forwarding Element and Control Separation - Evolution of Inter-Domain Routing - Network Processing Building Blocks: Enabling the Routers of the Future Session: Network Architecture - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6 - A new routing architecture: Atomised Routing - Internetworking MPLS Layer 2 Transport with an IP Services Network Session: Storage Area Networks - Storage as a Network Node - Object-Based Storage - Design, Implementation, and Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP - SANs Considerations Session: Mobile & Wireless Networks - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6 - Challenges and Roadmap of UMTS Network Deployment - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS - Mobile Authentication and QoS - Mobile Handoff Technologies Tuesday June 24 Session: Inter-Domain Routing - Optimizing Route Convergence - Traceroute and BGP AS Path Incongruities - Domain Constrained Multicast: A New Approach for IP Multicast Routing Session: Applications & Services - Securing the Web with Next Generation Encryption Technologies - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21 - A novel EAC semantic for the RTSP protocol - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet Session: Network Management & Planning - Pseudowire OAM: A Mandatory Yet Often Overlooked Feature - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Probems - Design Of Fast Fault Restoration System For WDM Networks - Cross-domain multimedia service provisioning, the EVOLUTE solution Session: QoS Based Routing - QoS Routing in Networks with Non-Deterministic Information - Active Dynamic Routing - QoS routing for Differentiated Services: simulations and prototype experiments - Probabilistic routing for QoS improvement in GPS networks - Fluid flow network modeling for hop-by-hop feedback control design and analysis We look forward to seeing you at the Conference. Regards, Conference Technical Co-chairs: - Dr. Maurice Gagnaire, ENST, France - Daniel Awduche Technical Program Committee of the Internetworking 2003 Conference: - Roberto Sabella, Erisson - Dr. Moshe Zukerman, Univ. of Melbourne - Nada Golmie, NIST - Dr. Guy Pujolle, LIP6, France - Dr. Samir Tohme, ENST, France - Stefano Trumpy, Italian National Research Council - Dr. Ibrahim Habib, City Univ. of NY - Dr. Marc Lobelle, UCL University, Belgium - Dr. Parviz Yegani, Cisco Systems - Dr. G.S. Kuo - Dr. Abbas Jamalipour, Univ. of Sydney - Dr. Hussein Mouftah, Univ. of Ottawa - James Kempf - Elizabeth Rodriguez - Dr. Ferit Yegenoglu, Isocore - Dr. Ali Zadeh, George Mason University - Dr. Tony Przygienda, Xebeo - Ran Canetti, IBM --0-479845920-1052153325=:13835 Content-Type: text/html; charset=us-ascii
 

     Internetworking 2003 International Conference
     Hilton San Jose & Towers Hotel, California
              June 22-June 24, 2003
    http://www.caitr.org/internetworking03/index.htm
  
You are cordially invited to attend the Internetworking 2003 International Conference to be held in San Jose, California, June 22-24, 2003. The 3-day event consists of two-days of highly technical sessions, preceded by four technical tutorials.
Registration for the conference is underway. Please visit http://www.caitr.org/internetworking03/registration.htm and follow instructions for registration. The early registration discounts are extremely attractive and are valid till June 1, 2003.
Important Dates:
---------------------
- Early Registration Rates Cut-Off Date: Sept 30
- Tutorials: Oct 27, 1:00-6:00 pm
- Conference sessions: October 28-29 8:30am-6:00pm
Program:
-------------
(visit http://www.caitr.org/internetworking03/program.htm for abstracts and speaker details)
Sunday June 22
    Tutorial-1: MPLS VPNs 
    Tutorial-2: IPv6 
    Tutorial-3: Mobile Wireless Internet Architecture and Protocols
    Tutorial-4: Voice over Packet 
Monday June 23
    Welcome and Keynote 
    Session: Network Technology Trends
      - Forwarding Element and Control Separation
      - Evolution of Inter-Domain Routing
      - Network Processing Building Blocks: Enabling the Routers of the Future
    Session: Network Architecture
      - An architecture for IPv6 VPNs and IPv6 transport over MPLS/GMPLS multiservice backbones IPv6
      - A new routing architecture: Atomised Routing
      - Internetworking MPLS Layer 2 Transport with an IP Services Network
    Session: Storage Area Networks
      - Storage as a Network Node
      - Object-Based Storage
      - Design, Implementation, and ! Performance Analysis of the iSCSI Protocol for SCSI over TCP/IP
      - SANs Considerations
 
    Session: Mobile & Wireless Networks
      - CertBU: Certificate-based Techniques for Securing Mobile IPv6 Binding Updates IPv6
      - Challenges and Roadmap of UMTS Network Deployment
      - Inter-working Mobile IPv6 with IP Multimedia Subsystem in UMTS 
      - Mobile Authentication and QoS 
      - Mobile Handoff Technologies 
Tuesday June 24
    Session: Inter-Domain Routing
      - Optimizing Route Convergence
      - Traceroute and BGP AS Path Incongruities 
      - Domain Constrained Multicast: A New Approach for IP Multicast Routing
 
    Session: Applications & Services
     -  Securing the Web with Next Generation Encryption Technologies
     - Impact of the live radio on the Internet, and the real-time streaming audio, in the ComUNITY cable system from Com21
     - A novel EAC semantic for the RTSP protocol
     - Towards an end-to-end architecture integrating new Transport and IP services in a DiffServ Internet
 
    Session: Network Management & Planning
     -  Pseudowire OAM: A Mandatory Ye! t Often Overlooked Feature 
     - A Multicommodity Flow Formulation for the MPLS Layout Design: Reduced Complexity Layout and Minimum Relayout Probems
     - Design Of Fast Fault Restoration System For WDM Networks
     - Cross-domain multimedia service provisioning, the EVOLUTE solution
 
    Session: QoS Based Routing
     - QoS Routing in Networks with Non-Deterministic Information
     - Active Dynamic Routing
     - QoS routing for Differentiated Services: simulations and prototype experiments
     - Probabilistic routing for QoS improvement in GPS networks
     - Fluid flow network modeling for hop-by-hop feedback control design and analysis
 
We look forward to seeing you at the Conference.
Regards,
 Conference Technical Co-chai! rs:
 - Dr. Maurice Gagnaire, ENST, France
 - Daniel Awduche
 Technical Program Committee of the Internetworking 2003 Conference:
 - Roberto Sabella, Erisson
 - Dr. Moshe Zukerman, Univ. of Melbourne
 - Nada Golmie, NIST
 - Dr. Guy Pujolle, LIP6, France
 - Dr. Samir Tohme, ENST, France
 - Stefano Trumpy, Italian National Research Council
 - Dr. Ibrahim Habib, City Univ. of NY
 - Dr. Marc Lobelle, UCL University, Belgium
 - Dr. Parviz Yegani, Cisco Systems
 - Dr. G.S. Kuo
 - Dr. Abbas Jamalipour, Univ. of Sydney
 - Dr. Hussein Mouftah, Univ. of Ottawa
 - James Kempf
 - Elizabeth Rodriguez
 - Dr. Ferit Yegenoglu, Isocore
 - Dr. Ali Zadeh, George Mason University
 - Dr. Tony Przygienda, Xebeo
 - Ran Canetti, IBM

 
--0-479845920-1052153325=:13835-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 5 10:37:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h45Hbwhs028134; Mon, 5 May 2003 10:37:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h45HbweS028133; Mon, 5 May 2003 10:37:58 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h45Hbths028126 for ; Mon, 5 May 2003 10:37:55 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h45HaYKw017127 for ; Mon, 5 May 2003 10:36:34 -0700 (PDT) Received: from motgate5.mot.com (motgate5.mot.com [144.189.100.105]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h45HaSTl008823 for ; Mon, 5 May 2003 10:36:28 -0700 (PDT) Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate5.mot.com (Motorola/Motgate5) with ESMTP id h45HaSsI012865 for ; Mon, 5 May 2003 10:36:28 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id h45HaOQx002438 for ; Mon, 5 May 2003 12:36:26 -0500 Received: from motorola.com (ma19-0008.e2.bcs.mot.com [10.14.10.58]) by zin05exm02.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id K155KK5R; Mon, 5 May 2003 23:06:22 +0530 Message-ID: <3EB6A111.D13497D0@motorola.com> Date: Mon, 05 May 2003 13:36:17 -0400 From: Bhaskar S Organization: Motorola Inc. X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: "Bound, Jim" , Michel Py Subject: Re: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) References: <9C422444DE99BC46B3AD3C6EAFC9711B032411E1@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have seen some network boxes which use ethernet as the backplane. Say for example using J4/P4 of CompactPCI. In this case one would like to have a private address space for the backplane. So that any outsider would not be able to see the internals of the boxes. I am wondering how we would setup IP address for the backplane interfaces of these boxes in the current scenario? Any suggestions? "Bound, Jim" wrote: > > Michel, > > > Bottom line is that nobody tells me what to do on my network > > and certainly not the IETF. > > I completely agree. The IETF is in the business of defining standards > that may or may not be used in the real world. For the effort of > defining the standard for SLs we are at an impasse and for many years, > thus we have decided to deprecate them for now until a proposal/plan > exists. That is a prudent and logical action. > > Users can do whatever they want and vendors too. 100% agree. That is > not the issue or has anything to do with this decision in the IETF, as > standards body. > > If I did not like the decision and believed it was important for users I > would tell them to ignore the IETF. I have done that in a few very rare > cases and will do it again if necessary. If you believe that you should > do the same and that's fine. > > But we have made a decision and we should stand by it and move on here. > That is more imporant than SLs to this IETF at this time. We cannot > continue to debate what has clear consensus and this one does. It is > going to kill the IETF and a major large problem with this standards > body that has to be fixed and this discussion is prime example of the > problem. > > > > > > > > I don't agree with you that customers will do as you say. > > > > Maybe you should listen more to customers, because the have, > > they are and they will. > > I do daily and about IPv6. They want to never deal with NAT again. > They also want real security which private address space does not give > them unless they have no links to the outside Internet anywhere within > their network. > > I advise any user I speak with not to use them, except at their own > risk. They will not just blindly use SLs I simply do not agree. They > are well aware of our indecisive conclusions and their use within this > effort in the IETF if not directly then indirectly. > > Until we define their use and scope within an IPv6 network there is no > logical use for them by any user. Other than a false belief in securing > their network. Once that belief is shown to be false (and it has by > many now) the reasons for private addresses become illogical and only > emotional. And emotion is not a good plan for a business decision. Any > user that sees that will not decide in favor of emotion. > > We should be talking about scoping of network link partitions not SLs > and once we have that understood address scoping besides LLs and Globals > will be clearer. Why not have Org-Locals, or Dept-Locals. Etc? The > reason is we do not technically understand their use or limitations > within the IPv6 architecture, there has been no running code at one bake > off to verify they do not break network connectivity for multisited > nodes or cause security faults as just two examples. With Globals and > LLs we have a clue. We have no real clue for IPv6 only a few theories > and cannot get consensus on that so we deprecate them for now. > > Private addresses in IPv4 are NOT the same as Private Addresses in IPv6. > In IPv6 it creates an address and network partition scoping abstraction > we simply have not completed our thought processes on and why I believe > it prudent technically to deprecate them for now. > > Can you point me to a public test bed (not private vendor) that has made > extensive use of SLs with IPv6 and verified their use as we have for > Globals and LLs in any IPv6 test bed in Asia, Europe, or North America? > > Or if you know of stuff going on out of our intra-planetary system that > is fair too :--) > > /jim > > > > > Michel. > > > > > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- Best Regards, Bhaskar S. 978-858-2896 (o) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 5 11:00:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h45Hxxhs028482; Mon, 5 May 2003 11:00:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h45HxxWI028481; Mon, 5 May 2003 10:59:59 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h45Hxuhs028474 for ; Mon, 5 May 2003 10:59:56 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h45HweKw025294 for ; Mon, 5 May 2003 10:58:40 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h45HwZTl018945 for ; Mon, 5 May 2003 10:58:35 -0700 (PDT) Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA18049; Mon, 5 May 2003 10:57:51 -0700 (PDT) Message-Id: <5.1.0.14.2.20030505134643.045e3800@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 05 May 2003 13:47:44 -0400 To: Bhaskar S From: Margaret Wasserman Subject: Re: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3EB6A111.D13497D0@motorola.com> References: <9C422444DE99BC46B3AD3C6EAFC9711B032411E1@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bhaskar, In the case you have described, I think that link-local addressing would work well. Margaret At 01:36 PM 5/5/2003 -0400, Bhaskar S wrote: >Hi, > >I have seen some network boxes which use ethernet as the backplane. Say >for example using J4/P4 of CompactPCI. In this case one would like to >have a private address space for the backplane. So that any outsider >would not be able to see the internals of the boxes. > >I am wondering how we would setup IP address for the backplane >interfaces of these boxes in the current scenario? > >Any suggestions? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 5 11:08:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h45I8nhs028659; Mon, 5 May 2003 11:08:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h45I8n0n028658; Mon, 5 May 2003 11:08:49 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h45I8khs028648 for ; Mon, 5 May 2003 11:08:46 -0700 (PDT) Received: from patan.sun.com (patan.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h45I7Tuc003851 for ; Mon, 5 May 2003 11:07:30 -0700 (PDT) Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by patan.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA29302 for ; Mon, 5 May 2003 12:07:24 -0600 (MDT) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h45I7Jua025837; Mon, 5 May 2003 11:07:19 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id ADV69991; Mon, 5 May 2003 11:07:18 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA08237; Mon, 5 May 2003 11:07:18 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16054.43094.53011.299558@thomasm-u1.cisco.com> Date: Mon, 5 May 2003 11:07:18 -0700 (PDT) To: Bhaskar S Cc: ipng@sunroof.eng.sun.com, "Bound, Jim" , Michel Py Subject: Re: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) In-Reply-To: <3EB6A111.D13497D0@motorola.com> References: <9C422444DE99BC46B3AD3C6EAFC9711B032411E1@tayexc13.americas.cpqcorp.net> <3EB6A111.D13497D0@motorola.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bhaskar S writes: > Hi, > > I have seen some network boxes which use ethernet as the backplane. Say > for example using J4/P4 of CompactPCI. In this case one would like to > have a private address space for the backplane. So that any outsider > would not be able to see the internals of the boxes. > > I am wondering how we would setup IP address for the backplane > interfaces of these boxes in the current scenario? Link locals wouldn't suffice? Mike -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 5 12:02:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h45J2chs029527; Mon, 5 May 2003 12:02:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h45J2beO029526; Mon, 5 May 2003 12:02:37 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h45J2Yhs029519 for ; Mon, 5 May 2003 12:02:34 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h45J1Iuc024205 for ; Mon, 5 May 2003 12:01:18 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA06536 for ; Mon, 5 May 2003 13:01:12 -0600 (MDT) Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h45J1CG7029696 for ; Mon, 5 May 2003 12:01:12 -0700 (MST) Received: from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h45J15ir012394 for ; Mon, 5 May 2003 14:01:09 -0500 Received: from motorola.com (ma19-0008.e2.bcs.mot.com [10.14.10.58]) by zin05exm02.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2656.59) id K155KLFS; Tue, 6 May 2003 00:31:03 +0530 Message-ID: <3EB6B4EA.A28A3A99@motorola.com> Date: Mon, 05 May 2003 15:00:58 -0400 From: Bhaskar S Organization: Motorola Inc. X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com CC: Michael Thomas , "Bound, Jim" , Michel Py Subject: Re: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) References: <9C422444DE99BC46B3AD3C6EAFC9711B032411E1@tayexc13.americas.cpqcorp.net> <3EB6A111.D13497D0@motorola.com> <16054.43094.53011.299558@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mike, Yes I feel you are correct. My understanding is that link-local address are not global addresses (pl correct me if I am wrong). To use it I should not be connected to the internet. I'll need to block these addresses from getting into the internet. Michael Thomas wrote: > > Bhaskar S writes: > > Hi, > > > > I have seen some network boxes which use ethernet as the backplane. Say > > for example using J4/P4 of CompactPCI. In this case one would like to > > have a private address space for the backplane. So that any outsider > > would not be able to see the internals of the boxes. > > > > I am wondering how we would setup IP address for the backplane > > interfaces of these boxes in the current scenario? > > Link locals wouldn't suffice? > > Mike -- Best Regards, Bhaskar S. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 5 12:19:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h45JJVhs029773; Mon, 5 May 2003 12:19:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h45JJVkK029772; Mon, 5 May 2003 12:19:31 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h45JJShs029765 for ; Mon, 5 May 2003 12:19:28 -0700 (PDT) Received: from pheriche.sun.com (pheriche.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h45JICuc001815 for ; Mon, 5 May 2003 12:18:12 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by pheriche.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA29387 for ; Mon, 5 May 2003 13:18:06 -0600 (MDT) Received: from IDLEWYLDE.windriver.com ([147.11.233.3]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id MAA11690; Mon, 5 May 2003 12:17:18 -0700 (PDT) Message-Id: <5.1.0.14.2.20030505151248.045e4e50@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 05 May 2003 15:14:09 -0400 To: Bhaskar S From: Margaret Wasserman Subject: Re: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Cc: ipng@sunroof.eng.sun.com, Michael Thomas , "Bound, Jim" , Michel Py In-Reply-To: <3EB6B4EA.A28A3A99@motorola.com> References: <9C422444DE99BC46B3AD3C6EAFC9711B032411E1@tayexc13.americas.cpqcorp.net> <3EB6A111.D13497D0@motorola.com> <16054.43094.53011.299558@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bhaskar, Link-local addresses are not routed at all, they just work on a single link. So you won't need to do anything special to block these addresses from getting onto the global Internet, as no IP implementation should forward them. Of course, if you are writing the IP implementation yourself, you shouldn't forward them. Margaret At 03:00 PM 5/5/2003 -0400, Bhaskar S wrote: >Hi Mike, > >Yes I feel you are correct. > >My understanding is that link-local address are not global addresses (pl >correct me if I am wrong). To use it I should not be connected to the >internet. > >I'll need to block these addresses from getting into the internet. > >Michael Thomas wrote: > > > > Bhaskar S writes: > > > Hi, > > > > > > I have seen some network boxes which use ethernet as the backplane. Say > > > for example using J4/P4 of CompactPCI. In this case one would like to > > > have a private address space for the backplane. So that any outsider > > > would not be able to see the internals of the boxes. > > > > > > I am wondering how we would setup IP address for the backplane > > > interfaces of these boxes in the current scenario? > > > > Link locals wouldn't suffice? > > > > Mike > >-- >Best Regards, > >Bhaskar S. >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home 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 May 6 05:09:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h46C9mhs005489; Tue, 6 May 2003 05:09:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h46C9mcx005488; Tue, 6 May 2003 05:09:48 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h46C9ihs005481 for ; Tue, 6 May 2003 05:09:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h46C8RKw012808 for ; Tue, 6 May 2003 05:08:27 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id GAA12411 for ; Tue, 6 May 2003 06:08:21 -0600 (MDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h46C8KD04778 for ; Tue, 6 May 2003 15:08:20 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 6 May 2003 15:08:19 +0300 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 6 May 2003 15:08:19 +0300 Received: from esebe012.NOE.Nokia.com ([172.21.138.51]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 6 May 2003 15:08:18 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe012.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Tue, 6 May 2003 15:08:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Avoiding interface failure upon DAD failure Date: Tue, 6 May 2003 15:08:16 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Avoiding interface failure upon DAD failure Thread-Index: AcMTB9jkKe/nJtQZRKm1lsehmKqciQAwAIcg To: , Cc: X-OriginalArrivalTime: 06 May 2003 12:08:18.0171 (UTC) FILETIME=[2DF1BCB0:01C313C8] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h46C9jhs005482 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jari, > This is something that came up in the IESG review of Mobile > IPv6 base specification (draft-ietf-mobileip-ipv6-21.txt). > Erik asked us to get an opinion from the IPv6 WG on this. > > As you know, upon failing Duplicate Address Detection, RFC 2462 > requires IPv6 nodes to stop using the address and wait for > reconfiguration (Section 4). In addition, if the failed address > was a link-local address formed from an interface identifier, > the interface should be disabled (Section 5.4.5). > > The second action is relatively drastic in situations where > a host visits a large number of networks and is therefore > more likely to get into this situation either by accident or > by a malicious act. (SEND WG will eventually solve the > latter issue, though.) I agree that the solution posed by 2462 is (IMO) too drastic. > In Mobile IPv6, we've recommended that if the mobile > node wishes to avoid disabling its interface, it can > generate link-local addresses in an RFC 3041 fashion > and use them. Therefore, the addresses will not be > based on an interface identifier and the interface > will not have to be disabled per RFC 2462. (Existing > rules in the ND RFCs are followed.) Here's the text > we have on this: I think that this solution (& your proposed text) is a reasonable way forward. I think that we should consider updated 2462. br, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 6 12:33:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h46JXMhs007270; Tue, 6 May 2003 12:33:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h46JXMDn007269; Tue, 6 May 2003 12:33:22 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h46JXJhs007262 for ; Tue, 6 May 2003 12:33:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h46JW1uc015827 for ; Tue, 6 May 2003 12:32:01 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id NAA20339 for ; Tue, 6 May 2003 13:31:54 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h46JVpp07829; Tue, 6 May 2003 22:31:51 +0300 Date: Tue, 6 May 2003 22:31:50 +0300 (EEST) From: Pekka Savola To: Jari Arkko cc: ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Avoiding interface failure upon DAD failure In-Reply-To: <3EB65F73.30901@kolumbus.fi> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 5 May 2003, Jari Arkko wrote: > 7.6 Avoiding Failures from Duplicate Addresses > > Upon failing Duplicate Address Detection, [13] requires IPv6 nodes to > stop using the address and wait for reconfiguration. In addition, if > the failed address was a link-local address formed from an interface > identifier, the interface should be disabled. > > Mobile nodes that wish to avoid this situation MAY use temporary > link-local addresses as follows. The mobile node SHOULD generate a > random interface identifier and use it for assigning itself a > link-local address for use on this link. In order to do this, the > mobile node applies to the link-local address the procedure described > in RFC 3041 [18] for global addresses. At most 5 consecutive > attempts SHOULD be performed to generate such addresses and test them > through Duplicate Address Detection. If after these attempts no > unique address was found, the mobile node SHOULD log a system error > and give up attempting to find a link-local address on that > interface, until the node moves to a new link. > > And now to the questions for the IPv6 WG: Is this (a) appropriate and > (b) in line with RFC 2462 and other possible RFCs? The intent seems rather reasonable to me. The first two sentences of the second paragraph seem slightly ambiguous to me: Mobile nodes that wish to avoid this situation MAY use temporary link-local addresses as follows. The mobile node SHOULD generate a random interface identifier and use it for assigning itself a link-local address for use on this link. ==> why a 'SHOULD'? Would and alternative be to just use the same address which collided (as with the previous versions of the spec)? It seems to me that this might be written a bit differently, like: Mobile nodes that wish to avoid this situation MAY use temporary link-local addresses by generating a random interface identifier and using it for assigning itself a link-local address for use on this link. As another issue: At most 5 consecutive attempts SHOULD be performed to generate such addresses Does this intend to say that implementetations SHOULD do consecutive attempts? I don't agree that it's necessary, RFC3041 are very random, and if there is a collision, something is very wrong. Or that implementations SHOULD NOT perform more than 5 attempts? (A very reasonable thing to say.) Depending on the intent, the sentence could be rephrased slightly. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 6 12:49:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h46JnYhs007605; Tue, 6 May 2003 12:49:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h46JnYLA007604; Tue, 6 May 2003 12:49:34 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h46JnShs007590 for ; Tue, 6 May 2003 12:49:28 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h46JmBuc020087 for ; Tue, 6 May 2003 12:48:11 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id NAA26646 for ; Tue, 6 May 2003 13:48:04 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 2D0D46A903; Tue, 6 May 2003 22:48:03 +0300 (EEST) Message-ID: <3EB81124.7020509@kolumbus.fi> Date: Tue, 06 May 2003 22:46:44 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Avoiding interface failure upon DAD failure References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > The intent seems rather reasonable to me. Great. > The first two sentences of the second paragraph seem slightly ambiguous to > me: > > Mobile nodes that wish to avoid this situation MAY use temporary > link-local addresses as follows. The mobile node SHOULD generate a > random interface identifier and use it for assigning itself a > link-local address for use on this link. > > ==> why a 'SHOULD'? Would and alternative be to just use the same address > which collided (as with the previous versions of the spec)? > > It seems to me that this might be written a bit differently, like: > > Mobile nodes that wish to avoid this situation MAY use temporary > link-local addresses by generating a > random interface identifier and using it for assigning itself a > link-local address for use on this link. Sounds very good. The existing text indeed uses strangly MAY and then a SHOULD. > As another issue: > > At most 5 consecutive > attempts SHOULD be performed to generate such addresses > > Does this intend to say that implementetations SHOULD do consecutive > attempts? I don't agree that it's necessary, RFC3041 are very random, > and if there is a collision, something is very wrong. Or that > implementations SHOULD NOT perform more than 5 attempts? (A very > reasonable thing to say.) The latter. Rephrased. Thanks. --Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 6 21:42:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h474ghhs010919; Tue, 6 May 2003 21:42:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h474gh41010918; Tue, 6 May 2003 21:42:43 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h474gehs010911 for ; Tue, 6 May 2003 21:42:40 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h474fNKw020431 for ; Tue, 6 May 2003 21:41:23 -0700 (PDT) Received: from SifyMail1.1 (sifyr3.maa.sify.net [202.144.76.26]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with SMTP id VAA00261 for ; Tue, 6 May 2003 21:41:16 -0700 (PDT) Received: (qmail 11066 invoked by uid 7002); 7 May 2003 09:49:55 +0530 Received: from 202.144.76.26 (HELO SifyMail1.1) (202.144.76.26) by 202.144.76.26 with SMTP; 7 May 2003 09:49:55 +0530 Received: (qmail 11664 invoked by uid 7002); 7 May 2003 09:49:54 +0530 Received: from 202.144.76.21 (HELO SifyMail1.0) (202.144.76.21) by 0 with SMTP; 7 May 2003 09:49:54 +0530 Received: (qmail 11660 invoked from 97.114.47.114 by host webmail5.maa.sify.net by uid 99); 7 May 2003 09:49:54 +0530 To: ipng@sunroof.eng.sun.com Subject: oid for IPv6 address in snmp request Message-ID: <1052281194.3eb8896a66b62@webmail5.maa.sify.net> Date: Wed, 07 May 2003 09:49:54 +0500 (IST) From: Ravi Kumar M MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk hi, can any one let me know how to give the oid for IPv6 address in SNMP request? Thanks & regards Ravi ------------------------------------------------- Sify Mail - now with Anti-virus protection powered by Trend Micro, USA. Know more at http://mail.sify.com Sify Power mail- a Premium Service from Sify Mail! know more at http://mail.sify.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 May 7 05:26:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47CQNhs012929; Wed, 7 May 2003 05:26:23 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h47CQMDh012928; Wed, 7 May 2003 05:26:22 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47CQJhs012921 for ; Wed, 7 May 2003 05:26:19 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h47CP0Kw009157 for ; Wed, 7 May 2003 05:25:01 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id GAA27683 for ; Wed, 7 May 2003 06:24:55 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id EFC27CD81; Wed, 7 May 2003 08:24:53 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 7 May 2003 08:24:53 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Wed, 7 May 2003 08:24:53 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD728@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Thread-Index: AcMTLONxltBdzOC8QbqOVCFr7IMyggBZpnlA From: "Bound, Jim" To: "Bhaskar S" , Cc: "Michel Py" X-OriginalArrivalTime: 07 May 2003 12:24:53.0851 (UTC) FILETIME=[A9D432B0:01C31493] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h47CQKhs012922 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I would suggest this is a valid use of Link-Local addresses on the backplane. Why would that not work and I would use when we have scoping figured out in this case. Esp for CompactPCI? /jim > -----Original Message----- > From: Bhaskar S [mailto:Bhaskar.s@motorola.com] > Sent: Monday, May 05, 2003 1:36 PM > To: ipng@sunroof.eng.sun.com > Cc: Bound, Jim; Michel Py > Subject: Re: Your Appeal Regarding Site-Local Deprecation > (Was: Consensus on Site-Local Addressing) > > > Hi, > > I have seen some network boxes which use ethernet as the > backplane. Say for example using J4/P4 of CompactPCI. In this > case one would like to have a private address space for the > backplane. So that any outsider would not be able to see the > internals of the boxes. > > I am wondering how we would setup IP address for the > backplane interfaces of these boxes in the current scenario? > > Any suggestions? > > "Bound, Jim" wrote: > > > > Michel, > > > > > Bottom line is that nobody tells me what to do on my network and > > > certainly not the IETF. > > > > I completely agree. The IETF is in the business of > defining standards > > that may or may not be used in the real world. For the effort of > > defining the standard for SLs we are at an impasse and for > many years, > > thus we have decided to deprecate them for now until a > proposal/plan > > exists. That is a prudent and logical action. > > > > Users can do whatever they want and vendors too. 100% > agree. That is > > not the issue or has anything to do with this decision in > the IETF, as > > standards body. > > > > If I did not like the decision and believed it was > important for users > > I would tell them to ignore the IETF. I have done that in > a few very > > rare cases and will do it again if necessary. If you > believe that you > > should do the same and that's fine. > > > > But we have made a decision and we should stand by it and move on > > here. That is more imporant than SLs to this IETF at this time. We > > cannot continue to debate what has clear consensus and this > one does. > > It is going to kill the IETF and a major large problem with this > > standards body that has to be fixed and this discussion is prime > > example of the problem. > > > > > > > > > > > > I don't agree with you that customers will do as you say. > > > > > > Maybe you should listen more to customers, because the have, they > > > are and they will. > > > > I do daily and about IPv6. They want to never deal with NAT again. > > They also want real security which private address space > does not give > > them unless they have no links to the outside Internet > anywhere within > > their network. > > > > I advise any user I speak with not to use them, except at their own > > risk. They will not just blindly use SLs I simply do not > agree. They > > are well aware of our indecisive conclusions and their use > within this > > effort in the IETF if not directly then indirectly. > > > > Until we define their use and scope within an IPv6 network > there is no > > logical use for them by any user. Other than a false belief in > > securing their network. Once that belief is shown to be > false (and it > > has by many now) the reasons for private addresses become illogical > > and only emotional. And emotion is not a good plan for a business > > decision. Any user that sees that will not decide in favor > of emotion. > > > > We should be talking about scoping of network link > partitions not SLs > > and once we have that understood address scoping besides > LLs and Globals > > will be clearer. Why not have Org-Locals, or Dept-Locals. > Etc? The > > reason is we do not technically understand their use or limitations > > within the IPv6 architecture, there has been no running code at one > > bake off to verify they do not break network connectivity for > > multisited nodes or cause security faults as just two > examples. With > > Globals and LLs we have a clue. We have no real clue for > IPv6 only a > > few theories and cannot get consensus on that so we > deprecate them for > > now. > > > > Private addresses in IPv4 are NOT the same as Private Addresses in > > IPv6. In IPv6 it creates an address and network partition scoping > > abstraction we simply have not completed our thought > processes on and > > why I believe it prudent technically to deprecate them for now. > > > > Can you point me to a public test bed (not private vendor) that has > > made extensive use of SLs with IPv6 and verified their use > as we have > > for Globals and LLs in any IPv6 test bed in Asia, Europe, or North > > America? > > > > Or if you know of stuff going on out of our intra-planetary system > > that is fair too :--) > > > > /jim > > > > > > > > Michel. > > > > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > -- > Best Regards, > > Bhaskar S. > > 978-858-2896 (o) > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 7 05:27:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47CR0hs012946; Wed, 7 May 2003 05:27:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h47CR0C4012945; Wed, 7 May 2003 05:27:00 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47CQvhs012938 for ; Wed, 7 May 2003 05:26:57 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h47CPcKw009237 for ; Wed, 7 May 2003 05:25:38 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA09402 for ; Wed, 7 May 2003 06:25:33 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id C13E0A648; Wed, 7 May 2003 08:25:32 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 7 May 2003 08:25:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Wed, 7 May 2003 08:25:32 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD729@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Thread-Index: AcMTMTFQPxVa52l2QSONefEcpH5h4gBYoFwA From: "Bound, Jim" To: "Michael Thomas" , "Bhaskar S" Cc: , "Michel Py" X-OriginalArrivalTime: 07 May 2003 12:25:32.0679 (UTC) FILETIME=[C0F8E170:01C31493] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h47CQvhs012939 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Why not please explain I know this space fairly well on my day job? /jim > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, May 05, 2003 2:07 PM > To: Bhaskar S > Cc: ipng@sunroof.eng.sun.com; Bound, Jim; Michel Py > Subject: Re: Your Appeal Regarding Site-Local Deprecation > (Was: Consensus on Site-Local Addressing) > > > Bhaskar S writes: > > Hi, > > > > I have seen some network boxes which use ethernet as the > backplane. Say > for example using J4/P4 of CompactPCI. In > this case one would like to > have a private address space > for the backplane. So that any outsider > would not be able > to see the internals of the boxes. > > > I am wondering how we would setup IP address for the > backplane > interfaces of these boxes in the current scenario? > > Link locals wouldn't suffice? > > 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 Wed May 7 05:28:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47CSths012974; Wed, 7 May 2003 05:28:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h47CSsp0012973; Wed, 7 May 2003 05:28:54 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47CSphs012966 for ; Wed, 7 May 2003 05:28:51 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h47CRWKw009522 for ; Wed, 7 May 2003 05:27:32 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA15007 for ; Wed, 7 May 2003 05:27:27 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id B8DE18A6E; Wed, 7 May 2003 08:27:26 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 7 May 2003 08:27:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Date: Wed, 7 May 2003 08:27:26 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD72A@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Your Appeal Regarding Site-Local Deprecation (Was: Consensus on Site-Local Addressing) Thread-Index: AcMTOLTsGc1zp4KiSPm+iLJA/quHZgBWx18Q From: "Bound, Jim" To: "Bhaskar S" , Cc: "Michael Thomas" , "Michel Py" X-OriginalArrivalTime: 07 May 2003 12:27:26.0679 (UTC) FILETIME=[04EBE670:01C31494] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h47CSphs012967 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk When the xxPCI or backplane requires communication off the back plane to say another back plane over a network I would argue if on the same link the LLs work still but if off-link then use globals and secure your network. /jim > -----Original Message----- > From: Bhaskar S [mailto:Bhaskar.s@motorola.com] > Sent: Monday, May 05, 2003 3:01 PM > To: ipng@sunroof.eng.sun.com > Cc: Michael Thomas; Bound, Jim; Michel Py > Subject: Re: Your Appeal Regarding Site-Local Deprecation > (Was: Consensus on Site-Local Addressing) > > > Hi Mike, > > Yes I feel you are correct. > > My understanding is that link-local address are not global > addresses (pl correct me if I am wrong). To use it I should > not be connected to the internet. > > I'll need to block these addresses from getting into the internet. > > Michael Thomas wrote: > > > > Bhaskar S writes: > > > Hi, > > > > > > I have seen some network boxes which use ethernet as the > backplane. > > Say > for example using J4/P4 of CompactPCI. In this case > one would > > like to > have a private address space for the backplane. > So that any > > outsider > would not be able to see the internals of the boxes. > > > > I am wondering how we would setup IP address for the backplane > > > interfaces of these boxes in the current scenario? > > > > Link locals wouldn't suffice? > > > > Mike > > -- > Best Regards, > > Bhaskar S. > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 7 05:40:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47CeYhs013534; Wed, 7 May 2003 05:40:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h47CeXCe013533; Wed, 7 May 2003 05:40:33 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47CeUhs013526 for ; Wed, 7 May 2003 05:40:30 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h47CdCuc029697 for ; Wed, 7 May 2003 05:39:12 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA20991 for ; Wed, 7 May 2003 05:39:06 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 0B8FCBC54; Wed, 7 May 2003 08:39:06 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 7 May 2003 08:39:05 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Avoiding interface failure upon DAD failure Date: Wed, 7 May 2003 08:39:03 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD72B@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Avoiding interface failure upon DAD failure Thread-Index: AcMTBlW6HjB0ZnGYTGKkP0Wc2NpBdwBjpCig From: "Bound, Jim" To: "Jari Arkko" , Cc: "Erik Nordmark" X-OriginalArrivalTime: 07 May 2003 12:39:05.0987 (UTC) FILETIME=[A5BDD530:01C31495] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h47CeUhs013527 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jarko, My input is that if LLs do not pass DaD then something is very broken. To do a work around this is not prudent in our standards process when DaD breaks. In any interoperability test suite I know if you fail DaD and don't do what our specs say you fail the test period. Use of RFC 3041 was mean't (IMO) to be used once normal DaD was working not as end-run around the rules of DaD for mobile nodes. I am not convinced by your mail this is acceptable and this is valid concern by ADs. I do not think SEND needs to complete to move forward at all and I will be sending clear errors to several of the principles regarding their misuse of IPsec or request for alterations soon. Just fail on the interface per the specs and move forward with the spec. Regards, /jim > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Monday, May 05, 2003 8:56 AM > To: ipng@sunroof.eng.sun.com > Cc: Erik Nordmark > Subject: Avoiding interface failure upon DAD failure > > > > Hi, > > This is something that came up in the IESG review of Mobile > IPv6 base specification (draft-ietf-mobileip-ipv6-21.txt). > Erik asked us to get an opinion from the IPv6 WG on this. > > As you know, upon failing Duplicate Address Detection, RFC > 2462 requires IPv6 nodes to stop using the address and wait > for reconfiguration (Section 4). In addition, if the failed > address was a link-local address formed from an interface > identifier, the interface should be disabled (Section 5.4.5). > > The second action is relatively drastic in situations where > a host visits a large number of networks and is therefore > more likely to get into this situation either by accident or > by a malicious act. (SEND WG will eventually solve the > latter issue, though.) > > In Mobile IPv6, we've recommended that if the mobile > node wishes to avoid disabling its interface, it can > generate link-local addresses in an RFC 3041 fashion > and use them. Therefore, the addresses will not be > based on an interface identifier and the interface > will not have to be disabled per RFC 2462. (Existing > rules in the ND RFCs are followed.) Here's the text > we have on this: > > 7.6 Avoiding Failures from Duplicate Addresses > > Upon failing Duplicate Address Detection, [13] requires > IPv6 nodes to > stop using the address and wait for reconfiguration. In > addition, if > the failed address was a link-local address formed from > an interface > identifier, the interface should be disabled. > > Mobile nodes that wish to avoid this situation MAY use temporary > link-local addresses as follows. The mobile node SHOULD > generate a > random interface identifier and use it for assigning itself a > link-local address for use on this link. In order to do this, the > mobile node applies to the link-local address the > procedure described > in RFC 3041 [18] for global addresses. At most 5 consecutive > attempts SHOULD be performed to generate such addresses > and test them > through Duplicate Address Detection. If after these attempts no > unique address was found, the mobile node SHOULD log a > system error > and give up attempting to find a link-local address on that > interface, until the node moves to a new link. > > And now to the questions for the IPv6 WG: Is this (a) appropriate and > (b) in line with RFC 2462 and other possible RFCs? > > --Jari > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 7 07:08:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47E8Uhs014878; Wed, 7 May 2003 07:08:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h47E8USY014877; Wed, 7 May 2003 07:08:30 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47E8Rhs014870 for ; Wed, 7 May 2003 07:08:27 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h47E78Kw001723 for ; Wed, 7 May 2003 07:07:08 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA08058 for ; Wed, 7 May 2003 08:07:03 -0600 (MDT) 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 HAA24660; Wed, 7 May 2003 07:07:02 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h47E71M25288; Wed, 7 May 2003 07:07:01 -0700 X-mProtect: <200305071407> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.5.122, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUBWpSS; Wed, 07 May 2003 07:06:58 PDT Message-ID: <3EB9131E.5030707@iprg.nokia.com> Date: Wed, 07 May 2003 07:07:26 -0700 From: Charlie Perkins Organization: Nokia User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" CC: Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD72B@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Jim, Bound, Jim wrote: >Hi Jarko, > >My input is that if LLs do not pass DaD then something is very broken. > If DAD fails for the link-local address, then it means that the link-local address cannot be used. That is what is broken. It doesn't mean the interface is broken, which is what would be solved by making it fail. That is especially true in this case, because the mobile device is likely to evidence that the interface was working correctly until it tried to connect to a new point of attachment. Since that link-local address cannot be used, the device has to try another one. Disallowing this is indeed too drastic, because shutting the interface could cause major delays and user inconvenience. I don't think anyone has noticed any difficulties with just picking another link local address. >To do a work around this is not prudent in our standards process when >DaD breaks. In any interoperability test suite I know if you fail DaD >and don't do what our specs say you fail the test period. > Did anyone ever notice a problem with selecting a new link-local address? Isn't this what happens if a device tries to use a 3041 address which has a conflict? Regards, Charlie P. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 7 07:30:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47EUMhs015117; Wed, 7 May 2003 07:30:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h47EUMlR015116; Wed, 7 May 2003 07:30:22 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47EUIhs015109 for ; Wed, 7 May 2003 07:30:18 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h47ET0Kw005759 for ; Wed, 7 May 2003 07:29:00 -0700 (PDT) Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h47ESsPH012217 for ; Wed, 7 May 2003 07:28:55 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 7 May 2003 10:28:52 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141B9FD@ftmail.lab.flarion.com> From: Hesham Soliman To: "'Charlie Perkins'" , "Bound, Jim" Cc: Jari Arkko , ipng@sunroof.eng.sun.com Subject: RE: Avoiding interface failure upon DAD failure Date: Wed, 7 May 2003 10:28:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Did anyone ever notice a problem with selecting a new > link-local address? > Isn't this what happens if a device tries to use a 3041 > address which has a > conflict? => I would like to add that this is also needed for the global care-of address (i.e. pick another address if DAD fails according to RFC 3041). Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 7 08:06:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47F6Whs015451; Wed, 7 May 2003 08:06:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h47F6WTO015450; Wed, 7 May 2003 08:06:32 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47F6Ths015443 for ; Wed, 7 May 2003 08:06:29 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h47F5Auc028963 for ; Wed, 7 May 2003 08:05:10 -0700 (PDT) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id JAA03210 for ; Wed, 7 May 2003 09:05:04 -0600 (MDT) Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 76F217CA8; Wed, 7 May 2003 08:05:01 -0700 (PDT) Received: from whitestar.zk3.dec.com (whitestar.zk3.dec.com [16.140.64.49]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id 15088198B; Wed, 7 May 2003 11:04:59 -0400 (EDT) Received: from hp.com by whitestar.zk3.dec.com (8.12.6/1.1.29.3/18Jul02-1258PM) id h47F4urm003204; Wed, 7 May 2003 11:04:57 -0400 (EDT) Message-ID: <3EB92098.5070705@hp.com> Date: Wed, 07 May 2003 11:04:56 -0400 From: Vladislav Yasevich Organization: Hewlett Packard User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.3b) Gecko/20030318 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hesham Soliman Cc: Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure References: <748C6D0A58C0F94CA63C198B6674697A0141B9FD@ftmail.lab.flarion.com> In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0141B9FD@ftmail.lab.flarion.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030404020303030305050000" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is a cryptographically signed message in MIME format. --------------ms030404020303030305050000 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hesham Hesham Soliman wrote: > > Did anyone ever notice a problem with selecting a new > > link-local address? > > Isn't this what happens if a device tries to use a 3041 > > address which has a > > conflict? > > => I would like to add that this is also needed for > the global care-of address (i.e. pick another address > if DAD fails according to RFC 3041). I don't think so. The global COA is usually formed with the same ID as link local. So, if the link-local was gnerated using 3041 (as the mobile spec suggests), the global whould simply re-use the ID generated for the link-local address. So no special cases is needed. -vlad > > 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 > -------------------------------------------------------------------- > > -- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX Network Group Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 --------------ms030404020303030305050000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIISDCC BCAwggOJoAMCAQICEA+U9DHKkQsNror0sgqRSDMwDQYJKoZIhvcNAQEEBQAwgZ4xDzANBgNV BAoTBmhwLmNvbTEaMBgGA1UECxMRSVQgSW5mcmFzdHJ1Y3R1cmUxCzAJBgNVBAYTAlVTMSAw HgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTFAMD4GA1UEAxM3SGV3bGV0dC1QYWNr YXJkIFByaW1hcnkgQ2xhc3MgMiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMjA4MDgw MDAwMDBaFw0wMzA4MDgyMzU5NTlaMIGZMRgwFgYDVQQKFA9IZXdsZXR0LVBhY2thcmQxDjAM BgNVBAsUBUhQIElUMSYwJAYDVQQLFB1FbXBsb3ltZW50IFN0YXR1cyAtIEVtcGxveWVlczEb MBkGA1UEAxMSVmxhZGlzbGF2IFlhc2V2aWNoMSgwJgYJKoZIhvcNAQkBFhl2bGFkaXNsYXYu eWFzZXZpY2hAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzHlO8KO+ R6jaEmngSK2ilWaxfyQ8ik7qEyISMkYyFpl2NmZH77XLWLoXdDXd6RD8obNCK7/mf9hhOPNp 6SX26bEOMcjXxz0sTIAlyBWmDJEWMa+iwdx5L8VaHxmMu6Nsy/p19WGUh2F0UaQya2X/Y7Mc /T3OzrnkzoC4gLc+tBr/5v/S5H5F9SKDD3K9+mGQQrHSRbxhFWeG8tG6YMSZrsxEm2Mo/uOH qb+/yklnlQbqxmCmsswqlUoXkyaH/utbsUTEfE0ZnFpvZyGqBBJEao66mTeGUfUYPhy/zTHl VqqnhLGhJgc+vznJGzqnqsExqqHUUkYirGoGPiyuSF9VSQIDAQABo4HdMIHaMEMGA1UdEQQ8 MDqBGVZsYWRpc2xhdi5ZYXNldmljaEBocC5jb22BHVZsYWRpc2xhdi5ZYXNldmljaEBjb21w YXEuY29tMAkGA1UdEwQCMAAwYgYDVR0fBFswWTBXoFWgU4ZRaHR0cDovL29uc2l0ZWNybC52 ZXJpc2lnbi5jb20vSGV3bGV0dFBhY2thcmRDb21wYW55SVRJbmZyYXN0cnVjdHVyZS9MYXRl c3RDUkwuY3JsMBEGCWCGSAGG+EIBAQQEAwIHgDARBgpghkgBhvhFAQYJBAMBAf8wDQYJKoZI hvcNAQEEBQADgYEAdlbR6o5tWkaLOUSG3/Luw+0jKU5w23eikjR8eSrMv2FnMXUQB3o8yFG+ NBEgSGDSJ0G9LXAn5gN5c4/T56ZM0WslR/KYGQGbmFlHgcpcFQo7kWlQa+CDt0ibAX8X93pN H7IVjCY8xD47NaB8qIqpnj5j+iTUaeQeyOD3TL6++WIwggQgMIIDiaADAgECAhAPlPQxypEL Da6K9LIKkUgzMA0GCSqGSIb3DQEBBAUAMIGeMQ8wDQYDVQQKEwZocC5jb20xGjAYBgNVBAsT EUlUIEluZnJhc3RydWN0dXJlMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNr YXJkIENvbXBhbnkxQDA+BgNVBAMTN0hld2xldHQtUGFja2FyZCBQcmltYXJ5IENsYXNzIDIg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDIwODA4MDAwMDAwWhcNMDMwODA4MjM1OTU5 WjCBmTEYMBYGA1UEChQPSGV3bGV0dC1QYWNrYXJkMQ4wDAYDVQQLFAVIUCBJVDEmMCQGA1UE CxQdRW1wbG95bWVudCBTdGF0dXMgLSBFbXBsb3llZXMxGzAZBgNVBAMTElZsYWRpc2xhdiBZ YXNldmljaDEoMCYGCSqGSIb3DQEJARYZdmxhZGlzbGF2Lnlhc2V2aWNoQGhwLmNvbTCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMx5TvCjvkeo2hJp4EitopVmsX8kPIpO6hMi EjJGMhaZdjZmR++1y1i6F3Q13ekQ/KGzQiu/5n/YYTjzaekl9umxDjHI18c9LEyAJcgVpgyR FjGvosHceS/FWh8ZjLujbMv6dfVhlIdhdFGkMmtl/2OzHP09zs655M6AuIC3PrQa/+b/0uR+ RfUigw9yvfphkEKx0kW8YRVnhvLRumDEma7MRJtjKP7jh6m/v8pJZ5UG6sZgprLMKpVKF5Mm h/7rW7FExHxNGZxab2chqgQSRGqOupk3hlH1GD4cv80x5Vaqp4SxoSYHPr85yRs6p6rBMaqh 1FJGIqxqBj4srkhfVUkCAwEAAaOB3TCB2jBDBgNVHREEPDA6gRlWbGFkaXNsYXYuWWFzZXZp Y2hAaHAuY29tgR1WbGFkaXNsYXYuWWFzZXZpY2hAY29tcGFxLmNvbTAJBgNVHRMEAjAAMGIG A1UdHwRbMFkwV6BVoFOGUWh0dHA6Ly9vbnNpdGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQ YWNrYXJkQ29tcGFueUlUSW5mcmFzdHJ1Y3R1cmUvTGF0ZXN0Q1JMLmNybDARBglghkgBhvhC AQEEBAMCB4AwEQYKYIZIAYb4RQEGCQQDAQH/MA0GCSqGSIb3DQEBBAUAA4GBAHZW0eqObVpG izlEht/y7sPtIylOcNt3opI0fHkqzL9hZzF1EAd6PMhRvjQRIEhg0idBvS1wJ+YDeXOP0+em TNFrJUfymBkBm5hZR4HKXBUKO5FpUGvgg7dImwF/F/d6TR+yFYwmPMQ+OzWgfKiKqZ4+Y/ok 1GnkHsjg90y+vvliMYIEIDCCBBwCAQEwgbMwgZ4xDzANBgNVBAoTBmhwLmNvbTEaMBgGA1UE CxMRSVQgSW5mcmFzdHJ1Y3R1cmUxCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBh Y2thcmQgQ29tcGFueTFAMD4GA1UEAxM3SGV3bGV0dC1QYWNrYXJkIFByaW1hcnkgQ2xhc3Mg MiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eQIQD5T0McqRCw2uivSyCpFIMzAJBgUrDgMCGgUA oIICQTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMzA1MDcx NTA0NTZaMCMGCSqGSIb3DQEJBDEWBBSg5JHqaPscHhm9SKuBCZmWgV4W4jBSBgkqhkiG9w0B CQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUr DgMCBzANBggqhkiG9w0DAgIBKDCBxAYJKwYBBAGCNxAEMYG2MIGzMIGeMQ8wDQYDVQQKEwZo cC5jb20xGjAYBgNVBAsTEUlUIEluZnJhc3RydWN0dXJlMQswCQYDVQQGEwJVUzEgMB4GA1UE ChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxQDA+BgNVBAMTN0hld2xldHQtUGFja2FyZCBQ cmltYXJ5IENsYXNzIDIgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCEA+U9DHKkQsNror0sgqR SDMwgcYGCyqGSIb3DQEJEAILMYG2oIGzMIGeMQ8wDQYDVQQKEwZocC5jb20xGjAYBgNVBAsT EUlUIEluZnJhc3RydWN0dXJlMQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNr YXJkIENvbXBhbnkxQDA+BgNVBAMTN0hld2xldHQtUGFja2FyZCBQcmltYXJ5IENsYXNzIDIg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkCEA+U9DHKkQsNror0sgqRSDMwDQYJKoZIhvcNAQEB BQAEggEAG4okZrjtwbUrn57+RqMv+l05iY2iSO5KYjjOcNmRcVU+Ed9DGxsMu2ULQyUHdGBc j8l3/13fCoNqPkB+Pr1Wwmz03PEo4MqhAXGiRRKv3dn37obgdvOs9DUKMUAuPr7wlbJTALtN DWTXnuRTTQuD9K+rMuNOdHp1Y6rvn6Pw44C5n7YyMrHvNaeaxOKMTUpvKj+gQhCX2Epd80Hc pMD0pq3ApdALded2MhmBn9aklD/kek4ToygJvavUdLPWKFfY2GjACUbvCE6N9EuxeIxtbXl2 iBMOtmZkkVKYm1ZRQ3OjK/SUKRJSV1g9oqC/kV2hQL+QTmwTOfj48SmhXFV0/AAAAAAAAA== --------------ms030404020303030305050000-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 7 09:07:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47G7bhs015980; Wed, 7 May 2003 09:07:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h47G7bEb015979; Wed, 7 May 2003 09:07:37 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47G7Yhs015972 for ; Wed, 7 May 2003 09:07:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h47G6FKw001128 for ; Wed, 7 May 2003 09:06:15 -0700 (PDT) Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA05157 for ; Wed, 7 May 2003 09:06:09 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Wed, 7 May 2003 12:06:07 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BA00@ftmail.lab.flarion.com> From: Hesham Soliman To: "'Vladislav Yasevich'" , Hesham Soliman Cc: Jari Arkko , ipng@sunroof.eng.sun.com Subject: RE: Avoiding interface failure upon DAD failure Date: Wed, 7 May 2003 12:05:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hesham Soliman wrote: > > > Did anyone ever notice a problem with selecting a new > > > link-local address? > > > Isn't this what happens if a device tries to use a 3041 > > > address which has a > > > conflict? > > > > => I would like to add that this is also needed for > > the global care-of address (i.e. pick another address > > if DAD fails according to RFC 3041). > > I don't think so. The global COA is usually formed with > the same ID as link local. So, if the link-local was > gnerated using 3041 (as the mobile spec suggests), the > global whould simply re-use the ID generated for the link-local > address. So no special cases is needed. > => Well, there is nothing that prohibits having a different iid for globals. But anyway, I wasn't saying that there is an additional restriction for globals but simply that RFC3041 will be used for both ll and global addresses. There was a lot of emphasis on link-locals in the text and in emails from Jim and Charlie. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 7 10:57:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47Hv3hs017514; Wed, 7 May 2003 10:57:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h47Hv3PK017513; Wed, 7 May 2003 10:57:03 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47Hv0hs017506 for ; Wed, 7 May 2003 10:57:00 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h47Htfuc028378 for ; Wed, 7 May 2003 10:55:41 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h47HtZ1C004569 for ; Wed, 7 May 2003 11:55:35 -0600 (MDT) 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 KAA06319; Wed, 7 May 2003 10:55:29 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h47HtS323600; Wed, 7 May 2003 10:55:28 -0700 X-mProtect: <200305071755> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.159, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdSwJBJs; Wed, 07 May 2003 10:55:26 PDT Message-Id: <4.3.2.7.2.20030507102941.02d46f08@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 May 2003 10:54:59 -0700 To: Jari Arkko From: Bob Hinden Subject: Re: Avoiding interface failure upon DAD failure Cc: ipng@sunroof.eng.sun.com, Erik Nordmark In-Reply-To: <3EB65F73.30901@kolumbus.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, >The second action is relatively drastic in situations where >a host visits a large number of networks and is therefore >more likely to get into this situation either by accident or >by a malicious act. (SEND WG will eventually solve the >latter issue, though.) It seems to me that the likelihood a duplicate being detected using auto-configured addresses is very very small. If it does happen it indicates that something is broken. This could be hardware or software. Drastic action is appropriate because, assuming the link-local address was created using the hardware mac address, the same MAC address is going to be used at the link layer. If it is really a duplicate then link layer communication will fail. Changing the IPv6 address (i.e., a different IPv6 link-local address), won't have any effect. The only remedy is to try a different link layer address. >In Mobile IPv6, we've recommended that if the mobile >node wishes to avoid disabling its interface, it can >generate link-local addresses in an RFC 3041 fashion >and use them. Therefore, the addresses will not be >based on an interface identifier and the interface >will not have to be disabled per RFC 2462. (Existing >rules in the ND RFCs are followed.) Here's the text >we have on this: > > 7.6 Avoiding Failures from Duplicate Addresses > > Upon failing Duplicate Address Detection, [13] requires IPv6 nodes to > stop using the address and wait for reconfiguration. In addition, if > the failed address was a link-local address formed from an interface > identifier, the interface should be disabled. > > Mobile nodes that wish to avoid this situation MAY use temporary > link-local addresses as follows. The mobile node SHOULD generate a > random interface identifier and use it for assigning itself a > link-local address for use on this link. In order to do this, the > mobile node applies to the link-local address the procedure described > in RFC 3041 [18] for global addresses. At most 5 consecutive > attempts SHOULD be performed to generate such addresses and test them > through Duplicate Address Detection. If after these attempts no > unique address was found, the mobile node SHOULD log a system error > and give up attempting to find a link-local address on that > interface, until the node moves to a new link. Does this deal with picking different physical link layer addresses? >And now to the questions for the IPv6 WG: Is this (a) appropriate and >(b) in line with RFC 2462 and other possible RFCs? I think that doing DAD at all with auto-configured and temporary addresses isn't very beneficial due to the very low probability that a duplicate will be detected. In my view the cost of doing DAD is much higher than benefit. I think this is something the working group should discuss. However, due to this very low probability of a real duplicate occurring, when a duplicate is detected, it indicates that something is very broken. Consequentially, I am skeptical that the above mechanisms will really fix the problem. 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 May 7 11:34:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47IYdhs017945; Wed, 7 May 2003 11:34:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h47IYdGP017944; Wed, 7 May 2003 11:34:39 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47IYZhs017937 for ; Wed, 7 May 2003 11:34:35 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h47IXHKw025086 for ; Wed, 7 May 2003 11:33:17 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id MAA14084 for ; Wed, 7 May 2003 12:33:08 -0600 (MDT) 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 LAA08649 for ; Wed, 7 May 2003 11:33:03 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h47IX2v30040; Wed, 7 May 2003 11:33:02 -0700 X-mProtect: <200305071833> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.159, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdi50tcn; Wed, 07 May 2003 11:33:00 PDT Message-Id: <4.3.2.7.2.20030507111352.02d4cff0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 07 May 2003 11:32:31 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Draft on Globally Unique IPv6 Local Unicast Addresses Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I just submitted a draft titled "Globally Unique IPv6 Local Unicast Addresses". I believe this is a good alternative to Site-Local addresses. Please review the draft when it is out and send comments to the list. My intent in writing the draft was to put together a (hopefully) complete solution that folks can look out to see if the benefits exceed the cost/complexity. I suggest that the initial comments be limited to whether you think this approach (i.e., globally unique but not globally routing prefixes) is reasonable for the IPv6 working group to pursue. There are many details such as field sizes, allocation procedures, etc. can be debated endlessly. I think it is important to see if there is a possibility of reaching a consensus to peruse an approach like this. Then we can debate the details. Thanks, Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 7 13:04:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47K48hs018713; Wed, 7 May 2003 13:04:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h47K48N0018712; Wed, 7 May 2003 13:04:08 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47K45hs018705 for ; Wed, 7 May 2003 13:04:05 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h47K2kuc008278 for ; Wed, 7 May 2003 13:02:46 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h47K2eWs019656 for ; Wed, 7 May 2003 14:02:41 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EEB3B6A902; Wed, 7 May 2003 23:02:33 +0300 (EEST) Message-ID: <3EB9660B.3080402@kolumbus.fi> Date: Wed, 07 May 2003 23:01:15 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" Cc: ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jim Bound wrote: > I do not think SEND needs to complete to move forward at all There was no intent to wait for SEND. It was only mentioned for background. > Just fail on the interface per the specs and move forward with the spec. This is what I will do, unless IPv6 WG supports the proposed text. --Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 7 13:16:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47KGJhs018891; Wed, 7 May 2003 13:16:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h47KGJk6018890; Wed, 7 May 2003 13:16:19 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h47KGGhs018883 for ; Wed, 7 May 2003 13:16:16 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h47KEvKw001984 for ; Wed, 7 May 2003 13:14:57 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id OAA21959 for ; Wed, 7 May 2003 14:14:47 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id BCFF46A902; Wed, 7 May 2003 23:14:30 +0300 (EEST) Message-ID: <3EB968D8.6060805@kolumbus.fi> Date: Wed, 07 May 2003 23:13:12 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure References: <4.3.2.7.2.20030507102941.02d46f08@mailhost.iprg.nokia.com> In-Reply-To: <4.3.2.7.2.20030507102941.02d46f08@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Hinden wrote: > It seems to me that the likelihood a duplicate being detected using > auto-configured addresses is very very small. If it does happen it > indicates that something is broken. This could be hardware or software. > > Drastic action is appropriate because, assuming the link-local address > was created using the hardware mac address, the same MAC address is > going to be used at the link layer. I agree, but the proposal was to use randomly generated link-local addresses, hence the MAC address was not used. > I think that doing DAD at all with auto-configured and temporary > addresses isn't very beneficial due to the very low probability that a > duplicate will be detected. In my view the cost of doing DAD is much > higher than benefit. I think this is something the working group should > discuss. I agree. That is something that the IPv6 WG might look at in some point. But our proposal does not propose changes to DAD, it follows current RFCs. It simply proposes the use of an RFC 3041 like mechanism for the generation of link-local addresses independent of the MAC address. Given that we are not using the MAC address, 2462 rules do not call for disabling the interface. Of course, you could view this as an end-run as Jim did... > However, due to this very low probability of a real duplicate occurring, > when a duplicate is detected, it indicates that something is very > broken. Consequentially, I am skeptical that the above mechanisms will > really fix the problem. This is good point. Let's discuss this in some more depth. Here are the potentially guilty parties: (a) THIS node. In that case disabling the interface seems like the right thing to do. (b) OTHER node. Say, a broken network component responds to all DAD queries. In that case disabling the interface due to a visit to this link hurts, and it hurts on all subsequent links as well. Which one is more important? Hard to say... I also can't estimate what effect, if any, would a tough disabling rule have on the faulty nodes, would they be less likely to exhibit bad behaviour? You could also claim that the disable-until-the-admin-arrives approach serves as a useful warning sign that something is wrong either in this or the other node. But still, our proposal appears to build some resilience to the system (not fail forever, only on this link). It also appears to follow 2462, or? Comments? --Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 7 17:02:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4802khs021210; Wed, 7 May 2003 17:02:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4802kvX021209; Wed, 7 May 2003 17:02:46 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4802hhs021202 for ; Wed, 7 May 2003 17:02:43 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4801OKw013600 for ; Wed, 7 May 2003 17:01:24 -0700 (PDT) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4801H1C018961 for ; Wed, 7 May 2003 18:01:18 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KVN8AM1L4O95Y54G@vaxc.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Thu, 08 May 2003 10:01:02 +1000 Received: from kapow.its.monash.edu.au (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id D6B762000A; Thu, 08 May 2003 10:01:01 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id B5B3B20006; Thu, 08 May 2003 10:01:01 +1000 (EST) Date: Thu, 08 May 2003 10:01:01 +1000 From: Greg Daley Subject: Re: Avoiding interface failure upon DAD failure To: Bob Hinden Cc: Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EB99E3D.3020004@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <4.3.2.7.2.20030507102941.02d46f08@mailhost.iprg.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bob, just some comments about MAC Collision & DAD optimizations Bob Hinden wrote: > Jari, > >> The second action is relatively drastic in situations where >> a host visits a large number of networks and is therefore >> more likely to get into this situation either by accident or >> by a malicious act. (SEND WG will eventually solve the >> latter issue, though.) > > > It seems to me that the likelihood a duplicate being detected using > auto-configured addresses is very very small. If it does happen it > indicates that something is broken. This could be hardware or software. > > Drastic action is appropriate because, assuming the link-local address > was created using the hardware mac address, the same MAC address is > going to be used at the link layer. If it is really a duplicate then > link layer communication will fail. Changing the IPv6 address (i.e., a > different IPv6 link-local address), won't have any effect. The only > remedy is to try a different link layer address. In the situation which you mention, the configuring node has received a successful DAD defence from the existing node, before either de-configuring the interface, or re-attempting DAD. This is regardless of the fact that the node which sent the DAD defence (if it was not a DAD proxy) was able to send the response itself, although the MAC was duplicated. If there is some more sinister issue with link-layer communication when the MAC addresses collide, then the orignal DAD defence would not have succeeded. (This is this possibility even on the first DAD attempt). It is straight-forward for the configuring node to inspect the source link-layer address option in the successful DAD defence NA to check whether the MAC advertised is the same as that of the configuring node. If this is the case, the node should deconfigure the interface. If the SLLAO indicates a different MAC, then I think that deconfiguring the interface is not called for, as it isn't likely that the configuring node's further attempt is going to cause problems. >> In Mobile IPv6, we've recommended that if the mobile >> node wishes to avoid disabling its interface, it can >> generate link-local addresses in an RFC 3041 fashion >> and use them. Therefore, the addresses will not be >> based on an interface identifier and the interface >> will not have to be disabled per RFC 2462. (Existing >> rules in the ND RFCs are followed.) Here's the text >> we have on this: >> >> 7.6 Avoiding Failures from Duplicate Addresses >> >> Upon failing Duplicate Address Detection, [13] requires IPv6 nodes to >> stop using the address and wait for reconfiguration. In addition, if >> the failed address was a link-local address formed from an interface >> identifier, the interface should be disabled. >> >> Mobile nodes that wish to avoid this situation MAY use temporary >> link-local addresses as follows. The mobile node SHOULD generate a >> random interface identifier and use it for assigning itself a >> link-local address for use on this link. In order to do this, the >> mobile node applies to the link-local address the procedure described >> in RFC 3041 [18] for global addresses. At most 5 consecutive >> attempts SHOULD be performed to generate such addresses and test them >> through Duplicate Address Detection. If after these attempts no >> unique address was found, the mobile node SHOULD log a system error >> and give up attempting to find a link-local address on that >> interface, until the node moves to a new link. > > > Does this deal with picking different physical link layer addresses? > >> And now to the questions for the IPv6 WG: Is this (a) appropriate and >> (b) in line with RFC 2462 and other possible RFCs? > > > I think that doing DAD at all with auto-configured and temporary > addresses isn't very beneficial due to the very low probability that a > duplicate will be detected. In my view the cost of doing DAD is much > higher than benefit. I think this is something the working group should > discuss. There are several optimizations which have been proposed regarding DAD, which reduce the cost of DAD testing. I'm not sure that discarding DAD is the right approach. 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 May 8 01:58:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h488w1hs024086; Thu, 8 May 2003 01:58:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h488w1mE024085; Thu, 8 May 2003 01:58:01 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h488vwhs024078 for ; Thu, 8 May 2003 01:57:58 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h488udKw003786 for ; Thu, 8 May 2003 01:56:39 -0700 (PDT) Received: from bowl.fysh.org ([195.167.170.152]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h488uXPH024432 for ; Thu, 8 May 2003 01:56:34 -0700 (PDT) Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 19DhCV-0007w6-00 for ; Thu, 08 May 2003 09:56:27 +0100 Date: Thu, 8 May 2003 09:56:27 +0100 From: Andrew Main To: ipng@sunroof.eng.sun.com Subject: IPv6 address text representation Message-ID: <20030508085627.GA27291@fysh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk The update of the URI syntax RFC, draft-fielding-uri-rfc2396bis, gives a precise ABNF syntax for IPv6 address textual format, on which Roy Fielding and I collaborated. This really ought to be in the IPv6 Addressing Architecture document -- RFC2373 had a faulty attempt at an ABNF grammar -- but the URI work came too late to get the grammar into the Addressing Architecture update that was being worked on at the time, now published as RFC3513. Bob Hinden suggested that the IP address textual representation work could be published as a standalone document instead. I've submitted a draft of this standalone document; it's draft-main-ipaddr-text-rep-00. In working out the syntax details with Roy, I ended up with a lot of historical material and rationale, which I think makes such a narrow-topic document worthwhile. Comments are invited. Obviously this list has a direct interest in seeing that the IPv6 address presentation format has been handled correctly. I'd also particularly like comments on the historical material from people who were there at the time; at the moment it's all based on archaeological analysis of the RFCs. >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Textual Representation of IPv4 and IPv6 Addresses > Author(s) : A. Main > Filename : draft-main-ipaddr-text-rep-00.txt > Pages : 11 > Date : 2003-5-2 > >Historically, the conventional textual representations of IPv4 and >IPv6 addresses have been poorly specified. This document gives >precise definitions of these conventions, together with advice for >implementors. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-main-ipaddr-text-rep-00.txt -zefram -- Andrew Main (Zefram) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 8 02:35:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h489Z8hs024382; Thu, 8 May 2003 02:35:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h489Z8pL024381; Thu, 8 May 2003 02:35:08 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h489Z4hs024374 for ; Thu, 8 May 2003 02:35:05 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h489Xjuc007830 for ; Thu, 8 May 2003 02:33:45 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id DAA03882 for ; Thu, 8 May 2003 03:33:30 -0600 (MDT) From: john.loughney@nokia.com Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h489XND05207 for ; Thu, 8 May 2003 12:33:24 +0300 (EET DST) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 8 May 2003 12:33:23 +0300 Received: from esebe015.NOE.Nokia.com ([172.21.138.54]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 12:33:23 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe015.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Thu, 8 May 2003 12:33:23 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Node Requirements update Date: Thu, 8 May 2003 12:33:22 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: AcI0PVMBBaVxgnmLScGnSK/ffiJOkjhBwtAA To: X-OriginalArrivalTime: 08 May 2003 09:33:23.0097 (UTC) FILETIME=[DE798090:01C31544] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h489Z5hs024375 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi all, I am starting to update the Node Requirements draft. The main issues are to handle the text for stateful address auto-configuration/ M & O bits & for DHCPv6 support. I will try to compose text and send it the the list before sending an updated draft to the list. Notes from the San Francisco IETF meeting follow. Thanks, John IPv6 Node Requirements, Open Issues -- John Loughney ---------------------------------------------------- John presented his open issues with his current version of IPv6 node requirements. --- Hesham Soliman asked about the DHCP support rewording re SHOULD or MAY. Doesn't consider it to be useful. Doesn't need to be a SHOULD. Dave Thaler asked Ralph Droms if there is still an interest in DHCP on this? Jim Bound felt stateful configuration is a MUST. M bit must be set. Node can ignore. Customers that have stateful environments will not go to stateless environments. Christian disagreed. No question that we must support stateless. Market will take care of this. MAY is enough. Rob Austein said that John should separate question on this. Bob Hinden, speaking personally, noted that he would not want to see people have to implement functionality they don't need. Perry Metzger felt that it doesn't matter which we choose as we are being precise about how to be imprecise. John wanted to know how to resolve. Bob Hinden asked who wanted to keep the existing text (says MAY). In looking at the text to see if this was the way to frame the question John decided it was best to send a proposed change to the list so it could be discussed Thursday. --- On privacy extensions for addr conf, Alain Durand said there are reverse path dns issues when a random address may not resolve. Keith said it is more general, and need an API for this. Pekka asked if this is actually used. John said probably good to have the code, but use can cause a problem so should be aware of that. If per node basis things will break it should be done on a per API basis. Seemed to be consensus to go with John's suggested text change. --- Mobile IP - Routers SHOULD support the requirements set for all IPv6 routers. Several comments that this doesn't sound right. Should be changed to routers SHOULD support mobile IP requirements. --- Security - still questions. What level of security to document. Gave example. Steve Belovin noted trying to get rid of DES. Thus should remove the MUST. John will ask someone in security to review this. Margaret noted that she liked the idea of separating security into a separate draft. Steve Belovin wanted to take this off line. John wants to hold off on the security section. He will edit the other items and ask if it is ready for last call, barring the way security is reviewed and/or changed. Bob Hinden wants to defer the security issue as IPSEC isn't useful in every device, e.g., a device that might want SSL or SSH for security, and doesn't want IPSEC. So need to think about this broadly, thus should go ahead without security for now to make progress. Jim Bound said that if we want to revisit MUST that it is an IPSEC job. Where do we stop if we do this. IPSEC is a MUST historically and IP6 is the front line of defense for security by using IPSEC to secure the IP level. Thomas concerned about a node requirements doc with no security. Need a lot of help from security group to have a serious discussion on this. John likes having a reference to a doc with current best current security practices for IPSEC. Keith doesn't like having IPSEC as it isn't really a solution. Jim Bound said we could make a more specific by node type document rather than this general approach. To alter the existing MUST/SHOULD with this doc is bad idea as it would be in conflict. Jim said he could do a review on MUSTS to see if anything should be changed. Keith felt that this specification should be for generic programmable nodes. Maybe other specific, i.e., fixed function, devices should not be covered by this. Margaret disagreed and noted that were many many of these types of devices to consider. Bob felt that the intro should note the scope re Keith's comment. John will pose issues about stateful addresses and M & O bits, as well as more discussion on security. Agreed that the wg needs to decide how to handle security. ------------ John Loughney provides a quick update on the nodes requirement draft. The big open issue was the state of the "stateful address auto-configuration" requirement. The agreement on the mailing list is to have this rated as "MAY support", for which John proposes a text; there is also a requirement that if the WG eventually chooses to say that application "SHOULD" support, there should be a strong qualifier authorizing implementations to opt out. A show of hands shows 59 hands up for preferring MAY, 21 for SHOULD; the chairs believe that this constitute rough consensus in the room, but we need to verify the decision on the mailing list. Another update on the requirement draft is the state of requirement of support for DHCPv6: must support if use for stateful address autoconfiguration; should support for other configuration; may support if no stateful or other configuration is needed. Christian Huitema asks for clarification, whether the "other configuration" really means "stateless DHCP". Thomas Narten asks whether we are making the explicit decision that DHCPv6 is "THE" stateful address configuration mechanism? John concludes that this specific paragraph needs further discussion on the mailing list. Ralph asks for clarification of the handling of the M bit and the O bit. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 8 07:00:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48E0Yhs027673; Thu, 8 May 2003 07:00:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48E0Y1d027672; Thu, 8 May 2003 07:00:34 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48E0Vhs027665 for ; Thu, 8 May 2003 07:00:31 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48DxCuc020828 for ; Thu, 8 May 2003 06:59:12 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h48Dx6PH028806 for ; Thu, 8 May 2003 06:59:07 -0700 (PDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id B72136A903; Thu, 8 May 2003 16:59:05 +0300 (EEST) Message-ID: <3EBA60E2.7010504@kolumbus.fi> Date: Thu, 08 May 2003 16:51:30 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: greg.daley@eng.monash.edu.au Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure References: <4.3.2.7.2.20030507102941.02d46f08@mailhost.iprg.nokia.com> <3EB99E3D.3020004@eng.monash.edu.au> In-Reply-To: <3EB99E3D.3020004@eng.monash.edu.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greg Daley wrote: > If this is the case, the node should deconfigure the interface. > If the SLLAO indicates a different MAC, then I think that > deconfiguring the interface is not called for, as it isn't > likely that the configuring node's further attempt is > going to cause problems. Sounds reasonable. However, I'm trying to figure out what, if anything, the Mobile IPv6 specification should say about this. Process-wise, the behaviour that you propose i.e. a change to the DAD behaviour belongs to the IPv6 WG. I'm not going to change DAD -- the only options available for me are (a) not saying anything or (b) recommending a particular type of an address [temporary] be used so that the implications of DAD failure are not as severe. Both are imho within bounds of the current RFCs, but Jim talked about an end-run and Bob didn't see this solving the real problem in the rare case of a collision. The issue is not so important that it justifies a very lengthy discussion, imho, and I will delete the text unless it is supported here. Perhaps we'll wait for one additional round of e-mails before taking a decision, it seemed that a part of the discussion was based on the wrong assumption that MAC addresses were used in the addresses. --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 May 8 07:14:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48EE6hs028302; Thu, 8 May 2003 07:14:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48EE6g6028301; Thu, 8 May 2003 07:14:06 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48EE3hs028294 for ; Thu, 8 May 2003 07:14:03 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48ECjuc023985 for ; Thu, 8 May 2003 07:12:45 -0700 (PDT) Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h48ECdPH007786 for ; Thu, 8 May 2003 07:12:39 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 8 May 2003 10:12:35 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BA04@ftmail.lab.flarion.com> From: Hesham Soliman To: "'Jari Arkko'" , greg.daley@eng.monash.edu.au Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: RE: Avoiding interface failure upon DAD failure Date: Thu, 8 May 2003 10:12:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > The issue is not so important that it justifies a very > lengthy discussion, imho, => Agreed. and I will delete the text > unless it is supported here. => I hope it is supported, otherwise, why is RFC 3041 a PS? Perhaps we'll wait for > one additional round of e-mails before taking a decision, > it seemed that a part of the discussion was based on > the wrong assumption that MAC addresses were used > in the addresses. => My only comment is that I don't understand what the discussion is about ;) MIPv6 effectively says: To configure a CoA use RFC 3041. Is this wrong? Is there something wrong with this RFC that it should not be used for a CoA? If so, why is it allowed in other cases? 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 May 8 07:17:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48EHehs028386; Thu, 8 May 2003 07:17:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48EHdpF028385; Thu, 8 May 2003 07:17:39 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48EHahs028378 for ; Thu, 8 May 2003 07:17:36 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48EGIKw004161 for ; Thu, 8 May 2003 07:16:18 -0700 (PDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h48EGCWs013788 for ; Thu, 8 May 2003 08:16:12 -0600 (MDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h48EFAK20853; Thu, 8 May 2003 16:15:10 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h48EF7of057495; Thu, 8 May 2003 16:15:07 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200305081415.h48EF7of057495@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Bob Hinden cc: Jari Arkko , ipng@sunroof.eng.sun.com, Erik Nordmark Subject: Re: Avoiding interface failure upon DAD failure In-reply-to: Your message of Wed, 07 May 2003 10:54:59 PDT. <4.3.2.7.2.20030507102941.02d46f08@mailhost.iprg.nokia.com> Date: Thu, 08 May 2003 16:15:07 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: => in general I agree with you but I have a comment about a detail: ... In my view the cost of doing DAD is much higher than benefit. => my concern is the cost and the benefit can be for two different persons, i.e., I have no objection about a "no-DAD" policy if and only if the choice between this policy and the standard one is in the hands of the network manager. Thanks Francis.Dupont@enst-bretagne.fr PS: DAD is not a toy: at least once it spared us a disaster... If something really needs improvement in RFC 2461/2462, it is more how to cleanup everything when a router's sent some rogue RAs. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 8 07:43:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48Ehjhs029006; Thu, 8 May 2003 07:43:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48Ehj1C029005; Thu, 8 May 2003 07:43:45 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48Ehghs028998 for ; Thu, 8 May 2003 07:43:42 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48EgNKw009758 for ; Thu, 8 May 2003 07:42:24 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h48EgHWs027925 for ; Thu, 8 May 2003 08:42:18 -0600 (MDT) Received: from piuha.net (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 6EDDA6A901; Thu, 8 May 2003 17:42:16 +0300 (EEST) Message-ID: <3EBA69AC.40006@kolumbus.fi> Date: Thu, 08 May 2003 17:29:00 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure References: <200305081415.h48EF7of057495@givry.rennes.enst-bretagne.fr> In-Reply-To: <200305081415.h48EF7of057495@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis Dupont wrote in answer to Bob Hinden: > ... In my view the cost of doing DAD is much higher than benefit. > > => my concern is the cost and the benefit can be for two different > persons, i.e., I have no objection about a "no-DAD" policy if and > only if the choice between this policy and the standard one is in > the hands of the network manager. I may agree with the above, but we seem to be departing the original discussion: If someone wants to work on improvements to DAD, or even eliminating DAD from temporary addresses, that's something for them to drive. My intention is to follow current 2462 to the letter. The only questions are whether I can use 3041-like link local addresses, and whether the goal (avoiding disabled link) is worthwhile. --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 May 8 08:38:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48FcXhs029651; Thu, 8 May 2003 08:38:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48FcXRX029650; Thu, 8 May 2003 08:38:33 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48FcThs029643 for ; Thu, 8 May 2003 08:38:29 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48FbBKw023235 for ; Thu, 8 May 2003 08:37:11 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h48Fb6Ws027687 for ; Thu, 8 May 2003 09:37:06 -0600 (MDT) 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 IAA05566; Thu, 8 May 2003 08:37:05 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h48Fb4f05680; Thu, 8 May 2003 08:37:04 -0700 X-mProtect: <200305081537> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd1SSrTL; Thu, 08 May 2003 08:37:03 PDT Message-ID: <3EBA799F.D42DD56@iprg.nokia.com> Date: Thu, 08 May 2003 08:37:03 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure References: <200305081415.h48EF7of057495@givry.rennes.enst-bretagne.fr> <3EBA69AC.40006@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Jari, Jari Arkko wrote: > My intention is to follow current 2462 to the > letter. The only questions are whether I can > use 3041-like link local addresses, and whether > the goal (avoiding disabled link) is worthwhile. >From the point of view of someone trying to use these devices, yes it is very worthwhile to avoid disabling the link unnecessarily. I strongly support keeping this functionality unless someone can point out why it is harmful. We should look at this matter from the point of view of what is best for the users. 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 May 8 11:27:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48IRChs001414; Thu, 8 May 2003 11:27:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48IRCgq001413; Thu, 8 May 2003 11:27:12 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48IR9hs001406 for ; Thu, 8 May 2003 11:27:09 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48IPoKw020806 for ; Thu, 8 May 2003 11:25:51 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id LAA13137 for ; Thu, 8 May 2003 11:25:44 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h48IPdY28155; Thu, 8 May 2003 21:25:39 +0300 Date: Thu, 8 May 2003 21:25:39 +0300 (EEST) From: Pekka Savola To: "Charles E. Perkins" cc: Jari Arkko , Subject: Re: Avoiding interface failure upon DAD failure In-Reply-To: <3EBA799F.D42DD56@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 Thu, 8 May 2003, Charles E. Perkins wrote: > Jari Arkko wrote: > > > My intention is to follow current 2462 to the > > letter. The only questions are whether I can > > use 3041-like link local addresses, and whether > > the goal (avoiding disabled link) is worthwhile. > > >From the point of view of someone trying to use > these devices, yes it is very worthwhile to > avoid disabling the link unnecessarily. > > I strongly support keeping this functionality > unless someone can point out why it is harmful. > We should look at this matter from the point of > view of what is best for the users. Why do you believe there will be DAD conflicts? If the nodes use EUI64-based addressing, this should really, really, never happen -- UNLESS someone is acting in a malicious manner on the link; and in that case this proposal does not work, just adds complexity. The simplest would be just to log an error, and disable the interface. A MIPv6 specific interpretation of the latter could be ", until the MN moves on to a new link when DAD can be re-tried". This would also seem reasonable IMO. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 8 11:37:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48IbShs001677; Thu, 8 May 2003 11:37:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48IbSYG001676; Thu, 8 May 2003 11:37:28 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48IbOhs001669 for ; Thu, 8 May 2003 11:37:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48Ia6Kw024878 for ; Thu, 8 May 2003 11:36:06 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h48Ia1PH003575 for ; Thu, 8 May 2003 11:36:01 -0700 (PDT) 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 LAA14816; Thu, 8 May 2003 11:36:01 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h48Ia0b19535; Thu, 8 May 2003 11:36:00 -0700 X-mProtect: <200305081836> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (172.18.141.41, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdNYzcPb; Thu, 08 May 2003 11:35:58 PDT Message-ID: <3EBAA38E.2000709@iprg.nokia.com> Date: Thu, 08 May 2003 11:35:58 -0700 From: Vijay Devarapalli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola CC: "Charles E. Perkins" , Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > UNLESS someone is acting in a malicious manner on the link; this is what we are concerned about. the proposal makes it worthless for the malicious node to launch an attack. Vijay -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 8 11:39:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48Id6hs001709; Thu, 8 May 2003 11:39:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48Id6WF001708; Thu, 8 May 2003 11:39:06 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48Id2hs001701 for ; Thu, 8 May 2003 11:39:03 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48IbiKw025610 for ; Thu, 8 May 2003 11:37:44 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h48IbcPH004544 for ; Thu, 8 May 2003 11:37:39 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h48IbXM28268; Thu, 8 May 2003 21:37:33 +0300 Date: Thu, 8 May 2003 21:37:32 +0300 (EEST) From: Pekka Savola To: Vijay Devarapalli cc: "Charles E. Perkins" , Jari Arkko , Subject: Re: Avoiding interface failure upon DAD failure In-Reply-To: <3EBAA38E.2000709@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 Thu, 8 May 2003, Vijay Devarapalli wrote: > Pekka Savola wrote: > > UNLESS someone is acting in a malicious manner on the link; > > this is what we are concerned about. > > the proposal makes it worthless for the malicious node to launch > an attack. Incorrect. The malicious node can just reply to the RFC3041 DAD's up to 5 times, and then the interface will get disabled anyway. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 8 11:42:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48Ig3hs001864; Thu, 8 May 2003 11:42:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48Ig3OO001863; Thu, 8 May 2003 11:42:03 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48Ifxhs001850 for ; Thu, 8 May 2003 11:41:59 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48Ieeuc016423 for ; Thu, 8 May 2003 11:40:40 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h48IeWiY026914 for ; Thu, 8 May 2003 12:40:32 -0600 (MDT) 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 LAA14976; Thu, 8 May 2003 11:40:26 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h48IeQj23932; Thu, 8 May 2003 11:40:26 -0700 X-mProtect: <200305081840> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdV8irkm; Thu, 08 May 2003 11:40:25 PDT Message-ID: <3EBAA499.D75B7920@iprg.nokia.com> Date: Thu, 08 May 2003 11:40:25 -0700 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: Pekka Savola CC: Jari Arkko , ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Pekka, Pekka Savola wrote: > Why do you believe there will be DAD conflicts? Actually, I do not believe there will be conflicts according to your use scenario. But IPv6 isn't supposed to be usable for only those scenarios. If a node picks a random link-local address, it should be able to use it as long as their are no conflicts. If such a node then moves to a new link, there is a very small possibility of a conflict. In that case, the newly arrived mobile node ought to pick another address without making the device owner curse and swear and do the thing. > A MIPv6 specific interpretation of the latter could be > ", until the MN moves on to a new link when DAD can be > re-tried". This would also seem reasonable IMO. It's reasonable, unless the next link is 15 km ahead. 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 May 8 12:11:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48JAxhs002469; Thu, 8 May 2003 12:10:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48JAx0i002468; Thu, 8 May 2003 12:10:59 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48JAuhs002461 for ; Thu, 8 May 2003 12:10:56 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48J9cKw006373 for ; Thu, 8 May 2003 12:09:38 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id NAA07170 for ; Thu, 8 May 2003 13:09:32 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 396596A902; Thu, 8 May 2003 22:09:25 +0300 (EEST) Message-ID: <3EBAAB16.1020904@kolumbus.fi> Date: Thu, 08 May 2003 22:08:06 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola Cc: ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: > If the nodes use EUI64-based addressing, this should really, really, never > happen -- UNLESS someone is acting in a malicious manner on the link; and > in that case this proposal does not work, just adds complexity. > > The simplest would be just to log an error, and disable the interface. > > A MIPv6 specific interpretation of the latter could be ", until the MN > moves on to a new link when DAD can be re-tried". This would also seem > reasonable IMO. The proposal does not attempt to survive the situation on the link; it follows the 3041 5-attempt scheme to avoid accidental collisions and then stops. It simply puts in some additional resilience, by making the failure of the interface not last forever. So, it seems that we've tried to accomplish exactly what you suggest above -- though in a slightly different way. I'd be happy to do this in the above way, if the group finds that acceptable. That is, we could have some text that says that DAD failures per 2462 last only while we are on the same link. --Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 8 12:31:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48JVUhs002689; Thu, 8 May 2003 12:31:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48JVUMV002688; Thu, 8 May 2003 12:31:30 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48JVRhs002681 for ; Thu, 8 May 2003 12:31:27 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48JU9uc003245 for ; Thu, 8 May 2003 12:30:09 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h48JU3PH004678 for ; Thu, 8 May 2003 12:30:04 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 294EE6A902; Thu, 8 May 2003 22:30:03 +0300 (EEST) Message-ID: <3EBAAFEC.6000605@kolumbus.fi> Date: Thu, 08 May 2003 22:28:44 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola , Vijay Devarapalli Cc: ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: >>the proposal makes it worthless for the malicious node to launch >>an attack. > > > Incorrect. The malicious node can just reply to the RFC3041 DAD's up to 5 > times, and then the interface will get disabled anyway. You are both right, in a way... Pekka is right that the malicious node case is really not defensible, at least not until SEND arrives. However, Vijay's point is that such a situation should not disable the device for ever. Say, when I get home from the office I happen to drive by the All-DAD-Probes-Answered building and my device accidentally attaches to its WLAN network, DADs, fails, and disables my interface. I have just one interface, so before the "admin" fixes the problem the device is useless. If I get an important message, I won't be alerted, because its against the law to do an "ifconfig eth0 up" while driving. (And if its my grandmother, she'll might take the device to the shop for repair when something this unexpected happens.) Anyway, I don't think there's any point in spending too much effort on this. There are activities to take care of ND attacks, there are activities to look at DAD optimization. Either we find that the RFC 3041 approach is OK for link-locals as well, use Pekka's suggestion of resetting the failure when moving to a new link, or just skip this and depend on future specifications to deal with it. --Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 8 13:19:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48KJqhs004063; Thu, 8 May 2003 13:19:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48KJqQS004062; Thu, 8 May 2003 13:19:52 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48KJmhs004052 for ; Thu, 8 May 2003 13:19:48 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48KIUuc017910 for ; Thu, 8 May 2003 13:18:30 -0700 (PDT) Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA23192 for ; Thu, 8 May 2003 14:18:24 -0600 (MDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h48KKZQK004632; Thu, 8 May 2003 23:20:35 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h48KKXI2004631; Thu, 8 May 2003 23:20:33 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Avoiding interface failure upon DAD failure From: Mika Liljeberg To: "Charles E. Perkins" Cc: Pekka Savola , Jari Arkko , ipng@sunroof.eng.sun.com In-Reply-To: <3EBAA499.D75B7920@iprg.nokia.com> References: <3EBAA499.D75B7920@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1052425233.3992.6.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 08 May 2003 23:20:33 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2003-05-08 at 21:40, Charles E. Perkins wrote: > If a node picks a random link-local address, it > should be able to use it as long as their are no > conflicts. If such a node then moves to a new > link, there is a very small possibility of a conflict. Have you done a probability analysis on this? Is the probability of interface failure due to address collision significantly higher than, say, link failure due to problems in the radio propagation environment? My gut feeling is, not even close. MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 8 13:37:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48Kbjhs004617; Thu, 8 May 2003 13:37:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48KbjkS004616; Thu, 8 May 2003 13:37:45 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48Kbghs004609 for ; Thu, 8 May 2003 13:37:42 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48KaNKw007587 for ; Thu, 8 May 2003 13:36:24 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h48KaIWs006052 for ; Thu, 8 May 2003 14:36:18 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id EBA2B6A903; Thu, 8 May 2003 23:36:12 +0300 (EEST) Message-ID: <3EBABF6D.1080206@kolumbus.fi> Date: Thu, 08 May 2003 23:34:53 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mika Liljeberg Cc: "Charles E. Perkins" , ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure References: <3EBAA499.D75B7920@iprg.nokia.com> <1052425233.3992.6.camel@devil> In-Reply-To: <1052425233.3992.6.camel@devil> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mika Liljeberg wrote: > Have you done a probability analysis on this? Is the probability of > interface failure due to address collision significantly higher than, > say, link failure due to problems in the radio propagation environment? > My gut feeling is, not even close. I think your gut feeling is right. (Although you could argue that in some malicious case the probability could be 1; but I don't want to enter a discussion which is mostly a SEND issue. Plus with the exception of EMP, radio problems don't stay once you move to a different place ;-) .) Anyway, what should we do with the probabilities? Are you saying that everything with a smaller probability than radio problems should not be pursued? Perhaps the argument is that the probability is neglible. It is, I agree. Still, shouldn't we do the right thing even if the probability of the bad thing happening is very small? --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 May 8 13:41:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48KfPhs004693; Thu, 8 May 2003 13:41:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48KfPDd004691; Thu, 8 May 2003 13:41:25 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48KfKhs004676 for ; Thu, 8 May 2003 13:41:20 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48Ke2Kw008841 for ; Thu, 8 May 2003 13:40:02 -0700 (PDT) Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h48KdvPH028260 for ; Thu, 8 May 2003 13:39:57 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 8 May 2003 16:39:53 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BA0B@ftmail.lab.flarion.com> From: Hesham Soliman To: "'Mika Liljeberg'" , "Charles E. Perkins" Cc: Pekka Savola , Jari Arkko , ipng@sunroof.eng.sun.com Subject: RE: Avoiding interface failure upon DAD failure Date: Thu, 8 May 2003 16:39:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > On Thu, 2003-05-08 at 21:40, Charles E. Perkins wrote: > > If a node picks a random link-local address, it > > should be able to use it as long as their are no > > conflicts. If such a node then moves to a new > > link, there is a very small possibility of a conflict. > > Have you done a probability analysis on this? Is the probability of > interface failure due to address collision significantly higher than, > say, link failure due to problems in the radio propagation > environment? > My gut feeling is, not even close. => Fully agree with you, so let's remove DAD from IPv6! This is not the point being discussed.... The point is, should 3041 be used to generate CoAs or not? 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 May 8 13:50:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48Kowhs005054; Thu, 8 May 2003 13:50:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48KowOH005053; Thu, 8 May 2003 13:50:58 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48Koshs005043 for ; Thu, 8 May 2003 13:50:54 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48KnaKw012116 for ; Thu, 8 May 2003 13:49:36 -0700 (PDT) Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id OAA19104 for ; Thu, 8 May 2003 14:49:29 -0600 (MDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h48KpkQK004791; Thu, 8 May 2003 23:51:47 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h48Kpic3004789; Thu, 8 May 2003 23:51:44 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Avoiding interface failure upon DAD failure From: Mika Liljeberg To: Jari Arkko Cc: "Charles E. Perkins" , ipng@sunroof.eng.sun.com In-Reply-To: <3EBABF6D.1080206@kolumbus.fi> References: <3EBAA499.D75B7920@iprg.nokia.com> <1052425233.3992.6.camel@devil> <3EBABF6D.1080206@kolumbus.fi> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1052427103.3992.15.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 08 May 2003 23:51:44 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2003-05-08 at 23:34, Jari Arkko wrote: > Anyway, what should we do with the probabilities? Are you > saying that everything with a smaller probability than > radio problems should not be pursued? It's part of the cost-benefit analysis. If the probability of collision is low enough not to be a significant factor in the total failure rate, the user is not going to see any difference one way or the other. If this is the case, the added implementation complexity is not warranted. > Perhaps the argument is that the probability is neglible. > It is, I agree. Still, shouldn't we do the right thing > even if the probability of the bad thing happening is > very small? Only if the cost-benefit analysis makes sense. MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 8 13:57:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48KvUhs005260; Thu, 8 May 2003 13:57:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48KvUeH005259; Thu, 8 May 2003 13:57:30 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48KvQhs005249 for ; Thu, 8 May 2003 13:57:26 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48Ku8Kw014790 for ; Thu, 8 May 2003 13:56:08 -0700 (PDT) Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h48Ku1PH025314 for ; Thu, 8 May 2003 13:56:02 -0700 (PDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h48KwBQK004819; Thu, 8 May 2003 23:58:11 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h48Kw9Np004818; Thu, 8 May 2003 23:58:09 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: Avoiding interface failure upon DAD failure From: Mika Liljeberg To: Hesham Soliman Cc: "Charles E. Perkins" , Pekka Savola , Jari Arkko , ipng@sunroof.eng.sun.com In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0141BA0B@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A0141BA0B@ftmail.lab.flarion.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1052427488.3996.19.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 08 May 2003 23:58:09 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2003-05-08 at 23:39, Hesham Soliman wrote: > The point is, should 3041 be used to generate CoAs > or not? If it doesn't perceivably improve the total failure rate observed by the user, no. MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 8 13:59:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48Kxjhs005356; Thu, 8 May 2003 13:59:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48Kxjv2005355; Thu, 8 May 2003 13:59:45 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48Kxghs005348 for ; Thu, 8 May 2003 13:59:42 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48KwOKw015607 for ; Thu, 8 May 2003 13:58:24 -0700 (PDT) Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h48KwHPH027226 for ; Thu, 8 May 2003 13:58:18 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Thu, 8 May 2003 16:58:17 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BA0D@ftmail.lab.flarion.com> From: Hesham Soliman To: "'Mika Liljeberg'" , Hesham Soliman Cc: "Charles E. Perkins" , Pekka Savola , Jari Arkko , ipng@sunroof.eng.sun.com Subject: RE: Avoiding interface failure upon DAD failure Date: Thu, 8 May 2003 16:58:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > The point is, should 3041 be used to generate CoAs > > or not? > > If it doesn't perceivably improve the total failure rate > observed by the > user, no. => Ok. So do you think that RFC 3041 should be used at all? I mean, do you say "no" for the MIPv6 spec only or for any address? Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 8 14:09:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48L9Ths005737; Thu, 8 May 2003 14:09:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48L9Too005736; Thu, 8 May 2003 14:09:29 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48L9Phs005729 for ; Thu, 8 May 2003 14:09:25 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48L87uc005568 for ; Thu, 8 May 2003 14:08:07 -0700 (PDT) Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h48L81PH009433 for ; Thu, 8 May 2003 14:08:01 -0700 (PDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h48LAHQK004904; Fri, 9 May 2003 00:10:17 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h48LAGJ1004903; Fri, 9 May 2003 00:10:16 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: RE: Avoiding interface failure upon DAD failure From: Mika Liljeberg To: Hesham Soliman Cc: "Charles E. Perkins" , Pekka Savola , Jari Arkko , ipng@sunroof.eng.sun.com In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0141BA0D@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A0141BA0D@ftmail.lab.flarion.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1052428215.4000.27.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 09 May 2003 00:10:16 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 2003-05-08 at 23:58, Hesham Soliman wrote: > => Ok. So do you think that RFC 3041 should be used > at all? I mean, do you say "no" for the MIPv6 spec > only or for any address? I mean don't make RFC3041 a pre-requisite for MIPv6, unless there is a clear benefit. "MAY use RFC3041 to configure CoA" is fine by me. Personally, I think the 5 retries in RFC3041 are an overkill but, as someone pointed out, it's already an RFC. MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 8 14:15:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48LFJhs006027; Thu, 8 May 2003 14:15:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48LFICs006025; Thu, 8 May 2003 14:15:18 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48LFFhs006018 for ; Thu, 8 May 2003 14:15:15 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48LDvKw022880 for ; Thu, 8 May 2003 14:13:57 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA01214 for ; Thu, 8 May 2003 15:13:51 -0600 (MDT) 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 OAA23508; Thu, 8 May 2003 14:13:51 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h48LDoZ01953; Thu, 8 May 2003 14:13:50 -0700 X-mProtect: <200305082113> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdIF8ARh; Thu, 08 May 2003 14:13:49 PDT Message-ID: <3EBAC88D.A1AC4D3A@iprg.nokia.com> Date: Thu, 08 May 2003 14:13:49 -0700 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: Mika Liljeberg CC: ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure References: <748C6D0A58C0F94CA63C198B6674697A0141BA0D@ftmail.lab.flarion.com> <1052428215.4000.27.camel@devil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello folks, Mika Liljeberg wrote: > I mean don't make RFC3041 a pre-requisite for MIPv6, unless there is a > clear benefit. "MAY use RFC3041 to configure CoA" is fine by me. This MAY is also fine with me -- in fact, I don't think it was ever the intention to mandate that the device try new addresses. 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 May 8 14:20:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48LKZhs006444; Thu, 8 May 2003 14:20:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48LKZox006443; Thu, 8 May 2003 14:20:35 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48LKThs006426 for ; Thu, 8 May 2003 14:20:29 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48LJBuc010233 for ; Thu, 8 May 2003 14:19:11 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h48LJ6PH023670 for ; Thu, 8 May 2003 14:19:06 -0700 (PDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 5159C6A903; Fri, 9 May 2003 00:19:05 +0300 (EEST) Message-ID: <3EBAC97A.8000402@kolumbus.fi> Date: Fri, 09 May 2003 00:17:46 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Charles E. Perkins" Cc: Mika Liljeberg , ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure References: <748C6D0A58C0F94CA63C198B6674697A0141BA0D@ftmail.lab.flarion.com> <1052428215.4000.27.camel@devil> <3EBAC88D.A1AC4D3A@iprg.nokia.com> In-Reply-To: <3EBAC88D.A1AC4D3A@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charles E. Perkins wrote: >>I mean don't make RFC3041 a pre-requisite for MIPv6, unless there is a >>clear benefit. "MAY use RFC3041 to configure CoA" is fine by me. > > > This MAY is also fine with me -- in fact, I don't think > it was ever the intention to mandate that the device > try new addresses. This scheme is already a MAY in the current spec. --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 May 8 15:07:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48M7jhs007637; Thu, 8 May 2003 15:07:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h48M7jar007636; Thu, 8 May 2003 15:07:45 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h48M7ehs007627 for ; Thu, 8 May 2003 15:07:41 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h48M6Muc026132 for ; Thu, 8 May 2003 15:06:22 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA04718 for ; Thu, 8 May 2003 16:06:17 -0600 (MDT) 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 PAA26120 for ; Thu, 8 May 2003 15:06:16 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h48M6GU02159; Thu, 8 May 2003 15:06:16 -0700 X-mProtect: <200305082206> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.159, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdBB9DSe; Thu, 08 May 2003 15:06:14 PDT Message-Id: <4.3.2.7.2.20030508150436.02d725e0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 May 2003 15:05:45 -0700 To: ipng@sunroof.eng.sun.com From: Bob Hinden Subject: Fwd: I-D ACTION:draft-hinden-ipv6-global-local-addr-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FYI >To: IETF-Announce: ; >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-hinden-ipv6-global-local-addr-00.txt >Date: Thu, 08 May 2003 15:34:43 -0400 >Sender: owner-ietf-announce@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : Globally Unique IPv6 Local Unicast Addresses > Author(s) : R. Hinden > Filename : draft-hinden-ipv6-global-local-addr-00.txt > Pages : 10 > Date : 2003-5-8 > >This document defines an unicast address format that is globally >unique and is intended for local communications, usually inside of a >site. They are not expected to be routable on the global Internet >given current routing technology. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hinden-ipv6-global-local-addr-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-hinden-ipv6-global-local-addr-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-hinden-ipv6-global-local-addr-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: <2003-5-8113033.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-hinden-ipv6-global-local-addr-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 May 8 17:10:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h490Aohs009640; Thu, 8 May 2003 17:10:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h490AoCW009638; Thu, 8 May 2003 17:10:50 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h490Ajhs009621 for ; Thu, 8 May 2003 17:10:45 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4909QKw018366 for ; Thu, 8 May 2003 17:09:27 -0700 (PDT) Received: from esunmail ([129.147.58.198]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4909LiY024766 for ; Thu, 8 May 2003 18:09:21 -0600 (MDT) Received: from xpa-fe1 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HEL00CKLF3KEZ@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Thu, 08 May 2003 18:09:21 -0600 (MDT) Received: from sun.com ([129.146.15.19]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HEL000J2F3JA7@mail.sun.net> for ipng@sunroof.eng.sun.com; Thu, 08 May 2003 18:09:20 -0600 (MDT) Date: Thu, 08 May 2003 17:09:18 -0700 From: Alain Durand Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Message-id: <3EBAF1AE.9030608@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <4.3.2.7.2.20030507111352.02d4cff0@mailhost.iprg.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've read the draft, here are some comments. 1- This is clearly better than "current" Site Local addresses. The "ambiguity" factor is removed. Now the question is: Is this better enough? I have concerns when those addresses will be used in conjonction of globally routable addresses on the same node. 3- The whole idea of a switch on a box to say that this node is "allowed" to talk to the outside is not realistic in open environments where users bring their own machine (ex: 802.11 hot spots, university campus networks,...) and would lead to difficult to diagnose situations. 4- For this to work, the current rules on default address selection would probably have to change to say: prefer greater scope when available. 5- But even then, it is unclear how multi-party applications would work. Say, A & B are within the same site, C is external. A is "allowed" to communicate externaly, B is not. If the application running on A wants to communicate with both 'easily', it would make sense to use the globaly routable address for both connections. 6- As seen in the example before, this does not remove the burden for applications to deal with 'scoped addresses'. 7- Take the example of 2 sites, A & B using 2 "local" prefixes and 2 global prefixes at the same time. Now, A and B decide to establish an 'extranet' connection and would like to 'scope' their inter-communications by using those special addresses. How is address selection suppose to handle this? Is it expected that A & B will somehow have to make their local view of the DNS visible to the other? So, as a conclusion, this is only appealing if you think that the concept of scoped addresses is good and the only issue with Site Local addresses was thier ambiguity. If you believe that introducing scope in applications via special classes of addresses is not a good think to do, and it would be better done it via routing alone, this proposal does no good. - Alain. ps: minor nits at this point, this proposal is mixing architecture properties with policy decisions. The way bits are managed bellow the initial /7 or /8 allocation up to the /64 boundary are not relevant to this discussion. You may want to suggest /48 allocation as in RFC3177, but there is nothing technical about it. The way bits are allocated in that space (random, delegation, aggregation on criterias other than network toplology,...) is a completly orthogonal discussion. ps2: Using the HD ratio to analyse the address space properties would help. I ran some numbers if you're interested. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 8 17:27:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h490R5hs010033; Thu, 8 May 2003 17:27:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h490R5Qd010031; Thu, 8 May 2003 17:27:05 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h490Qxhs010017 for ; Thu, 8 May 2003 17:26:59 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h490Peuc007520 for ; Thu, 8 May 2003 17:25:41 -0700 (PDT) Received: from ALPHA2.ITS.MONASH.EDU.AU (alpha2.its.monash.edu.au [130.194.1.4]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id RAA13899 for ; Thu, 8 May 2003 17:25:35 -0700 (PDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxc.its.monash.edu.au (PMDF V6.1 #39306) with ESMTP id <01KVONF2TIKK960IKI@vaxc.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 09 May 2003 10:25:19 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id AED5112C007; Fri, 09 May 2003 10:25:18 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 8AC8D12C004; Fri, 09 May 2003 10:25:18 +1000 (EST) Date: Fri, 09 May 2003 11:25:16 +1000 From: Greg Daley Subject: Re: Fwd: I-D ACTION:draft-hinden-ipv6-global-local-addr-00.txt To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EBB037C.4080802@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en, en-us User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 References: <4.3.2.7.2.20030508150436.02d725e0@mailhost.iprg.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Bob, Thanks for putting out the draft. I'm interested in why you chose to use a registry rather than a stateless random service? I guess that the chance that someone incorrectly reads the registry provided prefix is greater than the chance of collision due to two merging sites selecting the same random number. Is there a perceived benefit to having 'registered uniqueness'? Forty-one coin tosses are possibly onerous, but this only need to be done once per organization... (except if all are 0's or 1's :) Greg Daley Bob Hinden wrote: > FYI > >> To: IETF-Announce: ; >> From: Internet-Drafts@ietf.org >> Reply-to: Internet-Drafts@ietf.org >> Subject: I-D ACTION:draft-hinden-ipv6-global-local-addr-00.txt >> Date: Thu, 08 May 2003 15:34:43 -0400 >> Sender: owner-ietf-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Globally Unique IPv6 Local Unicast Addresses >> Author(s) : R. Hinden >> Filename : draft-hinden-ipv6-global-local-addr-00.txt >> Pages : 10 >> Date : 2003-5-8 >> >> This document defines an unicast address format that is globally >> unique and is intended for local communications, usually inside of a >> site. They are not expected to be routable on the global Internet >> given current routing technology. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-hinden-ipv6-global-local-addr-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-hinden-ipv6-global-local-addr-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-hinden-ipv6-global-local-addr-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: <2003-5-8113033.I-D@ietf.org> >> >> ENCODING mime >> FILE /internet-drafts/draft-hinden-ipv6-global-local-addr-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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 8 20:15:34 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h493FYhs013108; Thu, 8 May 2003 20:15:34 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h493FX3R013107; Thu, 8 May 2003 20:15:33 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h493FThs013100 for ; Thu, 8 May 2003 20:15:29 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h493EBKw006656 for ; Thu, 8 May 2003 20:14:11 -0700 (PDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id UAA17214 for ; Thu, 8 May 2003 20:14:05 -0700 (PDT) Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate3.mot.com (Motorola/Motgate3) with ESMTP id h493E5G7026268 for ; Thu, 8 May 2003 20:14:05 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by az33exr01.mot.com (Motorola/az33exr01) with ESMTP id h493E0ir010037 for ; Thu, 8 May 2003 22:14:02 -0500 Received: from motorola.com (aewhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h493DwVI000274 for ; Fri, 9 May 2003 13:13:59 +1000 (EST) Message-ID: <3EBB1CF6.8738E383@motorola.com> Date: Fri, 09 May 2003 13:13:58 +1000 From: Andrew White Reply-To: awhite@arc.corp.mot.com Organization: Motorola Australia Research Centre X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <4.3.2.7.2.20030507111352.02d4cff0@mailhost.iprg.nokia.com> <3EBAF1AE.9030608@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain Durand wrote: > 5- But even then, it is unclear how multi-party applications would work. > Say, A & B are within the same site, C is external. > A is "allowed" to communicate externaly, B is not. If the application > running on A wants to communicate with both 'easily', it would > make sense to use the globaly routable address for both connections. If A is proxying the connections both ways, it can happily use the local address for B and the global address for C. If A is forwarding an address reference, B + C are never going to be able to communicate no matter which 'B' address is passed to C (since B can't communicate externally). If B can communicate externally, but only on some addresses, it seems the solutions are either: * A passes the NAME of C (or B), and lets the two nodes figure out which address to use. * A knows about potential filtering rules, and thus chooses the appropriate address. That said, consider for a moment if B has only global addresses... (1) If B has only one address, then it doesn't matter what A (or B or C) does, the connection between B and C will succeed or fail depending on filters (and network state). (2) If B has multiple addresses with identical filtering, see (1). (3) If B has multiple addresses with non-identical filtering, then A either passes C a name and trusts that the external-OK one is in the DNS. Or it guesses which address to pass. Or it passes all of them. Very similar to the local + global case, except in that case the application can tell that it shouldn't expect the local address to work. I've seen this point (#5) come up a few times, and I believe it to be a red herring. There seem to be two obvious solutions: (1) Ban multihomed hosts (except for routers). (2) Write applications so that they don't assume single-homed hosts and an unfiltered address space. Or, "applications that forward addresses across filtering boundaries need to apply the address selection rules to their forwarding." > 4- For this to work, the current rules on default address selection > would probably have to change to say: prefer greater scope when > available. I disagree. Is there a good reason an internal-internal app wouldn't prefer a local rather than global address? > 6- As seen in the example before, this does not remove the burden for > applications to deal with 'scoped addresses'. Only those apps wishing to do cross-scope forwarding of addresses. All others may remain blissfully ignorant and let address selection 'do the right thing'. > 7- Take the example of 2 sites, A & B using 2 "local" prefixes > and 2 global prefixes at the same time. Now, A and B > decide to establish an 'extranet' connection and would like > to 'scope' their inter-communications by using those special addresses. > How is address selection suppose to handle this? > Is it expected that A & B will somehow have to make their local > view of the DNS visible to the other? Yes. If site A and site B create a tunnel, they have effectively merged. Some additional effort will be required to ensure that DNS requests in A for B can travel across the tunnel to B, and vice versa. If no tunnel exists, the sites cannot merge, and therefore cannot communicate 'locally'. -- Andrew White -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 8 23:04:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4964ehs014390; Thu, 8 May 2003 23:04:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4964ePo014389; Thu, 8 May 2003 23:04:40 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4964bhs014382 for ; Thu, 8 May 2003 23:04:37 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4963Juc016152 for ; Thu, 8 May 2003 23:03:19 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id AAA14027 for ; Fri, 9 May 2003 00:03:13 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h49636Q00970; Fri, 9 May 2003 09:03:06 +0300 Date: Fri, 9 May 2003 09:03:06 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: Bob Hinden , Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <3EBAF1AE.9030608@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, 8 May 2003, Alain Durand wrote: > 5- But even then, it is unclear how multi-party applications would work. > Say, A & B are within the same site, C is external. > A is "allowed" to communicate externaly, B is not. If the application > running on A wants to communicate with both 'easily', it would > make sense to use the globaly routable address for both connections. > > 6- As seen in the example before, this does not remove the burden for > applications to deal with 'scoped addresses'. It seems to me that this could also be considered a feature. If B is not allowed to communicate externally, participating in a multi-party app should fail with C that is outside of the site. However, referrals work (to some degree) because they are not ambiguous. On the other hand, if A uses a global IPv6 address and B a local IPv6 address, those should also be able to communicate with each other. I haven't read the draft yet so there may be holes here: but the point is, if the border is being made with access-list type filtering at the edge of the site, it doesn't matter: internal "local-only" users and internal "global-only" or "local+global" users should very well be able to communicate with each other inside the site, with "prefer greatest scope" rule. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 8 23:17:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h496HPhs014634; Thu, 8 May 2003 23:17:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h496HP3I014633; Thu, 8 May 2003 23:17:25 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h496HMhs014626 for ; Thu, 8 May 2003 23:17:22 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h496G3uc021428 for ; Thu, 8 May 2003 23:16:04 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id AAA23677 for ; Fri, 9 May 2003 00:15:58 -0600 (MDT) 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 XAA19568; Thu, 8 May 2003 23:15:57 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h496Fvg01229; Thu, 8 May 2003 23:15:57 -0700 X-mProtect: <200305090615> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (209.157.142.164, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdS1IoPb; Thu, 08 May 2003 23:15:55 PDT Message-Id: <4.3.2.7.2.20030508215103.0339f150@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 May 2003 23:15:24 -0700 To: Alain Durand From: Bob Hinden Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3EBAF1AE.9030608@sun.com> References: <4.3.2.7.2.20030507111352.02d4cff0@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain, Thanks for the feedback. My intent in the draft (and apparently it should have been clearer) was to not say these were scoped addresses (or more accurately that have smaller scope than global unicast). I say they are intended for local communication, but can be used for non-local communication if the appropriate routes are set up. So I would say that applications may have to select between these addresses based and global unicast for reasons of reachability, but I don't think this is different from having to select from multiple global unicast addresses. Bob At 05:09 PM 5/8/2003, Alain Durand wrote: >I've read the draft, here are some comments. > >1- This is clearly better than "current" Site Local addresses. >The "ambiguity" factor is removed. Now the question is: >Is this better enough? I have concerns when those >addresses will be used in conjonction of globally routable >addresses on the same node. > >3- The whole idea of a switch on a box to say that this node is "allowed" >to talk to the outside is not realistic in open environments where users >bring their own machine (ex: 802.11 hot spots, university campus networks,...) >and would lead to difficult to diagnose situations. > >4- For this to work, the current rules on default address selection >would probably have to change to say: prefer greater scope when available. > >5- But even then, it is unclear how multi-party applications would work. >Say, A & B are within the same site, C is external. >A is "allowed" to communicate externaly, B is not. If the application >running on A wants to communicate with both 'easily', it would >make sense to use the globaly routable address for both connections. > >6- As seen in the example before, this does not remove the burden for >applications to deal with 'scoped addresses'. > >7- Take the example of 2 sites, A & B using 2 "local" prefixes >and 2 global prefixes at the same time. Now, A and B >decide to establish an 'extranet' connection and would like >to 'scope' their inter-communications by using those special addresses. >How is address selection suppose to handle this? >Is it expected that A & B will somehow have to make their local >view of the DNS visible to the other? > > >So, as a conclusion, this is only appealing if you think that the concept >of scoped addresses is good and the only issue with Site Local addresses >was thier ambiguity. If you believe that introducing scope in applications via >special classes of addresses is not a good think to do, and it would >be better done it via routing alone, this proposal does no good. > >- Alain. > > >ps: minor nits at this point, this proposal is mixing architecture >properties with policy decisions. The way bits are managed >bellow the initial /7 or /8 allocation up to the /64 boundary >are not relevant to this discussion. You may want to suggest >/48 allocation as in RFC3177, but there is nothing technical >about it. The way bits are allocated in that space (random, >delegation, aggregation on criterias other than network toplology,...) >is a completly orthogonal discussion. > > >ps2: Using the HD ratio to analyse the address space >properties would help. I ran some numbers if you're interested. > > > > > > > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 9 00:17:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h497HShs015005; Fri, 9 May 2003 00:17:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h497HSVU015004; Fri, 9 May 2003 00:17:28 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h497HOhs014997 for ; Fri, 9 May 2003 00:17:25 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h497G4uc014610 for ; Fri, 9 May 2003 00:16:04 -0700 (PDT) Received: from relay4.alcatel.be (alc245.alcatel.be [195.207.101.245]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id BAA29690 for ; Fri, 9 May 2003 01:15:58 -0600 (MDT) From: Robert.Peschi@alcatel.be Received: from bemail01.net.alcatel.be (bemail01.net.alcatel.be [138.203.145.85]) by relay4.alcatel.be (8.12.9/8.12.9) with ESMTP id h497KKLC018578; Fri, 9 May 2003 09:20:32 +0200 Sensitivity: Subject: Re: Avoiding interface failure upon DAD failure To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Date: Fri, 9 May 2003 09:15:29 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/09/2003 09:15:42 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis.Dupont@enst-bretagne.fr > PS: DAD is not a toy: at least once it spared us > a disaster...If something really needs improvement > in RFC 2461/2462, it is more how to cleanup everything > when a router's sent some rogue RAs. By the way I find it a bit amazing that RFC 2462 section 5.4 just acknowledges DAD unreliability with no hint as how to fix it: >From 2462 section 5.4: "Note that the method for detecting duplicates is not completely reliable, and it is possible that duplicate addresses will still exist (e.g., if the link was partitioned while Duplicate Address Detection was performed)." So, what about if this case would happen ? Robert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 9 01:21:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h498LWhs015400; Fri, 9 May 2003 01:21:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h498LWT8015399; Fri, 9 May 2003 01:21:32 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h498LThs015392 for ; Fri, 9 May 2003 01:21:29 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h498K9Kw009339 for ; Fri, 9 May 2003 01:20:09 -0700 (PDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h498K3iY011294 for ; Fri, 9 May 2003 02:20:03 -0600 (MDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h498JxK05190; Fri, 9 May 2003 10:20:00 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h498Jxof060764; Fri, 9 May 2003 10:19:59 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200305090819.h498Jxof060764@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Robert.Peschi@alcatel.be cc: ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure In-reply-to: Your message of Fri, 09 May 2003 09:15:29 +0200. Date: Fri, 09 May 2003 10:19:59 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In your previous mail you wrote: > PS: DAD is not a toy: at least once it spared us > a disaster... By the way I find it a bit amazing that RFC 2462 section 5.4 just acknowledges DAD unreliability with no hint as how to fix it: => DAD is about problem (mainly from human errors) avoidance, DAD is NOT a security tool therefore it has not to be 100% reliable. 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 Fri May 9 01:24:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h498Omhs015434; Fri, 9 May 2003 01:24:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h498Om9K015433; Fri, 9 May 2003 01:24:48 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h498Ojhs015426 for ; Fri, 9 May 2003 01:24:45 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h498NPuc008957 for ; Fri, 9 May 2003 01:23:25 -0700 (PDT) Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id CAA10819 for ; Fri, 9 May 2003 02:23:15 -0600 (MDT) Received: from yhhan (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.8/8.12.1) with SMTP id h498N83X019252; Fri, 9 May 2003 17:23:12 +0900 (KST) Message-ID: <010001c31604$2d98e160$3d2f024b@yhhan> From: "Youn-Hee Han" To: "Mika Liljeberg" Cc: References: <3EBAA499.D75B7920@iprg.nokia.com> <1052425233.3992.6.camel@devil> <3EBABF6D.1080206@kolumbus.fi> <1052427103.3992.15.camel@devil> Subject: Re: Avoiding interface failure upon DAD failure Date: Fri, 9 May 2003 17:22:44 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id h498Ojhs015427 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On the whole, the discussion about this subject comes to a conclusion as "May use RFC3041 to configure link-local address or global address (CoA)". Right? I also hate to make this discussion long, I would like to give my opinion about the probability of address collision. MikaL wrote: > > It's part of the cost-benefit analysis. If the probability of collision > is low enough not to be a significant factor in the total failure rate, > the user is not going to see any difference one way or the other. If > this is the case, the added implementation complexity is not warranted. > > > Perhaps the argument is that the probability is neglible. > > It is, I agree. Still, shouldn't we do the right thing > > even if the probability of the bad thing happening is > > very small? > > Only if the cost-benefit analysis makes sense. Not all nodes and interfaces contain IEEE identifiers. In such cases, an interface identifier is generated through some other means (e.g., at random), and the resultant interface identifier is not globally unique. Several guys think that DAD is far more likely to succeed than fail for even randomly auto-configured addresses. right? However, such optimistic thought becomes valid only when randomly auto-configured addresses are truly random and they are distributed uniformly and globally. We can think an unfortunated case that two or more nodes use the same seed for random number generation. If the nodes meet in a link, the collision probability may be high. To think another example, let us assume that there is a series of links where a great quantity of IPv6 nodes exists and a node wanders about within the series of links. If the node generates its CoA randomly whenever moving to one of the series, the probability of address collision may be high, too. The above cases occurs more frequently in the future, where more and more real-objects have their IPv6 address (please think about ubiquitous computing environment). Comments? --YH -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 9 01:25:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h498P1hs015444; Fri, 9 May 2003 01:25:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h498P1pw015443; Fri, 9 May 2003 01:25:01 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h498Ouhs015436 for ; Fri, 9 May 2003 01:24:57 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h498NbKw010553 for ; Fri, 9 May 2003 01:23:37 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id BAA22322 for ; Fri, 9 May 2003 01:23:31 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E3AA-0001De-00; Fri, 09 May 2003 09:23:30 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E3AA-0001DZ-00; Fri, 09 May 2003 09:23:30 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id JAA115430; Fri, 9 May 2003 09:23:27 +0100 Message-ID: <3EBB659F.C91C7BD0@hursley.ibm.com> Date: Fri, 09 May 2003 10:23:59 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Alain Durand CC: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <4.3.2.7.2.20030507111352.02d4cff0@mailhost.iprg.nokia.com> <3EBAF1AE.9030608@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain Durand wrote: .... > So, as a conclusion, this is only appealing if you think that the concept > of scoped addresses is good and the only issue with Site Local addresses > was thier ambiguity. If you believe that introducing scope in > applications via > special classes of addresses is not a good think to do, and it would > be better done it via routing alone, this proposal does no good. I don't think the second sentence is true. Even if applications have no understanding of scope, the kind of problems with RFC 1918 addresses that have to be handled today by complex /32 static route configurations (and would need /128 routes in IPv6 under FEC0::) will be handled much more simply with /48 routes. In other words, this proposal solves the ambiguity problem regardless of scope. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 9 02:39:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h499dkhs016398; Fri, 9 May 2003 02:39:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h499dkrm016397; Fri, 9 May 2003 02:39:46 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h499dghs016390 for ; Fri, 9 May 2003 02:39:43 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h499cNuc006215 for ; Fri, 9 May 2003 02:38:23 -0700 (PDT) Received: from relay4.alcatel.be (alc245.alcatel.be [195.207.101.245]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id DAA04069 for ; Fri, 9 May 2003 03:38:16 -0600 (MDT) From: Robert.Peschi@alcatel.be Received: from bemail01.net.alcatel.be (bemail01.net.alcatel.be [138.203.145.85]) by relay4.alcatel.be (8.12.9/8.12.9) with ESMTP id h499gwLC011334; Fri, 9 May 2003 11:42:58 +0200 Sensitivity: Subject: Re: Avoiding interface failure upon DAD failure To: Francis Dupont Cc: ipng@sunroof.eng.sun.com Date: Fri, 9 May 2003 11:38:07 +0200 Message-ID: X-MIMETrack: Serialize by Router on BEMAIL01/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 05/09/2003 11:38:07 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Francis.Dupont@enst-bretagne.fr wrote: > => DAD is about problem (mainly from human errors) > avoidance, DAD is NOT a security tool therefore it > has not to be 100% reliable. I agree that DAD is not a security tool. I understood that DAD was a tool to bring/keep the network operational. It was from this point of view of operational robustness that I was a bit amazed... Regards, Robert -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 9 02:40:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h499ebhs016417; Fri, 9 May 2003 02:40:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h499eb7x016416; Fri, 9 May 2003 02:40:37 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h499eYhs016408 for ; Fri, 9 May 2003 02:40:34 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h499dEKw009366 for ; Fri, 9 May 2003 02:39:14 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id DAA06588 for ; Fri, 9 May 2003 03:39:06 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 789E46A903; Fri, 9 May 2003 12:38:59 +0300 (EEST) Message-ID: <3EBB76E5.2030209@kolumbus.fi> Date: Fri, 09 May 2003 12:37:41 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Youn-Hee Han Cc: Mika Liljeberg , ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure References: <3EBAA499.D75B7920@iprg.nokia.com> <1052425233.3992.6.camel@devil> <3EBABF6D.1080206@kolumbus.fi> <1052427103.3992.15.camel@devil> <010001c31604$2d98e160$3d2f024b@yhhan> In-Reply-To: <010001c31604$2d98e160$3d2f024b@yhhan> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Youn-Hee Han wrote: > On the whole, the discussion about this subject comes > to a conclusion as "May use RFC3041 to configure link-local > address or global address (CoA)". Right? I think so. > Not all nodes and interfaces contain IEEE identifiers. In such > cases, an interface identifier is generated through some other > means (e.g., at random), and the resultant interface identifier is > not globally unique. > > Several guys think that DAD is far more likely to succeed than fail > for even randomly auto-configured addresses. right? > However, such optimistic thought becomes valid only when randomly > auto-configured addresses are truly random and they are distributed > uniformly and globally. > > We can think an unfortunated case that two or more nodes use > the same seed for random number generation. You are right. RFC 3041 does bring this up in Section 3.2.2 and even references some documents on good random number generation. This will help folks produce good implementations. I'm sure it won't prevent some other folks from producing bad implementations ;-( If there's anything positive in that, maybe its the fact that such implementations are much more likely to collide with another device of the same kind than with the good implementations. --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 May 9 03:10:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49AAlhs017040; Fri, 9 May 2003 03:10:48 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49AAlG1017039; Fri, 9 May 2003 03:10:47 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49AAihs017032 for ; Fri, 9 May 2003 03:10:44 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49A9Nuc018364 for ; Fri, 9 May 2003 03:09:23 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id EAA18106 for ; Fri, 9 May 2003 04:09:16 -0600 (MDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E4oT-0001IQ-00; Fri, 09 May 2003 11:09:13 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E4oT-0001IG-00; Fri, 09 May 2003 11:09:13 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id LAA155500; Fri, 9 May 2003 11:09:10 +0100 Message-ID: <3EBB7E66.FBFBD67E@hursley.ibm.com> Date: Fri, 09 May 2003 12:09:42 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Andrew Main CC: ipng@sunroof.eng.sun.com Subject: Re: IPv6 address text representation References: <20030508085627.GA27291@fysh.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Andrew, Andrew Main wrote: > > The update of the URI syntax RFC, draft-fielding-uri-rfc2396bis, > gives a precise ABNF syntax for IPv6 address textual format, on which > Roy Fielding and I collaborated. This really ought to be in the IPv6 > Addressing Architecture document -- RFC2373 had a faulty attempt at an > ABNF grammar -- but the URI work came too late to get the grammar into the > Addressing Architecture update that was being worked on at the time, now > published as RFC3513. Bob Hinden suggested that the IP address textual > representation work could be published as a standalone document instead. > > I've submitted a draft of this standalone document; it's > draft-main-ipaddr-text-rep-00. In working out the syntax details with > Roy, I ended up with a lot of historical material and rationale, which > I think makes such a narrow-topic document worthwhile. Agreed. I'm glad someone finally got the ABNF right. In your history, I think you might mention the BNF in [MTP] which was inherited by RFC 821. Embarassingly, I can add to the history by admitting that the faulty ABNF in [IPV6-AA-2] was mine (see the message appended below). A few other comments on the draft. Should it be Informational? Wouldn't it be better to have it available as a normative reference? I suggest adding after the first paragraph of the Introduction something like: It is generally considered undesirable for numeric IP addresses to be stored anywhere but in the DNS system, to avoid operational problems when hosts or networks are renumbered for any reason [RFC 1900]. However, this does not remove the need to represent addresses textually in documents, user interfaces, configuration files, and some protocols. > 4.3 Delimitation ... > In contexts where an IP address needs to be distinguished from > similar-looking data that can appear in the same place, there is > precedent (from email addresses and URLs) for enclosing an IP address > in brackets ("[]") as a distinguisher. You could usefully refer here to RFC 821, RFC 2732, and [URI]. Brian --------- Date: Mon, 27 Oct 1997 13:56:49 GMT Message-Id: <9710271356.AA35978@hursley.ibm.com> From: "(Brian E Carpenter)" Subject: (IPng 4705) draft-ietf-ipngwg-addr-arch-v2-03.txt To: ipng@sunroof.eng.sun.com Reply-To: brian@hursley.ibm.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-ipng@eng.sun.com Precedence: bulk Just some minor points on draft-ietf-ipngwg-addr-arch-v2-03.txt 1. Given the difficulty we have in persuading the URL and SMTP folks to do the right thing with the textual representation, I suggest including a BNF syntax version as an annex. A rough cut is annexed to this email. 2. I know why we say > o An anycast address must not be assigned to an IPv6 host, that > is, it may be assigned to an IPv6 router only. but is this really going to be tenable? It certainly isn't enforceable. 3. For the record: I know I lost this one, but I still think it is wrong to invert the universal/local bit in EUI-64. Brian Carpenter In the variant of BNF used for URL syntax: IPv6address = hexpart [ ":" IPv4address ] IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*hex hex = digit | "A" | "a" | "B" digit = "1" | "2" | "3" -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home 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 May 9 03:44:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49AiQhs017341; Fri, 9 May 2003 03:44:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49AiQOq017340; Fri, 9 May 2003 03:44:26 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49AiNhs017333 for ; Fri, 9 May 2003 03:44:23 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49Ah2uc001314 for ; Fri, 9 May 2003 03:43:02 -0700 (PDT) Received: from bowl.fysh.org ([195.167.170.152]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA20330 for ; Fri, 9 May 2003 04:42:56 -0600 (MDT) Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 19E5L5-0007j5-00 for ; Fri, 09 May 2003 11:42:55 +0100 Date: Fri, 9 May 2003 11:42:54 +0100 To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-hinden-ipv6-global-local-addr-00.txt Message-ID: <20030509104254.GA3502@fysh.org> References: <200305081934.PAA06055@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200305081934.PAA06055@ietf.org> User-Agent: Mutt/1.3.28i From: Zefram Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Overall this looks like a very good idea. I'm enormously more comfortable about the idea of using these Globally Unique addresses than site-local addresses. A handful of minor points: 0. The name you're using to refer to the addresses, "globally unique IPv6 local addresses", doesn't express the essential characteristics of these addresses. There are many types of IPv6 address that are globally unique (most of them, in fact), and the word "local" is too vague in this context. The interesting characteristics of these addresses are that they're (a) provider-independent, (b) globally scoped (globally unique), (c) not generally routable. A better tag, therefore, might be "unroutable global IPv6 addresses". "local", as in local routeability, is one way they can be used, but isn't an inherent property of the address type, and so shouldn't be mentioned in this tag at all. 1. Why reserve the all-zeroes and all-ones global IDs? The convention in IPv6 is that we don't reserve these values in any field. If the intent is merely to prevent these IDs being allocated in the normal manner, it seems better to say that they must never be assigned at all, rather than saying that they might be used in the future. 2. You propose allocation by a central registry. There is an obvious alternative of uncoordinated random allocation by end users, which has already been suggested on this list. Why not support both? Some arrangement like fc00::/8 being centrally allocated and fd00::/8 being reserved for independent random allocation. It's a bit like the UUID system, where there is a choice between putting a MAC address in the UUID or using the space for randomness. Obviously random allocation doesn't have a strong guarantee of uniqueness, and in fact the birthday paradox applies, which is why central allocation is useful, but that doesn't make independent random allocation unuseful. 3. Whether it's officially supported or not, I expect some people will randomly allocate their own prefix, so advice on how to do it right (use a strong entropy source, such as in the last resort tossing coins) would be worth adding to the draft. 4. The privacy of prefix ownership looks like a good idea. Escrow of it sounds innocuous, but I don't think you've justified the need for it. The draft says "It is escrowed to insure there are no duplicate allocations and in case it is needed in the future.". Duplicate allocations, more than one prefix to one user, are not a problem: the EUR10 fee will prevent large-scale abusive allocation, and some organisations might have a legitimate need for more than 16 bits of subnet ID within unroutable global address space. I suggest that all the "in case it is needed in the future" scenarios that we want to allow can be handled by having a cryptographically signed certificate from the registry that allows a prefix owner to prove ownership of their prefix, without the registry needing to keep records of who owns which prefix. This also has the advantage that pseudonymous allocations, and similar scenarios, aren't a problem for the registry. -zefram -- Andrew Main (Zefram) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 9 04:32:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49BW1hs017830; Fri, 9 May 2003 04:32:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49BW0p6017829; Fri, 9 May 2003 04:32:00 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49BVvhs017821 for ; Fri, 9 May 2003 04:31:57 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49BUauc019569 for ; Fri, 9 May 2003 04:30:37 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA02685 for ; Fri, 9 May 2003 04:30:31 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E658-00077t-00; Fri, 09 May 2003 12:30:30 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E658-00077o-00; Fri, 09 May 2003 12:30:30 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA115454; Fri, 9 May 2003 12:30:26 +0100 Message-ID: <3EBB9172.338C380C@hursley.ibm.com> Date: Fri, 09 May 2003 13:30:58 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Zefram CC: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-hinden-ipv6-global-local-addr-00.txt References: <200305081934.PAA06055@ietf.org> <20030509104254.GA3502@fysh.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Zefram wrote: ... > > 2. You propose allocation by a central registry. There is an obvious > alternative of uncoordinated random allocation by end users, which > has already been suggested on this list. Why not support both? > Some arrangement like fc00::/8 being centrally allocated and fd00::/8 > being reserved for independent random allocation. It's a bit like the > UUID system, where there is a choice between putting a MAC address > in the UUID or using the space for randomness. Obviously random > allocation doesn't have a strong guarantee of uniqueness, and in > fact the birthday paradox applies, which is why central allocation is > useful, but that doesn't make independent random allocation unuseful. I'm sure that unless a guaranteed-unique allocator is available, some user sites will be uncomfortable. Allowing a probably-unique alternative without a central allocator is OK, but it has to come with health warnings. > > 3. Whether it's officially supported or not, I expect some people will > randomly allocate their own prefix, so advice on how to do it right > (use a strong entropy source, such as in the last resort tossing coins) > would be worth adding to the draft. Yes. And in fact, since people will do it anyway, it is safer to allow for it in the spec. > > 4. The privacy of prefix ownership looks like a good idea. Escrow of it > sounds innocuous, but I don't think you've justified the need for it. > The draft says "It is escrowed to insure there are no duplicate > allocations and in case it is needed in the future.". Duplicate > allocations, more than one prefix to one user, are not a problem: It means duplicate allocations of the same prefix, I think, and they would certainly be a problem. In other words the list of prefixes that have been allocated certainly needs to be stored in ultra secure archival, in case the allocator crashes and burns. For this purpose, we don't need to escrow the "ownership". But... > the EUR10 fee will prevent large-scale abusive allocation, and some > organisations might have a legitimate need for more than 16 bits of > subnet ID within unroutable global address space. I suggest that all > the "in case it is needed in the future" scenarios that we want to > allow can be handled by having a cryptographically signed certificate > from the registry that allows a prefix owner to prove ownership of > their prefix, without the registry needing to keep records of who > owns which prefix. This also has the advantage that pseudonymous > allocations, and similar scenarios, aren't a problem for the registry. Yes they are, if local law enforcement makes them a problem. There are plenty of precedents for that. Actually, this is why we probably do need the alternative random mechanism - so that a user site that doesn't want its prefix escrowed can still get a prefix, subject to the low risk of a collision. Brian > > -zefram > -- > Andrew Main (Zefram) > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 9 05:15:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49CFIhs018263; Fri, 9 May 2003 05:15:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49CFIhr018262; Fri, 9 May 2003 05:15:18 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49CFFhs018255 for ; Fri, 9 May 2003 05:15:15 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49CDsuc006146 for ; Fri, 9 May 2003 05:13:54 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA14808 for ; Fri, 9 May 2003 06:13:48 -0600 (MDT) From: john.loughney@nokia.com Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h49CDlD19824 for ; Fri, 9 May 2003 15:13:47 +0300 (EET DST) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 9 May 2003 15:13:46 +0300 Received: from esebe002.NOE.Nokia.com ([172.21.138.17]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 9 May 2003 15:13:46 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 9 May 2003 15:13:46 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Avoiding interface failure upon DAD failure Date: Fri, 9 May 2003 15:13:41 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Avoiding interface failure upon DAD failure Thread-Index: AcMVo6UYajdyIbKwQly9hlGS9ZIvHAAgFe2g To: , Cc: , X-OriginalArrivalTime: 09 May 2003 12:13:46.0189 (UTC) FILETIME=[70B28FD0:01C31624] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h49CFFhs018256 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Mika, > On Thu, 2003-05-08 at 23:34, Jari Arkko wrote: > > Anyway, what should we do with the probabilities? Are you > > saying that everything with a smaller probability than > > radio problems should not be pursued? > > It's part of the cost-benefit analysis. If the probability of collision > is low enough not to be a significant factor in the total failure rate, > the user is not going to see any difference one way or the other. If > this is the case, the added implementation complexity is not > warranted. > > > Perhaps the argument is that the probability is neglible. > > It is, I agree. Still, shouldn't we do the right thing > > even if the probability of the bad thing happening is > > very small? > > Only if the cost-benefit analysis makes sense. I agree with you in principle, but part of the cost-benefit analysis should also consider the 'predictability' of failure. What I mean is that if the DAD failure happened everytime that you tried to connect to a specific access point, then the cost would be very high (in my opinion). However, if the DAD failure is fairly random and does not measurably increase the total rate of failure of connecting, then I would think that adding complexity to the specification is not warrented. Has anyone come-up with cases where DAD would fail? thanks, John -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 9 05:18:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49CIbhs018335; Fri, 9 May 2003 05:18:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49CIb1F018333; Fri, 9 May 2003 05:18:37 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49CIYhs018324 for ; Fri, 9 May 2003 05:18:34 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49CHDKw011231 for ; Fri, 9 May 2003 05:17:13 -0700 (PDT) Received: from bowl.fysh.org ([195.167.170.152]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA02262 for ; Fri, 9 May 2003 05:17:07 -0700 (PDT) Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 19E6oE-0006IY-00 for ; Fri, 09 May 2003 13:17:06 +0100 Date: Fri, 9 May 2003 13:17:06 +0100 To: ipng@sunroof.eng.sun.com Subject: Re: I-D ACTION:draft-hinden-ipv6-global-local-addr-00.txt Message-ID: <20030509121706.GB3502@fysh.org> References: <200305081934.PAA06055@ietf.org> <20030509104254.GA3502@fysh.org> <3EBB9172.338C380C@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EBB9172.338C380C@hursley.ibm.com> User-Agent: Mutt/1.3.28i From: Zefram Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: >It means duplicate allocations of the same prefix, I think, and they >would certainly be a problem. In other words the list of prefixes that >have been allocated certainly needs to be stored in ultra secure >archival, in case the allocator crashes and burns. For this purpose, >we don't need to escrow the "ownership". Ah, yes. That interpretation of "duplicate allocation" hadn't occurred to me, since it's got nothing at all to do with the identity of prefix owners. Might I suggest that the "ultra secure archival" here ought to include widespread public mirroring -- there's no need for the list of allocated prefixes to be secret. >Yes they are, if local law enforcement makes them a problem. There are >plenty of precedents for that. My intent in proposing not keeping ownership records was that this avoids the possibility of law-enforcement-like problems. If the registry has a big secret list of prefix owners, we have to decide who gets access to that list, and then get issues of people violating the policy, accusations, suspicions, and so on. If the registry doesn't keep this secret then it doesn't need to protect the secret. I propose that the only long-lived secret the registry has should be its private certificate-signing key, which is much less of a problem. Or so it seems to me, at least. I don't have any real experience with coerced-disclosure issues. Maybe it just doesn't work the way I think it does. >Actually, this is why we probably do need the alternative random >mechanism - so that a user site that doesn't want its prefix >escrowed can still get a prefix, subject to the low risk of a collision. That's certainly a source of users that are going to use random allocation whether or not it's officially supported. -zefram -- Andrew Main (Zefram) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 9 05:35:30 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49CZUhs018777; Fri, 9 May 2003 05:35:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49CZU0R018776; Fri, 9 May 2003 05:35:30 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49CZQhs018769 for ; Fri, 9 May 2003 05:35:26 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49CY6uc014247 for ; Fri, 9 May 2003 05:34:06 -0700 (PDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h49CXxiY028310 for ; Fri, 9 May 2003 06:34:00 -0600 (MDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h49CXuK08502; Fri, 9 May 2003 14:33:56 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h49CXuof061606; Fri, 9 May 2003 14:33:56 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200305091233.h49CXuof061606@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: john.loughney@nokia.com cc: mika.liljeberg@welho.com, jari.arkko@kolumbus.fi, charliep@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure In-reply-to: Your message of Fri, 09 May 2003 15:13:41 +0300. Date: Fri, 09 May 2003 14:33:56 +0200 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: Has anyone come-up with cases where DAD would fail? => real case: manual setup of a router (so without autoconf) with a manual IID (common if you need to know it, 1 is easier than 260:5cff:fef4:90f :-) copied without care to another router. IMHO DAD failures are far more frequent when not automatical config is used, i.e., for routers and boxes running some services like DNS. 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 Fri May 9 06:21:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49DLRhs019671; Fri, 9 May 2003 06:21:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49DLRYo019670; Fri, 9 May 2003 06:21:27 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49DLOhs019663 for ; Fri, 9 May 2003 06:21:24 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49DK2uc002434 for ; Fri, 9 May 2003 06:20:02 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h49DJuWs007274 for ; Fri, 9 May 2003 07:19:56 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h49DJtD24682 for ; Fri, 9 May 2003 16:19:55 +0300 (EET DST) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 9 May 2003 16:19:55 +0300 Received: from esebe001.NOE.Nokia.com ([172.21.138.30]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 9 May 2003 16:19:55 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 9 May 2003 16:19:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Avoiding interface failure upon DAD failure Date: Fri, 9 May 2003 16:19:53 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Avoiding interface failure upon DAD failure Thread-Index: AcMWJ0vtqkqwCoT3RGqzmxZL+gtVkwABjR0g From: To: Cc: , , , X-OriginalArrivalTime: 09 May 2003 13:19:54.0170 (UTC) FILETIME=[ADCC69A0:01C3162D] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h49DLOhs019664 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Francis, Do you think that is applicable for the MIP case? Even still, if there was a mechanism to pick 3041 addresses after a manual setting, then it should work OK ...or better yet, use 3041 address instead of manual configs ... John > -----Original Message----- > From: ext Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: 09 May, 2003 15:34 > To: Loughney John (NRC/Helsinki) > Cc: mika.liljeberg@welho.com; jari.arkko@kolumbus.fi; Perkins Charles > (IPRG); ipng@sunroof.eng.sun.com > Subject: Re: Avoiding interface failure upon DAD failure > > > In your previous mail you wrote: > > Has anyone come-up with cases where DAD would fail? > > => real case: manual setup of a router (so without autoconf) with > a manual IID (common if you need to know it, 1 is easier than > 260:5cff:fef4:90f :-) copied without care to another router. > IMHO DAD failures are far more frequent when not automatical config > is used, i.e., for routers and boxes running some services like DNS. > > 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 Fri May 9 06:28:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49DSfhs019866; Fri, 9 May 2003 06:28:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49DSfnQ019865; Fri, 9 May 2003 06:28:41 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49DSbhs019858 for ; Fri, 9 May 2003 06:28:37 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49DRHuc005154 for ; Fri, 9 May 2003 06:27:17 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h49DRCPH022621 for ; Fri, 9 May 2003 06:27:12 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 9 May 2003 06:27:21 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F7DA@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMVv+b2qyg2WkGLSNKkLiDQbnhBPgAaiYKQ From: "Michel Py" To: "Bob Hinden" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h49DSchs019859 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, I have read this draft, comments below. It is clear that the intent was to remove ambiguity, which of course is a good idea. However, I wonder if in this case the risk induced by the cure is not worse than the disease. In the current state of the draft, there is no way to guarantee that this will not become a wild PI mess. There are two things that we can't enforce: 1. We can't enforce router vendors to code the default blackholes. Before moving ahead with this I would like to hear clear signs from the players in the field that they would support it. 2. We can't enforce operators to filter the prefix. I dropped filters on my BGP feeds and from one of my peers (a well-known player) I get all kinds of crud including /64 routes, /48 routes, /41 routes, name it I get it. The demand for PI is very strong. There are people that would support it. The major concern I have with this draft is that your original intent (remove ambiguity of private addresses) which is good could easily be perverted into global random PI which is terrible. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 9 06:54:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49Dsnhs020261; Fri, 9 May 2003 06:54:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49DsnZg020260; Fri, 9 May 2003 06:54:49 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49Dsjhs020253 for ; Fri, 9 May 2003 06:54:45 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49DrPKw023839 for ; Fri, 9 May 2003 06:53:25 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h49DrJiY011397 for ; Fri, 9 May 2003 07:53:19 -0600 (MDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E8JL-0000Lj-00 for ipng@sunroof.eng.sun.com; Fri, 09 May 2003 14:53:19 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19E8JL-0000Le-00 for ipng@sunroof.eng.sun.com; Fri, 09 May 2003 14:53:19 +0100 Received: from hursley.ibm.com (dhcp21-189.zurich.ibm.com [9.4.21.189]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA155618 for ; Fri, 9 May 2003 14:53:16 +0100 Message-ID: <3EBBB2EC.154D2CBC@hursley.ibm.com> Date: Fri, 09 May 2003 15:53:48 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <963621801C6D3E4A9CF454A1972AE8F504F7DA@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: > > Bob, > > I have read this draft, comments below. > > It is clear that the intent was to remove ambiguity, which of course is > a good idea. However, I wonder if in this case the risk induced by the > cure is not worse than the disease. In the current state of the draft, > there is no way to guarantee that this will not become a wild PI mess. > There are two things that we can't enforce: > > 1. We can't enforce router vendors to code the default blackholes. > Before moving ahead with this I would like to hear clear signs from the > players in the field that they would support it. Why is this different from FEC0::/10? > > 2. We can't enforce operators to filter the prefix. I dropped filters on > my BGP feeds and from one of my peers (a well-known player) I get all > kinds of crud including /64 routes, /48 routes, /41 routes, name it I > get it. I think there will be Darwinian effects here, as we saw during the first years of CIDR. But yes, if someone pays enough, they will get their /64 announced. That will happen whatever we write in RFCs. > > The demand for PI is very strong. There are people that would support > it. The major concern I have with this draft is that your original > intent (remove ambiguity of private addresses) which is good could > easily be perverted into global random PI which is terrible. Can you propose a solution to ambiguous local addresses that doesn't have this risk? Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 9 07:25:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49EPQhs020720; Fri, 9 May 2003 07:25:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49EPQJm020719; Fri, 9 May 2003 07:25:26 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49EPNhs020712 for ; Fri, 9 May 2003 07:25:23 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49EO2uc027653 for ; Fri, 9 May 2003 07:24:02 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h49ENuiY000116 for ; Fri, 9 May 2003 08:23:56 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h49ENnV05071; Fri, 9 May 2003 17:23:49 +0300 Date: Fri, 9 May 2003 17:23:49 +0300 (EEST) From: Pekka Savola To: Michel Py cc: Bob Hinden , Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F7DA@server2000.arneill-py.sacramento.ca.us> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 9 May 2003, Michel Py wrote: > 1. We can't enforce router vendors to code the default blackholes. > Before moving ahead with this I would like to hear clear signs from the > players in the field that they would support it. IMO, any proposal which says "default blackholes" it at least dubious if not broken. That lets the user to go into a safe dream that some good guy out there will actually have the software supporting such blacholes. Which is why there should not be blackholes. Such blackholes must be configured manually, or *AT LEAST* enabled manually. Access controls must be explicit, not implicit. All other choices would seem to lead to broken assumptions at the host implementor's side. > The demand for PI is very strong. There are people that would support > it. The major concern I have with this draft is that your original > intent (remove ambiguity of private addresses) which is good could > easily be perverted into global random PI which is terrible. Which may be why some form of PI may have to be defined, with strict criteria for application. But assumption that if we have PI, everyone must have PI (and more so, routable PI), may be an unfortunate reality, but a reality we must change if we want to introduce PI. But this is an issue for multi6. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 9 07:27:35 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49ERZhs020743; Fri, 9 May 2003 07:27:35 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49ERZkl020742; Fri, 9 May 2003 07:27:35 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49ERVhs020735 for ; Fri, 9 May 2003 07:27:31 -0700 (PDT) Received: from lukla.Sun.COM (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49EQAKw008114 for ; Fri, 9 May 2003 07:26:10 -0700 (PDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by lukla.Sun.COM (8.9.3p2+Sun/8.9.3) with ESMTP id IAA13581 for ; Fri, 9 May 2003 08:26:02 -0600 (MDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h49EPvK10376; Fri, 9 May 2003 16:25:57 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h49EPwof061921; Fri, 9 May 2003 16:25:58 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200305091425.h49EPwof061921@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: john.loughney@nokia.com cc: mika.liljeberg@welho.com, jari.arkko@kolumbus.fi, charliep@iprg.nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Avoiding interface failure upon DAD failure In-reply-to: Your message of Fri, 09 May 2003 16:19:53 +0300. Date: Fri, 09 May 2003 16:25:58 +0200 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: Do you think that is applicable for the MIP case? => yes, it will be applicable when MIP will support mobile routers. And today it is applicable when the node can be attached to the home link without previous knowledge. 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 Fri May 9 09:10:23 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49GAMhs022293; Fri, 9 May 2003 09:10:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49GAMiN022292; Fri, 9 May 2003 09:10:22 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49GAHhs022285 for ; Fri, 9 May 2003 09:10:17 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49G8uKw025518 for ; Fri, 9 May 2003 09:08:56 -0700 (PDT) Received: from esunmail ([129.147.58.120]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA02568 for ; Fri, 9 May 2003 10:08:51 -0600 (MDT) Received: from xpa-fe2 (esunmail [129.147.58.120]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HEM00IVGNIQT8@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Fri, 09 May 2003 10:08:50 -0600 (MDT) Received: from sun.com ([129.146.15.19]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HEM00KMUNIO7S@mail.sun.net> for ipng@sunroof.eng.sun.com; Fri, 09 May 2003 10:08:50 -0600 (MDT) Date: Fri, 09 May 2003 09:08:48 -0700 From: Alain Durand Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses To: Pekka Savola Cc: Michel Py , Bob Hinden , ipng@sunroof.eng.sun.com Message-id: <3EBBD290.3010304@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Pekka Savola wrote: >On Fri, 9 May 2003, Michel Py wrote: > > >>The demand for PI is very strong. There are people that would support >>it. The major concern I have with this draft is that your original >>intent (remove ambiguity of private addresses) which is good could >>easily be perverted into global random PI which is terrible. >> >> > >Which may be why some form of PI may have to be defined, with strict >criteria for application. But assumption that if we have PI, everyone >must have PI (and more so, routable PI), may be an unfortunate reality, >but a reality we must change if we want to introduce PI. > >But this is an issue for multi6. > Everybody want a free lunch in this story: routable PI. There is no reason to think that those non-routable PI will not be advertized in the DMZ if enough money is put on the table. - 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 Fri May 9 09:21:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49GLhhs022675; Fri, 9 May 2003 09:21:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49GLgkS022674; Fri, 9 May 2003 09:21:42 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49GLchs022664 for ; Fri, 9 May 2003 09:21:38 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49GKHKw001276 for ; Fri, 9 May 2003 09:20:17 -0700 (PDT) Received: from esunmail ([129.147.58.198]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h49GKBiY016424 for ; Fri, 9 May 2003 10:20:11 -0600 (MDT) Received: from xpa-fe2 (edgecal1 [129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HEM00IJKNZQSR@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Fri, 09 May 2003 10:19:03 -0600 (MDT) Received: from sun.com ([129.146.15.19]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HEM00KUINZP72@mail.sun.net> for ipng@sunroof.eng.sun.com; Fri, 09 May 2003 10:19:02 -0600 (MDT) Date: Fri, 09 May 2003 09:19:00 -0700 From: Alain Durand Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses To: Bob Hinden Cc: ipng@sunroof.eng.sun.com Message-id: <3EBBD4F4.5070909@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 References: <4.3.2.7.2.20030507111352.02d4cff0@mailhost.iprg.nokia.com> <4.3.2.7.2.20030508215103.0339f150@mailhost.iprg.nokia.com> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Hinden wrote: > Alain, > > Thanks for the feedback. > > My intent in the draft (and apparently it should have been clearer) > was to not say these were scoped addresses (or more accurately that > have smaller scope than global unicast). I say they are intended for > local communication, but can be used for non-local communication if > the appropriate routes are set up. It all depend on the definition of "scope" you're using. Those addresses are globally unique but one cannot assumed they can be reached from anywhere in the Internet. So, I claim that their "perceptive" value for an application is less than the one of global unicast addresses. > So I would say that applications may have to select between these > addresses based and global unicast for reasons of reachability, but I > don't think this is different from having to select from multiple > global unicast addresses. I disagree. See above. In multi-party environment, I a node needs to pass an IP address as identifier/locator to a peer, the odds of this to work are better if you use global unicast addresses. The issues are the same as with SL: If A, B & C do not share the same 'view' of the routable addres space, and there is an intersection at B, things will go wrong. - 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 Fri May 9 09:46:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49GkVhs023237; Fri, 9 May 2003 09:46:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49GkUcm023236; Fri, 9 May 2003 09:46:30 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49GkRhs023226 for ; Fri, 9 May 2003 09:46:27 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49Gj1Kw019966 for ; Fri, 9 May 2003 09:45:06 -0700 (PDT) Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id KAA02737 for ; Fri, 9 May 2003 10:44:55 -0600 (MDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h49GlHQK009067; Fri, 9 May 2003 19:47:17 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h49GlD1c009066; Fri, 9 May 2003 19:47:13 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Avoiding interface failure upon DAD failure From: Mika Liljeberg To: Youn-Hee Han Cc: ipng@sunroof.eng.sun.com In-Reply-To: <010001c31604$2d98e160$3d2f024b@yhhan> References: <3EBAA499.D75B7920@iprg.nokia.com> <1052425233.3992.6.camel@devil> <3EBABF6D.1080206@kolumbus.fi> <1052427103.3992.15.camel@devil> <010001c31604$2d98e160$3d2f024b@yhhan> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1052498833.3996.32.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 09 May 2003 19:47:13 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 2003-05-09 at 11:22, Youn-Hee Han wrote: > Several guys think that DAD is far more likely to succeed than fail > for even randomly auto-configured addresses. right? > However, such optimistic thought becomes valid only when randomly > auto-configured addresses are truly random and they are distributed > uniformly and globally. Fair enough, but having a bad random number generator is no excuse for retrying many times (with bad random numbers). The random number generator should be fixed instead. MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 9 13:58:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49Kwhhs028425; Fri, 9 May 2003 13:58:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49KwgQD028424; Fri, 9 May 2003 13:58:42 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49Kwbhs028417 for ; Fri, 9 May 2003 13:58:37 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49KvGuc021406 for ; Fri, 9 May 2003 13:57:16 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id OAA09996 for ; Fri, 9 May 2003 14:57:10 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h49Kuos08534; Fri, 9 May 2003 23:56:51 +0300 Date: Fri, 9 May 2003 23:56:50 +0300 (EEST) From: Pekka Savola To: Alain Durand cc: Michel Py , Bob Hinden , Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <3EBBD290.3010304@sun.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 May 2003, Alain Durand wrote: > Pekka Savola wrote: > >On Fri, 9 May 2003, Michel Py wrote: > > > > > >>The demand for PI is very strong. There are people that would support > >>it. The major concern I have with this draft is that your original > >>intent (remove ambiguity of private addresses) which is good could > >>easily be perverted into global random PI which is terrible. > >> > >> > > > >Which may be why some form of PI may have to be defined, with strict > >criteria for application. But assumption that if we have PI, everyone > >must have PI (and more so, routable PI), may be an unfortunate reality, > >but a reality we must change if we want to introduce PI. > > > >But this is an issue for multi6. > > > Everybody want a free lunch in this story: routable PI. > > There is no reason to think that those non-routable PI > will not be advertized in the DMZ if enough money > is put on the table. Which is why we should ensure that if you want to put money on the table, you have to bribe all the ISP's, not just your own :-). Should be a rather de-facto useful preventer for something like this :-). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 9 14:39:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49LdJhs029908; Fri, 9 May 2003 14:39:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49LdJYH029907; Fri, 9 May 2003 14:39:19 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49LdGhs029900 for ; Fri, 9 May 2003 14:39:16 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49Lbtuc014850 for ; Fri, 9 May 2003 14:37:55 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h49LboPH001969 for ; Fri, 9 May 2003 14:37:50 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 9 May 2003 14:37:59 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F5045811@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMWRXazCcioJeuNSYiZEteCFLDgqQALUV9w From: "Michel Py" To: "Alain Durand" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h49LdGhs029901 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Alain Durand wrote: > Everybody want a free lunch in this story: > routable PI. I would have said that this might be the free lunch that everybody wants. Unfortunately, free lunches are like freedom: in the end they're anything but free. > There is no reason to think that those non-routable > PI will not be advertized in the DMZ if enough money > is put on the table. Exactly. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 9 15:14:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49MEDhs000533; Fri, 9 May 2003 15:14:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49MEDD5000532; Fri, 9 May 2003 15:14:13 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49ME9hs000525 for ; Fri, 9 May 2003 15:14:09 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49MCmKw023156 for ; Fri, 9 May 2003 15:12:48 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h49MCgiY003485 for ; Fri, 9 May 2003 16:12:43 -0600 (MDT) Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Fri, 9 May 2003 15:12:42 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 May 2003 15:12:42 -0700 Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 09 May 2003 15:12:41 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Fri, 9 May 2003 15:12:40 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 9 May 2003 15:12:40 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Fri, 9 May 2003 15:12:51 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Fri, 9 May 2003 15:12:41 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMWRXazCcioJeuNSYiZEteCFLDgqQALUV9wAADg83A= From: "Christian Huitema" To: "Bob Hinden" Cc: X-OriginalArrivalTime: 09 May 2003 22:12:51.0418 (UTC) FILETIME=[21B93BA0:01C31678] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h49ME9hs000526 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, I believe your draft is a step in the right direction, but I regret that it does not support the "informal networking" scenario, in which unique numbers are assigned to network segments without intervention of an assignment authority. That scenario requires "self allocation". The obvious constraint in any self-allocation scheme is that it must either use a random number, or an reuse an already available identifier. We have been through this a couple of times, and we know that the random number route is fraught with perils. The birthday paradox dictates that the number of bits in the random number be at least twice the base 2 log of the number of objects in the system. If we aim for 10 billion networks, we would need at least 66 bits, and that does not sound very practical. This leaves us with the obvious alternative, i.e. to reuse an existing identifier. Two of those come to mind: IPv4 addresses, and IEEE 802 identifiers. Sites who have an IPv4 address could use it to build a 6to4 prefix, so we can leave that aside. But we could combine a unique IPv6 prefix (e.g. FEC0::/16) and a 48 bit IEEE 802 number to build a unique 64 bit link prefix. Such 64 bit prefixes would have many of the advantages of your global site identifiers, except they would identify links, not sites. Most important, they would not require an assignment authority. -- 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 Fri May 9 15:17:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49MHDhs000706; Fri, 9 May 2003 15:17:13 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h49MHDSP000704; Fri, 9 May 2003 15:17:13 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h49MH9hs000688 for ; Fri, 9 May 2003 15:17:09 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h49MFmuc004229 for ; Fri, 9 May 2003 15:15:48 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id PAA20456 for ; Fri, 9 May 2003 15:15:43 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 9 May 2003 15:15:52 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F7DC@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMWM1AGpkZix89+SEmA+vY0IISEDAAP+qXQ From: "Michel Py" To: "Brian Carpenter" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h49MH9hs000692 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> Michel Py wrote: >> 1. We can't enforce router vendors to code the default >> blackholes. Before moving ahead with this I would like >> to hear clear signs from the players in the field that >> they would support it. > Brian E Carpenter wrote: > Why is this different from FEC0::/10? It has nothing to do with the prefix itself but with the scope. Here's the scenario: Site A wants to pervert globally unique site-local addresses (the mechanism to make them globally unique such as a registry, random, MAC address hash etc is not relevant here) into globally routable globally unique addresses aka PI. Site A pays all of its upstreams to announce its prefix in the global routing table. Site A wants to talk to site B. Let's assume that nobody filters A's FEC0:x:y::/48 prefix between A and B (which by your own account below could happen). Site B receives site A's traffic. Some host at site B replies to site A. The egress router at site B dumps the return traffic into the bit bucket because the return address is scoped as site-local and the egress interface is in the global scope (or some similar reason). >> 2. We can't enforce operators to filter the prefix. I >> dropped filters on my BGP feeds and from one of my peers >> (a well-known player) I get all kinds of crud including >> /64 routes, /48 routes, /41 routes, name it I get it. > I think there will be Darwinian effects here, as we saw > during the first years of CIDR. But yes, if someone pays > enough, they will get their /64 announced. That will happen > whatever we write in RFCs. My point exactly. We can't rely on this alone. >> The demand for PI is very strong. There are people that >> would support it. The major concern I have with this draft >> is that your original intent (remove ambiguity of private >> addresses) which is good could easily be perverted into >> global random PI which is terrible. > Can you propose a solution to ambiguous local addresses that > doesn't thave this risk? Not without site-local addresses being part of the architecture. Can you? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 10 06:21:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4ADLUhs005065; Sat, 10 May 2003 06:21:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4ADLUHm005064; Sat, 10 May 2003 06:21:30 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4ADLRhs005057 for ; Sat, 10 May 2003 06:21:27 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4ADK7uc021855 for ; Sat, 10 May 2003 06:20:07 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA24222 for ; Sat, 10 May 2003 06:20:01 -0700 (PDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id DCD931D6F; Sat, 10 May 2003 09:20:00 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 10 May 2003 09:20:00 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Avoiding interface failure upon DAD failure Date: Sat, 10 May 2003 09:19:59 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7F4@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Avoiding interface failure upon DAD failure Thread-Index: AcMUokucFlI2Sz3gTFGUVGlzEVDX9wCVIGig From: "Bound, Jim" To: "Charlie Perkins" Cc: "Jari Arkko" , X-OriginalArrivalTime: 10 May 2003 13:20:00.0321 (UTC) FILETIME=[DBE0BB10:01C316F6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4ADLRhs005058 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, I will just say I do not support this exception for mobile nodes. I say figure it out and get LLs right. /jim > -----Original Message----- > From: Charlie Perkins [mailto:charliep@IPRG.nokia.com] > Sent: Wednesday, May 07, 2003 10:07 AM > To: Bound, Jim > Cc: Jari Arkko; ipng@sunroof.eng.sun.com > Subject: Re: Avoiding interface failure upon DAD failure > > > > Hello Jim, > > Bound, Jim wrote: > > >Hi Jarko, > > > >My input is that if LLs do not pass DaD then something is > very broken. > > > If DAD fails for the link-local address, then it means that the > link-local address > cannot be used. That is what is broken. It doesn't mean the > interface is broken, which is what would be solved by making > it fail. That is especially true in this case, because the > mobile device is likely to evidence that > the interface > was working correctly until it tried to connect to a new point of > attachment. > > Since that link-local address cannot be used, the device has > to try another one. Disallowing this is indeed too drastic, > because shutting the interface could cause major delays and > user inconvenience. I don't think anyone has noticed any > difficulties with just picking another link local address. > > >To do a work around this is not prudent in our standards > process when > >DaD breaks. In any interoperability test suite I know if > you fail DaD > >and don't do what our specs say you fail the test period. > > > Did anyone ever notice a problem with selecting a new > link-local address? Isn't this what happens if a device tries > to use a 3041 address which has a conflict? > > 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 Sat May 10 06:24:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4ADO9hs005097; Sat, 10 May 2003 06:24:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4ADO9n7005096; Sat, 10 May 2003 06:24:09 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4ADO5hs005088 for ; Sat, 10 May 2003 06:24:06 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4ADMkuc022135 for ; Sat, 10 May 2003 06:22:46 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4ADMfWs024705 for ; Sat, 10 May 2003 07:22:41 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id BC4311CB1; Sat, 10 May 2003 09:22:40 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 10 May 2003 09:22:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Avoiding interface failure upon DAD failure Date: Sat, 10 May 2003 09:22:40 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7F5@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Avoiding interface failure upon DAD failure Thread-Index: AcMU06bkfdM3S/l1SgOWjsa7EWhUeACI4ntw From: "Bound, Jim" To: "Jari Arkko" Cc: X-OriginalArrivalTime: 10 May 2003 13:22:40.0663 (UTC) FILETIME=[3B72FA70:01C316F7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4ADO6hs005089 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Good move sir. Or this will hold up MIPv6 yet again. /jim > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Wednesday, May 07, 2003 4:01 PM > To: Bound, Jim > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Avoiding interface failure upon DAD failure > > > Jim Bound wrote: > > > I do not think SEND needs to complete to move forward at all > > There was no intent to wait for SEND. It was only mentioned > for background. > > > Just fail on the interface per the specs and move forward > with the spec. > > This is what I will do, unless IPv6 WG supports the proposed text. > > --Jari > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 10 06:26:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4ADQ0hs005144; Sat, 10 May 2003 06:26:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4ADPxJx005143; Sat, 10 May 2003 06:25:59 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4ADPths005136 for ; Sat, 10 May 2003 06:25:55 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4ADOaKw029985 for ; Sat, 10 May 2003 06:24:36 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id HAA19624 for ; Sat, 10 May 2003 07:24:30 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 0810C1CD7; Sat, 10 May 2003 09:24:30 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 10 May 2003 09:24:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Avoiding interface failure upon DAD failure Date: Sat, 10 May 2003 09:24:29 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7F6@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Avoiding interface failure upon DAD failure Thread-Index: AcMVbPF1z78xEshmTfepbzdHQ96dOgBinEGg From: "Bound, Jim" To: "Francis Dupont" , "Bob Hinden" Cc: "Jari Arkko" , , "Erik Nordmark" X-OriginalArrivalTime: 10 May 2003 13:24:29.0850 (UTC) FILETIME=[7C8797A0:01C316F7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4ADPuhs005137 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk but the default is fail the interface from IETF standards perspective and Francis suggestion is good implementation deployment policy. This way MIPv6 move forward. /jim > -----Original Message----- > From: Francis Dupont [mailto:Francis.Dupont@enst-bretagne.fr] > Sent: Thursday, May 08, 2003 10:15 AM > To: Bob Hinden > Cc: Jari Arkko; ipng@sunroof.eng.sun.com; Erik Nordmark > Subject: Re: Avoiding interface failure upon DAD failure > > > In your previous mail you wrote: > > => in general I agree with you but I have a comment about a detail: > > ... In my view the cost of doing DAD is much higher than benefit. > > => my concern is the cost and the benefit can be for two > different persons, i.e., I have no objection about a "no-DAD" > policy if and only if the choice between this policy and the > standard one is in the hands of the network manager. > > Thanks > > Francis.Dupont@enst-bretagne.fr > > PS: DAD is not a toy: at least once it spared us a > disaster... If something really needs improvement in RFC > 2461/2462, it is more how to cleanup everything when a > router's sent some rogue RAs. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 10 06:27:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4ADRxhs005257; Sat, 10 May 2003 06:27:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4ADRxfZ005256; Sat, 10 May 2003 06:27:59 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4ADRrhs005237 for ; Sat, 10 May 2003 06:27:53 -0700 (PDT) Received: from brmea-mail-1.sun.com (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4ADQXuc022965 for ; Sat, 10 May 2003 06:26:33 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4ADQREL007274 for ; Sat, 10 May 2003 07:26:28 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 123A288C7; Sat, 10 May 2003 09:26:22 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sat, 10 May 2003 09:26:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Avoiding interface failure upon DAD failure Date: Sat, 10 May 2003 09:26:21 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7F7@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Avoiding interface failure upon DAD failure Thread-Index: AcMVeWal8AyILYo/RO+YmRR73NJqcQBfjQpw From: "Bound, Jim" To: "Charles E. Perkins" , "Jari Arkko" Cc: X-OriginalArrivalTime: 10 May 2003 13:26:21.0943 (UTC) FILETIME=[BF57A070:01C316F7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4ADRshs005238 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Charlie, You have it backwards. We don't support this you and others have to convince us to alter the base standard for mobile nodes and for me you have not done that please don't reverse the process here. This proposal is on the table for justfication not DAD. Regards, /jim > -----Original Message----- > From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > Sent: Thursday, May 08, 2003 11:37 AM > To: Jari Arkko > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Avoiding interface failure upon DAD failure > > > Hello Jari, > > Jari Arkko wrote: > > > My intention is to follow current 2462 to the > > letter. The only questions are whether I can > > use 3041-like link local addresses, and whether > > the goal (avoiding disabled link) is worthwhile. > > From the point of view of someone trying to use > these devices, yes it is very worthwhile to > avoid disabling the link unnecessarily. > > I strongly support keeping this functionality > unless someone can point out why it is harmful. > We should look at this matter from the point of > view of what is best for the users. > > Regards, > Charlie P. > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 10 06:52:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4ADqphs006049; Sat, 10 May 2003 06:52:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4ADqp7u006048; Sat, 10 May 2003 06:52:51 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4ADqmhs006041 for ; Sat, 10 May 2003 06:52:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4ADpTuc026681 for ; Sat, 10 May 2003 06:51:29 -0700 (PDT) Received: from bowl.fysh.org ([195.167.170.152]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4ADpNPH008762 for ; Sat, 10 May 2003 06:51:23 -0700 (PDT) Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 19EUkz-0001WR-00; Sat, 10 May 2003 14:51:21 +0100 Date: Sat, 10 May 2003 14:51:21 +0100 To: Christian Huitema Cc: Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Message-ID: <20030510135121.GA3918@fysh.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i From: Zefram Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian Huitema wrote: > But we could combine a unique IPv6 >prefix (e.g. FEC0::/16) and a 48 bit IEEE 802 number to build a unique >64 bit link prefix. This is a neat idea. It would be good to have this option available in addition to registered allocation and random self-allocation: these three allocation methods all have different trade-offs of uniqueness, immediacy, privacy, portability, and other factors, and we should leave it to the individual network administrator to decide what the right balance is for their own network. Mechanism, not policy. (In the same vein of diversity, consider also Tony Hain's draft on geographically-derived addresses.) A suggestion: it would be convenient, in some cases, to have a few bits available for a subnet ID. Scanarios in which there isn't a unique interface (with a unique EUI-48) for each subnet are obscure, but it's easier to imagine cases where there's only one EUI-48 that's *conveninent* to use. Also, note that the EUI-48 includes the scope and multicast bits, which will always be zero in this use, so we can compress the EUI-48 to a 46 bit field. I suggest having a 10-bit prefix, 46-bit compressed EUI-48 field, then 8 bits of subnet ID. The prefix can't be fec0::/10, because that has site-local scope semantics; it could perhaps be fe40::/10. -zefram -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 10 15:57:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4AMvWhs007825; Sat, 10 May 2003 15:57:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4AMvWJ2007824; Sat, 10 May 2003 15:57:32 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4AMvShs007817 for ; Sat, 10 May 2003 15:57:28 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4AMu9uc008265 for ; Sat, 10 May 2003 15:56:09 -0700 (PDT) Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4AMu3Ws026735 for ; Sat, 10 May 2003 16:56:04 -0600 (MDT) Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.6659); Sat, 10 May 2003 15:56:03 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 10 May 2003 15:56:02 -0700 Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 10 May 2003 15:56:02 -0700 Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 10 May 2003 15:56:02 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 10 May 2003 15:56:01 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Sat, 10 May 2003 15:56:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Sat, 10 May 2003 15:56:00 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMXC+upcrGLzTFFRMSOXL1n5oF6zQAOvLSN From: "Christian Huitema" To: "Zefram" Cc: "Bob Hinden" , X-OriginalArrivalTime: 10 May 2003 22:56:01.0288 (UTC) FILETIME=[53D1C880:01C31747] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4AMvThs007818 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A suggestion: it would be convenient, in some cases, to have a few bits > available for a subnet ID. Scanarios in which there isn't a unique > interface (with a unique EUI-48) for each subnet are obscure, but it's > easier to imagine cases where there's only one EUI-48 that's *conveninent* > to use. Also, note that the EUI-48 includes the scope and multicast bits, > which will always be zero in this use, so we can compress the EUI-48 to a > 46 bit field. I suggest having a 10-bit prefix, 46-bit compressed EUI-48 > field, then 8 bits of subnet ID. The prefix can't be fec0::/10, because > that has site-local scope semantics; it could perhaps be fe40::/10. Well, an alternative would be to use the U and G bit to indicate whether the 48 bit identifier is unique or picked at random. Allowing a "random number" as an escape patch would solve the case of "unnumbered links", those for which there is no handy number to use. -- 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 Sat May 10 21:24:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4B4OKhs008889; Sat, 10 May 2003 21:24:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4B4OKuj008888; Sat, 10 May 2003 21:24:20 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4B4OHhs008881 for ; Sat, 10 May 2003 21:24:17 -0700 (PDT) Received: from brmea-mail-1.sun.com (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4B4MvKw009988 for ; Sat, 10 May 2003 21:22:57 -0700 (PDT) Received: from kahuna.telstra.net (kahuna.telstra.net [203.50.0.6]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4B4MpAk020147 for ; Sat, 10 May 2003 22:22:52 -0600 (MDT) Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h4B4MCMK007652; Sun, 11 May 2003 14:22:21 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20030511141038.0189ee88@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 11 May 2003 14:21:59 +1000 To: ipng@sunroof.eng.sun.com From: Geoff Huston Subject: Draft on a V6 documentation prefix In-Reply-To: <20030510135121.GA3918@fysh.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I've checked with one of the WG chairs, and I'd like to give the working group a headsup to the draft http://www.ietf.org/internet-drafts/draft-huston-ipv6-documentation-prefix-00.txt In publishing this as an individual submission the authors were not explicitly intending that this document be adopted by the WG as a WG document, but any review and comment by WG members would be most helpful, of course. The draft documents an action taken within the APNIC community in late 2002, where the IPv6 prefix 2001:0DB8::/32 has been set aside for use in documentation examples, and in the IANA Considerations section the draft describes an IANA action to include this prefix in the IPv6 address registry as a reserved use prefix for documentation purposes. The draft has been in the Internet Drafts repository since Feb 16 and has elicited no editorial comments to date. (An earlier draft proposing the reservation of an IPv6 documentation was prepared by Mark Blanchett some years back in the context of the IPv6 working group, as I understand, but the draft has expired and no further action was taken with it and no address space reservation was made at the time.) regards, Geoff -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 11 02:03:40 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4B93dhs009544; Sun, 11 May 2003 02:03:40 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4B93dh7009543; Sun, 11 May 2003 02:03:39 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4B93ahs009536 for ; Sun, 11 May 2003 02:03:36 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4B92FKw021557 for ; Sun, 11 May 2003 02:02:16 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4B92AWs008227 for ; Sun, 11 May 2003 03:02:10 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id B68A1A832; Sun, 11 May 2003 05:02:09 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Sun, 11 May 2003 05:02:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Sun, 11 May 2003 05:02:08 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03411939@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMV9QHYWUgah6xHSIm06TX6h4IsQQBYSaDQ From: "Bound, Jim" To: "Bob Hinden" Cc: X-OriginalArrivalTime: 11 May 2003 09:02:09.0648 (UTC) FILETIME=[010D1F00:01C3179C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4B93ahs009537 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, This is an excellent idea and it will work. I hear others risk issues I believe the risk is worth it and I also believe this is very implementable expediently. What is so elegant about this proposal is that it completely eliminates the need for an implemented scoping architercture within products today until those of us who build and ship stacks in the market have more experience with the scoping architecture of IPv6 in the OS networking subsystem kernels within the vendor and open source community. This is a compromise I will support here and in the non IETF forums where we don't do standards but real deployment. Thank You for your leadership and those you acknowledged in the spec for their contributions. Regards, /jim -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 11 04:30:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BBU2hs010038; Sun, 11 May 2003 04:30:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4BBU1E3010037; Sun, 11 May 2003 04:30:01 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BBTwhs010030 for ; Sun, 11 May 2003 04:29:58 -0700 (PDT) Received: from brmea-mail-1.sun.com (lukla.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4BBSbuc028380 for ; Sun, 11 May 2003 04:28:37 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4BBSVAk008893 for ; Sun, 11 May 2003 05:28:31 -0600 (MDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Ep0I-00042Y-00; Sun, 11 May 2003 12:28:30 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Ep0I-00042T-00; Sun, 11 May 2003 12:28:30 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA139600; Sun, 11 May 2003 12:28:24 +0100 Message-ID: <3EBE2D9D.EAC8FC54@hursley.ibm.com> Date: Sun, 11 May 2003 13:01:49 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Michel Py CC: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <963621801C6D3E4A9CF454A1972AE8F504F7DC@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: ... > >> 2. We can't enforce operators to filter the prefix. I > >> dropped filters on my BGP feeds and from one of my peers > >> (a well-known player) I get all kinds of crud including > >> /64 routes, /48 routes, /41 routes, name it I get it. > > > I think there will be Darwinian effects here, as we saw > > during the first years of CIDR. But yes, if someone pays > > enough, they will get their /64 announced. That will happen > > whatever we write in RFCs. > > My point exactly. We can't rely on this alone. Now explain why it's a problem, if the customers pay enough to cover the costs. 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 May 11 04:30:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BBUFhs010048; Sun, 11 May 2003 04:30:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4BBUFmE010047; Sun, 11 May 2003 04:30:15 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BBU9hs010040 for ; Sun, 11 May 2003 04:30:09 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4BBSmuc028399 for ; Sun, 11 May 2003 04:28:48 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4BBShPH004987 for ; Sun, 11 May 2003 04:28:43 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Ep0U-00043L-00; Sun, 11 May 2003 12:28:42 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Ep0U-00043G-00; Sun, 11 May 2003 12:28:42 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA154966; Sun, 11 May 2003 12:28:36 +0100 Message-ID: <3EBE2DEA.2FF0E63F@hursley.ibm.com> Date: Sun, 11 May 2003 13:03:06 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Michel Py CC: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <963621801C6D3E4A9CF454A1972AE8F504F7DC@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: > > Brian, > > >> Michel Py wrote: > >> 1. We can't enforce router vendors to code the default > >> blackholes. Before moving ahead with this I would like > >> to hear clear signs from the players in the field that > >> they would support it. > > > Brian E Carpenter wrote: > > Why is this different from FEC0::/10? > > It has nothing to do with the prefix itself but with the scope. Of course. And why is the scope issue different, just because we have removed the ambiguity? 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 May 11 04:30:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BBUfhs010080; Sun, 11 May 2003 04:30:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4BBUfA9010079; Sun, 11 May 2003 04:30:41 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BBUXhs010066 for ; Sun, 11 May 2003 04:30:33 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4BBTCKw006094 for ; Sun, 11 May 2003 04:29:12 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id FAA17287 for ; Sun, 11 May 2003 05:29:05 -0600 (MDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Ep0m-000449-00; Sun, 11 May 2003 12:29:00 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Ep0l-000444-00; Sun, 11 May 2003 12:28:59 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA139606; Sun, 11 May 2003 12:28:49 +0100 Message-ID: <3EBE2E5A.B1A9A56B@hursley.ibm.com> Date: Sun, 11 May 2003 13:04:58 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Zefram CC: Christian Huitema , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <20030510135121.GA3918@fysh.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We need site prefixes, not link prefixes, even for SOHO networks. Brian Zefram wrote: > > Christian Huitema wrote: > > But we could combine a unique IPv6 > >prefix (e.g. FEC0::/16) and a 48 bit IEEE 802 number to build a unique > >64 bit link prefix. > > This is a neat idea. It would be good to have this option available in > addition to registered allocation and random self-allocation: these three > allocation methods all have different trade-offs of uniqueness, immediacy, > privacy, portability, and other factors, and we should leave it to the > individual network administrator to decide what the right balance is > for their own network. Mechanism, not policy. (In the same vein of > diversity, consider also Tony Hain's draft on geographically-derived > addresses.) > > A suggestion: it would be convenient, in some cases, to have a few bits > available for a subnet ID. Scanarios in which there isn't a unique > interface (with a unique EUI-48) for each subnet are obscure, but it's > easier to imagine cases where there's only one EUI-48 that's *conveninent* > to use. Also, note that the EUI-48 includes the scope and multicast bits, > which will always be zero in this use, so we can compress the EUI-48 to a > 46 bit field. I suggest having a 10-bit prefix, 46-bit compressed EUI-48 > field, then 8 bits of subnet ID. The prefix can't be fec0::/10, because > that has site-local scope semantics; it could perhaps be fe40::/10. > > -zefram -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 11 04:31:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BBV0hs010097; Sun, 11 May 2003 04:31:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4BBUxoq010096; Sun, 11 May 2003 04:30:59 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BBUqhs010082 for ; Sun, 11 May 2003 04:30:52 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4BBTUuc028480 for ; Sun, 11 May 2003 04:29:30 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4BBTOWs009732 for ; Sun, 11 May 2003 05:29:25 -0600 (MDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Ep1A-00045K-00; Sun, 11 May 2003 12:29:24 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19Ep19-00045F-00; Sun, 11 May 2003 12:29:23 +0100 Received: from hursley.ibm.com (gsine05.us.sine.ibm.com [9.14.6.45]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id MAA139620; Sun, 11 May 2003 12:29:17 +0100 Message-ID: <3EBE31D8.31FC8DDF@hursley.ibm.com> Date: Sun, 11 May 2003 13:19:52 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Geoff Huston CC: ipng@sunroof.eng.sun.com Subject: Re: Draft on a V6 documentation prefix References: <5.1.0.14.2.20030511141038.0189ee88@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Since you ask: I read this when it came out and thought "good." Ship it, imho. Brian Geoff Huston wrote: > > I've checked with one of the WG chairs, and I'd like to give the > working group a headsup to the draft > http://www.ietf.org/internet-drafts/draft-huston-ipv6-documentation-prefix-00.txt > > In publishing this as an individual submission the authors were not explicitly > intending that this document be adopted by the WG as a WG document, but > any review and comment by WG members would be most helpful, of course. > > The draft documents an action taken within the APNIC community in late 2002, > where the IPv6 prefix 2001:0DB8::/32 has been set aside for use in > documentation > examples, and in the IANA Considerations section the draft describes an > IANA action > to include this prefix in the IPv6 address registry as a reserved use > prefix for > documentation purposes. > > The draft has been in the Internet Drafts repository since Feb 16 and has > elicited no > editorial comments to date. > > (An earlier draft proposing the reservation of an IPv6 documentation was > prepared > by Mark Blanchett some years back in the context of the IPv6 working group, > as I > understand, but the draft has expired and no further action was taken with > it and > no address space reservation was made at the time.) > > regards, > > Geoff -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 11 05:49:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BCnjhs011069; Sun, 11 May 2003 05:49:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4BCnjjE011068; Sun, 11 May 2003 05:49:45 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BCnfhs011061 for ; Sun, 11 May 2003 05:49:41 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4BCmKKw017600 for ; Sun, 11 May 2003 05:48:20 -0700 (PDT) Received: from purgatory.unfix.org (cust.92.136.adsl.cistron.nl [195.64.92.136]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA10714 for ; Sun, 11 May 2003 06:48:14 -0600 (MDT) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 93493812B; Sun, 11 May 2003 14:48:10 +0200 (CEST) From: "Jeroen Massar" To: "'Brian E Carpenter'" , "'Geoff Huston'" Cc: Subject: RE: Draft on a V6 documentation prefix Date: Sun, 11 May 2003 14:48:10 +0200 Organization: Unfix Message-ID: <002201c317bb$94e1b910$210d640a@unfix.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: <3EBE31D8.31FC8DDF@hursley.ibm.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4BCnfhs011062 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > Since you ask: I read this when it came out and thought "good." > Ship it, imho. > > Brian > > Geoff Huston wrote: > > > > I've checked with one of the WG chairs, and I'd like to give the > > working group a headsup to the draft > > > http://www.ietf.org/internet-drafts/draft-huston-ipv6-documentation-pref ix-00.txt I try to use it as much as possible already. Though still IMHO it would have been a bit 'nicer' if it where 2001:d0c::/32, but this one works too. One thing that could be consider is how to document examples between 2 TLA's. Ofcourse one can use something in the lines of: "We will setup a BGP peering between ISPA who is allocated 2001:db8::/35 and ISPB who is allocated 2001:dba::/35." There will always be a case I think where one needs multiple prefixes for explainations and examples like these. Like Brian says: ship it. Delays are only irritating, like with the ip6.int->ip6.arpa transfer of 6bone :( BTW, is TLA still the good 'wording' for the prefixes allocated by the RIRs? 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 Sun May 11 06:46:03 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BDk3hs011403; Sun, 11 May 2003 06:46:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4BDk3j4011402; Sun, 11 May 2003 06:46:03 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BDk0hs011395 for ; Sun, 11 May 2003 06:46:00 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4BDidKw000306 for ; Sun, 11 May 2003 06:44:39 -0700 (PDT) Received: from kahuna.telstra.net (kahuna.telstra.net [203.50.0.6]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id GAA08190 for ; Sun, 11 May 2003 06:44:32 -0700 (PDT) Received: from gih505.telstra.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id h4BDhvMK012546; Sun, 11 May 2003 23:44:13 +1000 (EST) (envelope-from gih@telstra.net) Message-Id: <5.1.0.14.2.20030511233542.00b381c8@localhost> X-Sender: gih@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 11 May 2003 23:43:32 +1000 To: "Jeroen Massar" , "'Brian E Carpenter'" From: Geoff Huston Subject: RE: Draft on a V6 documentation prefix Cc: In-Reply-To: <002201c317bb$94e1b910$210d640a@unfix.org> References: <3EBE31D8.31FC8DDF@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > >I try to use it as much as possible already. >Though still IMHO it would have been a bit 'nicer' if it >where 2001:d0c::/32, but this one works too. I had thought of 2001:D0C0/32 , but I was too late with this suggestion as well! >One thing that could be consider is how to document >examples between 2 TLA's. Its a good point, but of course where you can think of a documentation example involving 2, you can think of an example involving 3 and so on. >Ofcourse one can use something >in the lines of: >"We will setup a BGP peering between ISPA who is allocated 2001:db8::/35 >and ISPB who is allocated 2001:dba::/35." >There will always be a case I think where one needs multiple >prefixes for explainations and examples like these. As you suggest, rewriting the example of multiple entities with slightly longer prefixes is a reasonable compromise in this case. Explicitly documenting this approach is a useful addition to the document and I will put it to my coauthors for consideration in a revision of the draft. Thank you for the suggestion. >Like Brian says: ship it. thanks! >Delays are only irritating, like with the ip6.int->ip6.arpa transfer of >6bone :( > >BTW, is TLA still the good 'wording' for the prefixes allocated by the >RIRs? My understanding is 'yes', but if not, then would someone closer to the currently correct terminology lexicon please correct me. regards, Geoff -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 11 08:35:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BFZrhs011781; Sun, 11 May 2003 08:35:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4BFZrhu011780; Sun, 11 May 2003 08:35:53 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BFZnhs011773 for ; Sun, 11 May 2003 08:35:50 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4BFYSKw015219 for ; Sun, 11 May 2003 08:34:28 -0700 (PDT) Received: from bowl.fysh.org ([195.167.170.152]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id IAA09873 for ; Sun, 11 May 2003 08:34:22 -0700 (PDT) Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 19EsqD-00048W-00; Sun, 11 May 2003 16:34:21 +0100 Date: Sun, 11 May 2003 16:34:21 +0100 To: Geoff Huston Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft on a V6 documentation prefix Message-ID: <20030511153421.GA8716@fysh.org> References: <5.1.0.14.2.20030511141038.0189ee88@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20030511141038.0189ee88@localhost> User-Agent: Mutt/1.3.28i From: Zefram Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Geoff Huston wrote: >The draft documents an action taken within the APNIC community in late 2002, >where the IPv6 prefix 2001:0DB8::/32 has been set aside for use in >documentation It's good to have such a prefix, but I wonder about the best place to put it. How permanent are the sub-TLA assignments under 2001::/16? It would be unfortunate to end punching a hole in an address block that might later be reassigned. Would assignment of a /16, perhaps 2d0c::/16, be too wasteful? -zefram -- Andrew Main (Zefram) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 11 16:47:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BNlahs012839; Sun, 11 May 2003 16:47:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4BNlaRJ012838; Sun, 11 May 2003 16:47:36 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4BNlXhs012831 for ; Sun, 11 May 2003 16:47:33 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4BNkBuc015543 for ; Sun, 11 May 2003 16:46:11 -0700 (PDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4BNk5Ws018062 for ; Sun, 11 May 2003 17:46:06 -0600 (MDT) Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Sun, 11 May 2003 16:46:05 -0700 Received: from 157.54.8.155 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 11 May 2003 16:46:05 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Sun, 11 May 2003 16:46:04 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 11 May 2003 16:46:04 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Sun, 11 May 2003 16:46:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Sun, 11 May 2003 16:46:02 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMXsIWaNQUnzpSQRaq59rS41+aJawAZhcjI From: "Christian Huitema" To: "Brian E Carpenter" , "Zefram" Cc: "Bob Hinden" , X-OriginalArrivalTime: 11 May 2003 23:46:03.0977 (UTC) FILETIME=[7BF98390:01C31817] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4BNlXhs012832 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > We need site prefixes, not link prefixes, even for SOHO networks. Are you actually sure of that? Every solution implies a trade-off. Automatic link prefixes are at one end of the trade-off; configured "site" prefixes at the other end. If you want isolation of some classes of addresses, you can achieve that with a firewall, and effectively block reachability of links outside your site. So, why not let two flowers bloom? Besides, what is a site? -- 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 Sun May 11 18:05:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4C15Lhs013314; Sun, 11 May 2003 18:05:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4C15LwP013313; Sun, 11 May 2003 18:05:21 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4C15Ghs013306 for ; Sun, 11 May 2003 18:05:16 -0700 (PDT) Received: from brmea-mail-1.sun.com (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4C13tKw010261 for ; Sun, 11 May 2003 18:03:55 -0700 (PDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4C13nAk015919 for ; Sun, 11 May 2003 19:03:50 -0600 (MDT) Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate2.mot.com (Motorola/Motgate2) with ESMTP id h4C13n9e022148 for ; Sun, 11 May 2003 18:03:49 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h4C13inb012961 for ; Sun, 11 May 2003 20:03:46 -0500 Received: from motorola.com (aewhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h4C13hVI017097 for ; Mon, 12 May 2003 11:03:43 +1000 (EST) Message-ID: <3EBEF2EF.1D4856DF@motorola.com> Date: Mon, 12 May 2003 11:03:43 +1000 From: Andrew White Reply-To: awhite@arc.corp.mot.com Organization: Motorola Australia Research Centre X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <20030510135121.GA3918@fysh.org> <3EBE2E5A.B1A9A56B@hursley.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian E Carpenter wrote: > > We need site prefixes, not link prefixes, even for SOHO networks. I disagree. You need a 'site prefix' if you intend to centrally number each link in the 'site', presumably with a number that can be used interchangably with a local /48 or a global /48. The other alternative is to let each link number itself, as described in draft-hinden-ipv6-global-site-local-00.txt draft-white-auto-subnet-00.txt (two variants of the same idea) By bootstrapping off the theoretically unique EUI48 we can give each link an unique prefix without any centralised intervention. The resulting addresses are not aggregable and thus not suitable for global routing, but are fine for a network of up to a few hundred links. A certain amount of cooperation is required between the DNS and hosts to set DNS up, but this is not necessarily an insurmountable problem. -- Andrew White -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 11 18:13:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4C1Dnhs013509; Sun, 11 May 2003 18:13:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4C1Dm9E013508; Sun, 11 May 2003 18:13:48 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4C1Djhs013501 for ; Sun, 11 May 2003 18:13:45 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4C1COuc026699 for ; Sun, 11 May 2003 18:12:24 -0700 (PDT) Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA03275 for ; Sun, 11 May 2003 18:12:18 -0700 (PDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KVSVV0QY949B0WCC@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Mon, 12 May 2003 11:10:24 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id EC95412C004; Mon, 12 May 2003 11:10:23 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id D954F12C003; Mon, 12 May 2003 11:10:23 +1000 (EST) Date: Mon, 12 May 2003 12:10:09 +1000 From: Greg Daley Subject: Re: Avoiding interface failure upon DAD failure To: "Bound, Jim" Cc: "Charles E. Perkins" , Jari Arkko , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EBF0281.9010007@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7F7@tayexc13.americas.cpqcorp.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, At this stage, I agree that MIPv6 should not wait for this issue. Link-Local collision is a relatively low probability, and diagnostics on the mobile device will be able to identify the issue. That said, I think that the current rfc2462 text is unnecessarily restrictive in this regard and doesn't cope with a legitimate application (IP mobility) appropriately (no offense intended to the authors, since otherwise I think it does a good job on DAD). Certainly, there should be follow-up both to clean up DAD, and later to specify the correct behaviour in a new draft in mobileip-wg. Greg Daley Bound, Jim wrote: > Charlie, > > You have it backwards. We don't support this you and others have to > convince us to alter the base standard for mobile nodes and for me you > have not done that please don't reverse the process here. This proposal > is on the table for justfication not DAD. > > Regards, > /jim > > >>-----Original Message----- >>From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >>Sent: Thursday, May 08, 2003 11:37 AM >>To: Jari Arkko >>Cc: ipng@sunroof.eng.sun.com >>Subject: Re: Avoiding interface failure upon DAD failure >> >> >>Hello Jari, >> >>Jari Arkko wrote: >> >> >>>My intention is to follow current 2462 to the >>>letter. The only questions are whether I can >>>use 3041-like link local addresses, and whether >>>the goal (avoiding disabled link) is worthwhile. >> >>From the point of view of someone trying to use >>these devices, yes it is very worthwhile to >>avoid disabling the link unnecessarily. >> >>I strongly support keeping this functionality >>unless someone can point out why it is harmful. >>We should look at this matter from the point of >>view of what is best for the users. >> >>Regards, >>Charlie P. >>-------------------------------------------------------------------- >>IETF IPng Working Group Mailing List >>IPng Home Page: http://playground.sun.com/ipng >>FTP archive: ftp://playground.sun.com/pub/ipng >>Direct all administrative requests to majordomo@sunroof.eng.sun.com >>-------------------------------------------------------------------- >> > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 11 21:58:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4C4wThs014580; Sun, 11 May 2003 21:58:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4C4wSPi014579; Sun, 11 May 2003 21:58:28 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4C4wOhs014572 for ; Sun, 11 May 2003 21:58:24 -0700 (PDT) Received: from kathmandu.sun.com (kathmandu.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4C4v3uc027990 for ; Sun, 11 May 2003 21:57:03 -0700 (PDT) Received: from ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by kathmandu.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id WAA22029 for ; Sun, 11 May 2003 22:56:56 -0600 (MDT) Received: from yhhan (localhost [127.0.0.1]) by ns.sait.samsung.co.kr (8.12.8/8.12.1) with SMTP id h4C4ui3X000879; Mon, 12 May 2003 13:56:45 +0900 (KST) Message-ID: <013a01c31842$d59bede0$3d2f024b@yhhan> From: "Youn-Hee Han" To: Cc: References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7F7@tayexc13.americas.cpqcorp.net> <3EBF0281.9010007@eng.monash.edu.au> Subject: Re: Avoiding interface failure upon DAD failure Date: Mon, 12 May 2003 13:51:14 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 x-mimeole: Produced By Microsoft MimeOLE V5.50.4807.1700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id h4C4wOhs014573 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greg Daley wrote: > That said, I think that the current rfc2462 text is > unnecessarily restrictive in this regard and doesn't > cope with a legitimate application (IP mobility) > appropriately (no offense intended to the authors, > since otherwise I think it does a good job on DAD). I agree with you. It is so restrictive that one DAD failure disables its interface. However, we should consider some suffering problems. If a node uses EUI-64 address as its IID, DAD failure implies IEEE 802 address collision in almost cases. In this case, another IID generation is useless becasue the communication is not allowed by lower layer. (This is already mentioned by Bob in this discussion) Although nodes are attached at IEEE 802 links, however , we can not assure that they all use EUI-64 address as thier IID. Some nodes can ganerate random IID. So, DAD failure does not always implies IEEE 802 address collision. If a node can detect whether the IID generation is useless, the problem can be clearly resloved. In my knowledge, however, it is not possible. > Certainly, there should be follow-up both to clean up > DAD, and later to specify the correct behaviour in > a new draft in mobileip-wg. As well as the correct behaviour, we can also specify several DAD Optimization in a new draft. (e.g., oDAD) YH ----- Original Message ----- From: "Greg Daley" To: "Bound, Jim" Cc: "Charles E. Perkins" ; "Jari Arkko" ; Sent: Monday, May 12, 2003 11:10 AM Subject: Re: Avoiding interface failure upon DAD failure > Hi Jim, > > At this stage, I agree that MIPv6 should not > wait for this issue. > > Link-Local collision is a relatively low probability, > and diagnostics on the mobile device will be able to > identify the issue. > > That said, I think that the current rfc2462 text is > unnecessarily restrictive in this regard and doesn't > cope with a legitimate application (IP mobility) > appropriately (no offense intended to the authors, > since otherwise I think it does a good job on DAD). > > Certainly, there should be follow-up both to clean up > DAD, and later to specify the correct behaviour in > a new draft in mobileip-wg. > > Greg Daley > > Bound, Jim wrote: > > Charlie, > > > > You have it backwards. We don't support this you and others have to > > convince us to alter the base standard for mobile nodes and for me you > > have not done that please don't reverse the process here. This proposal > > is on the table for justfication not DAD. > > > > Regards, > > /jim > > > > > >>-----Original Message----- > >>From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > >>Sent: Thursday, May 08, 2003 11:37 AM > >>To: Jari Arkko > >>Cc: ipng@sunroof.eng.sun.com > >>Subject: Re: Avoiding interface failure upon DAD failure > >> > >> > >>Hello Jari, > >> > >>Jari Arkko wrote: > >> > >> > >>>My intention is to follow current 2462 to the > >>>letter. The only questions are whether I can > >>>use 3041-like link local addresses, and whether > >>>the goal (avoiding disabled link) is worthwhile. > >> > >>From the point of view of someone trying to use > >>these devices, yes it is very worthwhile to > >>avoid disabling the link unnecessarily. > >> > >>I strongly support keeping this functionality > >>unless someone can point out why it is harmful. > >>We should look at this matter from the point of > >>view of what is best for the users. > >> > >>Regards, > >>Charlie P. > >>-------------------------------------------------------------------- > >>IETF IPng Working Group Mailing List > >>IPng Home Page: http://playground.sun.com/ipng > >>FTP archive: ftp://playground.sun.com/pub/ipng > >>Direct all administrative requests to majordomo@sunroof.eng.sun.com > >>-------------------------------------------------------------------- > >> > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 11 23:39:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4C6d2hs015284; Sun, 11 May 2003 23:39:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4C6d127015283; Sun, 11 May 2003 23:39:01 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4C6cwhs015276 for ; Sun, 11 May 2003 23:38:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4C6bbKw005385 for ; Sun, 11 May 2003 23:37:37 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id XAA04877 for ; Sun, 11 May 2003 23:37:31 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19F6wE-0003a9-00; Mon, 12 May 2003 07:37:30 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19F6wE-0003Zz-00; Mon, 12 May 2003 07:37:30 +0100 Received: from hursley.ibm.com (gsine08.us.sine.ibm.com [9.14.6.48]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id HAA180574; Mon, 12 May 2003 07:37:25 +0100 Message-ID: <3EBF4135.D3C90239@hursley.ibm.com> Date: Mon, 12 May 2003 08:37:41 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: awhite@arc.corp.mot.com CC: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <20030510135121.GA3918@fysh.org> <3EBE2E5A.B1A9A56B@hursley.ibm.com> <3EBEF2EF.1D4856DF@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk In response to both you and Christian, I think the arguments why we need /48s, and can afford to give them, are in RFC 3177. That doesn't exclude /64 in some cases, but as a general solution, we should assume the need for subnets and not assume automatic subnet numbering. Brian Andrew White wrote: > > Brian E Carpenter wrote: > > > > We need site prefixes, not link prefixes, even for SOHO networks. > > I disagree. You need a 'site prefix' if you intend to centrally number each > link in the 'site', presumably with a number that can be used interchangably > with a local /48 or a global /48. > > The other alternative is to let each link number itself, as described in > draft-hinden-ipv6-global-site-local-00.txt > draft-white-auto-subnet-00.txt > (two variants of the same idea) > > By bootstrapping off the theoretically unique EUI48 we can give each link an > unique prefix without any centralised intervention. The resulting addresses > are not aggregable and thus not suitable for global routing, but are fine > for a network of up to a few hundred links. > > A certain amount of cooperation is required between the DNS and hosts to set > DNS up, but this is not necessarily an insurmountable problem. > > -- > Andrew White -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 12 00:04:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4C74whs015705; Mon, 12 May 2003 00:04:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4C74v1V015704; Mon, 12 May 2003 00:04:57 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4C74shs015697 for ; Mon, 12 May 2003 00:04:54 -0700 (PDT) Received: from brmea-mail-1.sun.com (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4C73WKw009540 for ; Mon, 12 May 2003 00:03:33 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4C73QAk009421 for ; Mon, 12 May 2003 01:03:27 -0600 (MDT) Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA16258 for ; Mon, 12 May 2003 08:03:25 +0100 (BST) Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id IAA01977 for ; Mon, 12 May 2003 08:03:25 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h4C73Pa32296 for ipng@sunroof.eng.sun.com; Mon, 12 May 2003 08:03:25 +0100 Date: Mon, 12 May 2003 08:03:25 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Message-ID: <20030512070325.GD6809@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <20030510135121.GA3918@fysh.org> <3EBE2E5A.B1A9A56B@hursley.ibm.com> <3EBEF2EF.1D4856DF@motorola.com> <3EBF4135.D3C90239@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EBF4135.D3C90239@hursley.ibm.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Could both schemes (auto /64 and site /48) not progress as alternatives for deployment? What is on the table for site prefix allocation as that alternative to the white/hinden /64 proposals? I recall that older Solaris versions used to allocate interface MAC addresses per host rather than per interface (maybe they were looked up from some system storage rather than the interface itself), so we would need to be confident of not repeating such problems (where the clashes are in the routing device). How prevalent is this? (Of course, old Solaris versions have no IPv6 but the question is which OS's may do likewise in the future where that OS may be used as a routing platform, as Solaris often is, e.g. for firewalls) Tim On Mon, May 12, 2003 at 08:37:41AM +0200, Brian E Carpenter wrote: > In response to both you and Christian, I think the arguments why > we need /48s, and can afford to give them, are in RFC 3177. > > That doesn't exclude /64 in some cases, but as a general solution, > we should assume the need for subnets and not assume automatic subnet > numbering. > > Brian > > Andrew White wrote: > > > > Brian E Carpenter wrote: > > > > > > We need site prefixes, not link prefixes, even for SOHO networks. > > > > I disagree. You need a 'site prefix' if you intend to centrally number each > > link in the 'site', presumably with a number that can be used interchangably > > with a local /48 or a global /48. > > > > The other alternative is to let each link number itself, as described in > > draft-hinden-ipv6-global-site-local-00.txt > > draft-white-auto-subnet-00.txt > > (two variants of the same idea) > > > > By bootstrapping off the theoretically unique EUI48 we can give each link an > > unique prefix without any centralised intervention. The resulting addresses > > are not aggregable and thus not suitable for global routing, but are fine > > for a network of up to a few hundred links. > > > > A certain amount of cooperation is required between the DNS and hosts to set > > DNS up, but this is not necessarily an insurmountable problem. > > > > -- > > Andrew White > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 12 02:05:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4C955hs016844; Mon, 12 May 2003 02:05:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4C955wo016843; Mon, 12 May 2003 02:05:05 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4C951hs016835 for ; Mon, 12 May 2003 02:05:02 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4C93duc018475 for ; Mon, 12 May 2003 02:03:39 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4C93XWs002731 for ; Mon, 12 May 2003 03:03:34 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 44BA07C87; Mon, 12 May 2003 05:03:33 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Mon, 12 May 2003 05:03:33 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Avoiding interface failure upon DAD failure Date: Mon, 12 May 2003 05:03:32 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD830@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Avoiding interface failure upon DAD failure Thread-Index: AcMYQ6ThOpxT8pGMRA60XSbbZ53RBAAIVT/w From: "Bound, Jim" To: "Youn-Hee Han" , Cc: X-OriginalArrivalTime: 12 May 2003 09:03:33.0125 (UTC) FILETIME=[5D387350:01C31865] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4C952hs016836 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Greg and Youn-Hee, It is restrictive yes. But to relax that is fine if well thought out and discussed. But I think it important to understand why the nature of the restriction is to much and it what cases. As Youn-Hee pointed predicting IEEE 802 IID failures is a challenge. Also one does not have to use IEEE 802 for IID as a note. It could be CPU ID, etc. But discussion of when its ok to keep moving the failure mode is prudent for us to truly understand in the IETF. /jim > -----Original Message----- > From: Youn-Hee Han [mailto:yhhan@sait.samsung.co.kr] > Sent: Monday, May 12, 2003 12:51 AM > To: greg.daley@eng.monash.edu.au > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Avoiding interface failure upon DAD failure > > > Greg Daley wrote: > > > That said, I think that the current rfc2462 text is unnecessarily > > restrictive in this regard and doesn't cope with a legitimate > > application (IP mobility) appropriately (no offense > intended to the > > authors, since otherwise I think it does a good job on DAD). > > I agree with you. It is so restrictive that one DAD failure > disables its interface. However, we should consider > some suffering problems. > > If a node uses EUI-64 address as its IID, DAD failure > implies IEEE 802 address collision in almost cases. > In this case, another IID generation is useless > becasue the communication is not allowed by lower layer. > (This is already mentioned by Bob in this discussion) > > Although nodes are attached at IEEE 802 links, however > , we can not assure that they all use EUI-64 address as thier > IID. Some nodes can ganerate random IID. So, DAD failure > does not always implies IEEE 802 address collision. > > If a node can detect whether the IID generation is useless, > the problem can be clearly resloved. > In my knowledge, however, it is not possible. > > > Certainly, there should be follow-up both to clean up > > DAD, and later to specify the correct behaviour in > > a new draft in mobileip-wg. > > As well as the correct behaviour, we can also specify > several DAD Optimization in a new draft. (e.g., oDAD) > > YH > > > ----- Original Message ----- > From: "Greg Daley" > To: "Bound, Jim" > Cc: "Charles E. Perkins" ; "Jari > Arkko" ; > Sent: Monday, May 12, 2003 11:10 AM > Subject: Re: Avoiding interface failure upon DAD failure > > > > Hi Jim, > > > > At this stage, I agree that MIPv6 should not > > wait for this issue. > > > > Link-Local collision is a relatively low probability, > > and diagnostics on the mobile device will be able to > > identify the issue. > > > > That said, I think that the current rfc2462 text is unnecessarily > > restrictive in this regard and doesn't cope with a legitimate > > application (IP mobility) appropriately (no offense > intended to the > > authors, since otherwise I think it does a good job on DAD). > > > > Certainly, there should be follow-up both to clean up > > DAD, and later to specify the correct behaviour in > > a new draft in mobileip-wg. > > > > Greg Daley > > > > Bound, Jim wrote: > > > Charlie, > > > > > > You have it backwards. We don't support this you and > others have to > > > convince us to alter the base standard for mobile nodes > and for me > > > you have not done that please don't reverse the process > here. This > > > proposal is on the table for justfication not DAD. > > > > > > Regards, > > > /jim > > > > > > > > >>-----Original Message----- > > >>From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] > > >>Sent: Thursday, May 08, 2003 11:37 AM > > >>To: Jari Arkko > > >>Cc: ipng@sunroof.eng.sun.com > > >>Subject: Re: Avoiding interface failure upon DAD failure > > >> > > >> > > >>Hello Jari, > > >> > > >>Jari Arkko wrote: > > >> > > >> > > >>>My intention is to follow current 2462 to the > > >>>letter. The only questions are whether I can > > >>>use 3041-like link local addresses, and whether > > >>>the goal (avoiding disabled link) is worthwhile. > > >> > > >>From the point of view of someone trying to use > > >>these devices, yes it is very worthwhile to > > >>avoid disabling the link unnecessarily. > > >> > > >>I strongly support keeping this functionality > > >>unless someone can point out why it is harmful. > > >>We should look at this matter from the point of > > >>view of what is best for the users. > > >> > > >>Regards, > > >>Charlie P. > > > >>-------------------------------------------------------------------- > > >>IETF IPng Working Group Mailing List > > >>IPng Home Page: > http://playground.sun.com/ipng > > >>FTP archive: > ftp://playground.sun.com/pub/ipng > > >>Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > >>-------------------------------------------------------------------- > > >> > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPng Working Group Mailing List > > > IPng Home Page: > http://playground.sun.com/ipng > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > Direct all administrative requests to > majordomo@sunroof.eng.sun.com > > > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 12 08:04:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CF4Qhs019596; Mon, 12 May 2003 08:04:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4CF4QEa019595; Mon, 12 May 2003 08:04:26 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CF4Nhs019588 for ; Mon, 12 May 2003 08:04:23 -0700 (PDT) Received: from brmea-mail-1.sun.com (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4CF30Kw006601 for ; Mon, 12 May 2003 08:03:01 -0700 (PDT) Received: from p2.piuha.net (p2.piuha.net [131.160.192.2]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4CF2rAk025978 for ; Mon, 12 May 2003 09:02:54 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 3C3256A907 for ; Mon, 12 May 2003 18:02:51 +0300 (EEST) Message-ID: <3EBFB748.80600@kolumbus.fi> Date: Mon, 12 May 2003 18:01:28 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Summary: Avoiding interface failure upon DAD failure References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7F4@tayexc13.americas.cpqcorp.net> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7F4@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I'll try to summarize the discussion about this issue and propose a way forward. The proposal was to allow the use of randomly generated addresses a la 3041 for link-local addresses and care-of addresses in mobile nodes while they are roaming around. Since RFC 2462 requires less drastic collision actions (disable address) for random addresses than for EUI-64 based addresses (disable interface), this was thought to have a positive effect to the resiliency of the system, if after failure one would still like to use the interface after moving to another link. A part of the discussion that arose dealt with the issue of skipping DAD and how useful (or not) it is. This part of the discussion is not relevant for our original question, because we follow the current RFCs and do DAD as specified. However, it appears to be a periodically discussed subject in the IPv6 WG. As such, some further work in the WG might look at that. Ongoing efforts to look at optimistic DAD is one such item and I will suggest another one later in this e-mail. There was also a lot of discussion of EUI-64 -based address conflicts. This is also outside the scope of our proposal, and is ignored in this e-mail. But back to the proposal and the issues around it. The following points were made: Protocol issues: * Clearly, mobile nodes can use RFC 3041 addresses like any other application. No issue here (Hesham). * Mobile IPv6 should disable the link but when moving to a new link can re-try DAD (Pekka). * Discussion concludes that MAY use 3041 (Mika). * Move on without this and discuss the issue in depth in IPv6 later (Jim). * There is a need to work on clarifications and treatment of wireless cases for DAD (Greg). Desired behaviour: * Collision is so rare, should not bother to prepare for nice treatment if it happens (Mika). * Rare errors should also be handled, many IPv6 error handling mechanisms such as DAD work with rare events (Hesham, Jari). * Collision means something is serious wrong, should not continue (Bob, Pekka). * Devices should recover by themselves after moving elsewhere, otherwise device needs user attention or even service (Jari). * Disabling the interface is harmful to users (Charlie). * Diagnostics on the mobile node will be able to tell what's going on (Greg). Specifics of collisions: * There's a difference if the DAD failure is due to this node or another node, in the latter case disabling interface harms future use. Trouble is, hard to know which case it is (Jari). * Inspection of SSLA can tell you whether to disable the interface or not (Greg). * DAD failure means the address is bad, not interface (Charlie). * Why does the collision happen - EUI-64 collision, software/hardware problem, malicious user, random collision? This has an impact on the proper "cure". (Jari, Pekka, Vijay) Summary A key requirement question is of course whether it is desireable for the mobile nodes to disable themselves or have some form of automatic resilience against temporary problems. There was no clear consensus on this issue (though the question about whether EUI-64 or something else is used affected the discussion). My belief is that some level of resilience is necessary, unless EUI-64 addresses are used. This idea seems to be built into RFC 2462 as well, because it has different collision actions. Another important question is to what extent the existing protocols already support the desired behaviour. Clearly, mobile nodes can use 3041 addresses when they move around just like other nodes. Given the current 2462 rules, collisions for such addresses do not disable the interface. There are two limitations of this, however: (a) 3041 does not specify the creation of link-local addresses and (b) 3041 says that after 5 collisions, stop generating any more addresses on that interface. This is almost sufficient for the desired behaviour, since mobile node could presumably use only global care-of addresses, and getting to five collisions is highly unlikely. (Though it would seem better to have the limit per link.) Another current protocol facility is Neighbor Discovery in general, its concept of an interface. We've lately started to realize that it may not always be clear what is considered as an interface. Does movement to a new link constitute the initialization of an interface, resetting all knowledge of DAD failures, reconstructing all data structures? Recommended way forward: Existing specifications already can give (very) limited support for the feature that we desired. We could add the link-local case and in doing so say that the 5-collision limit is per link. We could also specify that DAD issues in general are "reset" upon movement to a new link. The latter in particular would appear quite reasonable. However, I am afraid of two things: (1) Perhaps the understanding for what ND information gets reset in what kind of movements should be developed in full for all of ND, and not just for the particular case of collisions. (2) Continued discussion. Therefore, my recommendation is that we delete the Section 7.6 from the Mobile IPv6 draft that deals with this issue, and work for the better understanding of what an interface means in the context of the following work: - A full & optimized movement detection scheme that has been suggested to be worked on in the MIP WG or one of its follow-up WGs. - Optimized DAD. - Possible other new work taking place wrt ND or DAD. --Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 12 08:24:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CFOchs019802; Mon, 12 May 2003 08:24:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4CFOcsC019801; Mon, 12 May 2003 08:24:38 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CFOZhs019793 for ; Mon, 12 May 2003 08:24:35 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4CFNCuc025104 for ; Mon, 12 May 2003 08:23:12 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4CFN6PH017828 for ; Mon, 12 May 2003 08:23:06 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Draft on a V6 documentation prefix MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Mon, 12 May 2003 08:23:18 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F5045814@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on a V6 documentation prefix Thread-Index: AcMXvZg39P+tuV0kTUC6bThZo9tsKQA3F0sw From: "Michel Py" To: "Jeroen Massar" , "Brian Carpenter" , "Geoff Huston" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4CFOZhs019795 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Jeroen Massar wrote: > Like Brian says: ship it. Concur. It does not go as far as I wished, but ship it anyway. > BTW, is TLA still the good 'wording' for the prefixes allocated > by the RIRs? No; this entire terminology is gone see draft-ietf-ipv6-unicast-aggr-v2-02.txt. The "GRP" (Globally Routed Prefix) you suggested earlier would be fine by me; I am already using it. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 12 08:42:48 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CFglhs020140; Mon, 12 May 2003 08:42:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4CFglr2020139; Mon, 12 May 2003 08:42:47 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CFgihs020132 for ; Mon, 12 May 2003 08:42:44 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4CFfLuc007265 for ; Mon, 12 May 2003 08:41:21 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4CFfGPH029137 for ; Mon, 12 May 2003 08:41:16 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Mon, 12 May 2003 08:41:28 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F5045816@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMXsIFBecvvchpuQTupEXMrh5GBqQA6obagAAB1SrA= From: "Michel Py" To: "Brian Carpenter" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4CFgihs020133 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> Michel Py wrote: >> It has nothing to do with the prefix itself but with the scope. > Brian E Carpenter wrote: > Of course. And why is the scope issue different, just because > we have removed the ambiguity? I read this the same way Jim does: > Jim Bound wrote: > What is so elegant about this proposal is that it completely > eliminates the need for an implemented scoping architercture > within products today There is "no scoping" written all over Bob's draft. Without getting into the "is this a good thing or not" stuff so far I have not seen any proposal that could mitigate the risk of removing ambiguity without creating a swamp if there is no scoping to back it up. In other words, if scoping goes the ambiguity will remain. >>>> 2. We can't enforce operators to filter the prefix. I dropped >>>> filters on my BGP feeds and from one of my peers (a well-known >>>> player) I get all kinds of crud including /64 routes, /48 routes, >>>> /41 routes, name it I get it. >>> I think there will be Darwinian effects here, as we saw during the >>> first years of CIDR. But yes, if someone pays enough, they will get >>> their /64 announced. That will happen whatever we write in RFCs. >> My point exactly. We can't rely on this alone. > Now explain why it's a problem, if the customers pay > enough to cover the costs. I though we were on agreement that routing table bloat was not a good idea? Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 12 08:44:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CFi1hs020160; Mon, 12 May 2003 08:44:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4CFi1og020159; Mon, 12 May 2003 08:44:01 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CFhvhs020152 for ; Mon, 12 May 2003 08:43:57 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4CFgYKw005087 for ; Mon, 12 May 2003 08:42:34 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4CFgTWs018525 for ; Mon, 12 May 2003 09:42:29 -0600 (MDT) Content-class: urn:content-classes:message Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Mon, 12 May 2003 08:42:19 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F5045817@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMYUagpp8VFh4EJT+CLILBFckaxfgASxIZA From: "Michel Py" To: "Brian Carpenter" , Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4CFhvhs020153 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Brian E Carpenter wrote: > In response to both you and Christian, I think the arguments why > we need /48s, and can afford to give them, are in RFC 3177. > That doesn't exclude /64 in some cases, but as a general solution, > we should assume the need for subnets and not assume automatic > subnet numbering. I completely agree with this. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 12 08:50:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CFoghs020304; Mon, 12 May 2003 08:50:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4CFogxv020303; Mon, 12 May 2003 08:50:42 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CFodhs020294 for ; Mon, 12 May 2003 08:50:39 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4CFnFuc013699 for ; Mon, 12 May 2003 08:49:15 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4CFnAPH004169 for ; Mon, 12 May 2003 08:49:10 -0700 (PDT) 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 IAA28489; Mon, 12 May 2003 08:47:25 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4CFlO403463; Mon, 12 May 2003 08:47:24 -0700 X-mProtect: <200305121547> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdsAl0GN; Mon, 12 May 2003 08:47:23 PDT Message-ID: <3EBFC20C.BDB84477@iprg.nokia.com> Date: Mon, 12 May 2003 08:47:24 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Jari Arkko CC: ipng@sunroof.eng.sun.com Subject: Re: Summary: Avoiding interface failure upon DAD failure References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7F4@tayexc13.americas.cpqcorp.net> <3EBFB748.80600@kolumbus.fi> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello Jari, There is no need to delete the section. I suspect that some of the objections were raised would no longer be at issue once the following are understood: - There are no changes whatsoever to the installed base of IPv6 addresses - A device could be working perfectly well, having run DAD on its link, but when moving to a new link then might reset its interface. I would hope that most designers would realize that the mobile device should NOT reset its interface in this circumstance, preferring instead to choose a(nother?) RFC 3041 randomized address. The progression of deleting more and more performance improvements from the specification has to be stopped, and in this case there is no reason at all to remove the language. Otherwise, someone would someday find that their mobile device stops working for no reason at all. There have been no convincing arguments presented why we should cause this pain, instead of allowing and encouraging the better design. I do not support this suggestion to delete section 7.6. On your summarized points: > * There's a difference if the DAD failure is due to > this node or another node, in the latter case disabling > interface harms future use. Trouble is, hard to know > which case it is (Jari). I do not see the relevance of this. If a node moves to a new link, on which some other node has by chance already used RFC 3041 to configure the incoming mobile node's address, then the incoming node should be allowed to gracefully recover. Therefore, this measure corrects a problem that is completely unrelated to DAD failure. Since the device is "known working" from a previous link, we should not expect that the address collision is due to interface failure. > * Why does the collision happen - EUI-64 collision, > software/hardware problem, malicious user, random > collision? This has an impact on the proper "cure". > (Jari, Pekka, Vijay) The _possibility_ (in this case, not very likely it seems) of future specification does NOT imply that all current specification is broken. Regards, Charlie P. Jari Arkko wrote: > > Hi, > > I'll try to summarize the discussion about this issue and propose > a way forward. > > The proposal was to allow the use of randomly generated addresses > a la 3041 for link-local addresses and care-of addresses in mobile > nodes while they are roaming around. Since RFC 2462 requires less > drastic collision actions (disable address) for random > addresses than for EUI-64 based addresses (disable interface), > this was thought to have a positive effect to the resiliency > of the system, if after failure one would still like to use > the interface after moving to another link. > > A part of the discussion that arose dealt with the issue > of skipping DAD and how useful (or not) it is. This part > of the discussion is not relevant for our original question, > because we follow the current RFCs and do DAD as specified. > However, it appears to be a periodically discussed subject > in the IPv6 WG. As such, some further work in the WG might > look at that. Ongoing efforts to look at optimistic DAD > is one such item and I will suggest another one later in > this e-mail. > > There was also a lot of discussion of EUI-64 -based > address conflicts. This is also outside the scope of > our proposal, and is ignored in this e-mail. > > But back to the proposal and the issues around it. > The following points were made: > > Protocol issues: > > * Clearly, mobile nodes can use RFC 3041 addresses > like any other application. No issue here (Hesham). > > * Mobile IPv6 should disable the link but when moving > to a new link can re-try DAD (Pekka). > > * Discussion concludes that MAY use 3041 (Mika). > > * Move on without this and discuss the issue in depth > in IPv6 later (Jim). > > * There is a need to work on clarifications and > treatment of wireless cases for DAD (Greg). > > Desired behaviour: > > * Collision is so rare, should not bother to prepare > for nice treatment if it happens (Mika). > > * Rare errors should also be handled, many IPv6 > error handling mechanisms such as DAD work > with rare events (Hesham, Jari). > > * Collision means something is serious wrong, should > not continue (Bob, Pekka). > > * Devices should recover by themselves after moving > elsewhere, otherwise device needs user attention > or even service (Jari). > > * Disabling the interface is harmful to users (Charlie). > > * Diagnostics on the mobile node will be able to > tell what's going on (Greg). > > Specifics of collisions: > > * There's a difference if the DAD failure is due to > this node or another node, in the latter case disabling > interface harms future use. Trouble is, hard to know > which case it is (Jari). > > * Inspection of SSLA can tell you whether to disable > the interface or not (Greg). > > * DAD failure means the address is bad, not interface > (Charlie). > > * Why does the collision happen - EUI-64 collision, > software/hardware problem, malicious user, random > collision? This has an impact on the proper "cure". > (Jari, Pekka, Vijay) > > Summary > > A key requirement question is of course whether it is > desireable for the mobile nodes to disable themselves > or have some form of automatic resilience against > temporary problems. There was no clear consensus on > this issue (though the question about whether EUI-64 > or something else is used affected the discussion). My > belief is that some level of resilience is necessary, > unless EUI-64 addresses are used. This idea seems to > be built into RFC 2462 as well, because it has different > collision actions. > > Another important question is to what extent the > existing protocols already support the desired > behaviour. Clearly, mobile nodes can use 3041 > addresses when they move around just like other > nodes. Given the current 2462 rules, collisions > for such addresses do not disable the interface. > There are two limitations of this, however: (a) > 3041 does not specify the creation of link-local > addresses and (b) 3041 says that after 5 collisions, > stop generating any more addresses on that interface. > This is almost sufficient for the desired behaviour, > since mobile node could presumably use only global > care-of addresses, and getting to five collisions > is highly unlikely. (Though it would seem better > to have the limit per link.) > > Another current protocol facility is Neighbor > Discovery in general, its concept of an interface. > We've lately started to realize that it may not > always be clear what is considered as an interface. > Does movement to a new link constitute the initialization > of an interface, resetting all knowledge of DAD failures, > reconstructing all data structures? > > Recommended way forward: > > Existing specifications already can give (very) limited > support for the feature that we desired. We could add > the link-local case and in doing so say that the 5-collision > limit is per link. We could also specify that DAD issues > in general are "reset" upon movement to a new link. The > latter in particular would appear quite reasonable. However, > I am afraid of two things: (1) Perhaps the understanding > for what ND information gets reset in what kind of movements > should be developed in full for all of ND, and not just for > the particular case of collisions. (2) Continued discussion. > > Therefore, my recommendation is that we delete the Section > 7.6 from the Mobile IPv6 draft that deals with this issue, > and work for the better understanding of what an interface > means in the context of the following work: > > - A full & optimized movement detection scheme that has > been suggested to be worked on in the MIP WG or one of > its follow-up WGs. > > - Optimized DAD. > > - Possible other new work taking place wrt ND or DAD. > > --Jari > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 12 10:40:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CHe7hs022385; Mon, 12 May 2003 10:40:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4CHe7sk022384; Mon, 12 May 2003 10:40:07 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CHe3hs022369 for ; Mon, 12 May 2003 10:40:03 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4CHceKw005416 for ; Mon, 12 May 2003 10:38:40 -0700 (PDT) Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4CHcXPH014022 for ; Mon, 12 May 2003 10:38:34 -0700 (PDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h4CHeiHZ009157; Mon, 12 May 2003 20:40:45 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h4CHefqO009156; Mon, 12 May 2003 20:40:41 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Summary: Avoiding interface failure upon DAD failure From: Mika Liljeberg To: "Charles E. Perkins" Cc: Jari Arkko , ipng@sunroof.eng.sun.com In-Reply-To: <3EBFC20C.BDB84477@iprg.nokia.com> References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7F4@tayexc13.americas.cpqcorp.net> <3EBFB748.80600@kolumbus.fi> <3EBFC20C.BDB84477@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1052761240.1174.46.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 12 May 2003 20:40:41 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 2003-05-12 at 18:47, Charles E. Perkins wrote: > - A device could be working perfectly well, having > run DAD on its link, but when moving to a new link > then might reset its interface. > > I would hope that most designers would realize that > the mobile device should NOT reset its interface > in this circumstance, preferring instead to choose > a(nother?) RFC 3041 randomized address. A node using RFC3041 will have two link-local addresses on the network interface: - FE80::EUI64_ID - FE80::TEMP_ID The node will do DAD for both. If DAD on the former fails, it is an indication of MAC address collision (or some equally fatal problem). In this case, the MN obviously SHOULD disable the interface (at least until it has moved to another link). If DAD on the latter fails, it is probably just bad luck and the MN might as well pick another TEMP_ID and try again. With that in mind, I fail to see how using RFC3041 addresses would give any benefit in terms of resilience, since the random nature of the TEMP_ID selection is causing the collisions in the first place. Why is the MIPv6 specification concerned with this anyway? MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 12 10:40:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CHeths022449; Mon, 12 May 2003 10:40:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4CHetPJ022448; Mon, 12 May 2003 10:40:55 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CHeqhs022438 for ; Mon, 12 May 2003 10:40:52 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4CHdTKw005916 for ; Mon, 12 May 2003 10:39:29 -0700 (PDT) Received: from rrmail01.lab.flarion.com (mail.flarion.com [63.103.94.23]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4CHdNPH014596 for ; Mon, 12 May 2003 10:39:24 -0700 (PDT) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2656.59) id ; Mon, 12 May 2003 13:39:21 -0400 Message-ID: <748C6D0A58C0F94CA63C198B6674697A0141BA29@ftmail.lab.flarion.com> From: Hesham Soliman To: "'Charles E. Perkins'" , Jari Arkko Cc: ipng@sunroof.eng.sun.com Subject: RE: Summary: Avoiding interface failure upon DAD failure Date: Mon, 12 May 2003 13:39:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Jari, Charlie > > There is no need to delete the section. > > I suspect that some of the objections were raised > would no longer be at issue once the following > are understood: > > - There are no changes whatsoever to the installed > base of IPv6 addresses > > - A device could be working perfectly well, having > run DAD on its link, but when moving to a new link > then might reset its interface. > > I would hope that most designers would realize that > the mobile device should NOT reset its interface > in this circumstance, preferring instead to choose > a(nother?) RFC 3041 randomized address. > > The progression of deleting more and more performance > improvements from the specification has to be > stopped, and in this case there is no reason at > all to remove the language. > > Otherwise, someone would someday find that their > mobile device stops working for no reason at all. > There have been no convincing arguments presented > why we should cause this pain, instead of allowing > and encouraging the better design. > > I do not support this suggestion to delete section 7.6. => What Charlie says above makes sense to me. As Jari mentioned in a previous email, most of the discussion I saw was about the probability of collision and the usefulness of DAD. None of that, IMO, is relevant to the proposal that Jari sent earlier. His proposal was as simple as: "We want to reference 3041 in the MIPv6 spec". I don't understand what could possibly be wrong with that. 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 May 12 10:49:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CHnfhs022997; Mon, 12 May 2003 10:49:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4CHnfeq022996; Mon, 12 May 2003 10:49:41 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CHnahs022977 for ; Mon, 12 May 2003 10:49:36 -0700 (PDT) Received: from brmea-mail-1.sun.com (lukla.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4CHmDKw012588 for ; Mon, 12 May 2003 10:48:14 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4CHm8Ak024169 for ; Mon, 12 May 2003 11:48:08 -0600 (MDT) 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 KAA04386; Mon, 12 May 2003 10:48:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4CHm7D05067; Mon, 12 May 2003 10:48:07 -0700 X-mProtect: <200305121748> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdE5HvyP; Mon, 12 May 2003 10:48:05 PDT Message-ID: <3EBFDE55.BB1A2517@iprg.nokia.com> Date: Mon, 12 May 2003 10:48:05 -0700 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: Mika Liljeberg CC: ipng@sunroof.eng.sun.com Subject: Re: Summary: Avoiding interface failure upon DAD failure References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7F4@tayexc13.americas.cpqcorp.net> <3EBFB748.80600@kolumbus.fi> <3EBFC20C.BDB84477@iprg.nokia.com> <1052761240.1174.46.camel@devil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Mika Liljeberg wrote: > > I would hope that most designers would realize that > > the mobile device should NOT reset its interface > > in this circumstance, preferring instead to choose > > a(nother?) RFC 3041 randomized address. > > A node using RFC3041 will have two link-local addresses on the network > interface: > > - FE80::EUI64_ID > - FE80::TEMP_ID > > The node will do DAD for both. > > If DAD on the former fails, it is an indication of MAC address collision > (or some equally fatal problem). In this case, the MN obviously SHOULD > disable the interface (at least until it has moved to another link). No, the mobile node should disable use of that address. What if some other node on the new link has configured a TEMP_ID that happens to collide with the mobile device's EUI64_ID? The proposal is to allow, in that case, the mobile node to configure a new TEMP_ID -- and NOT disable the hardware. > If DAD on the latter fails, it is probably just bad luck and the MN > might as well pick another TEMP_ID and try again. Exactly. > With that in mind, I fail to see how using RFC3041 addresses would give > any benefit in terms of resilience, since the random nature of the > TEMP_ID selection is causing the collisions in the first place. Why is > the MIPv6 specification concerned with this anyway? Only because it is, in many systems, a mistake to disable the hardware. Not all systems. No mandate is required, only the _possibility_ of designing a resilient system. 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 Mon May 12 11:14:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CIEqhs023615; Mon, 12 May 2003 11:14:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4CIEqwk023614; Mon, 12 May 2003 11:14:52 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CIEmhs023607 for ; Mon, 12 May 2003 11:14:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4CIDQuc016876 for ; Mon, 12 May 2003 11:13:26 -0700 (PDT) Received: from devil.pp.htv.fi (cs180132.pp.htv.fi [213.243.180.132]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4CIDJPH010650 for ; Mon, 12 May 2003 11:13:20 -0700 (PDT) Received: from devil.pp.htv.fi (localhost [127.0.0.1]) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) with ESMTP id h4CIFfHZ009329; Mon, 12 May 2003 21:15:42 +0300 Received: (from liljeber@localhost) by devil.pp.htv.fi (8.12.9/8.12.9/Debian-3) id h4CIFcqT009328; Mon, 12 May 2003 21:15:38 +0300 X-Authentication-Warning: devil.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: Summary: Avoiding interface failure upon DAD failure From: Mika Liljeberg To: "Charles E. Perkins" Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3EBFDE55.BB1A2517@iprg.nokia.com> References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD7F4@tayexc13.americas.cpqcorp.net> <3EBFB748.80600@kolumbus.fi> <3EBFC20C.BDB84477@iprg.nokia.com> <1052761240.1174.46.camel@devil> <3EBFDE55.BB1A2517@iprg.nokia.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: Message-Id: <1052763337.1175.60.camel@devil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 12 May 2003 21:15:38 +0300 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, 2003-05-12 at 20:48, Charles E. Perkins wrote: > Mika Liljeberg wrote: > > > > I would hope that most designers would realize that > > > the mobile device should NOT reset its interface > > > in this circumstance, preferring instead to choose > > > a(nother?) RFC 3041 randomized address. > > > > A node using RFC3041 will have two link-local addresses on the network > > interface: > > > > - FE80::EUI64_ID > > - FE80::TEMP_ID > > > > The node will do DAD for both. > > > > If DAD on the former fails, it is an indication of MAC address collision > > (or some equally fatal problem). In this case, the MN obviously SHOULD > > disable the interface (at least until it has moved to another link). > > No, the mobile node should disable use of that address. In that case you're doing more than just referring to RFC3041. RFC3041 merely defines a random TEMP_ID for configuring *additional* global addresses with better privacy characteristics. It does not remove the existing link-local address, nor addresses configured from it. > What if some other node on the new link has configured a TEMP_ID > that happens to collide with the mobile device's EUI64_ID? That can't happen, since RFC3041 IIDs will have the universal/local bit set to zero, while IIDs generated from MAC addresses will have the universal/local bit set to one. MikaL -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 12 11:44:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CIi3hs024159; Mon, 12 May 2003 11:44:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4CIi3rk024158; Mon, 12 May 2003 11:44:03 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CIi0hs024151 for ; Mon, 12 May 2003 11:44:00 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4CIgbuc008162 for ; Mon, 12 May 2003 11:42:37 -0700 (PDT) Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4CIgWPH004638 for ; Mon, 12 May 2003 11:42:32 -0700 (PDT) Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4CIgOAw013096; Mon, 12 May 2003 11:42:24 -0700 (PDT) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AEB46294; Mon, 12 May 2003 11:42:23 -0700 (PDT) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA25543; Mon, 12 May 2003 11:42:23 -0700 (PDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16063.60175.162236.489955@thomasm-u1.cisco.com> Date: Mon, 12 May 2003 11:42:23 -0700 (PDT) To: Hesham Soliman Cc: "'Charles E. Perkins'" , Jari Arkko , ipng@sunroof.eng.sun.com Subject: RE: Summary: Avoiding interface failure upon DAD failure In-Reply-To: <748C6D0A58C0F94CA63C198B6674697A0141BA29@ftmail.lab.flarion.com> References: <748C6D0A58C0F94CA63C198B6674697A0141BA29@ftmail.lab.flarion.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I haven't been following this all that closely, but maybe it's time for somebody to write a "DAD considered harmful" draft? DAD has always struck me as something of a tail-wagging-dog situation; that is, something that drives design decisions *far* beyond what the actual problem it solves is worth. Mike Hesham Soliman writes: > Jari, Charlie > > > > > There is no need to delete the section. > > > > I suspect that some of the objections were raised > > would no longer be at issue once the following > > are understood: > > > > - There are no changes whatsoever to the installed > > base of IPv6 addresses > > > > - A device could be working perfectly well, having > > run DAD on its link, but when moving to a new link > > then might reset its interface. > > > > I would hope that most designers would realize that > > the mobile device should NOT reset its interface > > in this circumstance, preferring instead to choose > > a(nother?) RFC 3041 randomized address. > > > > The progression of deleting more and more performance > > improvements from the specification has to be > > stopped, and in this case there is no reason at > > all to remove the language. > > > > Otherwise, someone would someday find that their > > mobile device stops working for no reason at all. > > There have been no convincing arguments presented > > why we should cause this pain, instead of allowing > > and encouraging the better design. > > > > I do not support this suggestion to delete section 7.6. > > => What Charlie says above makes sense to me. > As Jari mentioned in a previous email, most of > the discussion I saw was about the probability > of collision and the usefulness of DAD. None of > that, IMO, is relevant to the proposal that Jari > sent earlier. His proposal was as simple as: > "We want to reference 3041 in the MIPv6 spec". > I don't understand what could possibly be wrong with > that. > > Hesham > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 12 15:57:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CMvIhs026776; Mon, 12 May 2003 15:57:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4CMvI45026775; Mon, 12 May 2003 15:57:18 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CMvFhs026768 for ; Mon, 12 May 2003 15:57:15 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4CMtqKw026006 for ; Mon, 12 May 2003 15:55:52 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4CMtlWs004229 for ; Mon, 12 May 2003 16:55:47 -0600 (MDT) 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 PAA20883 for ; Mon, 12 May 2003 15:55:47 -0700 (PDT) X-Delivered-For: Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4CMtkR17663; Mon, 12 May 2003 15:55:46 -0700 X-mProtect: <200305122255> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.159, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdOXcHdX; Mon, 12 May 2003 15:55:43 PDT Message-Id: <4.3.2.7.2.20030512100351.028fadc0@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 12 May 2003 15:55:07 -0700 To: From: Bob Hinden Subject: RE: Draft on a V6 documentation prefix In-Reply-To: <002201c317bb$94e1b910$210d640a@unfix.org> References: <3EBE31D8.31FC8DDF@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk It looks OK to me as well. >One thing that could be consider is how to document >examples between 2 TLA's. Ofcourse one can use something >in the lines of: >"We will setup a BGP peering between ISPA who is allocated 2001:db8::/35 >and ISPB who is allocated 2001:dba::/35." >There will always be a case I think where one needs multiple >prefixes for explainations and examples like these. At some point, one needs the whole address space for documentation and it should be clear we can't do that. Consequently I think a single /32 should be fine for most purposes. Hopefully people setting up BGP peering can deal with something like: "We will setup a BGP peering between ISPA who is allocated XXXX:XXXX::/32 and ISPB who is allocated YYYY:YYYY::/32." I would also hope that the documentation made it clear that the prefix length might be something other than a /32. Bob -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 12 16:25:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CNPths027265; Mon, 12 May 2003 16:25:55 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4CNPtA6027264; Mon, 12 May 2003 16:25:55 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4CNPphs027257 for ; Mon, 12 May 2003 16:25:52 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4CNOTKw012237 for ; Mon, 12 May 2003 16:24:29 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA14509 for ; Mon, 12 May 2003 16:24:03 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Draft on a V6 documentation prefix MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Mon, 12 May 2003 16:23:58 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F7E2@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on a V6 documentation prefix Thread-Index: AcMY2mpzJ4QyNGxSTUKNHbO53hUjJwAAjmZQ From: "Michel Py" To: "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4CNPqhs027258 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > Bob Hinden wrote: > I think a single /32 should be fine for most purposes. Hopefully > people setting up BGP peering can deal with something like: > "We will setup a BGP peering between ISPA who is allocated > XXXX:XXXX::/32 and ISPB who is allocated YYYY:YYYY::/32." They certainly can, but the goal of the documentation prefix is to avoid hijacking of real prefixes when doing _lab_ work (after all, hijacking a prefix for documentation-only purposes without ever configuring these addresses is not wrong). The trouble with using things such as XXXX:XXXX::/32 and YYYY:YYYY::/32 is that they can't be configured on a router and won't prevent the hijacking of a real prefix when labing the case, which is what the documentation prefix tries to prevent from happening. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 12 22:40:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4D5ehhs028632; Mon, 12 May 2003 22:40:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4D5eg0i028631; Mon, 12 May 2003 22:40:42 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4D5edhs028624 for ; Mon, 12 May 2003 22:40:39 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4D5dHuc002922 for ; Mon, 12 May 2003 22:39:17 -0700 (PDT) Received: from mail-gw1.hursley.ibm.com (mail-gw1.hursley.ibm.com [194.196.110.15]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id WAA19423 for ; Mon, 12 May 2003 22:38:52 -0700 (PDT) Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw1.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19FSV1-0004x5-00; Tue, 13 May 2003 06:38:51 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw1.hursley.ibm.com with esmtp (Exim 4.12) id 19FSV1-0004x0-00; Tue, 13 May 2003 06:38:51 +0100 Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp15en17.hursley.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id GAA159228; Tue, 13 May 2003 06:38:47 +0100 Message-ID: <3EC08504.441F0A58@hursley.ibm.com> Date: Tue, 13 May 2003 07:39:16 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de MIME-Version: 1.0 To: Michel Py CC: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <963621801C6D3E4A9CF454A1972AE8F5045816@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel Py wrote: > > Brian, > > >> Michel Py wrote: > >> It has nothing to do with the prefix itself but with the scope. > > > Brian E Carpenter wrote: > > Of course. And why is the scope issue different, just because > > we have removed the ambiguity? > > I read this the same way Jim does: > > > Jim Bound wrote: > > What is so elegant about this proposal is that it completely > > eliminates the need for an implemented scoping architercture > > within products today > > There is "no scoping" written all over Bob's draft. Without getting into > the "is this a good thing or not" stuff so far I have not seen any > proposal that could mitigate the risk of removing ambiguity without > creating a swamp if there is no scoping to back it up. In other words, > if scoping goes the ambiguity will remain. Well, I am too literal minded to have read that in the proposal. I think it changes the scoping debate, but doesn't abolish it. As Tony Hain has pointed out, scope is a fact of life, whether we architect it or not. > > >>>> 2. We can't enforce operators to filter the prefix. I dropped > >>>> filters on my BGP feeds and from one of my peers (a well-known > >>>> player) I get all kinds of crud including /64 routes, /48 routes, > >>>> /41 routes, name it I get it. > > >>> I think there will be Darwinian effects here, as we saw during the > >>> first years of CIDR. But yes, if someone pays enough, they will get > >>> their /64 announced. That will happen whatever we write in RFCs. > > >> My point exactly. We can't rely on this alone. > > > Now explain why it's a problem, if the customers pay > > enough to cover the costs. > > I though we were on agreement that routing table bloat was not a good > idea? Indeed. But if a few Megacorps are willing to pay the ISPs to carry specific routes, that won't bloat the tables. If a lot of medium size companies tried the same, it would be bad. Brian > > Michel. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 13 00:24:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4D7O6hs029016; Tue, 13 May 2003 00:24:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4D7O6xs029015; Tue, 13 May 2003 00:24:06 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4D7O3hs029008 for ; Tue, 13 May 2003 00:24:03 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4D7Meuc017708 for ; Tue, 13 May 2003 00:22:40 -0700 (PDT) Received: from raven.ecs.soton.ac.uk (raven.ecs.soton.ac.uk [152.78.70.1]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4D7MX0W015704 for ; Tue, 13 May 2003 01:22:34 -0600 (MDT) Received: from pigeon.ecs.soton.ac.uk (ns1 [152.78.68.1]) by raven.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA19109 for ; Tue, 13 May 2003 08:22:32 +0100 (BST) Received: from login.ecs.soton.ac.uk (login [152.78.68.162]) by pigeon.ecs.soton.ac.uk (8.9.3p2/8.9.3) with ESMTP id IAA26337 for ; Tue, 13 May 2003 08:22:32 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id h4D7MWT05628 for ipng@sunroof.eng.sun.com; Tue, 13 May 2003 08:22:32 +0100 Date: Tue, 13 May 2003 08:22:32 +0100 From: Tim Chown To: ipng@sunroof.eng.sun.com Subject: Re: Draft on a V6 documentation prefix Message-ID: <20030513072231.GA5525@login.ecs.soton.ac.uk> Mail-Followup-To: ipng@sunroof.eng.sun.com References: <963621801C6D3E4A9CF454A1972AE8F504F7E2@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F7E2@server2000.arneill-py.sacramento.ca.us> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, May 12, 2003 at 04:23:58PM -0700, Michel Py wrote: > > They certainly can, but the goal of the documentation prefix is to avoid > hijacking of real prefixes when doing _lab_ work (after all, hijacking a > prefix for documentation-only purposes without ever configuring these > addresses is not wrong). The trouble with using things such as > XXXX:XXXX::/32 and YYYY:YYYY::/32 is that they can't be configured on a > router and won't prevent the hijacking of a real prefix when labing the > case, which is what the documentation prefix tries to prevent from > happening. So if we do create this prefix, what's the difference between this and an allocated prefix for private use in networks? You're suggesting it's not a documentation prefix, but a prefix for use in (disconnected) networks. Throw in v6 NAT and... ;) 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 Tue May 13 00:24:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4D7Ohhs029033; Tue, 13 May 2003 00:24:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4D7OhL9029032; Tue, 13 May 2003 00:24:43 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4D7Odhs029025 for ; Tue, 13 May 2003 00:24:39 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4D7NGuc017886 for ; Tue, 13 May 2003 00:23:16 -0700 (PDT) Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4D7N9Y9008883 for ; Tue, 13 May 2003 01:23:10 -0600 (MDT) Received: from thwack.its.monash.edu.au ([130.194.1.72]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KVUMXDMNGQ9C2YQL@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Tue, 13 May 2003 17:15:54 +1000 Received: from thwack.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9556312C009; Tue, 13 May 2003 17:15:46 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by thwack.its.monash.edu.au (Postfix) with ESMTP id 705E712C006; Tue, 13 May 2003 17:15:46 +1000 (EST) Date: Tue, 13 May 2003 18:15:26 +1000 From: Greg Daley Subject: Re: Avoiding interface failure upon DAD failure To: "Bound, Jim" Cc: Youn-Hee Han , ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EC0A99E.3030805@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD830@tayexc13.americas.cpqcorp.net> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jim, Your point is taken. When a supposed unique identifier fails to be unique, we have the problem. The Current RFC2462 text only refers to those link-local addresses formed from (unique) interface identifiers. I've been looking to see if there's a way to work around this issue in the fe80::EUI_64 case. I originally thought that the node undertaking DAD would be able to tell if there's a MAC collision (or not) by inspecting options in the DAD defence NA. My thought was that the conflicting MAC address would be contained in the NA's Target Link-Layer Address Option (which must be sent). Presence of a different MAC could be used to detect MAC non-collision. I've since realized that a defending node can send any of its MAC addresses in the TLLAO. So reception of a different MAC address does not imply that there is no MAC collision. Where there is a MAC Collision, there's no mechanism short of changing the MAC address of the interface which could allow safe operation. Maybe this could be done more automatically (choosing a (random) MAC address from the local scope perhaps), but I'm not sure that this should be in a Stateless Address Autoconfiguration document. Greg Bound, Jim wrote: > Greg and Youn-Hee, > > It is restrictive yes. But to relax that is fine if well thought out > and discussed. But I think it important to understand why the nature of > the restriction is to much and it what cases. As Youn-Hee pointed > predicting IEEE 802 IID failures is a challenge. Also one does not have > to use IEEE 802 for IID as a note. It could be CPU ID, etc. > > But discussion of when its ok to keep moving the failure mode is prudent > for us to truly understand in the IETF. > > /jim > > >>-----Original Message----- >>From: Youn-Hee Han [mailto:yhhan@sait.samsung.co.kr] >>Sent: Monday, May 12, 2003 12:51 AM >>To: greg.daley@eng.monash.edu.au >>Cc: ipng@sunroof.eng.sun.com >>Subject: Re: Avoiding interface failure upon DAD failure >> >> >>Greg Daley wrote: >> >> >>>That said, I think that the current rfc2462 text is unnecessarily >>>restrictive in this regard and doesn't cope with a legitimate >>>application (IP mobility) appropriately (no offense >> >>intended to the >> >>>authors, since otherwise I think it does a good job on DAD). >> >>I agree with you. It is so restrictive that one DAD failure >>disables its interface. However, we should consider >>some suffering problems. >> >>If a node uses EUI-64 address as its IID, DAD failure >>implies IEEE 802 address collision in almost cases. >>In this case, another IID generation is useless >>becasue the communication is not allowed by lower layer. >>(This is already mentioned by Bob in this discussion) >> >>Although nodes are attached at IEEE 802 links, however >>, we can not assure that they all use EUI-64 address as thier >>IID. Some nodes can ganerate random IID. So, DAD failure >>does not always implies IEEE 802 address collision. >> >>If a node can detect whether the IID generation is useless, >>the problem can be clearly resloved. >>In my knowledge, however, it is not possible. >> >> >>>Certainly, there should be follow-up both to clean up >>>DAD, and later to specify the correct behaviour in >>>a new draft in mobileip-wg. >> >>As well as the correct behaviour, we can also specify >>several DAD Optimization in a new draft. (e.g., oDAD) >> >>YH >> >> >>----- Original Message ----- >>From: "Greg Daley" >>To: "Bound, Jim" >>Cc: "Charles E. Perkins" ; "Jari >>Arkko" ; >>Sent: Monday, May 12, 2003 11:10 AM >>Subject: Re: Avoiding interface failure upon DAD failure >> >> >> >>>Hi Jim, >>> >>>At this stage, I agree that MIPv6 should not >>>wait for this issue. >>> >>>Link-Local collision is a relatively low probability, >>>and diagnostics on the mobile device will be able to >>>identify the issue. >>> >>>That said, I think that the current rfc2462 text is unnecessarily >>>restrictive in this regard and doesn't cope with a legitimate >>>application (IP mobility) appropriately (no offense >> >>intended to the >> >>>authors, since otherwise I think it does a good job on DAD). >>> >>>Certainly, there should be follow-up both to clean up >>>DAD, and later to specify the correct behaviour in >>>a new draft in mobileip-wg. >>> >>>Greg Daley >>> >>>Bound, Jim wrote: >>> >>>>Charlie, >>>> >>>>You have it backwards. We don't support this you and >>> >>others have to >> >>>>convince us to alter the base standard for mobile nodes >>> >>and for me >> >>>>you have not done that please don't reverse the process >>> >>here. This >> >>>>proposal is on the table for justfication not DAD. >>>> >>>>Regards, >>>>/jim >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Charles E. Perkins [mailto:charliep@iprg.nokia.com] >>>>>Sent: Thursday, May 08, 2003 11:37 AM >>>>>To: Jari Arkko >>>>>Cc: ipng@sunroof.eng.sun.com >>>>>Subject: Re: Avoiding interface failure upon DAD failure >>>>> >>>>> >>>>>Hello Jari, >>>>> >>>>>Jari Arkko wrote: >>>>> >>>>> >>>>> >>>>>>My intention is to follow current 2462 to the >>>>>>letter. The only questions are whether I can >>>>>>use 3041-like link local addresses, and whether >>>>>>the goal (avoiding disabled link) is worthwhile. >>>>> >>>>>From the point of view of someone trying to use >>>> >>>>>these devices, yes it is very worthwhile to >>>>>avoid disabling the link unnecessarily. >>>>> >>>>>I strongly support keeping this functionality >>>>>unless someone can point out why it is harmful. >>>>>We should look at this matter from the point of >>>>>view of what is best for the users. >>>>> >>>>>Regards, >>>>>Charlie P. >>>> >>>>-------------------------------------------------------------------- >>>> >>>>>IETF IPng Working Group Mailing List >>>>>IPng Home Page: >>>> >>http://playground.sun.com/ipng >> >>>>>FTP archive: >>>> >> ftp://playground.sun.com/pub/ipng >> >>>>>Direct all administrative requests to >>>> >>majordomo@sunroof.eng.sun.com >> >>>>-------------------------------------------------------------------- >>>> >>>> >>>> >>-------------------------------------------------------------------- >> >>>>IETF IPng Working Group Mailing List >>>>IPng Home Page: >>> >>http://playground.sun.com/ipng >> >>>>FTP archive: >>> >> ftp://playground.sun.com/pub/ipng >> >>>>Direct all administrative requests to >>> >>majordomo@sunroof.eng.sun.com >> >>-------------------------------------------------------------------- >> >>> >>>-------------------------------------------------------------------- >>>IETF IPng Working Group Mailing List >>>IPng Home Page: http://playground.sun.com/ipng >>>FTP archive: ftp://playground.sun.com/pub/ipng >>>Direct all administrative requests to majordomo@sunroof.eng.sun.com >>>-------------------------------------------------------------------- >>> >> >>-------------------------------------------------------------------- >>IETF IPng Working Group Mailing List >>IPng Home Page: http://playground.sun.com/ipng >>FTP archive: ftp://playground.sun.com/pub/ipng >>Direct all administrative requests to majordomo@sunroof.eng.sun.com >>-------------------------------------------------------------------- >> > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 04:58:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DBw5hs000606; Tue, 13 May 2003 04:58:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DBw5ll000605; Tue, 13 May 2003 04:58:05 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DBw2hs000598 for ; Tue, 13 May 2003 04:58:02 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DBubKw000210 for ; Tue, 13 May 2003 04:56:37 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4DBuV0W010590 for ; Tue, 13 May 2003 05:56:32 -0600 (MDT) Received: from IDLEWYLDE.windriver.com ([147.11.233.27]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA18265; Tue, 13 May 2003 04:56:22 -0700 (PDT) Message-Id: <5.1.0.14.2.20030513073116.048b7c58@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 13 May 2003 07:51:59 -0400 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Cc: Michel Py , ipng@sunroof.eng.sun.com In-Reply-To: <3EC08504.441F0A58@hursley.ibm.com> References: <963621801C6D3E4A9CF454A1972AE8F5045816@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, At 07:39 AM 5/13/2003 +0200, Brian E Carpenter wrote: >Well, I am too literal minded to have read that in the proposal. I think >it changes the scoping debate, but doesn't abolish it. As Tony Hain has >pointed out, scope is a fact of life, whether we architect it or not. At this point, I think we're really having an argument about what "scope" means... Does it mean that addresses have a certain scope in which they are: reachable? routable? unique? Does it mean that the match the description of scoped addressing in the IPv6 Scoped Addressing Architecture? I apply the following terms to these distinctions: Reachable & Unreachable Globally Routable & Local Globally Unique & Ambiguous I think of "scoped" addresses as unreachable, local and ambiguous, with all three attributes constrained at the same boundary (the site boundary, in the case of site-locals). So, by my definitions, the addresses described in Bob's proposal are _local_ addresses, but they are not _scoped_ addresses. It seems to me, though, that they may be _scoped_ by your definition and Tony's... Could you provide a definition? I am pretty certain that we all agree that there will continue to be firewalls in IPv6, and that those firewalls will make some addresses (and some address/port combinations) unreachable from other parts of the network. This will apply to both globally routable and local addresses, so any address could be unreachable from some parts of the network. Bob's proposal explicitly defines a type of addresses that are not expected to be routed throughout the Internet. So, these addresses are local, not globally routable. However, Bob's proposal defines addresses that are unique throughout the Internet. No single address identifies one node when used within one "scope" and another node when used in another "scope". So, these are not "scoped addresses", as defined in the IPv6 Scoped Addressing Architecture. I *think* that Bob and I are using the same definition for the term "scoped", but I hope he'll correct me if I'm wrong. > > I though we were on agreement that routing table bloat was not a good > > idea? > >Indeed. But if a few Megacorps are willing to pay the ISPs to carry >specific routes, that won't bloat the tables. If a lot of medium size >companies tried the same, it would be bad. As long as the cost of having a private address block routed across the Internet is high-enough that it makes financial sense for a Megacorp to do it, but it doesn't make sense for a mid-sized company to do it, then this would work fine... Personally, I think that the IETF should design the right technical solutions for addressing and leave it up to the registries and providers to determine the appropriate policies and business models for addressing. But, perhaps I'm just naive. 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 May 13 06:55:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DDtxhs001320; Tue, 13 May 2003 06:55:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DDtxPm001319; Tue, 13 May 2003 06:55:59 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DDtths001312 for ; Tue, 13 May 2003 06:55:55 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DDsVKw021259 for ; Tue, 13 May 2003 06:54:31 -0700 (PDT) Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4DDsPPH024407 for ; Tue, 13 May 2003 06:54:26 -0700 (PDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by e3.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4DDsNE2133050; Tue, 13 May 2003 09:54:23 -0400 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4DDsKK8191096; Tue, 13 May 2003 15:54:21 +0200 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA49752 from ; Tue, 13 May 2003 15:54:14 +0200 Message-Id: <3EC0F912.4C99B190@hursley.ibm.com> Date: Tue, 13 May 2003 15:54:26 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Margaret Wasserman Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <963621801C6D3E4A9CF454A1972AE8F5045816@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030513073116.048b7c58@mail.windriver.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, I have to be a bit careful here... I don't want to restart the scope wars on this thread, but I have severe doubts whether scope rules can be defined with the sort of mathematical clarity you might like. Given the prevalence of VPNs between private networks, I have difficulty knowing what a useful definition would look like. So I will actually decline to answer the question about what scope means, because I don't know any more (apart from link-local). This is linked to your last point. We do have to leave a lot of this to the operations community, and the question is what can we usefully give them in the way of generic scope mechanisms? Brian Margaret Wasserman wrote: > > Hi Brian, > > At 07:39 AM 5/13/2003 +0200, Brian E Carpenter wrote: > >Well, I am too literal minded to have read that in the proposal. I think > >it changes the scoping debate, but doesn't abolish it. As Tony Hain has > >pointed out, scope is a fact of life, whether we architect it or not. > > At this point, I think we're really having an argument about what > "scope" means... > > Does it mean that addresses have a certain scope in which they are: > reachable? routable? unique? Does it mean that the match the > description of scoped addressing in the IPv6 Scoped Addressing > Architecture? > > I apply the following terms to these distinctions: > > Reachable & Unreachable > Globally Routable & Local > Globally Unique & Ambiguous > > I think of "scoped" addresses as unreachable, local and ambiguous, > with all three attributes constrained at the same boundary (the > site boundary, in the case of site-locals). > > So, by my definitions, the addresses described in Bob's proposal > are _local_ addresses, but they are not _scoped_ addresses. > > It seems to me, though, that they may be _scoped_ by your > definition and Tony's... Could you provide a definition? > > I am pretty certain that we all agree that there will continue to > be firewalls in IPv6, and that those firewalls will make some > addresses (and some address/port combinations) unreachable from > other parts of the network. This will apply to both globally > routable and local addresses, so any address could be unreachable > from some parts of the network. > > Bob's proposal explicitly defines a type of addresses that are not > expected to be routed throughout the Internet. So, these addresses > are local, not globally routable. > > However, Bob's proposal defines addresses that are unique throughout > the Internet. No single address identifies one node when used within > one "scope" and another node when used in another "scope". So, these > are not "scoped addresses", as defined in the IPv6 Scoped Addressing > Architecture. > > I *think* that Bob and I are using the same definition for the > term "scoped", but I hope he'll correct me if I'm wrong. > > > > I though we were on agreement that routing table bloat was not a good > > > idea? > > > >Indeed. But if a few Megacorps are willing to pay the ISPs to carry > >specific routes, that won't bloat the tables. If a lot of medium size > >companies tried the same, it would be bad. > > As long as the cost of having a private address block routed across > the Internet is high-enough that it makes financial sense for a > Megacorp to do it, but it doesn't make sense for a mid-sized company > to do it, then this would work fine... > > Personally, I think that the IETF should design the right technical > solutions for addressing and leave it up to the registries and > providers to determine the appropriate policies and business models > for addressing. But, perhaps I'm just naive. > > 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 May 13 07:10:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DEAEhs001598; Tue, 13 May 2003 07:10:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DEAE7a001597; Tue, 13 May 2003 07:10:14 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DEAAhs001587 for ; Tue, 13 May 2003 07:10:10 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DE8kuc010770 for ; Tue, 13 May 2003 07:08:46 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4DE8eRh004136 for ; Tue, 13 May 2003 08:08:41 -0600 (MDT) Received: from IDLEWYLDE.windriver.com ([147.11.233.27]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id HAA16023; Tue, 13 May 2003 07:08:33 -0700 (PDT) Message-Id: <5.1.0.14.2.20030513100218.04a3ff30@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 13 May 2003 10:04:39 -0400 To: Brian E Carpenter From: Margaret Wasserman Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3EC0F912.4C99B190@hursley.ibm.com> References: <963621801C6D3E4A9CF454A1972AE8F5045816@server2000.arneill-py.sacramento.ca.us> <5.1.0.14.2.20030513073116.048b7c58@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, At 03:54 PM 5/13/2003 +0200, Brian E Carpenter wrote: >I have to be a bit careful here... I don't want to restart the >scope wars on this thread, I certainly don't either... >but I have severe doubts whether scope >rules can be defined with the sort of mathematical clarity >you might like. Given the prevalence of VPNs between private >networks, I have difficulty knowing what a useful definition would >look like. So I will actually decline to answer the question >about what scope means, because I don't know any more (apart from >link-local). Well, since we don't seem to have agreement on what the term means outside of the link-local case, perhaps we should try to stop using it? I think that it just leads to miscommunication. >This is linked to your last point. We do have to leave a lot of this to >the operations community, and the question is what can we usefully >give them in the way of generic scope mechanisms? Perhaps we should try asking them what they need? I realize that this is easier said than done (I'm fairly involved in the network management area...), but I think it's at least worth a try. 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 May 13 09:09:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DG9Jhs002261; Tue, 13 May 2003 09:09:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DG9Jk1002260; Tue, 13 May 2003 09:09:19 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DG9Fhs002253 for ; Tue, 13 May 2003 09:09:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DG7pKw006311 for ; Tue, 13 May 2003 09:07:51 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAA28567 for ; Tue, 13 May 2003 09:07:42 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 13 May 2003 09:07:54 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504581F@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMZEfgnexTim3fhRBq96F0XdL3BkAASBG3A From: "Michel Py" To: "Brian Carpenter" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4DG9Ghs002254 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, >> Michel Py wrote: >> I though we were on agreement that routing table bloat >> was not a good idea? > Indeed. But if a few Megacorps are willing to pay the ISPs > to carry specific routes, that won't bloat the tables. If > a lot of medium size companies tried the same, it would be > bad. Who's talking about a handful of few megacorps? Although it might be unfair, they will get their prefix announced no matter what; this is a fact of life. What do you plan to do in order to prevent small and mid-size businesses from announcing their prefix? All it takes is one salesdroid to figure it out; today lots of ISPs would gladly leak the customer's prefix for free just as an incentive to keep an existing customer or capture a new one. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 09:15:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DGFWhs002316; Tue, 13 May 2003 09:15:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DGFWat002315; Tue, 13 May 2003 09:15:32 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DGFShs002305 for ; Tue, 13 May 2003 09:15:28 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DGE4uc021840 for ; Tue, 13 May 2003 09:14:04 -0700 (PDT) Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4DGDxRh015520 for ; Tue, 13 May 2003 10:13:59 -0600 (MDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by e6.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4DGDuxr118288 for ; Tue, 13 May 2003 12:13:57 -0400 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4DGDsK8233944 for ; Tue, 13 May 2003 18:13:55 +0200 Received: from gsine05.us.sine.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA39266 from ; Tue, 13 May 2003 18:13:50 +0200 Message-Id: <3EC119DA.A7CDD297@hursley.ibm.com> Date: Tue, 13 May 2003 18:14:18 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <963621801C6D3E4A9CF454A1972AE8F504581F@server2000.arneill-py.sacramento.ca.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk My original point was indeed that nothing we write in an RFC can prevent this happening, except (possibly) if we find a radically better solution. Brian Michel Py wrote: > > Brian, > > >> Michel Py wrote: > >> I though we were on agreement that routing table bloat > >> was not a good idea? > > > Indeed. But if a few Megacorps are willing to pay the ISPs > > to carry specific routes, that won't bloat the tables. If > > a lot of medium size companies tried the same, it would be > > bad. > > Who's talking about a handful of few megacorps? Although it might be > unfair, they will get their prefix announced no matter what; this is a > fact of life. > > What do you plan to do in order to prevent small and mid-size businesses > from announcing their prefix? All it takes is one salesdroid to figure > it out; today lots of ISPs would gladly leak the customer's prefix for > free just as an incentive to keep an existing customer or capture a new > one. > > Michel. -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter Distinguished Engineer, Internet Standards & Technology, IBM On assignment at the IBM Zurich Laboratory, Switzerland -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 13 10:16:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DHGHhs002916; Tue, 13 May 2003 10:16:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DHGH3Z002915; Tue, 13 May 2003 10:16:17 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DHGDhs002908 for ; Tue, 13 May 2003 10:16:14 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DHEnKw029107 for ; Tue, 13 May 2003 10:14:49 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4DHEihm011779 for ; Tue, 13 May 2003 11:14:44 -0600 (MDT) 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 KAA12877; Tue, 13 May 2003 10:14:39 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4DHEcA00573; Tue, 13 May 2003 10:14:38 -0700 X-mProtect: <200305131714> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.159, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdnp3g5h; Tue, 13 May 2003 10:14:36 PDT Message-Id: <4.3.2.7.2.20030513095224.028b4e98@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 May 2003 10:13:59 -0700 To: "Michel Py" From: Bob Hinden Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Cc: In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504581F@server2000.arneill- py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Michel, >Who's talking about a handful of few megacorps? Although it might be >unfair, they will get their prefix announced no matter what; this is a >fact of life. > >What do you plan to do in order to prevent small and mid-size businesses >from announcing their prefix? All it takes is one salesdroid to figure >it out; today lots of ISPs would gladly leak the customer's prefix for >free just as an incentive to keep an existing customer or capture a new >one. I agree that if these non-aggregatable /48 prefixes were to be widely advertised it would create a route scaling problem for the Internet. This would, of course, be vary bad. However, I do not think this is likely to happen. I think the length of the prefix (i.e., /48) helps to make this very hard beyond a few directly connected ISPs. I think ISPs will as a general policy filter all prefixes longer than "n", where "n" is <= 48. I think this type of filtering is fairly common in IPv4. This will make it very hard for a /48 prefix of any type to be widely advertised, unless (as I think Pekka Savola said) they are willing to pay all ISPs to carry it. This should be enough of a disincentive to keep it from being a significant problem. 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 Tue May 13 10:29:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DHT0hs003093; Tue, 13 May 2003 10:29:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DHSxAn003092; Tue, 13 May 2003 10:28:59 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DHSuhs003085 for ; Tue, 13 May 2003 10:28:56 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DHRWuc021944 for ; Tue, 13 May 2003 10:27:32 -0700 (PDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4DHRQRh013580 for ; Tue, 13 May 2003 11:27:27 -0600 (MDT) Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 13 May 2003 10:27:23 -0700 Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 May 2003 10:27:22 -0700 Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 May 2003 10:27:22 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 13 May 2003 10:27:21 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 May 2003 10:27:21 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 13 May 2003 10:27:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Tue, 13 May 2003 10:27:20 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses thread-index: AcMZbyvkqZc3hTV5T46g3l9cuVsB3QABQDxg From: "Christian Huitema" To: "Brian E Carpenter" , X-OriginalArrivalTime: 13 May 2003 17:27:21.0227 (UTC) FILETIME=[E8FC85B0:01C31974] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4DHSuhs003086 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > > What do you plan to do in order to prevent small and mid-size businesses > > from announcing their prefix? All it takes is one salesdroid to figure > > it out; today lots of ISPs would gladly leak the customer's prefix for > > free just as an incentive to keep an existing customer or capture a new > > one. The only way to prevent that from happening is peer pressure from other ISPs. In practice the only tool ISPs have is to filter out announces of offending prefixes. Where the IETF can help is with a definition of "offending", so ISPs who filter can point to a standard when they get sued. Possible definition of offending include prefixes that are too long, prefixes that start by a scoped out string, etc. -- 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 May 13 10:29:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DHTAhs003103; Tue, 13 May 2003 10:29:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DHT9xD003102; Tue, 13 May 2003 10:29:09 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DHT4hs003095 for ; Tue, 13 May 2003 10:29:04 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DHRdKw008926 for ; Tue, 13 May 2003 10:27:40 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4DHRYhm017728 for ; Tue, 13 May 2003 11:27:34 -0600 (MDT) 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 KAA13501; Tue, 13 May 2003 10:27:33 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4DHRWR12505; Tue, 13 May 2003 10:27:32 -0700 X-mProtect: <200305131727> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.159, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdhDjy4n; Tue, 13 May 2003 10:27:30 PDT Message-Id: <4.3.2.7.2.20030513101430.028b4e98@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 May 2003 10:26:54 -0700 To: Margaret Wasserman From: Bob Hinden Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Cc: ipng@sunroof.eng.sun.com In-Reply-To: <5.1.0.14.2.20030513073116.048b7c58@mail.windriver.com> References: <3EC08504.441F0A58@hursley.ibm.com> <963621801C6D3E4A9CF454A1972AE8F5045816@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret, >Bob's proposal explicitly defines a type of addresses that are not >expected to be routed throughout the Internet. So, these addresses >are local, not globally routable. > >However, Bob's proposal defines addresses that are unique throughout >the Internet. No single address identifies one node when used within >one "scope" and another node when used in another "scope". So, these >are not "scoped addresses", as defined in the IPv6 Scoped Addressing >Architecture. > >I *think* that Bob and I are using the same definition for the >term "scoped", but I hope he'll correct me if I'm wrong. I tried hard to not define the term "scoped address". I only used the word "scope" once in the draft and that referred to global scope addresses. I may remove that use in the next version :-) The globally unique IPv6 local unicast addresses are not limited in their use to any scope less than global by their design because they have prefixes that are globally unique. By comparison site-local addresses were limited to a limited scope by their design because they had non-globally unique prefixes. So yes, I think we agree. 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 Tue May 13 10:30:51 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DHUphs003159; Tue, 13 May 2003 10:30:51 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DHUpSc003158; Tue, 13 May 2003 10:30:51 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DHUkhs003142 for ; Tue, 13 May 2003 10:30:46 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DHTMKw010397 for ; Tue, 13 May 2003 10:29:22 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4DHTHPH013834 for ; Tue, 13 May 2003 10:29:17 -0700 (PDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 13 May 2003 10:29:17 -0700 Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 May 2003 10:29:17 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 May 2003 10:29:16 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 May 2003 10:29:16 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 13 May 2003 10:29:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Tue, 13 May 2003 10:29:12 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses thread-index: AcMZdHw5DGYpIU5PRZuh/vr80BkkjQAAHtGw From: "Christian Huitema" To: "Bob Hinden" , "Michel Py" Cc: X-OriginalArrivalTime: 13 May 2003 17:29:15.0966 (UTC) FILETIME=[2D604DE0:01C31975] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4DHUlhs003143 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > I think the length of the prefix (i.e., /48) helps to make this very hard > beyond a few directly connected ISPs. I think ISPs will as a general > policy filter all prefixes longer than "n", where "n" is <= 48. I think > this type of filtering is fairly common in IPv4. This will make it very > hard for a /48 prefix of any type to be widely advertised, unless (as I > think Pekka Savola said) they are willing to pay all ISPs to carry > it. This should be enough of a disincentive to keep it from being a > significant problem. OTOH, it possible to use overlay technologies, e.g. distributed hash tables, to route these packets over a PA-addressed network. -- 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 May 13 10:58:55 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DHwshs004146; Tue, 13 May 2003 10:58:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DHwsQC004145; Tue, 13 May 2003 10:58:54 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DHwphs004138 for ; Tue, 13 May 2003 10:58:51 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DHvRKw003494 for ; Tue, 13 May 2003 10:57:27 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4DHvLPH004858 for ; Tue, 13 May 2003 10:57:21 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 13 May 2003 10:57:34 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F7E9@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMZcy4LU0AjiDb4TheiZuuwEMZSxQAAVjGw From: "Michel Py" To: "Bob Hinden" , "Christian Huitema" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4DHwphs004139 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > I agree that if these non-aggregatable /48 prefixes were to be > widely advertised it would create a route scaling problem for > the Internet. This would, of course, be vary bad. However, I do > not think this is likely to happen. > I think the length of the prefix (i.e., /48) helps to make this > very hard beyond a few directly connected ISPs. I think ISPs > will as a general policy filter all prefixes longer than "n", > where "n" is <= 48. I think this type of filtering is fairly > common in IPv4. This will make it very hard for a /48 prefix > of any type to be widely advertised, unless (as I think Pekka > Savola said) they are willing to pay all ISPs to carry it. > This should be enough of a disincentive to keep it from being > a significant problem. I do not share this point of view. As of today, I am already getting all kinds of prefix announcements from one of my IPv6 ISPs, not only /48s but all the way down to /64s. They don't filter at all, and this is _before_ any kind of PI addressing scheme is available. > Christian Huitema wrote: > The only way to prevent that from happening is peer pressure > from other ISPs. In practice the only tool ISPs have is to > filter out announces of offending prefixes. I agree. However, peer pressure happens only when there are a relatively small number of black sheep and/or when peering is difficult. In today's IPv6 business model without a DFZ where everyone provides free transit to everyone, it is relatively easy for an ISP that would decide not to filter (because they want to capture the IPv6 market) to find peers that would think the same way. Playing the devil's advocate, there even are some technical arguments for doing this: yes it does increase routing table size but OTOH it can reduce "scenic routing". Since this would provide a "solution" to the multihoming problem you can be sure that they would be popular, especially if the addresses are issued by some official entity/registry that has IETF/IANA's blessing. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 10:59:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DHxrhs004190; Tue, 13 May 2003 10:59:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DHxrIO004189; Tue, 13 May 2003 10:59:53 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DHxnhs004182 for ; Tue, 13 May 2003 10:59:50 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DHwPKw004395 for ; Tue, 13 May 2003 10:58:25 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4DHwJRh006435 for ; Tue, 13 May 2003 11:58:20 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4DHw5l22740; Tue, 13 May 2003 20:58:05 +0300 Date: Tue, 13 May 2003 20:58:05 +0300 (EEST) From: Pekka Savola To: Bob Hinden cc: Margaret Wasserman , Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <4.3.2.7.2.20030513101430.028b4e98@mailhost.iprg.nokia.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 13 May 2003, Bob Hinden wrote: > >Bob's proposal explicitly defines a type of addresses that are not > >expected to be routed throughout the Internet. So, these addresses > >are local, not globally routable. > > > >However, Bob's proposal defines addresses that are unique throughout > >the Internet. No single address identifies one node when used within > >one "scope" and another node when used in another "scope". So, these > >are not "scoped addresses", as defined in the IPv6 Scoped Addressing > >Architecture. > > > >I *think* that Bob and I are using the same definition for the > >term "scoped", but I hope he'll correct me if I'm wrong. > > I tried hard to not define the term "scoped address". I only used the word > "scope" once in the draft and that referred to global scope addresses. I > may remove that use in the next version :-) > > The globally unique IPv6 local unicast addresses are not limited in their > use to any scope less than global by their design because they have > prefixes that are globally unique. By comparison site-local addresses were > limited to a limited scope by their design because they had non-globally > unique prefixes. > > So yes, I think we agree. What would you propose to do with default address selection, if any? Should a preference in it be given to truly global or globally unique local addresses, or should these be indistinguishable from the point of view? This "addresses tried first" ordering is of some importance -- which one reason for having this "scope" concept. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 13 11:03:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DI3rhs004337; Tue, 13 May 2003 11:03:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DI3qUn004336; Tue, 13 May 2003 11:03:52 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DI3mhs004320 for ; Tue, 13 May 2003 11:03:48 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DI2Ouc023776 for ; Tue, 13 May 2003 11:02:24 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4DI2JPH008716 for ; Tue, 13 May 2003 11:02:19 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 13 May 2003 11:02:31 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F5045821@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMZdh46jTASZ/8rSkutxev4QPFDYgAAzvkg From: "Michel Py" To: "Bob Hinden" , "Margaret Wasserman" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4DI3nhs004322 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, > Bob Hinden wrote: > The globally unique IPv6 local unicast addresses are not limited > in their use to any scope less than global by their design because > they have prefixes that are globally unique. By comparison > site-local addresses were limited to a limited scope by their > design because they had non-globally unique prefixes. My reading as well, which is precisely why I say that it would have been possible to remove ambiguity of site-local addresses because they had a limited scope and why it's not possible with globally unique IPv6 local unicast addresses because of the lack of limitation by scope. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 11:19:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DIJdhs004960; Tue, 13 May 2003 11:19:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DIJddH004959; Tue, 13 May 2003 11:19:39 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DIJahs004952 for ; Tue, 13 May 2003 11:19:36 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DIIBKw026639 for ; Tue, 13 May 2003 11:18:11 -0700 (PDT) Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4DII60W029019 for ; Tue, 13 May 2003 12:18:06 -0600 (MDT) Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h4DII36H023477; Tue, 13 May 2003 11:18:04 -0700 (PDT) Received: from cisco.com (sjc-vpn3-10.cisco.com [10.21.64.10]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA19742; Tue, 13 May 2003 11:18:02 -0700 (PDT) Message-ID: <3EC136D9.9020409@cisco.com> Date: Tue, 13 May 2003 11:18:01 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Hinden CC: Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <3EC08504.441F0A58@hursley.ibm.com> <963621801C6D3E4A9CF454A1972AE8F5045816@server2000.arneill-py.sacramento.ca.us> <4.3.2.7.2.20030513101430.028b4e98@mailhost.iprg.nokia.com> In-Reply-To: <4.3.2.7.2.20030513101430.028b4e98@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob, I've read the draft, and ultimately I think Michel is correct in a couple of important ways that need to be carefully considered: 1. There really is no way to keep these addresses out of DNS. That's an operational BCP, perhaps, but the standard can't do much here. 2. It might be just as well because big honking enterprises are going to get their prefixes announced into the DFZ *anyway*. While it's good simplify the architectural constructs, particularly when it comes to the ambiguity introduced with SLs, and while I see this draft as addressing the disconnected network reasonably well, I'm still left with the concern that what will really happen is that people will go and get a PI address in order to avoid renumbering and then end up NATing *that* because it won't be routable. So while it's an marked improvement over SLs, I'm not sure it's enough of an improvement on its own. That begs the question. What is? I am hearing deafening silence when it comes to how prefix delegation will handle a large scale renumbering, particularly from a DNS standpoint. Are we expecting this to work through DDNS? If so, will a renumbering event today cause a DDOS attack on the name server? Where is this work to be done? Eliot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 13 12:15:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DJF7hs005727; Tue, 13 May 2003 12:15:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DJF7tn005726; Tue, 13 May 2003 12:15:07 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DJF4hs005719 for ; Tue, 13 May 2003 12:15:04 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DJDdKw013598 for ; Tue, 13 May 2003 12:13:39 -0700 (PDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4DJDWY9002238 for ; Tue, 13 May 2003 13:13:32 -0600 (MDT) Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.6624); Tue, 13 May 2003 12:13:31 -0700 Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 13 May 2003 12:13:31 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 13 May 2003 12:13:31 -0700 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(6.0.3790.0); Tue, 13 May 2003 12:13:31 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3788.0); Tue, 13 May 2003 12:13:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6851.8 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Tue, 13 May 2003 12:13:29 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses thread-index: AcMZf7+m+CZreDNwS/q30Q2WINlzgwAA25ww From: "Christian Huitema" To: "Eliot Lear" , "Bob Hinden" Cc: "Margaret Wasserman" , X-OriginalArrivalTime: 13 May 2003 19:13:30.0571 (UTC) FILETIME=[BD6949B0:01C31983] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4DJF4hs005720 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > While it's good simplify the architectural constructs, particularly when > it comes to the ambiguity introduced with SLs, and while I see this > draft as addressing the disconnected network reasonably well, I'm still > left with the concern that what will really happen is that people will > go and get a PI address in order to avoid renumbering and then end up > NATing *that* because it won't be routable. The only way to prevent that from happening is to define a form of scoping. If the GUILUA addresses are supposed to be in a scope of their own, then the hosts stacks can be instructed that they cannot be used as a source address when communicating with a non-GUILUA destination, and vice versa. If you wire that in enough hosts, then the NATing scenario that you describe will become a deployment nightmare, and the networks will end up using a different approach. -- 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 May 13 14:54:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DLsHhs006560; Tue, 13 May 2003 14:54:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DLsGYe006559; Tue, 13 May 2003 14:54:16 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DLsBhs006552 for ; Tue, 13 May 2003 14:54:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DLqjKw024030 for ; Tue, 13 May 2003 14:52:46 -0700 (PDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4DLqUPH019449 for ; Tue, 13 May 2003 14:52:30 -0700 (PDT) Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4DLqM3j005323; Tue, 13 May 2003 14:52:23 -0700 (PDT) Received: from cisco.com (sjc-vpn3-205.cisco.com [10.21.64.205]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA14330; Tue, 13 May 2003 14:52:24 -0700 (PDT) Message-ID: <3EC16917.1060000@cisco.com> Date: Tue, 13 May 2003 14:52:23 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Huitema CC: Bob Hinden , Margaret Wasserman , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, > The only way to prevent that from happening is to define a form of > scoping. I disagree. I think the only way to deal with the problem I describe is to deal with renumbering properly. Now, where shall that work be done? Eliot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 13 15:11:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DMBRhs006816; Tue, 13 May 2003 15:11:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DMBRKB006815; Tue, 13 May 2003 15:11:27 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DMBGhs006808 for ; Tue, 13 May 2003 15:11:18 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DM9quc017381 for ; Tue, 13 May 2003 15:09:52 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4DM9lPH029465 for ; Tue, 13 May 2003 15:09:47 -0700 (PDT) Received: from IDLEWYLDE.windriver.com ([147.11.233.27]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id PAA11262; Tue, 13 May 2003 15:09:33 -0700 (PDT) Message-Id: <5.1.0.14.2.20030513180349.04aa5e40@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 13 May 2003 18:04:21 -0400 To: Eliot Lear From: Margaret Wasserman Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Cc: Christian Huitema , Bob Hinden , ipng@sunroof.eng.sun.com In-Reply-To: <3EC16917.1060000@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Eliot, If you understand how to deal with renumbering properly, it might make sense to hold a BOF... Margaret At 02:52 PM 5/13/2003 -0700, Eliot Lear wrote: >Christian, > >>The only way to prevent that from happening is to define a form of >>scoping. > >I disagree. I think the only way to deal with the problem I describe is >to deal with renumbering properly. Now, where shall that work be done? > >Eliot > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 13 15:28:27 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DMSRhs007089; Tue, 13 May 2003 15:28:27 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DMSQCa007088; Tue, 13 May 2003 15:28:26 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DMSNhs007081 for ; Tue, 13 May 2003 15:28:23 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DMQxuc000526 for ; Tue, 13 May 2003 15:26:59 -0700 (PDT) Received: from fuchsia.home (ip26.coe.tnet.co.th [203.146.155.26]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4DMQoY9026836 for ; Tue, 13 May 2003 16:26:51 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h4DMPh6d006442 for ; Wed, 14 May 2003 05:25:44 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4DMMEf25750 for ; Wed, 14 May 2003 05:22:16 +0700 (ICT) From: Robert Elz To: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <5.1.0.14.2.20030513073116.048b7c58@mail.windriver.com> References: <5.1.0.14.2.20030513073116.048b7c58@mail.windriver.com> <963621801C6D3E4A9CF454A1972AE8F5045816@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 May 2003 05:22:14 +0700 Message-ID: <25748.1052864534@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 13 May 2003 07:51:59 -0400 From: Margaret Wasserman Message-ID: <5.1.0.14.2.20030513073116.048b7c58@mail.windriver.com> | At this point, I think we're really having an argument about what | "scope" means... This has all been most amusing... | I think of "scoped" addresses as unreachable, local and ambiguous, That's an odd definition, which seems designed more such that LLs and SLs (those kinds of addresses) are the only ones that get the label attached, as if "scope" is a pejorative annotation, and must be avoided at all costs just because it is evil (regardless of what it implies). | It seems to me, though, that they may be _scoped_ by your | definition and Tony's... Could you provide a definition? For me, a scoped address is anything which doesn't work similarly at any two points on the connected internet (similarly to allow differences related to RTT, packet loss rates, etc, to be ignored - but that's all that should be ignored). Actually all addresses are scoped - the "global" addresses we talk of are scoped to our Internet - someone setting up a rival internet could use all the same addresses in their own "global" scope. But I'm not sure this matters. | However, Bob's proposal defines addresses that are unique throughout | the Internet. That lasted all of a day... The proposals to allow people to invent their own random numbers rather than paying 10 Eur to some bureaucracy (along with a delay of probably several days) took that long to appear - with the (perfectly correct) rationalisation that allow it or not, people will do it, so there may as well at least be a way to formalise it. Brian contended that (some) people will want addresses that are known unique, but without some kind of enforcement policy that's impossible, and Bob's proposal has exactly none of that - the addresses are local and private, which means that no-one can know what addresses I'm using (unless I tell them) and so there's no way they can know that I just happened to pick the same number they did. The only way to enforce uniqueness is to make the addresses fail to work in some respect that matters (IP6.ARPA doesn't matter, so it doesn't help). The only way that matters for addresses really is routing, so for any address that isn't globally routed, ambiguity will be a fact of life. Accept it. Christian used the birthday paradox to assume that 41 bits of random number would not be enough - but while I am no statistician, I suspect that he got the domain wrong - it doesn't matter in the slightest what the probability is of a clash of identifiers with everyone else in the world, they don't see my ID and I don't see theirs - the set of sites (organisations if "site" is another bad word) with whom I want to have a high probability of no duplications is the ones with whom I want to share these addresses, and that set will usually be numbered in the hundreds, perhaps thousands, but certainly not billions. In any case, after all this, it is interesting to see that what we're left with is exactly Paul Francis NUSLA proposal (from a bit over 2 years ago I think, or was it 3?) except perhaps with the prefix changed. Truly nothing new... (and yes, I know the draft says that, this is not a criticism). kre ps: for what it is worth, I have no problems with this proposal, except the silly idea that anyone with half a brain would pay money to have a random number allocated. It retains the parts of site local that are important. Unfortunately (for Jim), it won't allow the scoping in his implementation to be removed, that's still needed for link locals - the only simplification this will allow (to anything) is to avoid the need for scope-aware routing. I'd also have no problem if the prefix were a /10 instead of /7, that's big enough. pps: No way could the ISOC just be handed the right to administer this space if it were to be administered - there's enormous revenue at stake here, and Govts all over the place are going to want to try and get it into their domain, so they get the benefits - India and China certainly have good claims, why should their (combined) > 2B population all be sending revenue to yet another US based organisation? -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 13 15:43:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DMhJhs007312; Tue, 13 May 2003 15:43:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DMhJfC007311; Tue, 13 May 2003 15:43:19 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DMhFhs007304 for ; Tue, 13 May 2003 15:43:16 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DMfpKw000123 for ; Tue, 13 May 2003 15:41:51 -0700 (PDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4DMfjhm015292 for ; Tue, 13 May 2003 16:41:45 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1CEFFBA9A; Tue, 13 May 2003 18:41:45 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Tue, 13 May 2003 18:41:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Tue, 13 May 2003 18:41:44 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD861@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMZR8jAAsxprteJTSaFdCUokLem5gAV9KnQ From: "Bound, Jim" To: "Margaret Wasserman" , "Brian E Carpenter" Cc: "Michel Py" , X-OriginalArrivalTime: 13 May 2003 22:41:44.0954 (UTC) FILETIME=[D4A4D5A0:01C319A0] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4DMhGhs007305 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk FOlks, unicast scope to implementor means this. I must know from a state machine or conditon that an address applies to a specific interface for a scope: link-local, site-local, and global. This is a simple definition and suggest for what I am about to say the more complex regarding slices through hosts, nets, and interfaces is not needed for now. as implementors we know how to do global address it can go over any scope above. as implementors "most" of us (not all IMO) have learned how to do deal with link-local when on same machine for two different links. we have proven we know this by interoperability testing, IPv6 forum lab testing, test suites, test beds running, and with early adopter customers we have using multiple links and link-local. we also know the affect above as standards architectects and designers of extensions to protocols. we understand the above "clearly" in my view. Ipv6 some day will be able to go far beyond this simple scoping and its in the architecture. Bob's spec gives us site communications but with global scoping and with some rules to reduce pain. All pain no. But enough to move forward. The spec removed the abmbiguity of scoping from the discussion to give users a means to use addresses only within their site. We have the skill here to build a standard from it, implement it and deploy it after those two acts. To me this is a no brainer and problem solved. Why not spend our time making the spec better and ready for IESG for PS whenever we can instead of debating its merits. This IMO is the mature, time-to-market, and compromised solution for us all to get what we want and do some real work as a team and move forward. Just my .25cents, /jim > -----Original Message----- > From: Margaret Wasserman [mailto:mrw@windriver.com] > Sent: Tuesday, May 13, 2003 7:52 AM > To: Brian E Carpenter > Cc: Michel Py; ipng@sunroof.eng.sun.com > Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses > > > > Hi Brian, > > At 07:39 AM 5/13/2003 +0200, Brian E Carpenter wrote: > >Well, I am too literal minded to have read that in the proposal. I > >think it changes the scoping debate, but doesn't abolish it. As Tony > >Hain has pointed out, scope is a fact of life, whether we > architect it > >or not. > > At this point, I think we're really having an argument about > what "scope" means... > > Does it mean that addresses have a certain scope in which > they are: reachable? routable? unique? Does it mean that > the match the description of scoped addressing in the IPv6 > Scoped Addressing Architecture? > > I apply the following terms to these distinctions: > > Reachable & Unreachable > Globally Routable & Local > Globally Unique & Ambiguous > > I think of "scoped" addresses as unreachable, local and > ambiguous, with all three attributes constrained at the same > boundary (the site boundary, in the case of site-locals). > > So, by my definitions, the addresses described in Bob's > proposal are _local_ addresses, but they are not _scoped_ addresses. > > It seems to me, though, that they may be _scoped_ by your > definition and Tony's... Could you provide a definition? > > I am pretty certain that we all agree that there will > continue to be firewalls in IPv6, and that those firewalls > will make some addresses (and some address/port combinations) > unreachable from other parts of the network. This will apply > to both globally routable and local addresses, so any address > could be unreachable from some parts of the network. > > Bob's proposal explicitly defines a type of addresses that > are not expected to be routed throughout the Internet. So, > these addresses are local, not globally routable. > > However, Bob's proposal defines addresses that are unique > throughout the Internet. No single address identifies one > node when used within one "scope" and another node when used > in another "scope". So, these are not "scoped addresses", as > defined in the IPv6 Scoped Addressing Architecture. > > I *think* that Bob and I are using the same definition for > the term "scoped", but I hope he'll correct me if I'm wrong. > > > > > I though we were on agreement that routing table bloat was not a > > > good idea? > > > >Indeed. But if a few Megacorps are willing to pay the ISPs to carry > >specific routes, that won't bloat the tables. If a lot of > medium size > >companies tried the same, it would be bad. > > As long as the cost of having a private address block routed > across the Internet is high-enough that it makes financial > sense for a Megacorp to do it, but it doesn't make sense for > a mid-sized company to do it, then this would work fine... > > Personally, I think that the IETF should design the right > technical solutions for addressing and leave it up to the > registries and providers to determine the appropriate > policies and business models for addressing. But, perhaps > I'm just naive. > > 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 Tue May 13 15:50:22 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DMoMhs007413; Tue, 13 May 2003 15:50:22 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DMoLqU007412; Tue, 13 May 2003 15:50:21 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DMoIhs007404 for ; Tue, 13 May 2003 15:50:18 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DMmrKw005079 for ; Tue, 13 May 2003 15:48:54 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4DMmmRh016267 for ; Tue, 13 May 2003 16:48:48 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 170FB691; Tue, 13 May 2003 18:48:48 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Tue, 13 May 2003 18:48:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Tue, 13 May 2003 18:48:47 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD862@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMZm2ldiDjncnUeQDq4Qcbi+mZz8AABl2sQ From: "Bound, Jim" To: "Eliot Lear" , "Christian Huitema" Cc: "Bob Hinden" , "Margaret Wasserman" , X-OriginalArrivalTime: 13 May 2003 22:48:47.0976 (UTC) FILETIME=[D0C8DE80:01C319A1] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4DMoIhs007406 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk We could start with router vendors implementing router renumbering on test beds and at interoperability events :--) /jim > -----Original Message----- > From: Eliot Lear [mailto:lear@cisco.com] > Sent: Tuesday, May 13, 2003 5:52 PM > To: Christian Huitema > Cc: Bob Hinden; Margaret Wasserman; ipng@sunroof.eng.sun.com > Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses > > > Christian, > > > The only way to prevent that from happening is to define a form of > > scoping. > > I disagree. I think the only way to deal with the problem I > describe is > to deal with renumbering properly. Now, where shall that > work be done? > > Eliot > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 13 16:00:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DN0dhs007861; Tue, 13 May 2003 16:00:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DN0dEE007860; Tue, 13 May 2003 16:00:39 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DN0Zhs007850 for ; Tue, 13 May 2003 16:00:35 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DMxBuc022291 for ; Tue, 13 May 2003 15:59:11 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4DMx5Y9015844 for ; Tue, 13 May 2003 16:59:05 -0600 (MDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 0777AAB6D; Tue, 13 May 2003 18:59:05 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Tue, 13 May 2003 18:59:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Summary: Avoiding interface failure upon DAD failure Date: Tue, 13 May 2003 18:59:04 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03241252@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary: Avoiding interface failure upon DAD failure Thread-Index: AcMYmgMZeI8WPadsQU+mZEAav7A//ABB+REA From: "Bound, Jim" To: "Jari Arkko" , X-OriginalArrivalTime: 13 May 2003 22:59:04.0822 (UTC) FILETIME=[40741960:01C319A3] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4DN0Zhs007851 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Jari, Charlie and I have been having an offline discussion. We don't fully agree but we agree on a lot more :--) And reading the mail. Here is wild suggestion and close to what you first proposed with restriction clause. In the spec: MAY use 3041 in DAD failure. But I would suggest wording that this is for the specific case of a "mobile node" moving. The reason I change is because I believe DAD failures are more possible than stationary nodes. The market requires mobile nodes and the mipv6 spec done. This is a solution for today and right now. The additional text states this does not apply to stationary nodes so we don't have those nodes ignoring DAD failures. Which was my main concern that we would open pandora's box. With the restriction we keep pandora in her box (not being gender insensitive but pandora was a female sorry and I like this old allegory). Then what we do is go work on this entire problem space of DAD and this is just one of the issues for mobile nodes of many we can work on and really subset of movement detection. We move the MIPv6 spec forward. We define a new problem space for movement detection we need to work on. And we not spend another 5 months debating this with multiple sides feet dug into the mud. We move forward to PS, we implement further (as this spec has a lot of implementation) and we see what happens. If we are wrong we go back and fix it during post PS process. PS is not the end of the day or the end of the work. We are allowed to be wrong once in awhile, but at this point in the IETF we MUST always move forward and begin to help some of the problems we have with getting stuff done in this community at large. My .50cents, /jim > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Monday, May 12, 2003 11:01 AM > To: ipng@sunroof.eng.sun.com > Subject: Summary: Avoiding interface failure upon DAD failure > > > > Hi, > > I'll try to summarize the discussion about this issue and > propose a way forward. > > The proposal was to allow the use of randomly generated > addresses a la 3041 for link-local addresses and care-of > addresses in mobile nodes while they are roaming around. > Since RFC 2462 requires less drastic collision actions > (disable address) for random addresses than for EUI-64 based > addresses (disable interface), this was thought to have a > positive effect to the resiliency of the system, if after > failure one would still like to use the interface after > moving to another link. > > A part of the discussion that arose dealt with the issue > of skipping DAD and how useful (or not) it is. This part > of the discussion is not relevant for our original question, > because we follow the current RFCs and do DAD as specified. > However, it appears to be a periodically discussed subject in > the IPv6 WG. As such, some further work in the WG might look > at that. Ongoing efforts to look at optimistic DAD is one > such item and I will suggest another one later in this e-mail. > > There was also a lot of discussion of EUI-64 -based > address conflicts. This is also outside the scope of > our proposal, and is ignored in this e-mail. > > But back to the proposal and the issues around it. > The following points were made: > > Protocol issues: > > * Clearly, mobile nodes can use RFC 3041 addresses > like any other application. No issue here (Hesham). > > * Mobile IPv6 should disable the link but when moving > to a new link can re-try DAD (Pekka). > > * Discussion concludes that MAY use 3041 (Mika). > > * Move on without this and discuss the issue in depth > in IPv6 later (Jim). > > * There is a need to work on clarifications and > treatment of wireless cases for DAD (Greg). > > Desired behaviour: > > * Collision is so rare, should not bother to prepare > for nice treatment if it happens (Mika). > > * Rare errors should also be handled, many IPv6 > error handling mechanisms such as DAD work > with rare events (Hesham, Jari). > > * Collision means something is serious wrong, should > not continue (Bob, Pekka). > > * Devices should recover by themselves after moving > elsewhere, otherwise device needs user attention > or even service (Jari). > > * Disabling the interface is harmful to users (Charlie). > > * Diagnostics on the mobile node will be able to > tell what's going on (Greg). > > Specifics of collisions: > > * There's a difference if the DAD failure is due to > this node or another node, in the latter case disabling > interface harms future use. Trouble is, hard to know > which case it is (Jari). > > * Inspection of SSLA can tell you whether to disable > the interface or not (Greg). > > * DAD failure means the address is bad, not interface > (Charlie). > > * Why does the collision happen - EUI-64 collision, > software/hardware problem, malicious user, random > collision? This has an impact on the proper "cure". > (Jari, Pekka, Vijay) > > Summary > > A key requirement question is of course whether it is > desireable for the mobile nodes to disable themselves or have > some form of automatic resilience against temporary problems. > There was no clear consensus on this issue (though the > question about whether EUI-64 or something else is used > affected the discussion). My belief is that some level of > resilience is necessary, unless EUI-64 addresses are used. > This idea seems to be built into RFC 2462 as well, because it > has different collision actions. > > Another important question is to what extent the > existing protocols already support the desired > behaviour. Clearly, mobile nodes can use 3041 > addresses when they move around just like other > nodes. Given the current 2462 rules, collisions > for such addresses do not disable the interface. > There are two limitations of this, however: (a) > 3041 does not specify the creation of link-local > addresses and (b) 3041 says that after 5 collisions, > stop generating any more addresses on that interface. > This is almost sufficient for the desired behaviour, > since mobile node could presumably use only global > care-of addresses, and getting to five collisions > is highly unlikely. (Though it would seem better > to have the limit per link.) > > Another current protocol facility is Neighbor > Discovery in general, its concept of an interface. > We've lately started to realize that it may not > always be clear what is considered as an interface. > Does movement to a new link constitute the initialization > of an interface, resetting all knowledge of DAD failures, > reconstructing all data structures? > > Recommended way forward: > > Existing specifications already can give (very) limited > support for the feature that we desired. We could add > the link-local case and in doing so say that the 5-collision > limit is per link. We could also specify that DAD issues in > general are "reset" upon movement to a new link. The latter > in particular would appear quite reasonable. However, I am > afraid of two things: (1) Perhaps the understanding for what > ND information gets reset in what kind of movements should be > developed in full for all of ND, and not just for the > particular case of collisions. (2) Continued discussion. > > Therefore, my recommendation is that we delete the Section > 7.6 from the Mobile IPv6 draft that deals with this issue, > and work for the better understanding of what an interface > means in the context of the following work: > > - A full & optimized movement detection scheme that has > been suggested to be worked on in the MIP WG or one of > its follow-up WGs. > > - Optimized DAD. > > - Possible other new work taking place wrt ND or DAD. > > --Jari > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 16:04:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DN4Jhs007996; Tue, 13 May 2003 16:04:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4DN4J73007994; Tue, 13 May 2003 16:04:19 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4DN4Fhs007985 for ; Tue, 13 May 2003 16:04:15 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4DN2ouc024476 for ; Tue, 13 May 2003 16:02:50 -0700 (PDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4DN2j0W017941 for ; Tue, 13 May 2003 17:02:45 -0600 (MDT) Received: from nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 62E48137F02; Tue, 13 May 2003 16:02:40 -0700 (PDT) Date: Tue, 13 May 2003 16:02:37 -0700 Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "Eliot Lear" , "Christian Huitema" , "Bob Hinden" , "Margaret Wasserman" , To: "Bound, Jim" From: David Conrad In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD862@tayexc13.americas.cpqcorp.net> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Router renumbering is trivial compared to modifying applications running within a site that have hardcoded addresses in ASCII text files. On Tuesday, May 13, 2003, at 03:48 PM, Bound, Jim wrote: > We could start with router vendors implementing router renumbering on > test beds and at interoperability events :--) > /jim > >> -----Original Message----- >> From: Eliot Lear [mailto:lear@cisco.com] >> Sent: Tuesday, May 13, 2003 5:52 PM >> To: Christian Huitema >> Cc: Bob Hinden; Margaret Wasserman; ipng@sunroof.eng.sun.com >> Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses >> >> >> Christian, >> >>> The only way to prevent that from happening is to define a form of >>> scoping. >> >> I disagree. I think the only way to deal with the problem I >> describe is >> to deal with renumbering properly. Now, where shall that >> work be done? >> >> Eliot >> >> >> -------------------------------------------------------------------- >> IETF IPng Working Group Mailing List >> IPng Home Page: http://playground.sun.com/ipng >> FTP archive: ftp://playground.sun.com/pub/ipng >> Direct all administrative requests to majordomo@sunroof.eng.sun.com >> -------------------------------------------------------------------- >> > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 18:13:19 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4E1DJhs009420; Tue, 13 May 2003 18:13:19 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4E1DJ0O009419; Tue, 13 May 2003 18:13:19 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4E1DFhs009412 for ; Tue, 13 May 2003 18:13:15 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4E1Bpuc015490 for ; Tue, 13 May 2003 18:11:51 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id SAA17272 for ; Tue, 13 May 2003 18:11:45 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Draft on a V6 documentation prefix MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 13 May 2003 18:11:57 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F7ED@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on a V6 documentation prefix Thread-Index: AcMZIVjWgDdRjIz5T6mJOVS4c0+ntAAkp9EQ From: "Michel Py" To: "Tim Chown" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4E1DGhs009413 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tim, >> Michel Py wrote: >> The trouble with using things such as XXXX:XXXX::/32 and >> YYYY:YYYY::/32 is that they can't be configured on a router and >> won't prevent the hijacking of a real prefix when labing the >> case, which is what the documentation prefix tries to prevent >> from happening. > Tim Chown wrote: > So if we do create this prefix, what's the difference between > this and an allocated prefix for private use in networks? Basically none. > You're suggesting it's not a documentation prefix, Not _only_ a documentation prefix. > but a prefix for use in (disconnected) networks. Throw in > v6 NAT and... ;) This is a very valid point that has been made several times before. It is clear that the documentation prefix is a prime candidate for hijacking for NAT purposes. That being said, there are plenty of other good candidates such as returned prefixes of 3ffe::/16, the entire 3ffe::/16 space after 6/6/6, 2002:RFC:1918::, a random prefix out of unallocated space in the C000::/16 range, etc. IMHO a _few_ /32 prefixes would be preferable for lab scenarios (for reasons outlined earlier) and would not encourage NAT more than a single one. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 18:18:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4E1IShs009534; Tue, 13 May 2003 18:18:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4E1IRki009533; Tue, 13 May 2003 18:18:27 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4E1IOhs009526 for ; Tue, 13 May 2003 18:18:24 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4E1H0Kw005571 for ; Tue, 13 May 2003 18:17:00 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4E1Gtx9024835 for ; Tue, 13 May 2003 18:16:55 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 13 May 2003 18:17:08 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F5045823@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMZf7+m+CZreDNwS/q30Q2WINlzgwAA25wwAAzBnqA= From: "Michel Py" To: "Christian Huitema" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4E1IOhs009527 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Christian, > Christian Huitema wrote: > The only way to prevent that from happening is to define a form > of scoping. If the GUILUA addresses are supposed to be in a scope > of their own, then the hosts stacks can be instructed that they > cannot be used as a source address when communicating with a > non-GUILUA destination, and vice versa. This would be too restrictive to many. There are plenty of legitimate uses where a host with a GUILUA address would have to talk to a host with a global address within the same organization. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 13 21:24:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4E4OChs011182; Tue, 13 May 2003 21:24:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4E4OBnb011181; Tue, 13 May 2003 21:24:11 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4E4O8hs011174 for ; Tue, 13 May 2003 21:24:08 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4E4MiKw028654 for ; Tue, 13 May 2003 21:22:44 -0700 (PDT) Received: from ss10.danlan.com ([199.33.144.62]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4E4Mbpd010130 for ; Tue, 13 May 2003 22:22:38 -0600 (MDT) Received: (from ddl@localhost) by ss10.danlan.com (8.9.3/8.9.3) id AAA28594; Wed, 14 May 2003 00:22:24 -0400 (EDT) Date: Wed, 14 May 2003 00:22:24 -0400 (EDT) From: Dan Lanciani Message-Id: <200305140422.AAA28594@ss10.danlan.com> To: ipng@sunroof.eng.sun.com Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Christian Huitema" wrote: |> I think the length of the prefix (i.e., /48) helps to make this very |hard |> beyond a few directly connected ISPs. I think ISPs will as a general |> policy filter all prefixes longer than "n", where "n" is <= 48. I |think |> this type of filtering is fairly common in IPv4. This will make it |very |> hard for a /48 prefix of any type to be widely advertised, unless (as |I |> think Pekka Savola said) they are willing to pay all ISPs to carry |> it. This should be enough of a disincentive to keep it from being a |> significant problem. | |OTOH, it possible to use overlay technologies, e.g. distributed hash |tables, to route these packets over a PA-addressed network. With any luck the use of the "overlay" addresses could overtake the use of the "native" PA addresses (without causing any central routing table explosion, of course). At that time we would be faced with answering the awkward question of why we didn't simply allow routable PI addresses via distributed routing in the first place... Dan Lanciani ddl@danlan.*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 May 14 03:44:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4EAiBhs012583; Wed, 14 May 2003 03:44:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4EAiBEL012582; Wed, 14 May 2003 03:44:11 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4EAi7hs012575 for ; Wed, 14 May 2003 03:44:07 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4EAghuc003603 for ; Wed, 14 May 2003 03:42:43 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4EAgax9020992 for ; Wed, 14 May 2003 03:42:38 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 0EFA0AB63; Wed, 14 May 2003 06:42:31 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Wed, 14 May 2003 06:42:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Wed, 14 May 2003 06:42:30 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03ABD881@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMZo8lu1JGnsO+cS4inAK+iuPPq5gAYbEDg From: "Bound, Jim" To: "David Conrad" Cc: "Eliot Lear" , "Christian Huitema" , "Bob Hinden" , "Margaret Wasserman" , X-OriginalArrivalTime: 14 May 2003 10:42:30.0843 (UTC) FILETIME=[8533D0B0:01C31A05] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4EAi7hs012576 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Your point about stating the obvious? thanks /jim > -----Original Message----- > From: David Conrad [mailto:david.conrad@nominum.com] > Sent: Tuesday, May 13, 2003 7:03 PM > To: Bound, Jim > Cc: Eliot Lear; Christian Huitema; Bob Hinden; Margaret > Wasserman; ipng@sunroof.eng.sun.com > Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses > > > Router renumbering is trivial compared to modifying applications > running within a site that have hardcoded addresses in ASCII > text files. > > On Tuesday, May 13, 2003, at 03:48 PM, Bound, Jim wrote: > > > We could start with router vendors implementing router > renumbering on > > test beds and at interoperability events :--) /jim > > > >> -----Original Message----- > >> From: Eliot Lear [mailto:lear@cisco.com] > >> Sent: Tuesday, May 13, 2003 5:52 PM > >> To: Christian Huitema > >> Cc: Bob Hinden; Margaret Wasserman; ipng@sunroof.eng.sun.com > >> Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses > >> > >> > >> Christian, > >> > >>> The only way to prevent that from happening is to define > a form of > >>> scoping. > >> > >> I disagree. I think the only way to deal with the problem > I describe > >> is to deal with renumbering properly. Now, where shall that > >> work be done? > >> > >> Eliot > >> > >> > >> > -------------------------------------------------------------------- > >> IETF IPng Working Group Mailing List > >> IPng Home Page: http://playground.sun.com/ipng > >> FTP archive: ftp://playground.sun.com/pub/ipng > >> Direct all administrative requests to majordomo@sunroof.eng.sun.com > >> > -------------------------------------------------------------------- > >> > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to majordomo@sunroof.eng.sun.com > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 14 04:01:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4EB1hhs012827; Wed, 14 May 2003 04:01:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4EB1g3o012826; Wed, 14 May 2003 04:01:42 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4EB1dhs012819 for ; Wed, 14 May 2003 04:01:39 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4EB0FKw015215 for ; Wed, 14 May 2003 04:00:15 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id EAA27158 for ; Wed, 14 May 2003 04:00:09 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4EAxUQ01583; Wed, 14 May 2003 17:59:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4EAvhf28391; Wed, 14 May 2003 17:57:45 +0700 (ICT) From: Robert Elz To: "Michel Py" cc: "Tim Chown" , ipng@sunroof.eng.sun.com Subject: Re: Draft on a V6 documentation prefix In-Reply-To: <963621801C6D3E4A9CF454A1972AE8F504F7ED@server2000.arneill-py.sacramento.ca.us> References: <963621801C6D3E4A9CF454A1972AE8F504F7ED@server2000.arneill-py.sacramento.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 May 2003 17:57:43 +0700 Message-ID: <28389.1052909863@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 13 May 2003 18:11:57 -0700 From: "Michel Py" Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F7ED@server2000.arneill-py.sacramento.ca.us> | It is clear that the documentation prefix is a prime candidate for | hijacking for NAT purposes. I had always assumed that the point of specifying a specific prefix as one to be used in documentation, would be that (good) implementations would notice at attempt to configure this particular prefix (someone copying examples from a manual) and refuse to allow it, with a message something along the lines of: That prefix is an example intended for examples only. You need to get a prefix allocated from your provider, or ... and use that instead of the example prefix used in documentation. Otherwise, there's little point having it. If that happens, then this particular prefix turns out to be the one prefix which is particularly unsuited for NAT (or other) hijacking. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 14 08:25:20 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4EFPKhs013928; Wed, 14 May 2003 08:25:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4EFPJZp013927; Wed, 14 May 2003 08:25:19 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4EFPGhs013920 for ; Wed, 14 May 2003 08:25:16 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4EFNqKw012401 for ; Wed, 14 May 2003 08:23:52 -0700 (PDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4EFNlsa009568 for ; Wed, 14 May 2003 09:23:47 -0600 (MDT) Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.6/8.12.6) with ESMTP id h4EFNkxG023352; Wed, 14 May 2003 08:23:47 -0700 (PDT) Received: from cisco.com (sjc-vpn1-352.cisco.com [10.21.97.96]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA06489; Wed, 14 May 2003 08:23:42 -0700 (PDT) Message-ID: <3EC25F7D.50607@cisco.com> Date: Wed, 14 May 2003 08:23:41 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Margaret Wasserman CC: Christian Huitema , Bob Hinden , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <5.1.0.14.2.20030513180349.04aa5e40@mail.windriver.com> In-Reply-To: <5.1.0.14.2.20030513180349.04aa5e40@mail.windriver.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > If you understand how to deal with renumbering properly, it might > make sense to hold a BOF... Honestly I'm not sure I do just yet. I was hoping we could flush out the matter on this list. For all I know, someone already has and I'm just behind the times. See my note to Dave. Eliot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 14 09:09:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4EG9ahs014217; Wed, 14 May 2003 09:09:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4EG9asO014216; Wed, 14 May 2003 09:09:36 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4EG9Whs014209 for ; Wed, 14 May 2003 09:09:32 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4EG89uc010329 for ; Wed, 14 May 2003 09:08:09 -0700 (PDT) Received: from eamail1-out.unisys.com (eamail1-out.unisys.com [192.61.61.99]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id JAB06018 for ; Wed, 14 May 2003 09:08:02 -0700 (PDT) Received: from us-ea-gtwy-7.ea.unisys.com (us-ea-gtwy-7.ea.unisys.com [192.61.145.102]) by eamail1-out.unisys.com (8.12.9/8.12.9) with ESMTP id h4EG7DJu009340 for ; Wed, 14 May 2003 16:07:16 GMT Received: by us-ea-gtwy-7.ea.unisys.com with Internet Mail Service (5.5.2656.59) id ; Wed, 14 May 2003 11:07:52 -0500 Message-ID: From: "Sellers, Julian P" To: ipng@sunroof.eng.sun.com Subject: Re: Draft on a V6 documentation prefix Date: Wed, 14 May 2003 11:07:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I must not understand IPv6 address prefix notation. RFC 3513 defines prefix-length as "a decimal value specifying how many of the leftmost contiguous bits of the address comprise the prefix." Geoff Huston wrote: ".....the IPv6 prefix 2001:0DB8::/32 has been set aside for use in documentation examples...."." Jeroen Massar wrote: "."...ISPA who is allocated 2001:db8::/35 and ISPB who is allocated 2001:dba::/35." Does the prefix 2001:0DB8::/32 include addresses whose leftmost 32 bits are 2001:0DBA? Julian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 14 09:32:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4EGW7hs014492; Wed, 14 May 2003 09:32:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4EGW7Y3014491; Wed, 14 May 2003 09:32:07 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4EGW4hs014484 for ; Wed, 14 May 2003 09:32:04 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4EGUeuc019288 for ; Wed, 14 May 2003 09:30:40 -0700 (PDT) Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4EGUZpd008727 for ; Wed, 14 May 2003 10:30:35 -0600 (MDT) Received: from alicia.nttmcl.com (localhost [127.0.0.1]) by alicia.nttmcl.com (8.12.5/8.12.5) with ESMTP id h4EGUYsM036397; Wed, 14 May 2003 09:30:34 -0700 (PDT) (envelope-from jj@alicia.nttmcl.com) Received: (from jj@localhost) by alicia.nttmcl.com (8.12.5/8.12.5/Submit) id h4EGUY1u036396; Wed, 14 May 2003 09:30:34 -0700 (PDT) (envelope-from jj) Date: Wed, 14 May 2003 09:30:34 -0700 From: Shannon -jj Behrens To: "Sellers, Julian P" Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft on a V6 documentation prefix Message-ID: <20030514163034.GD35909@alicia.nttmcl.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, May 14, 2003 at 11:07:35AM -0500, Sellers, Julian P wrote: > I must not understand IPv6 address prefix notation. > > RFC 3513 defines prefix-length as "a decimal value specifying how many of > the leftmost contiguous bits of the address comprise the prefix." > > Geoff Huston wrote: > > ".....the IPv6 prefix 2001:0DB8::/32 has been set aside for use in > documentation examples...."." > > Jeroen Massar wrote: > > "."...ISPA who is allocated 2001:db8::/35 and ISPB who is allocated > 2001:dba::/35." > > Does the prefix 2001:0DB8::/32 include addresses whose leftmost 32 bits are > 2001:0DBA? Unless I am even more confused than you (which is highly possible), no it doesn't. I think you got confused because they were talking about allocating *multiple* /32's (i.e. 2001:0DB8::/32, 2001:0DBA::/32, etc.). Best Regards, -jj -- Hacker is to software engineer as Climbing Mt. Everest is to building a Denny's there. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 14 12:02:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4EJ2bhs015710; Wed, 14 May 2003 12:02:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4EJ2beo015709; Wed, 14 May 2003 12:02:37 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4EJ2Yhs015702 for ; Wed, 14 May 2003 12:02:34 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4EJ1Auc005636 for ; Wed, 14 May 2003 12:01:10 -0700 (PDT) Received: from sina.com (sina187-156.sina.com.cn [202.106.187.156] (may be forged)) by brmea-mail-4.sun.com (8.12.9/8.12.9) with SMTP id h4EJ14pd009652 for ; Wed, 14 May 2003 13:01:04 -0600 (MDT) Received: (qmail 88345 invoked from network); 14 May 2003 11:48:14 -0000 Received: from unknown (HELO liusand) (218.22.21.6) by 202.106.187.156 with SMTP; 14 May 2003 11:48:14 -0000 Message-ID: <000701c31a10$c4cd65a0$0000fea9@liusand> From: "Liusand" To: Subject: Question about unsolicited MLD report for Solicited-Node Multicast Address Date: Wed, 14 May 2003 20:03:01 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 1 X-MSMail-Priority: High X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id h4EJ2Yhs015703 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, When I read RFC2461, 2462 & 2710, I found that RFC2461 & 2462 request that a node delays sending first NS message to avoid racing condition on the link. But according to RFC2710, MLD message for Solicited-Node Multicast Address ARE sent. Also from RFC2710, when a node joins a multicast group, a unsolicited MLD report SHOULD be sent. According to the implementation of Linux kernel 2.4.18 and USAGI-linux24-stable-20030214, when a node starts DAD procedure to statelessly autoconfigure its IPv6 address, a MLD report for the relevant Solicited-Node Multicast Address will be sent immediately even when the node boots up, while the NS for DAD will be delayed. Does the implementation above violate the policy of delaying sending the first message when a node boots up? I think the undelayed MLD report for the Solicited-Node Multicast Address may also cause racing condition on the link. So I suggest that this MLD report be delayed and be sent just before the NS for DAD. If the problem caused by such racing condition is not so severe, why not revoke such delay to speed up the DAD? Your comments will be appreciated! -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 14 12:25:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4EJPBhs015948; Wed, 14 May 2003 12:25:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4EJPBbH015947; Wed, 14 May 2003 12:25:11 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4EJP8hs015940 for ; Wed, 14 May 2003 12:25:08 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4EJNiKw021377 for ; Wed, 14 May 2003 12:23:44 -0700 (PDT) Received: from purgatory.unfix.org (cust.92.136.adsl.cistron.nl [195.64.92.136]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4EJNc3S001293 for ; Wed, 14 May 2003 13:23:38 -0600 (MDT) Received: from limbo (limbo.unfix.org [10.100.13.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by purgatory.unfix.org (Postfix) with ESMTP id 174B5813A; Wed, 14 May 2003 21:23:35 +0200 (CEST) From: "Jeroen Massar" To: "'Sellers, Julian P'" , Subject: RE: Draft on a V6 documentation prefix Date: Wed, 14 May 2003 21:23:35 +0200 Organization: Unfix Message-ID: <000f01c31a4e$51d487c0$210d640a@unfix.org> 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.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Sellers, Julian P wrote: > I must not understand IPv6 address prefix notation. > > RFC 3513 defines prefix-length as "a decimal value specifying > how many of > the leftmost contiguous bits of the address comprise the prefix." > > Geoff Huston wrote: > > ".....the IPv6 prefix 2001:0DB8::/32 has been set aside for use in > documentation examples...."." > > Jeroen Massar wrote: > > "."...ISPA who is allocated 2001:db8::/35 and ISPB who is allocated > 2001:dba::/35." > > Does the prefix 2001:0DB8::/32 include addresses whose > leftmost 32 bits are 2001:0DBA? Hope I don't type this wrong: 2001:db8::/32 = 01234567 89012345 01234567 89012345 00100000 00000001 : 00001101 10111000 2001:dba::/32 01234567 89012345 01234567 89012345 00100000 00000001 : 00001101 10111010 Thus nopes, but a /29 would include it though as the RIR's currently allocate per /29. Note that the above cites you made where from examples for examples and they where made to show that a /35 could be used in documentation in case where multiple TLA's (or GRP's ? :) are used in the documentation. Hmm maybe it would be useful to name TLA or GRP in the document so that that name is standardized too. If it becomes GRP I will have to do some redirs in GRH :) 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 Wed May 14 14:48:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4ELm7hs016555; Wed, 14 May 2003 14:48:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4ELm7Cn016554; Wed, 14 May 2003 14:48:07 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4ELm3hs016547 for ; Wed, 14 May 2003 14:48:03 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4ELkdKw022178 for ; Wed, 14 May 2003 14:46:39 -0700 (PDT) Received: from esunmail ([129.147.58.198]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4ELkTY9014917 for ; Wed, 14 May 2003 15:46:29 -0600 (MDT) Received: from xpa-fe1 ([129.147.58.198]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0HEW001JTCFLFA@edgemail1.Central.Sun.COM> for ipng@sunroof.eng.sun.com; Wed, 14 May 2003 15:45:21 -0600 (MDT) Received: from sun.com ([66.93.78.11]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTPSA id <0HEW0004JCFJFO@mail.sun.net> for ipng@sunroof.eng.sun.com; Wed, 14 May 2003 15:45:21 -0600 (MDT) Date: Wed, 14 May 2003 14:46:57 -0700 From: Alain Durand Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-reply-to: To: Pekka Savola Cc: Bob Hinden , Margaret Wasserman , ipng@sunroof.eng.sun.com Message-id: <95EFA9F4-8655-11D7-9ADD-00039376A6AA@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.552) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tuesday, May 13, 2003, at 10:58 AM, Pekka Savola wrote: > On Tue, 13 May 2003, Bob Hinden wrote: >>> Bob's proposal explicitly defines a type of addresses that are not >>> expected to be routed throughout the Internet. So, these addresses >>> are local, not globally routable. >>> >>> However, Bob's proposal defines addresses that are unique throughout >>> the Internet. No single address identifies one node when used within >>> one "scope" and another node when used in another "scope". So, these >>> are not "scoped addresses", as defined in the IPv6 Scoped Addressing >>> Architecture. >>> >>> I *think* that Bob and I are using the same definition for the >>> term "scoped", but I hope he'll correct me if I'm wrong. >> >> I tried hard to not define the term "scoped address". I only used >> the word >> "scope" once in the draft and that referred to global scope >> addresses. I >> may remove that use in the next version :-) >> >> The globally unique IPv6 local unicast addresses are not limited in >> their >> use to any scope less than global by their design because they have >> prefixes that are globally unique. By comparison site-local >> addresses were >> limited to a limited scope by their design because they had >> non-globally >> unique prefixes. >> >> So yes, I think we agree. > > What would you propose to do with default address selection, if any? > > Should a preference in it be given to truly global or globally unique > local addresses, or should these be indistinguishable from the point of > view? > > This "addresses tried first" ordering is of some importance -- which > one > reason for having this "scope" concept. Pekka is right. The real question behind Bob's proposal is not so much to know if it creates scopes or not, but what is the impact on the applications. If applications need to be aware of those addresses and take different actions if/when different combination of "bob's" or "regular" addresses exist, we end up with much of the issues we had with Site Local, ambiguity excepted. This needs to be clarified. - 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 Wed May 14 16:39:10 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4ENdAhs017247; Wed, 14 May 2003 16:39:10 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4ENdAKo017246; Wed, 14 May 2003 16:39:10 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4ENd6hs017239 for ; Wed, 14 May 2003 16:39:07 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4ENbhuc018923 for ; Wed, 14 May 2003 16:37:43 -0700 (PDT) Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id QAA28552 for ; Wed, 14 May 2003 16:37:36 -0700 (PDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KVWZEZCWO09C3DGS@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Thu, 15 May 2003 09:35:11 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2351B12C008; Thu, 15 May 2003 09:35:10 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 0F83F12C007; Thu, 15 May 2003 09:35:10 +1000 (EST) Date: Thu, 15 May 2003 10:34:42 +1000 From: Greg Daley Subject: Re: Question about unsolicited MLD report for Solicited-Node Multicast Address To: Liusand Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EC2E0A2.8030806@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <000701c31a10$c4cd65a0$0000fea9@liusand> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Liusand, Liusand wrote: > Hello, > When I read RFC2461, 2462 & 2710, I found that RFC2461 & 2462 request > that a node delays sending first NS message to avoid racing condition > on the link. But according to RFC2710, MLD message for Solicited-Node > Multicast Address ARE sent. Also from RFC2710, when a node joins a > multicast group, a unsolicited MLD report SHOULD be sent. This is a part of the specifications which is not exactly clear. The NS message is sent when DAD is to be undertaken. Initially, the node has not checked the address and needs to solicit in order to check if another node is in posession of this address. Does the node listen for NA messages for this address before it sends the DAD NS? If it does, then the MLD message has to be sent as soon as the task of listening to the multicast group is begun. This is because in some (future?) environments, valid multicast messages may not be delivered to the configuring node, unless the MLD message is sent on the link. If the node doesn't listen for NA's before the NS is sent, then there is no reason to join the solicited node multicast group for the address at a significantly before the DAD NS. Otherwise, we may see the situation you describe below. All nodes could notice that the link was available, and send MLD messages simultaneously in a way which could hamper the link. If the configuring nodes delay joining the multicast group to the same time that the DAD NS is sent, then two multicast packets (The MLD Report and the DAD NS) are sent at about the same time, and would be governed by the same random timer. In this case it is even more important that nodes obey the random delay for DAD! > According to the implementation of Linux kernel 2.4.18 and > USAGI-linux24-stable-20030214, when a node starts DAD procedure to > statelessly autoconfigure its IPv6 address, a MLD report for the relevant > Solicited-Node Multicast Address will be sent immediately even when the > node boots up, while the NS for DAD will be delayed. I think that you mean that the 2.4.18 kernel was patched with USAGI. I thought that the standard linux 2.4.18 kernel didn't do MLD for solicited nodes addresses. Is this your understanding too? > Does the implementation above violate the policy of delaying sending > the first message when a node boots up? I think the undelayed MLD report > for the Solicited-Node Multicast Address may also cause racing > condition on the link. So I suggest that this MLD report be delayed > and be sent just before the NS for DAD. If the problem caused by such > racing condition is not so severe, why not revoke such delay to speed up > the DAD? This is a genuine issue with the standards. The RFC text is both explicit, and contradictory. For Example: Section 5.4.2 of RFC 2462: "Before sending a Neighbor Solicitation, an interface MUST join ... the solicited-node multicast address" RFC 2710 implies this means sending an MLD report. and "If the Neighbor Solicitation is the first message to be sent from an interface after interface (re)initialization, the node should delay sending the message by a random delay" These statements are mutually exclusive, since the MLD report will always be sent before the Neighbor Solicitation. The statement which means that MLD reports are sent before the delay is this Mandatory requirement: " In order to improve the robustness of the Duplicate Address Detection algorithm, an interface MUST receive and process datagrams sent to the all-nodes multicast address or solicited-node multicast address of the tentative address while delaying transmission of the initial Neighbor Solicitation." This means that the MLD reports for solicited nodes multicast are sent as soon as the node decides to configure the address, and effectively defeats the randomization strategy. So the USAGI implementation may be correct, if misguided. 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 Wed May 14 18:38:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4F1cHhs017709; Wed, 14 May 2003 18:38:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4F1cHR7017708; Wed, 14 May 2003 18:38:17 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4F1cChs017701 for ; Wed, 14 May 2003 18:38:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4F1amKw015967 for ; Wed, 14 May 2003 18:36:48 -0700 (PDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4F1ahx9012984 for ; Wed, 14 May 2003 18:36:43 -0700 (PDT) Received: from il06exr06.mot.com (il06exr06.mot.com [129.188.137.136]) by motgate4.mot.com (Motorola/Motgate4) with ESMTP id h4F1agDS021661 for ; Wed, 14 May 2003 18:36:42 -0700 (MST) Received: from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by il06exr06.mot.com (Motorola/il06exr06) with ESMTP id h4F1abnb013671 for ; Wed, 14 May 2003 20:36:39 -0500 Received: from motorola.com (aewhite.arc.corp.mot.com [10.238.80.239]) by homer.arc.corp.mot.com (8.12.9/8.12.8) with ESMTP id h4F1aaVI022546 for ; Thu, 15 May 2003 11:36:36 +1000 (EST) Message-ID: <3EC2EF24.897EC232@motorola.com> Date: Thu, 15 May 2003 11:36:36 +1000 From: Andrew White Reply-To: awhite@arc.corp.mot.com Organization: Motorola Australia Research Centre X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <95EFA9F4-8655-11D7-9ADD-00039376A6AA@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Alain Durand wrote: > > On Tuesday, May 13, 2003, at 10:58 AM, Pekka Savola wrote: > > > What would you propose to do with default address selection, if any? > > > > Should a preference in it be given to truly global or globally unique > > local addresses, or should these be indistinguishable from the point of > > view? > > > > This "addresses tried first" ordering is of some importance -- which > > one > > reason for having this "scope" concept. > > Pekka is right. The real question behind Bob's proposal is not so much > to know if it creates scopes or not, but what is the impact on the > applications. > > If applications need to be aware of those addresses and take different > actions > if/when different combination of "bob's" or "regular" addresses exist, > we > end up with much of the issues we had with Site Local, ambiguity > excepted. > This needs to be clarified. Considering that using a local addressing scheme is optional and that the justifications for using such a scheme usually centre around having an addressing and routing architecture that works regardless of ISPs and global prefixes, let's assume that the existence of such addresses implies that the network wants applications to favour these prefixes. Let's further assume hosts implement default address selection (RFC3484). To favour local addresses, we give them a 'scope' (for the purposes of RFC3484) that is smaller than global unicast. Name -> address lookups will then return addresses in the following order: Src has local address: - Local addresses (longest prefix match first) - Global addresses (if src also has global, longest prefix match first) Src has only global address - Global addresses (longest prefix match first) - Local addresses Likewise, src address selection will choose a global address (longest prefix match) for traffic destined for a global address, and a local address (longest prefix match) for traffic destined to a local address. Destination Rule #2 favours matching source and destination scopes. Rule #8 favours smaller scope over larger. Rule #9 favours longest prefix match. Thus, in order of preference: Source -> Dest ---------------- Local -> Local Global -> Global Global -> Local Local -> Global Assuming that the host's IP library does its job, the application may ignore the distinction between local and global addresses UNLESS it intends to forward addresses between other hosts AND these referrals may cross the local filtering boundary. One obvious solution is to forward names instead. The other is to have a configuration switch telling the app that it may not use local destination addresses. One advantage of local addresses is this: - things that don't care about filters and scopes and ... don't have to. - things that need to care about filters and scopes have more information than they otherwise would. Of course, referrals may still fail even with globals, so any application doing referrals probably wants a bunch of recovery mechanisms. And thus can be ignorant of local addresses too, and accept that it may need to try a few addresses to get it to work. -- Andrew White -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 15 00:02:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4F72Ghs019003; Thu, 15 May 2003 00:02:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4F72FjZ019002; Thu, 15 May 2003 00:02:15 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4F72Chs018995 for ; Thu, 15 May 2003 00:02:12 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4F70mKw004200 for ; Thu, 15 May 2003 00:00:48 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4F70cx9005315 for ; Thu, 15 May 2003 00:00:41 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Thu, 15 May 2003 12:39:53 +0530 Received: from sivarka (sivarka.future.futsoft.com [10.20.6.73]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h4F6v30J015334 for ; Thu, 15 May 2003 12:27:04 +0530 Reply-To: From: "Sivaramakrishnan A" To: Subject: Anycast address - How to find the "nearest" router? Date: Thu, 15 May 2003 12:28:57 +0530 Message-Id: <000201c31aaf$769b6400$4906140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I have 2 Routers ( R1 and R2) in a link who are configured the same ANYCAST address. A packet is addressed to that anycast address. According to [ADDR-ARCH] the "nearest" one shoule receive this packet. Assume R1 is the "nearest" one here. But how does R1 know that "I'm the nearest, and I should process this packet?" . If Suppose if R1 is nearer, how is R2 restricted from processing the packet? thanks and regards, Sivaramakrishnan. A *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 15 02:40:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4F9eBhs019607; Thu, 15 May 2003 02:40:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4F9eBfh019606; Thu, 15 May 2003 02:40:11 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4F9e7hs019599 for ; Thu, 15 May 2003 02:40:07 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4F9cfuc016683 for ; Thu, 15 May 2003 02:38:41 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4F9cVx9011158 for ; Thu, 15 May 2003 02:38:34 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Thu, 15 May 2003 15:17:45 +0530 Received: from sivarka (sivarka.future.futsoft.com [10.20.6.73]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h4F9Yr0J019145; Thu, 15 May 2003 15:04:54 +0530 Reply-To: From: "Sivaramakrishnan A" To: "'Suvidh Mathur'" Cc: Subject: RE: Anycast address - How to find the "nearest" router? Date: Thu, 15 May 2003 15:06:50 +0530 Message-Id: <000401c31ac5$8401dd20$4906140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, I accept that the route table organisation can help to find the nearness of any router. So (In this case) do you mean, both R1 and R2 should agree upon themselves, that who should process the packet anycast addressed packet ? If yes, how could this be achieved? How can NS-NA exchange help us resolve who should receive the packet? thanks, Sivaramakrishnan. A -----Original Message----- From: Suvidh Mathur [mailto:Suvidh.Mathur@lntinfotech.com] Sent: Thursday, 15 May 2003 1:51 PM To: sivarka@future.futsoft.com Subject: Re: Anycast address - How to find the "nearest" router? Hi, What exactly do you mean by "nearest"? As per the RFC, nearest should be based on the routing protocols' notion of distance. Thus if R1 is nearer then R2, then the packet should reach R1 alone. If R1 and R2 are equi-distant, then either the routing table organization (at the sending nore and / or the intermediate routers) or NS - NA exchange (in case of R1 and R2 being onlink) should ensure that the packet is sent only to one of the routers. Hope this helps, Regards, Suvidh Thursday, 15 May, 2003 12:39 PM To: cc: From: "Sivaramakrishnan A" Subject: Anycast address - How to find the "nearest" router? Hi, I have 2 Routers ( R1 and R2) in a link who are configured the same ANYCAST address. A packet is addressed to that anycast address. According to [ADDR-ARCH] the "nearest" one shoule receive this packet. Assume R1 is the "nearest" one here. But how does R1 know that "I'm the nearest, and I should process this packet?" . If Suppose if R1 is nearer, how is R2 restricted from processing the packet? thanks and regards, Sivaramakrishnan. A *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 15 03:20:24 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FAKOhs019915; Thu, 15 May 2003 03:20:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4FAKO2d019914; Thu, 15 May 2003 03:20:24 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FAKKhs019907 for ; Thu, 15 May 2003 03:20:20 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FAItKw016352 for ; Thu, 15 May 2003 03:18:55 -0700 (PDT) Received: from mx1.ustc.edu.cn ([218.22.21.1]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4FAImpd006793 for ; Thu, 15 May 2003 04:18:49 -0600 (MDT) Received: from liusand ([210.45.123.53]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id SAA23147; Thu, 15 May 2003 18:13:54 +0800 Message-ID: <001501c31aca$c1aad460$357b2dd2@liusand> From: "Sha Liu" To: Cc: References: <000701c31a10$c4cd65a0$0000fea9@liusand> <3EC2E0A2.8030806@eng.monash.edu.au> Subject: Re: Question about unsolicited MLD report for Solicited-Node Multicast Address Date: Thu, 15 May 2003 11:20:40 +0800 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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id h4FAKLhs019908 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Dear Greg, Thanks for your explanation! Whether can we say that the combination of no delay in sending MLD report and delay in sending first NS is to lessen the racing condition on the link? In Linux kernel 2.4.18 source, I found a calling chain listed below: addrconf_dad_start() -> addrconf_join_solicit() -> ipv6_dev_mc_inc() -> igmp6_group_added() -> igmp6_join_group() -> igmp6_send() But in my tcpdump results, there is no MLD report exists. It is confusing me. ----- Original Message ----- From: "Greg Daley" To: "Liusand" Cc: Sent: Thursday, May 15, 2003 8:34 AM Subject: Re: Question about unsolicited MLD report for Solicited-Node Multicast Address > > Dear Liusand, > > Liusand wrote: > > Hello, > > When I read RFC2461, 2462 & 2710, I found that RFC2461 & 2462 request > > that a node delays sending first NS message to avoid racing condition > > on the link. But according to RFC2710, MLD message for Solicited-Node > > Multicast Address ARE sent. Also from RFC2710, when a node joins a > > multicast group, a unsolicited MLD report SHOULD be sent. > > > This is a part of the specifications which is not exactly clear. > > The NS message is sent when DAD is to be undertaken. > Initially, the node has not checked the address and needs to > solicit in order to check if another node is in posession of this > address. > > Does the node listen for NA messages for this address before it sends > the DAD NS? > > If it does, then the MLD message has to be sent as soon as the task > of listening to the multicast group is begun. This is because in some > (future?) environments, valid multicast messages may not be delivered > to the configuring node, unless the MLD message is sent on the link. > > If the node doesn't listen for NA's before the NS is sent, then there > is no reason to join the solicited node multicast group for the address > at a significantly before the DAD NS. Otherwise, we may see the > situation you describe below. > > All nodes could notice that the link was available, and send MLD > messages simultaneously in a way which could hamper the link. > > If the configuring nodes delay joining the multicast group to the > same time that the DAD NS is sent, then two multicast packets (The MLD > Report and the DAD NS) are sent at about the same time, and would be > governed by the same random timer. In this case it is even more > important that nodes obey the random delay for DAD! > > > > According to the implementation of Linux kernel 2.4.18 and > > USAGI-linux24-stable-20030214, when a node starts DAD procedure to > > statelessly autoconfigure its IPv6 address, a MLD report for the relevant > > Solicited-Node Multicast Address will be sent immediately even when the > > node boots up, while the NS for DAD will be delayed. > > I think that you mean that the 2.4.18 kernel was patched with USAGI. > I thought that the standard linux 2.4.18 kernel didn't do MLD for > solicited nodes addresses. > Is this your understanding too? > > > Does the implementation above violate the policy of delaying sending > > the first message when a node boots up? I think the undelayed MLD > report > > for the Solicited-Node Multicast Address may also cause racing > > condition on the link. So I suggest that this MLD report be delayed > > and be sent just before the NS for DAD. If the problem caused by such > > racing condition is not so severe, why not revoke such delay to speed up > > the DAD? > > This is a genuine issue with the standards. The RFC text is > both explicit, and contradictory. > > For Example: > > Section 5.4.2 of RFC 2462: > > "Before sending a Neighbor Solicitation, an interface MUST join ... > the solicited-node multicast address" > > RFC 2710 implies this means sending an MLD report. > and > > "If the Neighbor Solicitation is the first message to be sent from an > interface after interface (re)initialization, the node should delay > sending the message by a random delay" > > These statements are mutually exclusive, since the MLD report > will always be sent before the Neighbor Solicitation. > > The statement which means that MLD reports are sent before the delay > is this Mandatory requirement: > > " In order to improve the robustness of the > Duplicate Address Detection algorithm, an interface MUST receive and > process datagrams sent to the all-nodes multicast address or > solicited-node multicast address of the tentative address while > delaying transmission of the initial Neighbor Solicitation." > > This means that the MLD reports for solicited nodes multicast are > sent as soon as the node decides to configure the address, and > effectively defeats the randomization strategy. > > So the USAGI implementation may be correct, if misguided. > > 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 > -------------------------------------------------------------------- > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 15 04:42:16 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FBgFhs020476; Thu, 15 May 2003 04:42:16 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4FBgFR9020475; Thu, 15 May 2003 04:42:15 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FBgChs020468 for ; Thu, 15 May 2003 04:42:12 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FBekuc006490 for ; Thu, 15 May 2003 04:40:47 -0700 (PDT) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4FBeb3S024555 for ; Thu, 15 May 2003 05:40:41 -0600 (MDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by e1.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4FBeZWn176158 for ; Thu, 15 May 2003 07:40:36 -0400 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4FBeXQA198506 for ; Thu, 15 May 2003 13:40:34 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA52198 from ; Thu, 15 May 2003 13:40:32 +0200 Message-Id: <3EC37CCF.3F753DAC@hursley.ibm.com> Date: Thu, 15 May 2003 13:41:03 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <95EFA9F4-8655-11D7-9ADD-00039376A6AA@sun.com> <3EC2EF24.897EC232@motorola.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk below... Andrew White wrote: > > Alain Durand wrote: > > > > On Tuesday, May 13, 2003, at 10:58 AM, Pekka Savola wrote: > > > > > What would you propose to do with default address selection, if any? > > > > > > Should a preference in it be given to truly global or globally unique > > > local addresses, or should these be indistinguishable from the point of > > > view? > > > > > > This "addresses tried first" ordering is of some importance -- which > > > one > > > reason for having this "scope" concept. > > > > Pekka is right. The real question behind Bob's proposal is not so much > > to know if it creates scopes or not, but what is the impact on the > > applications. > > > > If applications need to be aware of those addresses and take different > > actions > > if/when different combination of "bob's" or "regular" addresses exist, > > we > > end up with much of the issues we had with Site Local, ambiguity > > excepted. > > This needs to be clarified. > > Considering that using a local addressing scheme is optional and that the > justifications for using such a scheme usually centre around having an > addressing and routing architecture that works regardless of ISPs and global > prefixes, let's assume that the existence of such addresses implies that the > network wants applications to favour these prefixes. > > Let's further assume hosts implement default address selection (RFC3484). > To favour local addresses, we give them a 'scope' (for the purposes of > RFC3484) that is smaller than global unicast. > > Name -> address lookups will then return addresses in the following order: > > Src has local address: > - Local addresses (longest prefix match first) > - Global addresses (if src also has global, longest prefix match first) > Src has only global address > - Global addresses (longest prefix match first) > - Local addresses > > Likewise, src address selection will choose a global address (longest prefix > match) for traffic destined for a global address, and a local address > (longest prefix match) for traffic destined to a local address. > > Destination Rule #2 favours matching source and destination scopes. Rule #8 > favours smaller scope over larger. Rule #9 favours longest prefix match. > > Thus, in order of preference: > Source -> Dest > ---------------- > Local -> Local > Global -> Global > Global -> Local > Local -> Global > > Assuming that the host's IP library does its job, the application may ignore > the distinction between local and global addresses UNLESS it intends to > forward addresses between other hosts AND these referrals may cross the > local filtering boundary. One obvious solution is to forward names > instead. The other is to have a configuration switch telling the app that > it may not use local destination addresses. > > One advantage of local addresses is this: > - things that don't care about filters and scopes and ... don't have to. > - things that need to care about filters and scopes have more information > than they otherwise would. > > Of course, referrals may still fail even with globals, so any application > doing referrals probably wants a bunch of recovery mechanisms. And thus can > be ignorant of local addresses too, and accept that it may need to try a few > addresses to get it to work. The trouble is that none of this answers the real world questions that a sophisticated applications environment ought to want to ask, such as: - which pair(*) of addresses will give the best reliability|throughput|delay? - which pair of addresses will stay within a specified security boundary (e.g. within the corporate firewall, within a given VPN connection, within a given Grid virtual organization)? I'm increasingly concerned that there is no way to resolve such questions by examining the prefix bits in an address or by defining scope as a set of concentric circles such as link-site-global. (*) 'pair' becomes 'set' for a referral or SCTP scenario, and the questions become correspondingly more complex. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 15 06:12:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FDCvhs020905; Thu, 15 May 2003 06:12:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4FDCueg020904; Thu, 15 May 2003 06:12:56 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FDCrhs020897 for ; Thu, 15 May 2003 06:12:53 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FDBRuc022461 for ; Thu, 15 May 2003 06:11:28 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4FDBGsa029078 for ; Thu, 15 May 2003 07:11:17 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4FDB6Q25901; Thu, 15 May 2003 20:11:08 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4FD6NZ05792; Thu, 15 May 2003 20:06:24 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <3EC37CCF.3F753DAC@hursley.ibm.com> References: <3EC37CCF.3F753DAC@hursley.ibm.com> <95EFA9F4-8655-11D7-9ADD-00039376A6AA@sun.com> <3EC2EF24.897EC232@motorola.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 May 2003 20:06:23 +0700 Message-ID: <5790.1053003983@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Thu, 15 May 2003 13:41:03 +0200 From: Brian E Carpenter Message-ID: <3EC37CCF.3F753DAC@hursley.ibm.com> | The trouble is that none of this answers the real world questions | that a sophisticated applications environment ought to want to ask, | such as: | I'm increasingly concerned that there is no way to resolve such questions | by examining the prefix bits in an address or by defining scope as a set | of concentric circles such as link-site-global. Why is this a surprise? Of course answers to those questions aren't going to be as simple as looking at a few bits - we shouldn't expect them to be, nor should we be criticising the bits for being unable to provide those answers. This is obvious as soon as you notice that the answers to the questions have a temporal component - which addressing manages to select the link which is most reliable (etc) varies as link conditions change, yet we obviously don't want the addressing to do so. Network boundaries could be delimited by addressing - but only as long as the network boundaries are nice fixed stable things, planned well in advance. That certainly won't serve every need. But that we cannot possibly solve every possible problem that exists with addressing doesn't mean that we shouldn't get whatever advantages that we can. We need stable local addressing. Whether that is the SL addresses that we have now, or the addresses in Bob's proposal (which despite his desire to make them different from SL's, have ended up being essentially the same - currently the one big difference is the bigger address space, that's really it, and that there are no multi-site nodes in his proposal). That this happened is no surprise - there's a demand that this kind of addressing fills, and everyone knows it. 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 May 15 06:53:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FDrchs021196; Thu, 15 May 2003 06:53:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4FDrccb021195; Thu, 15 May 2003 06:53:38 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FDrZhs021188 for ; Thu, 15 May 2003 06:53:35 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FDq9Kw029190 for ; Thu, 15 May 2003 06:52:09 -0700 (PDT) Received: from mx1.ustc.edu.cn ([218.22.21.1]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4FDq2pd008655 for ; Thu, 15 May 2003 07:52:03 -0600 (MDT) Received: from liusand ([210.45.123.53]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id VAA08863; Thu, 15 May 2003 21:43:15 +0800 Message-ID: <000901c31ae8$018d05e0$357b2dd2@liusand> From: "Sha Liu" To: Cc: References: <000401c31ac5$8401dd20$4906140a@future.futsoft.com> Subject: Re: Anycast address - How to find the "nearest" router? Date: Thu, 15 May 2003 21:43:44 +0800 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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id h4FDrZhs021189 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, I believe properly set the Override bit in NA message on that link can reach what you call agreement. E.g., R1's NAs for the anycast address set the Override bit to 1, while R2's NAs set it to 0. ----- Original Message ----- From: "Sivaramakrishnan A" To: "'Suvidh Mathur'" Cc: Sent: Thursday, May 15, 2003 5:36 PM Subject: RE: Anycast address - How to find the "nearest" router? > Hi, > > I accept that the route table organisation can help to find the > nearness of any router. So (In this case) do you mean, both R1 > and R2 should agree upon themselves, that who should process > the packet anycast addressed packet ? If yes, how could this be > achieved? > > How can NS-NA exchange help us resolve who should receive the packet? > > thanks, > Sivaramakrishnan. A > > -----Original Message----- > From: Suvidh Mathur [mailto:Suvidh.Mathur@lntinfotech.com] > Sent: Thursday, 15 May 2003 1:51 PM > To: sivarka@future.futsoft.com > Subject: Re: Anycast address - How to find the "nearest" router? > > > > Hi, > > What exactly do you mean by "nearest"? > > As per the RFC, nearest should be based on the routing protocols' notion of > distance. Thus if R1 is nearer then R2, then the packet should reach R1 > alone. > If R1 and R2 are equi-distant, then either the routing table organization > (at the sending nore and / or the intermediate routers) or NS - NA exchange > (in case of R1 and R2 being onlink) should ensure that the packet is sent > only to one of the routers. > > Hope this helps, > > Regards, > Suvidh > > Thursday, 15 May, 2003 12:39 PM > To: > cc: > From: "Sivaramakrishnan A" > Subject: Anycast address - How to find the "nearest" router? > > > > Hi, > I have 2 Routers ( R1 and R2) in a link who are configured the same > ANYCAST > address. > A packet is addressed to that anycast address. According to [ADDR-ARCH] the > "nearest" > one shoule receive this packet. Assume R1 is the "nearest" one here. But > how > does R1 know > that "I'm the nearest, and I should process this packet?" . If Suppose if > R1 is nearer, how is > R2 restricted from processing the packet? > thanks and regards, > Sivaramakrishnan. A > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 15 07:11:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FEB4hs021441; Thu, 15 May 2003 07:11:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4FEB3N1021440; Thu, 15 May 2003 07:11:03 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FEB0hs021433 for ; Thu, 15 May 2003 07:11:00 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FE9Yuc004075 for ; Thu, 15 May 2003 07:09:34 -0700 (PDT) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4FE9Spd014956 for ; Thu, 15 May 2003 08:09:28 -0600 (MDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4FE9Glr024888; Thu, 15 May 2003 16:09:17 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4FE9DDk079400; Thu, 15 May 2003 16:09:15 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA25250 from ; Thu, 15 May 2003 16:09:11 +0200 Message-Id: <3EC39FA5.DC5BB6F5@hursley.ibm.com> Date: Thu, 15 May 2003 16:09:41 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <3EC37CCF.3F753DAC@hursley.ibm.com> <95EFA9F4-8655-11D7-9ADD-00039376A6AA@sun.com> <3EC2EF24.897EC232@motorola.com> <5790.1053003983@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk kre, I won't disagree. I just don't want people to believe that we can define an addressing format, a scope rule, and we're done. Brian Robert Elz wrote: > > Date: Thu, 15 May 2003 13:41:03 +0200 > From: Brian E Carpenter > Message-ID: <3EC37CCF.3F753DAC@hursley.ibm.com> > > | The trouble is that none of this answers the real world questions > | that a sophisticated applications environment ought to want to ask, > | such as: > > | I'm increasingly concerned that there is no way to resolve such questions > | by examining the prefix bits in an address or by defining scope as a set > | of concentric circles such as link-site-global. > > Why is this a surprise? > > Of course answers to those questions aren't going to be as simple as > looking at a few bits - we shouldn't expect them to be, nor should we > be criticising the bits for being unable to provide those answers. > > This is obvious as soon as you notice that the answers to the questions > have a temporal component - which addressing manages to select the > link which is most reliable (etc) varies as link conditions change, yet > we obviously don't want the addressing to do so. > > Network boundaries could be delimited by addressing - but only as long > as the network boundaries are nice fixed stable things, planned well > in advance. That certainly won't serve every need. > > But that we cannot possibly solve every possible problem that exists > with addressing doesn't mean that we shouldn't get whatever advantages > that we can. We need stable local addressing. Whether that is the SL > addresses that we have now, or the addresses in Bob's proposal (which > despite his desire to make them different from SL's, have ended up > being essentially the same - currently the one big difference is the > bigger address space, that's really it, and that there are no multi-site > nodes in his proposal). That this happened is no surprise - there's > a demand that this kind of addressing fills, and everyone knows it. > > 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 May 15 10:30:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FHUWhs022353; Thu, 15 May 2003 10:30:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4FHUV7H022352; Thu, 15 May 2003 10:30:31 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FHUShs022345 for ; Thu, 15 May 2003 10:30:28 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FHT2Kw010710 for ; Thu, 15 May 2003 10:29:02 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [66.93.182.229]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4FHSvsa026474 for ; Thu, 15 May 2003 11:28:57 -0600 (MDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 2781550; Thu, 15 May 2003 10:28:56 -0700 (PDT) Date: Thu, 15 May 2003 12:28:56 -0500 From: David Terrell To: Brian E Carpenter Cc: IPv6 Subject: Re: C000 Message-ID: <20030515172855.GA2536@pianosa.catch22.org> Reply-To: David Terrell References: <3E957221.254CD6D5@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E957221.254CD6D5@hursley.ibm.com> User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 3:07PM up 3 days, 13:09, 30 users, load averages: 0.85, 0.64, 0.56 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 10, 2003 at 03:31:13PM +0200, Brian E Carpenter wrote: > Let's be constructive and ignore distractions like appeals. > Let's also assume that item (4) ["requirements for a local > addressing mechanism"] in the chairs' work list is relatively > straightfoward and obvious. > > Assume that we consider stable, probably unique, > unrouteable prefixes important enough to get their own 3-bit > prefix, and for the sake of argument let's pick C000::/3. > > Further assume that we want to generate /48s. > > Then the problem to solve is generating probably unique 45 bit > numbers easily and essentially free of charge. That's clearly possible > in several ways, so let's not debate details. > > Therefore, assume we have a way of generating such prefixes under C000::/3. > > What are they going to do to the scoped architecture? Will applications > need to treat them any differently from 2000::/3? Problem case: SIP A ---- SIP HUB ---- SIP B SIP A connects to SIP HUB in the site. SIP B is an external device not within the site. A connects to HUB over a C000::/3 address pair. B connects to HUB with a 2000::/3 address pair. A now needs to talk to B. What happens? This is _the_ demonstrated problem case for site-local. In the scoped world, the application can compare the zone IDs of the two addresses being referred to each other by checking the zone identifier of the local connection. In your scenario, it needs to have magic rules about C000::/3. How is the latter easier than the former? Scoping gives us (as a site administrator) an accurate way to make the site boundary clear, through host configuration (and autoconfiguration). Picking a (brand new!) magic prefix and starting over gives site administrators less information to pass to clients, and zero way to tell apart a "local site-local" address from a "remote site-local" address. Just because they're unique and don't have the words "site-local" in the specification doesn't mean they won't leak, or cause problems when they do leak, it just means we've completely dodged answering the question, and ensured another 5 year rev cycle before an answer gets completed. -- David Terrell | Nebcorp Prime Minister | dbt@meat.net | The best free things in life are free. http://wwn.nebcorp.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 May 15 11:22:41 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FIMfhs022730; Thu, 15 May 2003 11:22:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4FIMe9B022729; Thu, 15 May 2003 11:22:40 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FIMahs022722 for ; Thu, 15 May 2003 11:22:37 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4FIL6L28543; Thu, 15 May 2003 20:21:06 +0200 (MEST) Date: Thu, 15 May 2003 20:20:27 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: Router Lifetime question To: Peter Barany Cc: "'ipng@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <1B54FA3A2709D51195C800508BF9386A080B3884@zrc2c000.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > A question regarding RFC 2461. Unless I am missing something, there seems to > be some inconsistency in Sections 6.2.1 and 4.2 of RFC 2461 regarding the > value of the Router Lifetime. How is this resolved? See below. Thanks. I don't see an inconsistency - can you explain what you think is inconsistent? 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 May 15 11:23:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FINShs022747; Thu, 15 May 2003 11:23:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4FINRLA022746; Thu, 15 May 2003 11:23:27 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FINOhs022739 for ; Thu, 15 May 2003 11:23:24 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FILwKw003630 for ; Thu, 15 May 2003 11:21:58 -0700 (PDT) Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4FILqY9004838 for ; Thu, 15 May 2003 12:21:52 -0600 (MDT) Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h4FILh2Q018607; Thu, 15 May 2003 11:21:43 -0700 (PDT) Received: from cisco.com (sjc-vpn3-26.cisco.com [10.21.64.26]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA07513; Thu, 15 May 2003 11:21:42 -0700 (PDT) Message-ID: <3EC3DAB4.3080701@cisco.com> Date: Thu, 15 May 2003 11:21:40 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Terrell CC: Brian E Carpenter , IPv6 Subject: Re: C000 References: <3E957221.254CD6D5@hursley.ibm.com> <20030515172855.GA2536@pianosa.catch22.org> In-Reply-To: <20030515172855.GA2536@pianosa.catch22.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David Terrell wrote: > Problem case: > SIP A ---- SIP HUB ---- SIP B > > SIP A connects to SIP HUB in the site. SIP B is an external device not > within the site. > > A connects to HUB over a C000::/3 address pair. B connects to HUB > with a 2000::/3 address pair. > > A now needs to talk to B. > > What happens? You never get that far. If HUB wants to talk to A and B and they reside in different site-local scopes, there is no way to guarantee that the two spaces don't clash. Eliot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 15 11:31:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FIVEhs022833; Thu, 15 May 2003 11:31:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4FIVDV1022832; Thu, 15 May 2003 11:31:13 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FIVAhs022825 for ; Thu, 15 May 2003 11:31:10 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FITjKw007720 for ; Thu, 15 May 2003 11:29:45 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4FITa3S007388 for ; Thu, 15 May 2003 12:29:36 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4FITW511385; Thu, 15 May 2003 13:29:32 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 15 May 2003 13:29:32 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A080B38B8@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Erik Nordmark'" Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: Router Lifetime question Date: Thu, 15 May 2003 13:29:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31B0F.8A97F13E" 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_01C31B0F.8A97F13E Content-Type: text/plain; charset="iso-8859-1" What I mean to say is that the parameter AdvDefaultLifetime MUST be either zero or between MaxRtrAdvInterval and 9000 seconds (IPv6) per RFC 2461. Same thing for IPv4 per RFC 1256 (only the parameter is Advertisement Lifetime). The inconsistency (for lack of a better word) is that the Router Lifetime field is 16 bits and if set to anything greater than 9000 seconds then this would violate the specifications. So, if it is set to 18.2 hours (e.g., for some wireless cellular links) it violates the specs. Pete -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Thursday, May 15, 2003 1:20 PM To: Barany, Peter [RICH1:2H16:EXCH] Cc: 'ipng@sunroof.eng.sun.com' Subject: Re: Router Lifetime question > A question regarding RFC 2461. Unless I am missing something, there seems to > be some inconsistency in Sections 6.2.1 and 4.2 of RFC 2461 regarding the > value of the Router Lifetime. How is this resolved? See below. Thanks. I don't see an inconsistency - can you explain what you think is inconsistent? Erik ------_=_NextPart_001_01C31B0F.8A97F13E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Router Lifetime question

What I mean to say is that the parameter = AdvDefaultLifetime MUST be either zero or between MaxRtrAdvInterval and = 9000 seconds (IPv6) per RFC 2461. Same thing for IPv4 per RFC 1256 = (only the parameter is Advertisement Lifetime). The inconsistency (for = lack of a better word) is that the Router Lifetime field is 16 bits and = if set to anything greater than 9000 seconds then this would violate = the specifications. So, if it is set to 18.2 hours (e.g., for some = wireless cellular links) it violates the specs.

Pete

-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@sun.com]<= /FONT>
Sent: Thursday, May 15, 2003 1:20 PM
To: Barany, Peter [RICH1:2H16:EXCH]
Cc: 'ipng@sunroof.eng.sun.com'
Subject: Re: Router Lifetime question


> A question regarding RFC 2461. Unless I am = missing something, there seems to
> be some inconsistency in Sections 6.2.1 and 4.2 = of RFC 2461 regarding the
> value of the Router Lifetime. How is this = resolved? See below. Thanks.

I don't see an inconsistency - can you explain what = you think
is inconsistent?

    Erik

------_=_NextPart_001_01C31B0F.8A97F13E-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 15 12:16:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FJGwhs023473; Thu, 15 May 2003 12:16:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4FJGwQF023472; Thu, 15 May 2003 12:16:58 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FJGrhs023465 for ; Thu, 15 May 2003 12:16:55 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FJFCuc010442 for ; Thu, 15 May 2003 12:15:27 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by nwkea-mail-1.sun.com (8.9.3p2+Sun/8.9.3) with ESMTP id MAA05684 for ; Thu, 15 May 2003 12:15:06 -0700 (PDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h4FJD06I014497; Thu, 15 May 2003 12:13:01 -0700 (PDT) Received: from SIVAV.qualcomm.com ([10.50.68.49]) by sabrina.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h4FJCvBC015205; Thu, 15 May 2003 12:12:58 -0700 (PDT) Message-Id: <4.3.2.7.2.20030515120616.04a424e8@jittlov.qualcomm.com> X-Sender: sivav@jittlov.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 15 May 2003 12:13:00 -0700 To: Erik Nordmark From: Siva Veerepalli Subject: Re: Router Lifetime question Cc: Peter Barany , "'ipng@sunroof.eng.sun.com'" In-Reply-To: References: <"Your message with ID" <1B54FA3A2709D51195C800508BF9386A080B3884@zrc2c000.us.nortel.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_689316364==_.ALT" Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --=====================_689316364==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 08:20 PM 5/15/2003 +0200, Erik Nordmark wrote: > > A question regarding RFC 2461. Unless I am missing something, there > seems to > > be some inconsistency in Sections 6.2.1 and 4.2 of RFC 2461 regarding the > > value of the Router Lifetime. How is this resolved? See below. Thanks. > >I don't see an inconsistency - can you explain what you think >is inconsistent? Even though the Router Lifetime field allows a setting of upto 18.2 hrs, the AdvDefaultLifetime definition in the RFC does not allow setting of the Router Lifetime field to a value larger than 9000 seconds. Siva > 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 >-------------------------------------------------------------------- --=====================_689316364==_.ALT Content-Type: text/html; charset="us-ascii" At 08:20 PM 5/15/2003 +0200, Erik Nordmark wrote:
> A question regarding RFC 2461. Unless I am missing something, there seems to
> be some inconsistency in Sections 6.2.1 and 4.2 of RFC 2461 regarding the
> value of the Router Lifetime. How is this resolved? See below. Thanks.

I don't see an inconsistency - can you explain what you think
is inconsistent?

Even though the Router Lifetime field allows a setting of upto 18.2 hrs, the AdvDefaultLifetime definition in the RFC does not allow setting of the Router Lifetime field to a value larger than 9000 seconds.

Siva


    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
--------------------------------------------------------------------
--=====================_689316364==_.ALT-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 15 12:42:13 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FJgChs023729; Thu, 15 May 2003 12:42:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4FJgCMg023728; Thu, 15 May 2003 12:42:12 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FJg9hs023721 for ; Thu, 15 May 2003 12:42:09 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FJehuc018085 for ; Thu, 15 May 2003 12:40:43 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [66.93.182.229]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4FJecpd000184 for ; Thu, 15 May 2003 13:40:38 -0600 (MDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id 028EC334; Thu, 15 May 2003 12:11:27 -0700 (PDT) Date: Thu, 15 May 2003 14:11:27 -0500 From: David Terrell To: Eliot Lear Cc: IPv6 Subject: Re: C000 Message-ID: <20030515191127.GB2536@pianosa.catch22.org> Reply-To: David Terrell References: <3E957221.254CD6D5@hursley.ibm.com> <20030515172855.GA2536@pianosa.catch22.org> <3EC3DAB4.3080701@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EC3DAB4.3080701@cisco.com> User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 2:09PM up 4 days, 12:12, 37 users, load averages: 0.63, 0.50, 0.59 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, May 15, 2003 at 11:21:40AM -0700, Eliot Lear wrote: > >with a 2000::/3 address pair. > > > >A now needs to talk to B. > > > >What happens? > > You never get that far. If HUB wants to talk to A and B and they reside > in different site-local scopes, there is no way to guarantee that the > two spaces don't clash. HUB can at least know that A's site-local address is in a different scope by checking zone IDs. -- David Terrell | Nebcorp Prime Minister | dbt@meat.net | The best free things in life are free. http://wwn.nebcorp.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 May 15 14:28:43 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FLShhs024593; Thu, 15 May 2003 14:28:43 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4FLSgVg024592; Thu, 15 May 2003 14:28:42 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4FLSdhs024585 for ; Thu, 15 May 2003 14:28:39 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4FLRDuc029147 for ; Thu, 15 May 2003 14:27:13 -0700 (PDT) Received: from p2.piuha.net ([131.160.192.2]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4FLR73S013530 for ; Thu, 15 May 2003 15:27:08 -0600 (MDT) Received: from kolumbus.fi (p4.piuha.net [131.160.192.4]) by p2.piuha.net (Postfix) with ESMTP id 8ECB56A902; Fri, 16 May 2003 00:26:55 +0300 (EEST) Message-ID: <3EC405CC.8060705@kolumbus.fi> Date: Fri, 16 May 2003 00:25:32 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bound, Jim" Cc: ipng@sunroof.eng.sun.com Subject: Re: Summary: Avoiding interface failure upon DAD failure References: <9C422444DE99BC46B3AD3C6EAFC9711B03241252@tayexc13.americas.cpqcorp.net> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03241252@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bound, Jim wrote: > Hi Jari, > > Charlie and I have been having an offline discussion. We don't fully > agree but we agree on a lot more :--) And reading the mail. > > Here is wild suggestion and close to what you first proposed with > restriction clause. > > In the spec: > > MAY use 3041 in DAD failure. > > But I would suggest wording that this is for the specific case of a > "mobile node" moving. Well, perhaps this could be one way forward. But the above e-mail and some private conversions with other folks have alerted me to the fact that the original text that we proposed was unclear. It seems that many people interpreted it as "IF you run into a DAD failure, THEN you MAY start to use temporary addresses". However, this was not the intention. What we wanted to say was "You MAY use temporary addresses all of the time". Clarifying that might be another way forward. I do like your idea of binding this to movements only, perhaps that could also be done. How about: 7.6 Failures from Duplicate Addresses Upon failing Duplicate Address Detection, [13] requires IPv6 nodes to stop using the address and wait for manual configuration of a new address. In addition, if the failed address was a link-local address formed from an interface identifier, the interface should be disabled. Mobile nodes that wish to avoid a disabled link MAY avoid the use of interface identifiers when generating link-local addresses (and subsequent global addresses). If a collision is detected for such an address, it is no longer used but the status of the interface stays unchanged. Instead, mobile nodes MAY use temporary link-local addresses by generating a random interface identifier and using it for assigning itself a link-local address and derived care-of addresses for use on this link. In order to do this, the mobile node applies to the link-local address the procedure described in RFC 3041 [18] for global addresses. Implementations SHOULD NOT make more than 5 consecutive attempts to generate such addresses and test them through Duplicate Address Detection. If after these attempts no unique address was found, the mobile node SHOULD log a system error and give up attempting to find a link-local address on that interface, until the node moves to a new link. --Jari -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 15 19:07:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4G27fhs025453; Thu, 15 May 2003 19:07:41 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4G27fhW025452; Thu, 15 May 2003 19:07:41 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4G27chs025445 for ; Thu, 15 May 2003 19:07:38 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4G26CKw018394 for ; Thu, 15 May 2003 19:06:12 -0700 (PDT) Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4G2663S014775 for ; Thu, 15 May 2003 20:06:06 -0600 (MDT) Received: from kapow.its.monash.edu.au ([130.194.1.71]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KVYIUFBEGI9C3FGQ@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 16 May 2003 12:02:03 +1000 Received: from kapow.its.monash.edu.au (unknown [127.0.0.1]) by localhost (Postfix) with ESMTP id 018202000D; Fri, 16 May 2003 12:02:03 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by kapow.its.monash.edu.au (Postfix) with ESMTP id DBC6B2000C; Fri, 16 May 2003 12:02:02 +1000 (EST) Date: Fri, 16 May 2003 13:01:31 +1000 From: Greg Daley Subject: Re: Question about unsolicited MLD report for Solicited-Node Multicast Address To: Sha Liu Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3EC4548B.4000603@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <000701c31a10$c4cd65a0$0000fea9@liusand> <3EC2E0A2.8030806@eng.monash.edu.au> <001501c31aca$c1aad460$357b2dd2@liusand> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, This is obviously just an implementation issue (not really for ipv6-wg sorry). The issue you see in the Linux 2.4.18 kernel is caused by these lines in misnamed mcast.c:igmp6_join_group() ------------ if ((addr_type & (IPV6_ADDR_LINKLOCAL|IPV6_ADDR_LOOPBACK))) return; ------------ It is not sending MLD messages for link scoped multicast. Greg Sha Liu wrote: > Dear Greg, > Thanks for your explanation! > Whether can we say that the combination of no delay in sending MLD report and delay in sending first NS is to lessen the racing condition on the link? > In Linux kernel 2.4.18 source, I found a calling chain listed below: > addrconf_dad_start() -> addrconf_join_solicit() -> ipv6_dev_mc_inc() -> igmp6_group_added() -> igmp6_join_group() -> igmp6_send() > But in my tcpdump results, there is no MLD report exists. It is confusing me. > > ----- Original Message ----- > From: "Greg Daley" > To: "Liusand" > Cc: > Sent: Thursday, May 15, 2003 8:34 AM > Subject: Re: Question about unsolicited MLD report for Solicited-Node Multicast Address > > > >>Dear Liusand, >> >>Liusand wrote: >> >>>Hello, >>> When I read RFC2461, 2462 & 2710, I found that RFC2461 & 2462 request >> >> > that a node delays sending first NS message to avoid racing condition >> >>> on the link. But according to RFC2710, MLD message for Solicited-Node >>> Multicast Address ARE sent. Also from RFC2710, when a node joins a >> >> > multicast group, a unsolicited MLD report SHOULD be sent. >> >> >>This is a part of the specifications which is not exactly clear. >> >>The NS message is sent when DAD is to be undertaken. >>Initially, the node has not checked the address and needs to >>solicit in order to check if another node is in posession of this >>address. >> >>Does the node listen for NA messages for this address before it sends >>the DAD NS? >> >>If it does, then the MLD message has to be sent as soon as the task >>of listening to the multicast group is begun. This is because in some >>(future?) environments, valid multicast messages may not be delivered >>to the configuring node, unless the MLD message is sent on the link. >> >>If the node doesn't listen for NA's before the NS is sent, then there >>is no reason to join the solicited node multicast group for the address >>at a significantly before the DAD NS. Otherwise, we may see the >>situation you describe below. >> >>All nodes could notice that the link was available, and send MLD >>messages simultaneously in a way which could hamper the link. >> >>If the configuring nodes delay joining the multicast group to the >>same time that the DAD NS is sent, then two multicast packets (The MLD >>Report and the DAD NS) are sent at about the same time, and would be >>governed by the same random timer. In this case it is even more >>important that nodes obey the random delay for DAD! >> >> >> >>>According to the implementation of Linux kernel 2.4.18 and >> >> > USAGI-linux24-stable-20030214, when a node starts DAD procedure to >> > statelessly autoconfigure its IPv6 address, a MLD report for the relevant >> > Solicited-Node Multicast Address will be sent immediately even when the >> > node boots up, while the NS for DAD will be delayed. >> >>I think that you mean that the 2.4.18 kernel was patched with USAGI. >>I thought that the standard linux 2.4.18 kernel didn't do MLD for >>solicited nodes addresses. >>Is this your understanding too? >> >> >>> Does the implementation above violate the policy of delaying sending >> >> > the first message when a node boots up? I think the undelayed MLD >>report >> > for the Solicited-Node Multicast Address may also cause racing >> >>> condition on the link. So I suggest that this MLD report be delayed >> >> > and be sent just before the NS for DAD. If the problem caused by such >> > racing condition is not so severe, why not revoke such delay to speed up >> > the DAD? >> >>This is a genuine issue with the standards. The RFC text is >>both explicit, and contradictory. >> >>For Example: >> >>Section 5.4.2 of RFC 2462: >> >>"Before sending a Neighbor Solicitation, an interface MUST join ... >> the solicited-node multicast address" >> >>RFC 2710 implies this means sending an MLD report. >>and >> >>"If the Neighbor Solicitation is the first message to be sent from an >> interface after interface (re)initialization, the node should delay >> sending the message by a random delay" >> >>These statements are mutually exclusive, since the MLD report >>will always be sent before the Neighbor Solicitation. >> >>The statement which means that MLD reports are sent before the delay >>is this Mandatory requirement: >> >>" In order to improve the robustness of the >> Duplicate Address Detection algorithm, an interface MUST receive and >> process datagrams sent to the all-nodes multicast address or >> solicited-node multicast address of the tentative address while >> delaying transmission of the initial Neighbor Solicitation." >> >>This means that the MLD reports for solicited nodes multicast are >>sent as soon as the node decides to configure the address, and >>effectively defeats the randomization strategy. >> >>So the USAGI implementation may be correct, if misguided. >> >>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 >>-------------------------------------------------------------------- >> >> >> > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 16 03:14:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4GAEkhs026593; Fri, 16 May 2003 03:14:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4GAEkmH026592; Fri, 16 May 2003 03:14:46 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4GAEghs026585 for ; Fri, 16 May 2003 03:14:42 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4GADIuc004983 for ; Fri, 16 May 2003 03:13:18 -0700 (PDT) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4GADBHN025044 for ; Fri, 16 May 2003 03:13:12 -0700 (PDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4GAD1lr066412 for ; Fri, 16 May 2003 12:13:02 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4GACwaY094102 for ; Fri, 16 May 2003 12:12:59 +0200 Received: from dhcp22-123.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA62280 from ; Fri, 16 May 2003 12:12:56 +0200 Message-Id: <3EC4B9C6.A26CE602@hursley.ibm.com> Date: Fri, 16 May 2003 12:13:26 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: IPv6 Subject: Re: C000 References: <3E957221.254CD6D5@hursley.ibm.com> <20030515172855.GA2536@pianosa.catch22.org> <3EC3DAB4.3080701@cisco.com> <20030515191127.GB2536@pianosa.catch22.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk David Terrell wrote: > > On Thu, May 15, 2003 at 11:21:40AM -0700, Eliot Lear wrote: > > >with a 2000::/3 address pair. > > > > > >A now needs to talk to B. > > > > > >What happens? > > > > You never get that far. If HUB wants to talk to A and B and they reside > > in different site-local scopes, there is no way to guarantee that the > > two spaces don't clash. > > HUB can at least know that A's site-local address is in a different scope > by checking zone IDs. I'm not quite sure what a zone ID is, and we should probably have this discussion in the light of draft-hinden-ipv6-global-local-addr-00.txt, not my half-baked C000 suggestion. But yes, this is a real world problem and no address format tweaking will make it go away. However, if HUB concludes that A and B cannot communicate, but in fact they can due to an ad hoc VPN between them, then we are in trouble. This is why I don't understand how simple scoping rules can solve the problem. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 16 03:32:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4GAW7hs026834; Fri, 16 May 2003 03:32:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4GAW7Q1026833; Fri, 16 May 2003 03:32:07 -0700 (PDT) Received: from bebop.France.Sun.COM (bebop.France.Sun.COM [129.157.174.15]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4GAW3hs026826 for ; Fri, 16 May 2003 03:32:03 -0700 (PDT) Received: from lillen (punchin-nordmark.Eng.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id h4GAUTL26038; Fri, 16 May 2003 12:30:29 +0200 (MEST) Date: Fri, 16 May 2003 09:26:53 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Router Lifetime question To: Peter Barany , sivav@qualcomm.com Cc: "'Erik Nordmark'" , "'ipng@sunroof.eng.sun.com'" In-Reply-To: "Your message with ID" <1B54FA3A2709D51195C800508BF9386A080B38B8@zrc2c000.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > What I mean to say is that the parameter AdvDefaultLifetime MUST be either > zero or between MaxRtrAdvInterval and 9000 seconds (IPv6) per RFC 2461. Same > thing for IPv4 per RFC 1256 (only the parameter is Advertisement Lifetime). > The inconsistency (for lack of a better word) is that the Router Lifetime > field is 16 bits and if set to anything greater than 9000 seconds then this > would violate the specifications. So, if it is set to 18.2 hours (e.g., for > some wireless cellular links) it violates the specs. Thanks, now I understand your point. While the wording might be unfortunate and perhaps confusing, saying that 2^^16 seconds is 18.2 hours is correct. Even though the sender will not use more than 9000 seconds the protocol doesn't, and presumably shouldn't, have the receivers reject RAs with a router lifetime that is larger per the "consevative in what you send; liberal in what you accept" principle. So if we change the sentence in 4.2 from: The maximum value corresponds to 18.2 hours. to The field can contain values up to 65535 and receivers should handle any value, while the sending rules in section 6 limit the lifetime to 9000 seconds. would that be better? 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 May 16 04:26:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4GBQrhs027203; Fri, 16 May 2003 04:26:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4GBQrLr027202; Fri, 16 May 2003 04:26:53 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4GBQnhs027195 for ; Fri, 16 May 2003 04:26:49 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4GBPOKw025556 for ; Fri, 16 May 2003 04:25:25 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4GBPJpd015107 for ; Fri, 16 May 2003 05:25:19 -0600 (MDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19417; Fri, 16 May 2003 07:22:12 -0400 (EDT) Message-Id: <200305161122.HAA19417@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: ipng@sunroof.eng.sun.com, v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-park-scalable-multi-natpt-00.txt Date: Fri, 16 May 2003 07:21:57 -0400 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Scalable mNAT-PT Solution Author(s) : S. Park et al. Filename : draft-park-scalable-multi-natpt-00.txt Pages : 10 Date : 2003-5-15 This document provides scalability extension to NAT-PT. The extension is based on the use of DNS-ALG and exchange of load metrics amongst a cluster of NAT-PT devices. We refer such a NAT-PT device as mNAT-PT. mNAT-PT is valuable in connecting large V6 domains to legacy V4 domain. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-park-scalable-multi-natpt-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-scalable-multi-natpt-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-scalable-multi-natpt-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: <2003-5-15150104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-park-scalable-multi-natpt-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-park-scalable-multi-natpt-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-15150104.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 May 16 05:55:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4GCtdhs027591; Fri, 16 May 2003 05:55:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4GCtd67027590; Fri, 16 May 2003 05:55:39 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4GCtahs027583 for ; Fri, 16 May 2003 05:55:36 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4GCsBKw009443 for ; Fri, 16 May 2003 05:54:11 -0700 (PDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4GCs53S006326 for ; Fri, 16 May 2003 06:54:05 -0600 (MDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h4GCrwf19697; Fri, 16 May 2003 07:53:58 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 May 2003 07:53:58 -0500 Message-ID: <1B54FA3A2709D51195C800508BF9386A080B38B9@zrc2c000.us.nortel.com> From: "Peter Barany" To: "'Erik Nordmark'" , sivav@qualcomm.com Cc: "'ipng@sunroof.eng.sun.com'" Subject: RE: Router Lifetime question Date: Fri, 16 May 2003 07:53:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C31BAA.36E54EF6" 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_01C31BAA.36E54EF6 Content-Type: text/plain; charset="iso-8859-1" Perfect. That's what I wanted to know ... the client/receiver interpretation. Thanks. Pete -----Original Message----- From: Erik Nordmark [mailto:Erik.Nordmark@sun.com] Sent: Friday, May 16, 2003 2:27 AM To: Barany, Peter [RICH1:2H16:EXCH]; sivav@qualcomm.com Cc: 'Erik Nordmark'; 'ipng@sunroof.eng.sun.com' Subject: RE: Router Lifetime question > What I mean to say is that the parameter AdvDefaultLifetime MUST be either > zero or between MaxRtrAdvInterval and 9000 seconds (IPv6) per RFC 2461. Same > thing for IPv4 per RFC 1256 (only the parameter is Advertisement Lifetime). > The inconsistency (for lack of a better word) is that the Router Lifetime > field is 16 bits and if set to anything greater than 9000 seconds then this > would violate the specifications. So, if it is set to 18.2 hours (e.g., for > some wireless cellular links) it violates the specs. Thanks, now I understand your point. While the wording might be unfortunate and perhaps confusing, saying that 2^^16 seconds is 18.2 hours is correct. Even though the sender will not use more than 9000 seconds the protocol doesn't, and presumably shouldn't, have the receivers reject RAs with a router lifetime that is larger per the "consevative in what you send; liberal in what you accept" principle. So if we change the sentence in 4.2 from: The maximum value corresponds to 18.2 hours. to The field can contain values up to 65535 and receivers should handle any value, while the sending rules in section 6 limit the lifetime to 9000 seconds. would that be better? Erik ------_=_NextPart_001_01C31BAA.36E54EF6 Content-Type: text/html; charset="iso-8859-1" RE: Router Lifetime question

Perfect. That's what I wanted to know ... the client/receiver interpretation. Thanks.

Pete

-----Original Message-----
From: Erik Nordmark [mailto:Erik.Nordmark@sun.com]
Sent: Friday, May 16, 2003 2:27 AM
To: Barany, Peter [RICH1:2H16:EXCH]; sivav@qualcomm.com
Cc: 'Erik Nordmark'; 'ipng@sunroof.eng.sun.com'
Subject: RE: Router Lifetime question


> What I mean to say is that the parameter AdvDefaultLifetime MUST be either
> zero or between MaxRtrAdvInterval and 9000 seconds (IPv6) per RFC 2461. Same
> thing for IPv4 per RFC 1256 (only the parameter is Advertisement Lifetime).
> The inconsistency (for lack of a better word) is that the Router Lifetime
> field is 16 bits and if set to anything greater than 9000 seconds then this
> would violate the specifications. So, if it is set to 18.2 hours (e.g., for
> some wireless cellular links) it violates the specs.

Thanks, now I understand your point.

While the wording might be unfortunate and perhaps confusing, saying that
2^^16 seconds is 18.2 hours is correct.
Even though the sender will not use more than 9000 seconds the protocol
doesn't, and presumably shouldn't, have the receivers reject RAs with a
router lifetime that is larger per the "consevative in what you send;
liberal in what you accept" principle.

So if we change the sentence in 4.2 from:
        The maximum value corresponds to 18.2 hours.
to
        The field can contain values up to 65535 and receivers should
        handle any value, while the sending rules in section 6 limit
        the lifetime to 9000 seconds.
would that be better?

  Erik


------_=_NextPart_001_01C31BAA.36E54EF6-- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 16 10:36:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4GHavhs028350; Fri, 16 May 2003 10:36:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4GHavVt028349; Fri, 16 May 2003 10:36:57 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4GHarhs028342 for ; Fri, 16 May 2003 10:36:53 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4GHZSuc023490 for ; Fri, 16 May 2003 10:35:28 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4GHZNx9023589 for ; Fri, 16 May 2003 10:35:23 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 16 May 2003 10:35:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Message-ID: <963621801C6D3E4A9CF454A1972AE8F504F7F3@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMa16jH5rSet9glQ16AkPtcAOPZGwA96Qog From: "Michel Py" To: "Brian Carpenter" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4GHashs028343 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, > Brian E Carpenter wrote: > - which pair(*) of addresses will give the best > reliability|throughput|delay? > - which pair of addresses will stay within a specified > security boundary (e.g. within the corporate firewall, > within a given VPN connection, within a given Grid > virtual organization)? This leads to having the decisions of the address selection and TE being made by the site's edge router because it's the only box that has enough knowledge of the topology. Same would apply to flow label I think: there are numerous advantages of the address selection being done by the router that labels flows, with mutual awareness of the process. Although I agree that they could be cases like DMZ web servers that could get a copy of the routing table and the site's egress policy, most hosts within a site should have only one address (identifier) and let the SBR decides which PA address it maps to. In other words, a host could have multiple PA addresses but these addresses must be virtualized and projected in the SBR. > I'm increasingly concerned that there is no way to resolve such > questions by examining the prefix bits in an address or by > defining scope as a set of concentric circles such as > link-site-global. I never considered scope to be helpful with sophisticated traffic engineering. Scope can help with blackholing and with no-brainer decisions; I consider it more like a "last resort" TE solution. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 16 15:40:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4GMechs029297; Fri, 16 May 2003 15:40:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4GMec66029295; Fri, 16 May 2003 15:40:38 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4GMeYhs029287 for ; Fri, 16 May 2003 15:40:34 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4GMd9Kw024048 for ; Fri, 16 May 2003 15:39:09 -0700 (PDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4GMd33S016525 for ; Fri, 16 May 2003 16:39:03 -0600 (MDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 0DADEA64F; Fri, 16 May 2003 18:39:03 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 16 May 2003 18:39:02 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Fri, 16 May 2003 18:39:02 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03411A23@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMaZY9Ox/NkoQhNQRel+NzWN3mrlgBkSDtg From: "Bound, Jim" To: "Alain Durand" , "Pekka Savola" Cc: "Bob Hinden" , "Margaret Wasserman" , X-OriginalArrivalTime: 16 May 2003 22:39:02.0890 (UTC) FILETIME=[F34914A0:01C31BFB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4GMeYhs029288 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is transparent to applications completely. /jim > -----Original Message----- > From: Alain Durand [mailto:Alain.Durand@Sun.COM] > Sent: Wednesday, May 14, 2003 5:47 PM > To: Pekka Savola > Cc: Bob Hinden; Margaret Wasserman; ipng@sunroof.eng.sun.com > Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses > > > > On Tuesday, May 13, 2003, at 10:58 AM, Pekka Savola wrote: > > > On Tue, 13 May 2003, Bob Hinden wrote: > >>> Bob's proposal explicitly defines a type of addresses > that are not > >>> expected to be routed throughout the Internet. So, these > addresses > >>> are local, not globally routable. > >>> > >>> However, Bob's proposal defines addresses that are unique > throughout > >>> the Internet. No single address identifies one node when used > >>> within one "scope" and another node when used in another > "scope". > >>> So, these are not "scoped addresses", as defined in the > IPv6 Scoped > >>> Addressing Architecture. > >>> > >>> I *think* that Bob and I are using the same definition > for the term > >>> "scoped", but I hope he'll correct me if I'm wrong. > >> > >> I tried hard to not define the term "scoped address". I only used > >> the word > >> "scope" once in the draft and that referred to global scope > >> addresses. I > >> may remove that use in the next version :-) > >> > >> The globally unique IPv6 local unicast addresses are not limited in > >> their > >> use to any scope less than global by their design because they have > >> prefixes that are globally unique. By comparison site-local > >> addresses were > >> limited to a limited scope by their design because they had > >> non-globally > >> unique prefixes. > >> > >> So yes, I think we agree. > > > > What would you propose to do with default address selection, if any? > > > > Should a preference in it be given to truly global or > globally unique > > local addresses, or should these be indistinguishable from > the point > > of view? > > > > This "addresses tried first" ordering is of some importance -- which > > one > > reason for having this "scope" concept. > > Pekka is right. The real question behind Bob's proposal is > not so much to know if it creates scopes or not, but what is > the impact on the > applications. > > If applications need to be aware of those addresses and take > different > actions > if/when different combination of "bob's" or "regular" > addresses exist, > we > end up with much of the issues we had with Site Local, ambiguity > excepted. > This needs to be clarified. > > - 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 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 16 15:40:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4GMeihs029305; Fri, 16 May 2003 15:40:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4GMei7T029304; Fri, 16 May 2003 15:40:44 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4GMebhs029294 for ; Fri, 16 May 2003 15:40:37 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4GMdCuc012020 for ; Fri, 16 May 2003 15:39:12 -0700 (PDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4GMd7x9018185 for ; Fri, 16 May 2003 15:39:07 -0700 (PDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id B955B6DA; Fri, 16 May 2003 18:39:06 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.6673); Fri, 16 May 2003 18:39:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Summary: Avoiding interface failure upon DAD failure Date: Fri, 16 May 2003 18:39:06 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B03411A25@tayexc13.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Summary: Avoiding interface failure upon DAD failure Thread-Index: AcMbKMCEBGgbeuOSSb6QMBsksBXgEAAzn/4A From: "Bound, Jim" To: "Jari Arkko" , "Bound, Jim" Cc: X-OriginalArrivalTime: 16 May 2003 22:39:06.0609 (UTC) FILETIME=[F5808E10:01C31BFB] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4GMechs029296 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk This is good below yes. Good job. /jim > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@kolumbus.fi] > Sent: Thursday, May 15, 2003 5:26 PM > To: Bound, Jim > Cc: ipng@sunroof.eng.sun.com > Subject: Re: Summary: Avoiding interface failure upon DAD failure > > > Bound, Jim wrote: > > Hi Jari, > > > > Charlie and I have been having an offline discussion. We > don't fully > > agree but we agree on a lot more :--) And reading the mail. > > > > Here is wild suggestion and close to what you first proposed with > > restriction clause. > > > > In the spec: > > > > MAY use 3041 in DAD failure. > > > > But I would suggest wording that this is for the specific case of a > > "mobile node" moving. > > Well, perhaps this could be one way forward. > > But the above e-mail and some private conversions with other > folks have alerted me to the fact that the original text that > we proposed was unclear. It seems that many people > interpreted it as "IF you run into a DAD failure, THEN you > MAY start to use temporary addresses". However, this was not > the intention. What we wanted to say was "You MAY use > temporary addresses all of the time". > > Clarifying that might be another way forward. I do like > your idea of binding this to movements only, perhaps that > could also be done. How about: > > 7.6 Failures from Duplicate Addresses > > Upon failing Duplicate Address Detection, [13] requires > IPv6 nodes to > stop using the address and wait for manual configuration > of a new address. > In addition, if the failed address was a link-local address formed > from an interface identifier, the interface should be disabled. > > Mobile nodes that wish to avoid a disabled link MAY avoid the use > of interface identifiers when generating link-local addresses > (and subsequent global addresses). If a collision is detected for > such an address, it is no longer used but the status of > the interface > stays unchanged. > > Instead, mobile nodes MAY use temporary link-local addresses by > generating a random interface identifier and using it for > assigning > itself a link-local address and derived care-of addresses > for use on > this link. In order to do this, the mobile node applies > to the link-local > address the procedure described in RFC 3041 [18] for global > addresses. Implementations SHOULD NOT make more than 5 consecutive > attempts to generate such addresses and test them through > Duplicate > Address Detection. If after these attempts no unique address was > found, the mobile node SHOULD log a system error and give up > attempting to find a link-local address on that interface, until > the node moves to a new link. > > --Jari > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 16 22:29:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4H5Tshs000454; Fri, 16 May 2003 22:29:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4H5TrYO000453; Fri, 16 May 2003 22:29:53 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4H5Tohs000446 for ; Fri, 16 May 2003 22:29:50 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4H5SPuc027316 for ; Fri, 16 May 2003 22:28:25 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4H5SJsa014805 for ; Fri, 16 May 2003 23:28:19 -0600 (MDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4H5S6O25152; Sat, 17 May 2003 08:28:06 +0300 Date: Sat, 17 May 2003 08:28:05 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Alain Durand , Bob Hinden , Margaret Wasserman , Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B03411A23@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, 16 May 2003, Bound, Jim wrote: > This is transparent to applications completely. And to the operating system? Can in distinguish between the addresses? > > -----Original Message----- From: Alain Durand > > [mailto:Alain.Durand@Sun.COM] Sent: Wednesday, May 14, 2003 5:47 PM > > To: Pekka Savola Cc: Bob Hinden; Margaret Wasserman; > > ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 > > Local Unicast Addresses > > > > > > > > On Tuesday, May 13, 2003, at 10:58 AM, Pekka Savola wrote: > > > > > On Tue, 13 May 2003, Bob Hinden wrote: > > >>> Bob's proposal explicitly defines a type of addresses > > that are not > > >>> expected to be routed throughout the Internet. So, these > > addresses > > >>> are local, not globally routable. > > >>> > > >>> However, Bob's proposal defines addresses that are unique > > throughout > > >>> the Internet. No single address identifies one node when used > > >>> within one "scope" and another node when used in another > > "scope". > > >>> So, these are not "scoped addresses", as defined in the > > IPv6 Scoped > > >>> Addressing Architecture. > > >>> > > >>> I *think* that Bob and I are using the same definition > > for the term > > >>> "scoped", but I hope he'll correct me if I'm wrong. > > >> > > >> I tried hard to not define the term "scoped address". I only used > > >> the word > > >> "scope" once in the draft and that referred to global scope > > >> addresses. I > > >> may remove that use in the next version :-) > > >> > > >> The globally unique IPv6 local unicast addresses are not limited in > > >> their > > >> use to any scope less than global by their design because they have > > >> prefixes that are globally unique. By comparison site-local > > >> addresses were > > >> limited to a limited scope by their design because they had > > >> non-globally > > >> unique prefixes. > > >> > > >> So yes, I think we agree. > > > > > > What would you propose to do with default address selection, if any? > > > > > > Should a preference in it be given to truly global or > > globally unique > > > local addresses, or should these be indistinguishable from > > the point > > > of view? > > > > > > This "addresses tried first" ordering is of some importance -- which > > > one > > > reason for having this "scope" concept. > > > > Pekka is right. The real question behind Bob's proposal is > > not so much to know if it creates scopes or not, but what is > > the impact on the > > applications. > > > > If applications need to be aware of those addresses and take > > different > > actions > > if/when different combination of "bob's" or "regular" > > addresses exist, > > we > > end up with much of the issues we had with Site Local, ambiguity > > excepted. > > This needs to be clarified. > > > > - 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 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 17 09:09:26 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4HG9Phs001941; Sat, 17 May 2003 09:09:26 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4HG9Pde001940; Sat, 17 May 2003 09:09:25 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4HG9Mhs001933 for ; Sat, 17 May 2003 09:09:22 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4HG7tKw029081 for ; Sat, 17 May 2003 09:07:55 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4HG7nsa022346 for ; Sat, 17 May 2003 10:07:50 -0600 (MDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Sat, 17 May 2003 09:07:47 -0700 Reply-To: From: "Tony Hain" To: "'Bob Hinden'" , Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Sat, 17 May 2003 09:07:48 -0700 Message-ID: <135301c31c8e$766cee50$261e4104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <4.3.2.7.2.20030507111352.02d4cff0@mailhost.iprg.nokia.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4HG9Mhs001934 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I have been occupied for the last two weeks, and wanted to wait until I had time to seriously comment. Bob Hinden wrote: > My intent in writing the draft was to put together a > (hopefully) complete > solution that folks can look out to see if the benefits exceed the > cost/complexity. I don't believe this is complete since it only deals with the ambiguity part of the problem. I sent in the updated version -01 of my local scope requirements draft last weekend, and I understand it has made it through the I-D editor queue. > > I suggest that the initial comments be limited to whether you > think this > approach (i.e., globally unique but not globally routing prefixes) is > reasonable for the IPv6 working group to pursue. As others have commented, a registry fails to meet the need for a completely free easy to automate mechanism. Christian raised the concern about the number of bits needed, but as kre noted the real domain is limited to the sets where interconnections actually occur. Having both an automated and a manual mechanism like your proposal allows automation for the vast majority of unmanaged cases, but if a collision occurs, there is an alternative to work around it. I would expect some network managers to find your registry appealing in that it hints at an assurance of collision free space. As kre noted, you can't ever assure that because anyone can stomp on an allocation. One specific comment about this doc, we should have learned from the 2373 experience that putting operational policy in an IETF doc will eventually lead to trouble. In particular, identifying a specific monetary value does not belong here. I am not sure that it is reasonable for the IPv6 WG to work on this. In any case, a PI mechanism needs to be dealt with in parallel, and this should not be forwarded until the PI approach can move with it. At the same time, we probably should identify the issues related to name to address mapping, and comment on the operational issues related to applications that pass limited scope addresses outside their realm of reachability. It may also be useful to have a BCP requiring scope matching for the time being. (maybe that paragraph is the basis for a bof to develop a charter) Comments on the mail thread. Bob Hinden wrote: > Margaret, > > >Bob's proposal explicitly defines a type of addresses that are not > >expected to be routed throughout the Internet. So, these > addresses are > >local, not globally routable. > > > >However, Bob's proposal defines addresses that are unique throughout > >the Internet. No single address identifies one node when > used within > >one "scope" and another node when used in another "scope". > So, these > >are not "scoped addresses", as defined in the IPv6 Scoped Addressing > >Architecture. > > > >I *think* that Bob and I are using the same definition for the term > >"scoped", but I hope he'll correct me if I'm wrong. > > I tried hard to not define the term "scoped address". I only > used the word > "scope" once in the draft and that referred to global scope > addresses. I > may remove that use in the next version :-) > > The globally unique IPv6 local unicast addresses are not > limited in their > use to any scope less than global by their design because they have > prefixes that are globally unique. By comparison site-local > addresses were > limited to a limited scope by their design because they had > non-globally > unique prefixes. > > So yes, I think we agree. This is duplicitous and deceptive. The second sentence of the draft says these are not to be globally routed, therefore they are explicitly of different scope than a global scope address which are intended to be globally routed. Claiming they 'are not limited in their use to any scope less than global' at the same time the doc says they are limited in that way is confusing and wrong. Eliot Lear wrote: > I disagree. I think the only way to deal with the problem I > describe is > to deal with renumbering properly. If renumbering actually made any sense, we would reclaim the entire IPv4 space and start over. After all if it is good for the edge it must be even better and simpler for the core. Forced renumbering is a fantasy, so the WG needs to get over it. Any attempt to force network managers to change addresses will simply ensure they install a nat to isolate themselves from that insanity. Bound, Jim wrote: > ... > To me this is a no brainer and problem solved. Why not spend > our time making the spec better and ready for IESG for PS > whenever we can instead of debating its merits. This IMO is > the mature, time-to-market, and compromised solution for us > all to get what we want and do some real work as a team and > move forward. Because the problem is not solved. Polishing this and promoting it as the solution only prolongs the reconing day. Until app developers (including name resolution services) stop assuming the network is a flat routing space, the system will be broken. Andrew White wrote: > Considering that using a local addressing scheme is optional > and that the justifications for using such a scheme usually > centre around having an addressing and routing architecture > that works regardless of ISPs and global prefixes, let's > assume that the existence of such addresses implies that the > network wants applications to favour these prefixes. I agree. > > Let's further assume hosts implement default address > selection (RFC3484). > To favour local addresses, we give them a 'scope' (for the purposes of > RFC3484) that is smaller than global unicast. > There will be addresses with a scope smaller than global unicast, I think your point is to provide a mechanism to identify which ones they are. > Name -> address lookups will then return addresses in the > following order: > > Src has local address: > - Local addresses (longest prefix match first) > - Global addresses (if src also has global, longest prefix > match first) Src has only global address > - Global addresses (longest prefix match first) > - Local addresses Yes order might help apps that don't bother to look, but I don't think order matters as much as making sure that the address resolution mechanism doesn't return local addresses for queries that originate outside the reachable domain. There are many ways to accomplish this, so I think our job is to define the requirement and let the specific mechanism figure out the appropriate approach. > One advantage of local addresses is this: > - things that don't care about filters and scopes and ... > don't have to. > - things that need to care about filters and scopes have more > information than they otherwise would. > Yes !!! Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 18 04:33:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4IBXShs005912; Sun, 18 May 2003 04:33:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4IBXStV005911; Sun, 18 May 2003 04:33:28 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4IBXPhs005904 for ; Sun, 18 May 2003 04:33:25 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4IBVjKw029690 for ; Sun, 18 May 2003 04:31:45 -0700 (PDT) Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4IBVesa003667 for ; Sun, 18 May 2003 05:31:40 -0600 (MDT) Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h4IBVTBP019312; Sun, 18 May 2003 04:31:29 -0700 (PDT) Received: from cisco.com (sjc-vpn1-170.cisco.com [10.21.96.170]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id EAA13975; Sun, 18 May 2003 04:31:28 -0700 (PDT) Message-ID: <3EC76F0F.4080009@cisco.com> Date: Sun, 18 May 2003 04:31:27 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'Bob Hinden'" , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <135301c31c8e$766cee50$261e4104@eagleswings> In-Reply-To: <135301c31c8e$766cee50$261e4104@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, > I am not sure that it is reasonable for the IPv6 WG to work on this. Given that it would make little sense to have both this and a site-local mechanism, I don't see how you could avoid doing the work in the same area. > In any case, a PI mechanism needs to be dealt with in parallel, and this > should not be forwarded until the PI approach can move with it. I agree with this point, and as I believe others have said, I believe we need to recognize that the same issues would hit us with the doc prefix that was proposed. > At the > same time, we probably should identify the issues related to name to > address mapping, and comment on the operational issues related to > applications that pass limited scope addresses outside their realm of > reachability. It may also be useful to have a BCP requiring scope > matching for the time being. (maybe that paragraph is the basis for a > bof to develop a charter) This gets simplified since we've deprecated site-local. > > Eliot Lear wrote: > >>I disagree. I think the only way to deal with the problem I >>describe is >>to deal with renumbering properly. > > > If renumbering actually made any sense, we would reclaim the entire IPv4 > space and start over. Were this the only issue in order to reclaim IP addresses, perhaps it would have happened! As you well know there are all sorts of ambiguities of ownership of IPv4 addresses. > After all if it is good for the edge it must be > even better and simpler for the core. Funny you should mention this- much of the edge renumbers all the time. That's what DHCP and PPP have given us. Our problem space in only this regard has narrowed significantly since IPng began. In other ways, it's grown. > Forced renumbering is a fantasy, Except for most of the edge. > so the WG needs to get over it. No. The IP version 6 development team made a grave error by not properly dealing with administrative concerns in the beginning, so please let's deal with it now. > Any attempt to force network managers to > change addresses will simply ensure they install a nat to isolate > themselves from that insanity. Were this the root cause of the problem I would agree. But it is not, and so I don't. Make renumbering easier, so network managers needn't object to it. It's clearly possible, since it has been done on the edge once before. If you can manage such a transition in the end points you can manage it in the core. The hard remains the interaction with DNS, as far as I tell. I am by far not the first to identify the problem. The solution space cannot be rocket science, but my suspicion is that it does require enrollment of some sort in order to really scale. Eliot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 18 06:41:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4IDfuhs006713; Sun, 18 May 2003 06:41:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4IDftsN006712; Sun, 18 May 2003 06:41:55 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4IDfqhs006705 for ; Sun, 18 May 2003 06:41:52 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4IDeNKw023923 for ; Sun, 18 May 2003 06:40:23 -0700 (PDT) Received: from mx1.ustc.edu.cn ([218.22.21.1]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4IDe9HN012213 for ; Sun, 18 May 2003 06:40:14 -0700 (PDT) Received: from liusand ([210.45.123.53]) by mx1.ustc.edu.cn (8.8.7/8.8.6) with SMTP id VAA12961; Sun, 18 May 2003 21:36:33 +0800 Message-ID: <000c01c31d42$93909900$357b2dd2@liusand> From: "Sha Liu" To: Cc: References: <000401c31ac5$8401dd20$4906140a@future.futsoft.com> Subject: Re: Anycast address - How to find the "nearest" router? Date: Sun, 18 May 2003 21:37:05 +0800 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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by sunroof.eng.sun.com id h4IDfqhs006706 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, In RFC2461: "7.2.4. Sending Solicited Neighbor Advertisements If the Target Address is either an anycast address or a unicast address for which the node is providing proxy service, or the Target Link-Layer Address option is not included, the Override flag SHOULD be set to zero. Otherwise, the Override flag SHOULD be set to one. Proper setting of the Override flag ensures that nodes give preference to non-proxy advertisements, even when received after proxy advertisements, and also ensures that the first advertisement for an anycast address "wins"." ----- Original Message ----- From: "Sivaramakrishnan A" To: "'Suvidh Mathur'" Cc: Sent: Thursday, May 15, 2003 5:36 PM Subject: RE: Anycast address - How to find the "nearest" router? > Hi, > > I accept that the route table organisation can help to find the > nearness of any router. So (In this case) do you mean, both R1 > and R2 should agree upon themselves, that who should process > the packet anycast addressed packet ? If yes, how could this be > achieved? > > How can NS-NA exchange help us resolve who should receive the packet? > > thanks, > Sivaramakrishnan. A > > -----Original Message----- > From: Suvidh Mathur [mailto:Suvidh.Mathur@lntinfotech.com] > Sent: Thursday, 15 May 2003 1:51 PM > To: sivarka@future.futsoft.com > Subject: Re: Anycast address - How to find the "nearest" router? > > > > Hi, > > What exactly do you mean by "nearest"? > > As per the RFC, nearest should be based on the routing protocols' notion of > distance. Thus if R1 is nearer then R2, then the packet should reach R1 > alone. > If R1 and R2 are equi-distant, then either the routing table organization > (at the sending nore and / or the intermediate routers) or NS - NA exchange > (in case of R1 and R2 being onlink) should ensure that the packet is sent > only to one of the routers. > > Hope this helps, > > Regards, > Suvidh > > Thursday, 15 May, 2003 12:39 PM > To: > cc: > From: "Sivaramakrishnan A" > Subject: Anycast address - How to find the "nearest" router? > > > > Hi, > I have 2 Routers ( R1 and R2) in a link who are configured the same > ANYCAST > address. > A packet is addressed to that anycast address. According to [ADDR-ARCH] the > "nearest" > one shoule receive this packet. Assume R1 is the "nearest" one here. But > how > does R1 know > that "I'm the nearest, and I should process this packet?" . If Suppose if > R1 is nearer, how is > R2 restricted from processing the packet? > thanks and regards, > Sivaramakrishnan. A > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 18 06:53:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4IDr8hs006889; Sun, 18 May 2003 06:53:08 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4IDr84a006888; Sun, 18 May 2003 06:53:08 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4IDr5hs006881 for ; Sun, 18 May 2003 06:53:05 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4IDpWKw025907 for ; Sun, 18 May 2003 06:51:32 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4IDpRsa005822 for ; Sun, 18 May 2003 07:51:27 -0600 (MDT) Received: from IDLEWYLDE.windriver.com ([147.11.233.1]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id GAA21734; Sun, 18 May 2003 06:51:10 -0700 (PDT) Message-Id: <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 18 May 2003 09:47:02 -0400 To: Eliot Lear From: Margaret Wasserman Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Cc: alh-ietf@tndh.net, "'Bob Hinden'" , ipng@sunroof.eng.sun.com In-Reply-To: <3EC76F0F.4080009@cisco.com> References: <135301c31c8e$766cee50$261e4104@eagleswings> <135301c31c8e$766cee50$261e4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Eliot, At 04:31 AM 5/18/2003 -0700, Eliot Lear wrote: >>I am not sure that it is reasonable for the IPv6 WG to work on this. > >Given that it would make little sense to have both this and a site-local >mechanism, I don't see how you could avoid doing the work in the same area. It would be possible to move the whole concept of "local" addressing (with the exception of link-local, which we already have well-defined) out of the IPv6 WG and into a separate WG. This would have some advantages, most important of which, IMO, is that it would allow the original IPv6 WG to focus on finishing up the remaining pieces of IPv6 and bug fixing some of the older pieces, while the new WG could focus on the issue of local addressing. >>In any case, a PI mechanism needs to be dealt with in parallel, and this >>should not be forwarded until the PI approach can move with it. > >I agree with this point, and as I believe others have said, I believe we >need to recognize that the same issues would hit us with the doc prefix >that was proposed. I certainly think that work on a PI routing model should happen outside of the IPv6 WG. I'm not even totally sure that this should be in the Internet area, rather than Routing. >>so the WG needs to get over it. > >No. The IP version 6 development team made a grave error by not properly >dealing with administrative concerns in the beginning, so please let's >deal with it now. Why do you think that the problem of renumbering specifically falls under the auspices of the IPv6 WG? The IPv6 WG has already done some work on router renumbering, but, depending on how far you want to go, renumbering is actually a systemic issue. Do you want to renumber DNS, security associations, existing connections? If so, these are problems for the DNS groups, the security area and the the transport area, not just the IPv6 WG. Margaret -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sun May 18 08:18:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4IFIkhs007294; Sun, 18 May 2003 08:18:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4IFIkpm007293; Sun, 18 May 2003 08:18:46 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4IFIhhs007286 for ; Sun, 18 May 2003 08:18:43 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4IFHEuc020872 for ; Sun, 18 May 2003 08:17:14 -0700 (PDT) Received: from c001.snv.cp.net (h013.c001.snv.cp.net [209.228.32.127]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with SMTP id h4IFH9pd007597 for ; Sun, 18 May 2003 09:17:09 -0600 (MDT) Received: (cpmta 14426 invoked from network); 18 May 2003 08:17:08 -0700 Received: from 212.150.211.163 (HELO w2knerick) by smtp.register-admin.com (209.228.32.127) with SMTP; 18 May 2003 08:17:08 -0700 X-Sent: 18 May 2003 15:17:08 GMT Message-ID: <014d01c31d50$8660b5e0$54051eac@ttitelecom.com> Reply-To: "EricLKlein" From: "EricLKlein" To: References: <135301c31c8e$766cee50$261e4104@eagleswings> <135301c31c8e$766cee50$261e4104@eagleswings> <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Sun, 18 May 2003 18:16:54 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk ----- Original Message ----- From: Margaret Wasserman > > It would be possible to move the whole concept of "local" > addressing (with the exception of link-local, which we > already have well-defined) out of the IPv6 WG and into a > separate WG. > > This would have some advantages, most important of which, > IMO, is that it would allow the original IPv6 WG to focus > on finishing up the remaining pieces of IPv6 and bug > fixing some of the older pieces, while the new WG could > focus on the issue of local addressing. I am not sure how we can "finish the remaining pieces of IPv6" without resolving the whole Link-Local issue. As far as I can tell no consensus has been reached, and we are all anticipating (or dreading) the hijacking of addresses to be used as locals as no alternative has been supported by the WG to replace what has been stated in the RFC's for the past 2 years (ie: FE8, FE9, FEA, and FEB). Currently there are over 40 places on the internet where this information occures as registered by Yahoo ( http://search.yahoo.com/search?p=%2Bipv6+%2B%22local+address%22+%2BFE8+&ei=U TF-8&vm=i&n=20&fl=0&x=wrt ) So eithter we as the IPNG WG find an answer and spread it soon, or these addresses will be as good as hijacked based on published recommendations on many hardware and software sites. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 18 11:21:45 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4IILjhs008127; Sun, 18 May 2003 11:21:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4IILiYc008126; Sun, 18 May 2003 11:21:44 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4IILfhs008119 for ; Sun, 18 May 2003 11:21:41 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4IIJrKw008641 for ; Sun, 18 May 2003 11:19:53 -0700 (PDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4IIJkHN024557 for ; Sun, 18 May 2003 11:19:47 -0700 (PDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h4IIJCN11054; Sun, 18 May 2003 21:19:13 +0300 Date: Sun, 18 May 2003 21:19:12 +0300 (EEST) From: Pekka Savola To: Margaret Wasserman cc: Eliot Lear , , "'Bob Hinden'" , Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Sun, 18 May 2003, Margaret Wasserman wrote: > >>In any case, a PI mechanism needs to be dealt with in parallel, and this > >>should not be forwarded until the PI approach can move with it. > > > >I agree with this point, and as I believe others have said, I believe we > >need to recognize that the same issues would hit us with the doc prefix > >that was proposed. > > I certainly think that work on a PI routing model should > happen outside of the IPv6 WG. I'm not even totally > sure that this should be in the Internet area, rather than > Routing. Or even Ops & Mgmt. (Many aspects of PI, at least with current tradeoffs require policies and operations action -- rather than protocols.) /me runs -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 18 23:48:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4J6mChs010743; Sun, 18 May 2003 23:48:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4J6mCbV010742; Sun, 18 May 2003 23:48:12 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4J6m8hs010733 for ; Sun, 18 May 2003 23:48:08 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4J6kaKw010399 for ; Sun, 18 May 2003 23:46:36 -0700 (PDT) Received: from jade.coe.psu.ac.th ([192.150.250.54]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4J6kTsa007031 for ; Mon, 19 May 2003 00:46:30 -0600 (MDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4IEUWV06094; Sun, 18 May 2003 21:30:34 +0700 (ICT) From: Robert Elz To: Margaret Wasserman cc: Eliot Lear , alh-ietf@tndh.net, "'Bob Hinden'" , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> References: <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <135301c31c8e$766cee50$261e4104@eagleswings> <135301c31c8e$766cee50$261e4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 18 May 2003 21:30:32 +0700 Message-ID: <6092.1053268232@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Sun, 18 May 2003 09:47:02 -0400 From: Margaret Wasserman Message-ID: <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> | This would have some advantages, most important of which, | IMO, is that it would allow the original IPv6 WG to focus | on finishing up the remaining pieces of IPv6 and bug | fixing some of the older pieces, while the new WG could | focus on the issue of local addressing. It isn't possible to "finish" IPv6 without local addressing - one of the aims of IPv6 was to be able to do everything that IPv4 can do (better ways where possible), so there won't be any justifications for anyone to stay with IPv4, because v6 can't do X. IPv4 has local (private) addresses that are immune from outside control. IPv6 needs the same, or something demonstrably better. Just deciding that *you* don't need the things (for any value of "you") or think that they're evil, isn't good enough. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 19 00:27:11 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4J7RBhs011219; Mon, 19 May 2003 00:27:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4J7RAst011218; Mon, 19 May 2003 00:27:10 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4J7R7hs011211 for ; Mon, 19 May 2003 00:27:07 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4J7PcKw023901 for ; Mon, 19 May 2003 00:25:38 -0700 (PDT) Received: from fsnt.future.futsoft.com ([203.197.140.35]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4J7PUx9000261 for ; Mon, 19 May 2003 00:25:32 -0700 (PDT) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 19 May 2003 11:13:35 +0530 Received: from sivarka (sivarka.future.futsoft.com [10.20.6.73]) by kailash.future.futsoft.com (8.12.2/8.12.2) with SMTP id h4J54gVd005752; Mon, 19 May 2003 10:34:42 +0530 Reply-To: From: "Sivaramakrishnan A" To: "'Sha Liu'" Cc: Subject: RE: Anycast address - How to find the "nearest" router? Date: Mon, 19 May 2003 10:36:54 +0530 Message-Id: <000301c31dc4$77e68f20$4906140a@future.futsoft.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <000c01c31d42$93909900$357b2dd2@liusand> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi, When sending NA for anycast address, the Override Bit should always be set to 0. So the Neighbour Cache of the node receiving this NA is updated from the First advertisement! All other nodes sending NA for that anycast address, would also send with O bit set to 0 which will have no effect on the Neighbour cache of the receiving Node. Hence, as you specified "the first advertisement for an anycast address 'wins' "! regards, Sivaramakrishnan. A -----Original Message----- From: Sha Liu [mailto:liusand@sina.com] Sent: Sunday, 18 May 2003 7:07 PM To: sivarka@future.futsoft.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Anycast address - How to find the "nearest" router? Hi, In RFC2461: "7.2.4. Sending Solicited Neighbor Advertisements If the Target Address is either an anycast address or a unicast address for which the node is providing proxy service, or the Target Link-Layer Address option is not included, the Override flag SHOULD be set to zero. Otherwise, the Override flag SHOULD be set to one. Proper setting of the Override flag ensures that nodes give preference to non-proxy advertisements, even when received after proxy advertisements, and also ensures that the first advertisement for an anycast address "wins"." ----- Original Message ----- From: "Sivaramakrishnan A" To: "'Suvidh Mathur'" Cc: Sent: Thursday, May 15, 2003 5:36 PM Subject: RE: Anycast address - How to find the "nearest" router? > Hi, > > I accept that the route table organisation can help to find the > nearness of any router. So (In this case) do you mean, both R1 > and R2 should agree upon themselves, that who should process > the packet anycast addressed packet ? If yes, how could this be > achieved? > > How can NS-NA exchange help us resolve who should receive the packet? > > thanks, > Sivaramakrishnan. A > > -----Original Message----- > From: Suvidh Mathur [mailto:Suvidh.Mathur@lntinfotech.com] > Sent: Thursday, 15 May 2003 1:51 PM > To: sivarka@future.futsoft.com > Subject: Re: Anycast address - How to find the "nearest" router? > > > > Hi, > > What exactly do you mean by "nearest"? > > As per the RFC, nearest should be based on the routing protocols' notion of > distance. Thus if R1 is nearer then R2, then the packet should reach R1 > alone. > If R1 and R2 are equi-distant, then either the routing table organization > (at the sending nore and / or the intermediate routers) or NS - NA exchange > (in case of R1 and R2 being onlink) should ensure that the packet is sent > only to one of the routers. > > Hope this helps, > > Regards, > Suvidh > > Thursday, 15 May, 2003 12:39 PM > To: > cc: > From: "Sivaramakrishnan A" > Subject: Anycast address - How to find the "nearest" router? > > > > Hi, > I have 2 Routers ( R1 and R2) in a link who are configured the same > ANYCAST > address. > A packet is addressed to that anycast address. According to [ADDR-ARCH] the > "nearest" > one shoule receive this packet. Assume R1 is the "nearest" one here. But > how > does R1 know > that "I'm the nearest, and I should process this packet?" . If Suppose if > R1 is nearer, how is > R2 restricted from processing the packet? > thanks and regards, > Sivaramakrishnan. A > > *************************************************************************** > This message is proprietary to Future Software Limited (FSL) > and is intended solely for the use of the individual to whom it > is addressed. It may contain privileged or confidential information > and should not be circulated or used for any purpose other than for > what it is intended. > > If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, > you are notified that you are strictly prohibited from using, > copying, altering, or disclosing the contents of this message. > FSL accepts no responsibility for loss or damage arising from > the use of the information transmitted by this email including > damage from virus. > *************************************************************************** > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- > > *************************************************************************** This message is proprietary to Future Software Limited (FSL) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSL accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. *************************************************************************** -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 19 04:53:08 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JBr7hs012839; Mon, 19 May 2003 04:53:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4JBr779012838; Mon, 19 May 2003 04:53:07 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JBr4hs012831 for ; Mon, 19 May 2003 04:53:04 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4JBpEuc026926 for ; Mon, 19 May 2003 04:51:15 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4JBp9pd026047 for ; Mon, 19 May 2003 05:51:09 -0600 (MDT) Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id EAA04395; Mon, 19 May 2003 04:50:42 -0700 (PDT) Message-Id: <5.1.0.14.2.20030519073316.040d4e20@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 19 May 2003 07:46:41 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Cc: Eliot Lear , alh-ietf@tndh.net, "'Bob Hinden'" , ipng@sunroof.eng.sun.com In-Reply-To: <6092.1053268232@munnari.OZ.AU> References: <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <135301c31c8e$766cee50$261e4104@eagleswings> <135301c31c8e$766cee50$261e4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Robert, At 09:30 PM 5/18/2003 +0700, Robert Elz wrote: > | This would have some advantages, most important of which, > | IMO, is that it would allow the original IPv6 WG to focus > | on finishing up the remaining pieces of IPv6 and bug > | fixing some of the older pieces, while the new WG could > | focus on the issue of local addressing. > >It isn't possible to "finish" IPv6 without local addressing - IMO, if IPv6 is successful, it will never be "finished". Is IPv4 finished? However, we can finish up some pieces (i.e the MIBs). IMO, we should be trying to move to a model where there is no single IPv6 WG, and work on different parts of IPv6 is occurring in parallel in several WGs of smaller scope. This would allow more community visibility in what work is taking place in IPv6, and would allow us to get specialists/experts involved who only care about specific IPv6 work areas. >one of >the aims of IPv6 was to be able to do everything that IPv4 can do >(better ways where possible), so there won't be any justifications for >anyone to stay with IPv4, because v6 can't do X. Who said that the aim of IPv6 was to be able to do everything that IPv4 can do? While I think that, in general, IPv6 _can_ do everything that IPv4 can do, it certainly wouldn't make sense to duplicate any features of IPv4 that: - Were included as compromises to conserve address space, or - We later determined were a Bad Idea. Some argue that local addressing (a la RFC 1918) falls into both of these categories. >IPv4 has local (private) addresses that are immune from outside control. >IPv6 needs the same, or something demonstrably better. I personally think that we will need some type of provider- independent local addressing, iff we can't figure out a way to globally route provider-independent addresses... But, that's just my opinion. You seem to start with the premise that we won't be able to find a scalable, provider-independent routing mechanism. It hasn't been demonstrated (yet) that there is rough consensus in the WG about this, and we probably won't be able to demonstrate that until the WG comes to some agreement on the requirements for local addressing (which we could already have, although they aren't written down -- do they need to be?) and until we have a proposal that gains rough consensus in the WG. This is a very complicated topic, and there are a lot of trade-offs that need to be considered between pursuing non-globally-routable local addressing mechanisms, pursuing provider-independent routing mechanisms, pursuing automated renumbering systems to obviate (one of the) need(s) for local addressing, etc. The fact that I think that this chunk of work is something that could reasonably be broken off into a separate, focused WG doesn't mean that I think it should die. In fact, I think it is less likely to die if it gets its own resources (dedicated meeting time, dedicated chairs, etc.). However, this isn't my decision -- the decision about how to organize the work in the area belongs to the ADs. 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 May 19 09:30:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JGUKhs013994; Mon, 19 May 2003 09:30:20 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4JGUKrK013993; Mon, 19 May 2003 09:30:20 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JGUEhs013986 for ; Mon, 19 May 2003 09:30:14 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4JGSjKw013731 for ; Mon, 19 May 2003 09:28:45 -0700 (PDT) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4JGSdsa024947 for ; Mon, 19 May 2003 10:28:39 -0600 (MDT) Received: from banzai.rose.hp.com (banzai.rose.hp.com [15.29.42.63]) by palrel12.hp.com (Postfix) with ESMTP id 164F61C00B77 for ; Mon, 19 May 2003 09:28:36 -0700 (PDT) Received: from banzai.rose.hp.com (sergey@localhost [127.0.0.1]) by banzai.rose.hp.com (8.9.3 (PHNE_26305+JAGae58098)/8.9.3 SMKit7.03) with ESMTP id JAA18767 for ; Mon, 19 May 2003 09:28:27 -0700 (PDT) Message-ID: <3EC9062B.3090407@banzai.rose.hp.com> Date: Mon, 19 May 2003 09:28:27 -0700 From: Sergey Gerasimov User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.2) Gecko/20021203 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Multihomed devices on the same subnet (prefix) question References: <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <135301c31c8e$766cee50$261e4104@eagleswings> <135301c31c8e$766cee50$261e4104@eagleswings> <5.1.0.14.2.20030519073316.040d4e20@mail.windriver.com> In-Reply-To: <5.1.0.14.2.20030519073316.040d4e20@mail.windriver.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, We are trying to resolve the following scenario for multi-homed (2 frontplanes) device: 1. device does not have very good UI until netwrok connected 2. device has .11 and .3 frontplanes hot at the same time 3. initial power up is likely stateless, likely link local on some or all frontplanes 4. initial .11 configuration is likely ad-hoc (peer to peeer) Now, if device comes up in .11 ad-hoc link local and .3 link local, then there is no connectivity between the .3 and .11 but they are on the same subnet (have same prefix in v6 world). Rotuing table is not likely to be accessible (or would be very hard to navigate) without sophisticated UI (web) which requires network connectivity. The potential problem here is that packets will be routed to the wrong frontplane depending on the order in which the routes are inserted in the cache. I understand that some possible ways are to battle this: 1. create a precendence oreder for the frontplanes (e.g. .3 always first, .11 always last) 2. disallow same subnets (what about v6?) for different frontplanes 3. manipulate routing cache (manually or via some set of rules) 4. ... others ...? I am sure somebody has already come across this one and has some ideas. Any information will be helpful. It is really not a v6 question only, but appears to apply to both v6 and v4. Thanks, Sergey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 19 09:59:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JGxxhs014747; Mon, 19 May 2003 09:59:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4JGxwcI014746; Mon, 19 May 2003 09:59:58 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JGxths014737 for ; Mon, 19 May 2003 09:59:55 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4JGwQuc011087 for ; Mon, 19 May 2003 09:58:26 -0700 (PDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4JGwK3S007083 for ; Mon, 19 May 2003 10:58:20 -0600 (MDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h4JGwFK27255; Mon, 19 May 2003 18:58:15 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h4JGwFof013865; Mon, 19 May 2003 18:58:15 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200305191658.h4JGwFof013865@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Sergey Gerasimov cc: ipng@sunroof.eng.sun.com Subject: Re: Multihomed devices on the same subnet (prefix) question In-reply-to: Your message of Mon, 19 May 2003 09:28:27 PDT. <3EC9062B.3090407@banzai.rose.hp.com> Date: Mon, 19 May 2003 18:58:15 +0200 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 no connectivity between the .3 and .11 but they are on the same subnet (have same prefix in v6 world). => this seems to be a bug: two different links should not share an on-line prefix. I understand that some possible ways are to battle this: 2. disallow same subnets (what about v6?) for different frontplanes => IMHO this is the obvious solution. but appears to apply to both v6 and v4. => I agree, IPv4 won't work too in your case. Regards Francis.Dupont@enst-bretagne.fr -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 19 10:08:39 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JH8dhs014974; Mon, 19 May 2003 10:08:39 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4JH8cE8014973; Mon, 19 May 2003 10:08:38 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JH8Zhs014966 for ; Mon, 19 May 2003 10:08:35 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4JH76Kw001884 for ; Mon, 19 May 2003 10:07:06 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4JH70Y9012438 for ; Mon, 19 May 2003 11:07:00 -0600 (MDT) 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 KAA16177; Mon, 19 May 2003 10:07:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4JH70320024; Mon, 19 May 2003 10:07:00 -0700 X-mProtect: <200305191707> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpda8a9y1; Mon, 19 May 2003 10:06:58 PDT Message-ID: <3EC91072.90209@iprg.nokia.com> Date: Mon, 19 May 2003 10:12:18 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sergey Gerasimov CC: ipng@sunroof.eng.sun.com Subject: Re: Multihomed devices on the same subnet (prefix) question References: <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <135301c31c8e$766cee50$261e4104@eagleswings> <135301c31c8e$766cee50$261e4104@eagleswings> <5.1.0.14.2.20030519073316.040d4e20@mail. Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Is this perhaps a case for the multi-link subnet proposal? Fred ftemplin@iprg.nokia.com Sergey Gerasimov wrote: > Hello, > > We are trying to resolve the following scenario for multi-homed (2 > frontplanes) device: > > 1. device does not have very good UI until netwrok connected > 2. device has .11 and .3 frontplanes hot at the same time > 3. initial power up is likely stateless, likely link local on some or > all frontplanes > 4. initial .11 configuration is likely ad-hoc (peer to peeer) > > Now, if device comes up in .11 ad-hoc link local and .3 link local, then > there is no connectivity between the .3 and .11 but they are on the same > subnet (have same prefix in v6 world). Rotuing table is not likely to > be accessible (or would be very hard to navigate) without sophisticated > UI (web) which requires network connectivity. The potential problem > here is that packets will be routed to the wrong frontplane depending on > the order in which the routes are inserted in the cache. > > I understand that some possible ways are to battle this: > > 1. create a precendence oreder for the frontplanes (e.g. .3 always > first, .11 always last) > 2. disallow same subnets (what about v6?) for different frontplanes > 3. manipulate routing cache (manually or via some set of rules) > 4. ... others ...? > > I am sure somebody has already come across this one and has some ideas. > Any information will be helpful. It is really not a v6 question only, > but appears to apply to both v6 and v4. > > Thanks, > Sergey > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home 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 May 19 10:13:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JHDLhs015103; Mon, 19 May 2003 10:13:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4JHDLjZ015102; Mon, 19 May 2003 10:13:21 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JHDHhs015092 for ; Mon, 19 May 2003 10:13:17 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4JHBfuc016350 for ; Mon, 19 May 2003 10:11:41 -0700 (PDT) Received: from mailserv.ait.ac.th (mailserv.ait.ac.th [203.159.5.10]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4JHBY3S012548 for ; Mon, 19 May 2003 11:11:35 -0600 (MDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailserv.ait.ac.th (Postfix) with ESMTP id B9F9632ECC; Tue, 20 May 2003 00:10:31 +0700 (ICT) Received: from mailserv.ait.ac.th ([127.0.0.1]) by localhost (mailserv.ait.ac.th [127.0.0.1:10024]) (amavisd-new) with ESMTP id 07148-09; Tue, 20 May 2003 00:10:31 +0700 (ICT) Received: from delta.cs.mu.OZ.AU (unknown [203.159.26.94]) by mailserv.ait.ac.th (Postfix) with ESMTP id 91C9132E75; Tue, 20 May 2003 00:10:31 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4JEUUH17978; Mon, 19 May 2003 21:30:31 +0700 (ICT) From: Robert Elz To: Margaret Wasserman Cc: Eliot Lear , alh-ietf@tndh.net, "'Bob Hinden'" , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <5.1.0.14.2.20030519073316.040d4e20@mail.windriver.com> References: <5.1.0.14.2.20030519073316.040d4e20@mail.windriver.com> <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <135301c31c8e$766cee50$261e4104@eagleswings> <135301c31c8e$766cee50$261e4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 19 May 2003 21:30:30 +0700 Message-ID: <17976.1053354630@munnari.OZ.AU> X-Virus-Scanned: by amavisd-new Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 19 May 2003 07:46:41 -0400 From: Margaret Wasserman Message-ID: <5.1.0.14.2.20030519073316.040d4e20@mail.windriver.com> | Who said that the aim of IPv6 was to be able to do everything | that IPv4 can do? It was something from the early days of the WG. The actual wording I am half remembering might have been from Steve Deering, but that's no more than a guess. But it should be obvious - if there's anything (even half way supportable) that IPv4 can do, that IPv6 doesn't have an answer to, then there will be a class of users who will simply say "IPv6 is impossible, it cannot handle my needs". | While I think that, in general, IPv6 _can_ | do everything that IPv4 can do, it certainly wouldn't make | sense to duplicate any features of IPv4 that: | | - Were included as compromises to conserve | address space, or Compromises, no - but address space conservation is still important. There are lots of IPv6 addresses (there were once lots of IPv4 addresses too...) but they're not an infinite resource, and they'll eventually run out. There are enough that if we do a decent job of management, they'll outlast other parts of the protocol for sure - but there aren't enough that we can afford to be stupid in the way they're allocated. Eg: (stupid suggestion no-one is making that I know of) one might argue that /24 addresses (16M of them) are as many as can possibly be flat routed, so that's the allocation size that the RIR's should be giving out - and then everyone should go get their own private /24 (or make that /32 with a 2001 meaningless prefix grafted on the front if you like) If we were to do something that dumb though, we'd be out of IPv6 addresses in no time - we still need address conservation measures developed for IPv4 (including CIDR and more) | - We later determined were a Bad Idea. Anything truly a bad idea from IPv4 has fallen out of use, and is no longer relevant (and that isn't an empty set). What you're probably referring to though are things that some people argue are bad ideas, but which are in very widespread use. That stuff isn't really "bad idea", its "I don't like that" - and is really prejudice. | Some argue that local addressing (a la RFC 1918) falls into | both of these categories. They do - but they can't deny how much it is used. We certainly don't have to duplicate everything in IPv4 the way it was done exactly, what we need is something that fills the needs that anything which is in actual use in IPv4 fulfill. That is, we need methods to offer the functions that 1918 addresses offer, it doesn't have to be done the same way as 1918 does it. | You seem to start with the premise that we won't be able | to find a scalable, provider-independent routing mechanism. I start with the premise that after years of trying, we haven't managed to come up with any kind of topology insensitive global addressing that allows routing that scales. (Note: topology independent is what is important, not provider-independent). I am not willing to bet a cent that we will magically find a solution in the next year or so - especially given that no-one seemed to like the only half way promising method that was ever proposed (that is, having the end hosts run the routing function, and source routing). Yet, we still have needs to handle, that we cannot simply afford to ignore if no means of topology independent routing ever gets found. Do you have any proposals for methods which might actually work for topology independent routing that might even give rise to some hope that there ever will be such a method? If you don't, perhaps you should stop suggesting to the WG that waiting for this is a useful way to accomplish anything at all. | It hasn't been demonstrated (yet) that there is rough | consensus in the WG about this, I wasn't able to work out what antecedent "this" had here. | pursuing automated | renumbering systems to obviate (one of the) need(s) for | local addressing, etc. No, but you're not the only one to leap to this incorrect conclusion. The easier renumbering is, the more we need local addressing, not the less - if renumbering is practically impossible, then topology (provider) dependent addresses become (essentially) stable - by customer lock in. That's not good from other viewpoints, but it makes for stable addressing. It is when addresses are changing that some stable local addressing is needed, not for when globals are stable. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 19 10:21:29 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JHLThs015409; Mon, 19 May 2003 10:21:29 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4JHLTgc015408; Mon, 19 May 2003 10:21:29 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JHLPhs015398 for ; Mon, 19 May 2003 10:21:25 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4JHJuKw007162 for ; Mon, 19 May 2003 10:19:56 -0700 (PDT) Received: from mailserv.ait.ac.th (mailserv.ait.ac.th [203.159.5.10]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4JHJoHN009725 for ; Mon, 19 May 2003 10:19:50 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailserv.ait.ac.th (Postfix) with ESMTP id 9F61D32ECD; Tue, 20 May 2003 00:18:42 +0700 (ICT) Received: from mailserv.ait.ac.th ([127.0.0.1]) by localhost (mailserv.ait.ac.th [127.0.0.1:10024]) (amavisd-new) with ESMTP id 09487-02; Tue, 20 May 2003 00:18:42 +0700 (ICT) Received: from delta.cs.mu.OZ.AU (unknown [203.159.26.94]) by mailserv.ait.ac.th (Postfix) with ESMTP id 7ACDC32E75; Tue, 20 May 2003 00:18:42 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4JHHFq19851; Tue, 20 May 2003 00:17:16 +0700 (ICT) From: Robert Elz To: Sergey Gerasimov Cc: ipng@sunroof.eng.sun.com Subject: Re: Multihomed devices on the same subnet (prefix) question In-Reply-To: <3EC9062B.3090407@banzai.rose.hp.com> References: <3EC9062B.3090407@banzai.rose.hp.com> <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <135301c31c8e$766cee50$261e4104@eagleswings> <135301c31c8e$766cee50$261e4104@eagleswings> <5.1.0.14.2.20030519073316.040d4e20@mail.windriver.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 May 2003 00:17:15 +0700 Message-ID: <19849.1053364635@munnari.OZ.AU> X-Virus-Scanned: by amavisd-new Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 19 May 2003 09:28:27 -0700 From: Sergey Gerasimov Message-ID: <3EC9062B.3090407@banzai.rose.hp.com> | Now, if device comes up in .11 ad-hoc link local and .3 link local, then | there is no connectivity between the .3 and .11 but they are on the same | subnet (have same prefix in v6 world). v6: No, they have the same numeric value, in different scopes. The address needs a scope identifier to indicate which scope (subnet for LL) it is within. | 4. ... others ...? The scope identifier fixes this. The API has a defined way to include that in the binary form of addresses, but there's no standard way to include it in textual representations - some OS's write it as address%scope where scope is the name of the interface connected to the subnet in question (it isn't really important, as at this level, no portability is really required). | I am sure somebody has already come across this one and has some ideas. | Any information will be helpful. It is really not a v6 question only, | but appears to apply to both v6 and v4. For v4, multiple connected link local nets generally gets a "don't go there", or "Danger, Will Robinson" type response. It probably isn't worth any kind of standardised mechanism this late in the v4 game (though you could certainly do one, probably like v6's, if only for consistency, for your own needs). It is however very opportune that you have raised this issue just now, as it should help to point out to (some) people that applications really need to deal with this kind of scenario - which means that they need to be able to deal with scoped ambiguous addresses, and that whatever they believe they have simplified in the silly attempt to delete site-local addresses amounts to approximately zero. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 19 10:39:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JHdxhs016090; Mon, 19 May 2003 10:39:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4JHdx26016089; Mon, 19 May 2003 10:39:59 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JHdths016077 for ; Mon, 19 May 2003 10:39:55 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4JHcQKw015622 for ; Mon, 19 May 2003 10:38:26 -0700 (PDT) Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4JHcLHN020592 for ; Mon, 19 May 2003 10:38:21 -0700 (PDT) Received: from IDLEWYLDE.windriver.com ([147.11.233.8]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id KAA05813; Mon, 19 May 2003 10:38:03 -0700 (PDT) Message-Id: <5.1.0.14.2.20030519132522.041e74a0@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 19 May 2003 13:34:08 -0400 To: Robert Elz From: Margaret Wasserman Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Cc: ipng@sunroof.eng.sun.com In-Reply-To: <17976.1053354630@munnari.OZ.AU> References: <5.1.0.14.2.20030519073316.040d4e20@mail.windriver.com> <5.1.0.14.2.20030519073316.040d4e20@mail.windriver.com> <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <135301c31c8e$766cee50$261e4104@eagleswings> <135301c31c8e$766cee50$261e4104@eagleswings> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk At 09:30 PM 5/19/2003 +0700, Robert Elz wrote: Hi Robert, >They do - but they can't deny how much it is used. We certainly don't >have to duplicate everything in IPv4 the way it was done exactly, what >we need is something that fills the needs that anything which is in >actual use in IPv4 fulfill. That is, we need methods to offer the >functions that 1918 addresses offer, it doesn't have to be done the same >way as 1918 does it. Which is why we suggested that the WG should work on understand the requirements for local addressing. In other words, what operational needs are filled by RFC 1918 addresses and/or NAT? Then we can talk about how to meet those needs in IPv6, hopefully in a way that is more architecturally sound. So far, we seem to have a list that runs something like: - Addressing for disconnected networks. - Simple local access control? (Although I'm not sure anyone uses RFC 1918 for this in IPv4.) - Portable local addressing for: - Intermittently connected networks. - Renumbered networks (i.e. ISP changes). There should, I think, be a set of requirements under each of these areas... For instance, an administrator shouldn't have to pay an ISP for service in order to number a disconnected network. We don't necessarily need a single solution that solves all of these cases. There may be different solutions for different cases. There may be also people in the WG, though, who disagree about whether we need to solve some of these problems. IMO, the best way to drive discussion on this would be to put forth a fairly simple requirements document that covers each of these cases. If no one else does it before I have time, maybe I'll do it... but I'd rather that someone else did it. > | pursuing automated > | renumbering systems to obviate (one of the) need(s) for > | local addressing, etc. > >No, but you're not the only one to leap to this incorrect conclusion. I don't actually think that renumbering obviates the need for portable addressing... I was just listing one of the fairly vocal views in the WG right now. 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 May 19 11:07:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JI73hs016579; Mon, 19 May 2003 11:07:03 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4JI73BV016578; Mon, 19 May 2003 11:07:03 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JI70hs016571 for ; Mon, 19 May 2003 11:07:00 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4JI5Vuc009913 for ; Mon, 19 May 2003 11:05:31 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4JI5Psa022217 for ; Mon, 19 May 2003 12:05:25 -0600 (MDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Mon, 19 May 2003 11:05:23 -0700 Reply-To: From: "Tony Hain" To: "'Bob Hinden'" , Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Mon, 19 May 2003 11:05:23 -0700 Message-ID: <011c01c31e31$385dfba0$74164104@eagleswings> 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.4510 In-Reply-To: <135301c31c8e$766cee50$261e4104@eagleswings> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Just a followup to my previous note: It was not my intent to say that Bob was intentionally trying to be deceptive and mislead the working group. So I apologize to Bob if it came across that way. I was trying to point out the contradiction between: Margaret: > >Bob's proposal explicitly defines a type of addresses that are not > >expected to be routed throughout the Internet. So, these > >addresses are local, not globally routable. Bob: > The globally unique IPv6 local unicast addresses are not > limited in their > use to any scope less than global by their design because they have > prefixes that are globally unique. and the subsequent claim that the chairs agree on the definition. The definition can not be both, limited to local use, and not limited to less than global, at the same time. Either these are unlimited and useful globally, or they are local (for some definition of local). Claiming they are both at the same time is the problem here. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 19 12:23:49 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JJNnhs016959; Mon, 19 May 2003 12:23:49 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4JJNnak016958; Mon, 19 May 2003 12:23:49 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JJNkhs016951 for ; Mon, 19 May 2003 12:23:46 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4JJMHKw001417 for ; Mon, 19 May 2003 12:22:17 -0700 (PDT) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4JJMBsa003809 for ; Mon, 19 May 2003 13:22:11 -0600 (MDT) Received: from banzai.rose.hp.com (banzai.rose.hp.com [15.29.42.63]) by palrel11.hp.com (Postfix) with ESMTP id 22D4D1C01DD1 for ; Mon, 19 May 2003 12:22:11 -0700 (PDT) Received: from banzai.rose.hp.com (sergey@localhost [127.0.0.1]) by banzai.rose.hp.com (8.9.3 (PHNE_26305+JAGae58098)/8.9.3 SMKit7.03) with ESMTP id MAA22087 for ; Mon, 19 May 2003 12:22:10 -0700 (PDT) Message-ID: <3EC92EE2.6070004@banzai.rose.hp.com> Date: Mon, 19 May 2003 12:22:10 -0700 From: Sergey Gerasimov User-Agent: Mozilla/5.0 (X11; U; HP-UX 9000/785; en-US; rv:1.2) Gecko/20021203 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Multihomed devices on the same subnet (prefix) question References: <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <135301c31c8e$766cee50$261e4104@eagleswings> <135301c31c8e$766cee50$261e4104@eagleswings> <5.1.0.14.2.20030519073316.040d4e20@mail. <3EC91072.90209@iprg.nokia.com> In-Reply-To: <3EC91072.90209@iprg.nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hello, there are couple of things that still do not appear clear to me. I understand that v4 has a problem and that is something we are trying to solve here locallly as we cannot get away from the dual stack. However, here is what I read in the RFC2461 for v6: When sending a packet to a destination, a node uses a combination of the Destination Cache, the Prefix List, and the Default Router List to determine the IP address of the appropriate next hop, an operation known as "next-hop determination". Once the IP address of the next hop is known, the Neighbor Cache is consulted for link-layer information about that neighbor. Now, let's say we have a node that has a leg in .11 ad-hoc, FE80:xxx configured and a leg in .3, also link local configured. Assuming prefix and default router caches are empty, all communications are link local. Now we have a mobile workstation that joined our ad-hoc network and we want to transmit to it. Mobile workstation also has a link local address. Aren't we going to end up sending on the .3 leg anyways if it is first in the table? I guess I am also a bit fuzzy on what happens when we get a connection from the remote node to us. I think that neighbour discovery happens first (solicited from the remote connecting to us, if link local?, or from router if global?) and that populates our destination cache ... however, does tdestination cache contain the interface identifier that was (is) associated with the neghour discovery exchange? That is something I could not quite get from the RFC. Thanks a lot! Sergey -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 19 15:03:47 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JM3lhs018232; Mon, 19 May 2003 15:03:47 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4JM3knd018231; Mon, 19 May 2003 15:03:46 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4JM3hhs018224 for ; Mon, 19 May 2003 15:03:43 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4JM2Euc003640 for ; Mon, 19 May 2003 15:02:14 -0700 (PDT) Received: from max6.rrze.uni-erlangen.de (max6.rrze.uni-erlangen.de [131.188.3.214]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4JM1lY9016236 for ; Mon, 19 May 2003 16:01:47 -0600 (MDT) Received: from devil.rrze.uni-erlangen.de by max6.rrze.uni-erlangen.de with ESMTP for ipng@sunroof.eng.sun.com; Tue, 20 May 2003 00:01:46 +0200 Received: from devil.rrze.uni-erlangen.de (devil [127.0.0.1]) by devil.rrze.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id h4JM1jab099805 for ; Tue, 20 May 2003 00:01:46 +0200 (CEST) (envelope-from unrz111@devil.rrze.uni-erlangen.de) Received: (from unrz111@localhost) by devil.rrze.uni-erlangen.de (8.12.9/8.12.9/Submit) id h4JM1jQ2099804 for ipng@sunroof.eng.sun.com; Tue, 20 May 2003 00:01:45 +0200 (CEST) From: Jochen Kaiser Date: Tue, 20 May 2003 00:01:45 +0200 To: ipng@sunroof.eng.sun.com Subject: solicited group multicast address; prob of understanding Message-Id: <20030519220145.GA98841@devil.rrze.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk HI, I am reading about autocinfiguration DAD at the moment and have a problem of understanding: When an interface comes up, it gets a tentative ipv6 address. I quote RFC 2491: Prior to performing Duplicate Address Detection, a host will join the all-nodes multicast address and the solicited-node multicast address corresponding to the host's tentative address (see 4.2. Joining a Multicast Group). The IPv6 host initiates Duplicate Address Detection by sending a Neighbor Solicitation to solicited-node multicast address corresponding to the host's tentative address, with the tentative address as the target. When I understand this correctly, a host joins his 'own' multicast group "FF01::1:FF:aa:bb:cc" and then sends a NS packet to the solicited node multicast address of the node. So if there is another host in this group, DAD gets an NA message and DAD fails. Is it really that you generate a special mc group per node? I don't believe this and think that I am misunderstanding this. My netstat doesn't show it, too. Any help to enlighten me strongly appreciated since I am a bit confused right now. with kind regards, Jochen Kaiser -- Dipl. Inf. Jochen Kaiser, GPG 0x3C93A870, phone +49 9131 85-28681 Network Administration mailto:jochen.kaiser@rrze.uni-erlangen.de Regionales Rechenzentrum Universitaet Erlangen-Nuernberg, Germany Homepage and PublicKey: http://ipv6.rrze.uni-erlangen.de/~unrz111 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 19 19:05:15 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4K25Ehs019660; Mon, 19 May 2003 19:05:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4K25EhA019659; Mon, 19 May 2003 19:05:14 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4K25Bhs019652 for ; Mon, 19 May 2003 19:05:11 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4K23buc016902 for ; Mon, 19 May 2003 19:03:37 -0700 (PDT) Received: from mailserv.ait.ac.th (mailserv.ait.ac.th [203.159.5.10]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4K23VY9009777 for ; Mon, 19 May 2003 20:03:31 -0600 (MDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailserv.ait.ac.th (Postfix) with ESMTP id E152732EF9; Tue, 20 May 2003 09:02:26 +0700 (ICT) Received: from mailserv.ait.ac.th ([127.0.0.1]) by localhost (mailserv.ait.ac.th [127.0.0.1:10024]) (amavisd-new) with ESMTP id 17697-07; Tue, 20 May 2003 09:02:26 +0700 (ICT) Received: from delta.cs.mu.OZ.AU (unknown [203.159.26.94]) by mailserv.ait.ac.th (Postfix) with ESMTP id A601632EF4; Tue, 20 May 2003 09:02:26 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4K1qnq24698; Tue, 20 May 2003 08:52:50 +0700 (ICT) From: Robert Elz To: Sergey Gerasimov Cc: ipng@sunroof.eng.sun.com Subject: Re: Multihomed devices on the same subnet (prefix) question In-Reply-To: <3EC92EE2.6070004@banzai.rose.hp.com> References: <3EC92EE2.6070004@banzai.rose.hp.com> <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <5.1.0.14.2.20030518093827.040983f8@mail.windriver.com> <135301c31c8e$766cee50$261e4104@eagleswings> <135301c31c8e$766cee50$261e4104@eagleswings> <5.1.0.14.2.20030519073316.040d4e20@mail. <3EC91072.90209@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 May 2003 08:52:49 +0700 Message-ID: <24696.1053395569@munnari.OZ.AU> X-Virus-Scanned: by amavisd-new Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 19 May 2003 12:22:10 -0700 From: Sergey Gerasimov Message-ID: <3EC92EE2.6070004@banzai.rose.hp.com> | Now, let's say we have a node that has a leg in .11 ad-hoc, FE80:xxx | configured and a leg in .3, also link local configured. Assuming prefix | and default router caches are empty, all communications are link local. Yes. What you need to do though is consider that LL addresses aren't 128 bits long, they're 144 bits (or something else like that). The extra 16 bits aren't sent on the wire, they're local to your node. For LL addresses, they just number interfaces (0 1 2 3 ...) (or that's the usual way, but because they're local to you internally, you can use any other scheme you like - including making them be 32 or 64 bits as required, and making them be a pointer to an interface structure or similar). The extra bits should be considered as the most significant bits of the address (which is relevant when doing longest match comparisons and such, but only there). Once you understand that the addresses are longer than 128 bits everything gets simpler to understand, and the ambiguity that you believe exists really doesn't exist at all. The only issue that's left is where these extra bits come from, since they're local to your node, they're obviously not in the DNS, or anywhere else like that. There are two cases to consider - when you receive the address from over the wire, and when it originates in your node. The first is easy - when a packet arrives, it arrives over some interface. That interface "belongs" to one of these extra identifiers, that identifier is what is used. That is, in yoru case, you might decide that the .3 interface should have identifier "3" and the .11 interface should be "11". (This is convenient for this example, but in real life would obviuously not make sense, as there are likely to be multiple .3 interfaces, and they can't all be called "3" - only one of them - there might even be multiple .11 interfaces, though that's proabably less likely). Now, any time you receive any address (in headers, or anywhere else) that's FE80::xxx from the .3 interface, you should consider (and store) the address as 3:FE80::XXXX - if from the .11 interface, you should treat it as 11:FE80::XXXX (or B:FE80::XXXX as you prefer). The IPv6 sockaddr struct has a field into which the extra identifier is put, so when the address is passed back to the application (if it is), everything is included. When an address comes from an application, the application needs to fill in that extra field - if the app is just passing back an address it previously got from the kernel (getpeername() or similar) then the data will be there already (even for global addresses, which don't need the extra bits, in theory anyway, it is there - should be set to 0). LLL addresses generally don't (certainly shouldn't) come from the DNS, so that's not an issue (the DNS has no possible way to store your nodes private identification numbers, obviously). Other name to address conversion mechanisms aren't yet finished - but anything that is doing dynamic discovery (sending requests for a name, getting back answers) is getting the answer over a specific link, and the ID comes from the link over which the answer was received. Where the address (numeric address) originates from a user, the user is responsible for supplying the info - and getaddrinfo() should be able to parse addresses containing scope identifiers into the 128 bit "address" and the extra "scope ID". On the system I use, that's done like ping fe80::1%ex0 or ping fe80::1%wi0 where ex0 and wi0 are my .3 and .11 interfaces (resp). Getaddrinfo() extracts the interface name, looks it up in the kernel, extracts the numeric identifier associated (3 or 11 in our example) and includes it in the address structure returned. The actual syntax is irrelevant (I have seen other OSs where the app is required to get the scope identifier from a separate arg to the command, and include it in the address itself - which seems pretty dumb to me, but "whatever works"). All this means that most applications need to do nothing at all special, if the OS is sane - it all "just works", but some need to take special care when they deal with addresses, to notice when LL addresses appear, and handle the scope ID appropriately (which includes not sending packets with one scope-id to a node whose address is in a different scope). [The same is true of site local addresses, for which most nodes will have only one scope-ID which simplifies things very little actually, but the required LL processing carries forth naturally to SL as well.] Does this help? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 19 19:08:54 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4K28rhs019690; Mon, 19 May 2003 19:08:54 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4K28r1Z019689; Mon, 19 May 2003 19:08:53 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4K28ohs019682 for ; Mon, 19 May 2003 19:08:50 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4K27Luc018002 for ; Mon, 19 May 2003 19:07:21 -0700 (PDT) Received: from mailserv.ait.ac.th (mailserv.ait.ac.th [203.159.5.10]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4K27F3S014336 for ; Mon, 19 May 2003 20:07:15 -0600 (MDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailserv.ait.ac.th (Postfix) with ESMTP id 4585C32EF0; Tue, 20 May 2003 09:06:11 +0700 (ICT) Received: from mailserv.ait.ac.th ([127.0.0.1]) by localhost (mailserv.ait.ac.th [127.0.0.1:10024]) (amavisd-new) with ESMTP id 24795-08; Tue, 20 May 2003 09:06:11 +0700 (ICT) Received: from delta.cs.mu.OZ.AU (unknown [203.159.26.94]) by mailserv.ait.ac.th (Postfix) with ESMTP id 1EAAA32EE8; Tue, 20 May 2003 09:06:11 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4K1uUq24712; Tue, 20 May 2003 08:56:31 +0700 (ICT) From: Robert Elz To: Jochen Kaiser Cc: ipng@sunroof.eng.sun.com Subject: Re: solicited group multicast address; prob of understanding In-Reply-To: <20030519220145.GA98841@devil.rrze.uni-erlangen.de> References: <20030519220145.GA98841@devil.rrze.uni-erlangen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 May 2003 08:56:30 +0700 Message-ID: <24710.1053395790@munnari.OZ.AU> X-Virus-Scanned: by amavisd-new Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 20 May 2003 00:01:45 +0200 From: Jochen Kaiser Message-ID: <20030519220145.GA98841@devil.rrze.uni-erlangen.de> | Is it really that you generate a special mc group per node? Yes. Note that a node is only ever a member of one of these (well, assuming it forms all of its addresses from the same IID anyway, 3041 using hosts have a more interesting life). The practical effect of this is that ND packets need only be processed by the node for whom they're intended in most cases (multicast group clashes are possible, but aren't very likely). Contrast this with ARP where an ARP request wakens every node on the LAN, all but one of which ignore it. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 19 19:40:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4K2e2hs020221; Mon, 19 May 2003 19:40:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4K2e2YF020220; Mon, 19 May 2003 19:40:02 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4K2dwhs020213 for ; Mon, 19 May 2003 19:39:58 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4K2cMuc027292 for ; Mon, 19 May 2003 19:38:22 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4K2cGHN011493 for ; Mon, 19 May 2003 19:38:17 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Mon, 19 May 2003 19:38:33 -0700 Message-ID: <963621801C6D3E4A9CF454A1972AE8F5067105@server2000.arneill-py.sacramento.ca.us> X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMeKr311C5RrXfbR4aFzMYeKEwr0AATeLFQ From: "Michel Py" To: "Robert Elz" , "Margaret Wasserman" Cc: "Eliot Lear" , "Tony Hain" , "Bob Hinden" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4K2dxhs020214 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> Margaret Wasserman wrote: >> Who said that the aim of IPv6 was to be able to do >> everything that IPv4 can do? > Robert Elz wrote: > It was something from the early days of the WG. The actual > wording I am half remembering might have been from Steve > Deering, but that's no more than a guess. > But it should be obvious - if there's anything (even half way > supportable) that IPv4 can do, that IPv6 doesn't have an answer > to, then there will be a class of users who will simply say > "IPv6 is impossible, it cannot handle my needs". I could not agree more. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 20 02:47:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4K9l2hs021821; Tue, 20 May 2003 02:47:02 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4K9l28m021820; Tue, 20 May 2003 02:47:02 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4K9kxhs021813 for ; Tue, 20 May 2003 02:46:59 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4K9jTuc029626 for ; Tue, 20 May 2003 02:45:29 -0700 (PDT) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4K9jNx9007913 for ; Tue, 20 May 2003 02:45:24 -0700 (PDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4K9jAlr107758 for ; Tue, 20 May 2003 11:45:13 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4K9ifhV216406 for ; Tue, 20 May 2003 11:44:47 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA45662 from ; Tue, 20 May 2003 11:44:39 +0200 Message-Id: <3EC9F925.F87DD519@hursley.ibm.com> Date: Tue, 20 May 2003 11:45:09 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <011c01c31e31$385dfba0$74164104@eagleswings> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony Hain wrote: > > Just a followup to my previous note: > > It was not my intent to say that Bob was intentionally trying to be > deceptive and mislead the working group. So I apologize to Bob if it > came across that way. > > I was trying to point out the contradiction between: > Margaret: > > >Bob's proposal explicitly defines a type of addresses that are not > > >expected to be routed throughout the Internet. So, these > > >addresses are local, not globally routable. > Bob: > > The globally unique IPv6 local unicast addresses are not > > limited in their > > use to any scope less than global by their design because they have > > prefixes that are globally unique. > > and the subsequent claim that the chairs agree on the definition. The > definition can not be both, limited to local use, and not limited to > less than global, at the same time. Either these are unlimited and > useful globally, or they are local (for some definition of local). > Claiming they are both at the same time is the problem here. I think the underlying problem is that there is no black and white distinction between local and global, when network mergers, service hosting, and VPNs, are considered. I can see very well how to use Bob's proposal in such an ambiguous situation, without worrying too much about whether it's local or global or something in between. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 20 09:15:06 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4KGF6hs023884; Tue, 20 May 2003 09:15:06 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4KGF6cM023883; Tue, 20 May 2003 09:15:06 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4KGF2hs023876 for ; Tue, 20 May 2003 09:15:02 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4KGDWuc006900 for ; Tue, 20 May 2003 09:13:32 -0700 (PDT) Received: from pianosa.catch22.org (pianosa.catch22.org [66.93.182.229]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4KGDQx9021314 for ; Tue, 20 May 2003 09:13:26 -0700 (PDT) Received: by pianosa.catch22.org (Postfix, from userid 1000) id B2E9234C; Tue, 20 May 2003 09:13:25 -0700 (PDT) Date: Tue, 20 May 2003 11:13:24 -0500 From: David Terrell To: Thomas Narten Cc: Dan Lanciani , ipng@sunroof.eng.sun.com Subject: Re: Why I support deprecating SLs Message-ID: <20030520161324.GA7738@pianosa.catch22.org> Reply-To: David Terrell References: <200304032244.RAA06152@ss10.danlan.com> <200304040116.h341GZw06002@cichlid.adsl.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200304040116.h341GZw06002@cichlid.adsl.duke.edu> User-Agent: Mutt/1.4i X-vi: Version 1.79 (10/23/96) The CSRG, University of California, Berkeley. X-Nethack: You feel like someone is making a pointless Nethack reference.--More-- X-Uptime: 11:05AM up 9 days, 9:07, 37 users, load averages: 0.51, 0.54, 0.61 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, Apr 03, 2003 at 08:16:35PM -0500, Thomas Narten wrote: > > > |Thomas Narten wrote: > > | > > |> - Site-locals should be retained as a means for internal > > |> connections to survive global prefix renumbering. > > | > > |4) This is strikes me as a nice requirement, but something we don't > > | have a solution for, even with SLs. We need to accept that we have > > | no solution and SL is doesn't really seem to be a help here. > > > Please explain why you feel that internal connections using site-locals will > > not survive global prefix renumbering. > > Internal connections using SLs will survive renumbering. But that is > the easy part and by itself is largely uninteresting. > > The tough question is, how do we get applications in general to prefer > SLs for local communication. Note that it is not enough for a handful > of applications to use SLs and survive renumbering, my assumption is > you want pretty much all intra-site communication to use SLs. I.e., if > only 30% of your intra-site traffic is using SLs, and a renumbering > takes place, 70% of your traffic is still potentially impacted. That > doesn't seem like much of a real solution to me. I disagree. If that 70% of traffic is short lived, on demand traffic such as, say, HTTP, I don't think it's such a big deal. Site locals need to be in place for things that will not survive a renumbering well. NFS, DNS resolvers, long-lived TCP sessions (database connections?) etc; things that break when the number is changed. -- David Terrell | Nebcorp Prime Minister | dbt@meat.net | The best free things in life are free. http://wwn.nebcorp.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 May 21 00:13:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4L7DIhs028827; Wed, 21 May 2003 00:13:18 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4L7DHNl028826; Wed, 21 May 2003 00:13:17 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4L7DEhs028819 for ; Wed, 21 May 2003 00:13:14 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4L7BhKw003203 for ; Wed, 21 May 2003 00:11:43 -0700 (PDT) Received: from mailout1.samsung.com ([203.254.224.24]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4L7Ba3K010087 for ; Wed, 21 May 2003 01:11:37 -0600 (MDT) Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) id <0HF8006086M848@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Wed, 21 May 2003 16:10:56 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTP id <0HF800JFV6M7YY@mailout1.samsung.com> for ipng@sunroof.eng.sun.com; Wed, 21 May 2003 16:10:55 +0900 (KST) Received: from praveen ([107.108.4.247]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.05 (built Nov 6 2002)) with ESMTPA id <0HF800J936M5HW@mmp2.samsung.com> for ipng@sunroof.eng.sun.com; Wed, 21 May 2003 16:10:55 +0900 (KST) Date: Wed, 21 May 2003 12:36:59 +0530 From: Praveen Rajendran Subject: Re: solicited group multicast address; prob of understanding To: Jochen Kaiser , ipng@sunroof.eng.sun.com Message-id: <006001c31f67$93b9b660$f7046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 X-Mailer: Microsoft Outlook Express 5.50.4522.1200 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20030519220145.GA98841@devil.rrze.uni-erlangen.de> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > When I understand this correctly, a host joins his 'own' multicast > group "FF01::1:FF:aa:bb:cc" and then sends a NS packet to the > solicited node multicast address of the node. So if there is > another host in this group, DAD gets an NA message and DAD fails. > DAD can also fail when you get a NS message with the same target address. This can happen when two nodes with the same address attempt to do DAD simultaneously with each receiving the others NS message after transmitting their own. > Is it really that you generate a special mc group per node? > I don't believe this and think that I am misunderstanding this. > My netstat doesn't show it, too. > Yes you generate a special mc group per node in order to minimize the number of nodes on the link processing your NS. Since the solicited node Multicast address is formed by taking the last 4 bytes of the IP address there only a small probability that more than one node in a link can be listening on that address. Praveen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 21 00:43:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4L7hVhs029086; Wed, 21 May 2003 00:43:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4L7hUUV029085; Wed, 21 May 2003 00:43:30 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4L7hRhs029078 for ; Wed, 21 May 2003 00:43:27 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4L7fvKw016247 for ; Wed, 21 May 2003 00:41:57 -0700 (PDT) Received: from max6.rrze.uni-erlangen.de (max6.rrze.uni-erlangen.de [131.188.3.214]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4L7fpep021958 for ; Wed, 21 May 2003 01:41:51 -0600 (MDT) Received: from devil.rrze.uni-erlangen.de by max6.rrze.uni-erlangen.de with ESMTP; Wed, 21 May 2003 09:41:49 +0200 Received: from devil.rrze.uni-erlangen.de (devil [127.0.0.1]) by devil.rrze.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id h4L7fnab048760; Wed, 21 May 2003 09:41:49 +0200 (CEST) (envelope-from Jochen.Kaiser@rrze.uni-erlangen.de) Received: (from unrz111@localhost) by devil.rrze.uni-erlangen.de (8.12.9/8.12.9/Submit) id h4L7fnmo048759; Wed, 21 May 2003 09:41:49 +0200 (CEST) X-Authentication-Warning: devil.rrze.uni-erlangen.de: unrz111 set sender to Jochen.Kaiser@rrze.uni-erlangen.de using -f Date: Wed, 21 May 2003 09:41:49 +0200 From: Jochen Kaiser To: Robert Elz Cc: ipng@sunroof.eng.sun.com Subject: Re: solicited group multicast address; MLD in L2 only networks? Message-Id: <20030521074149.GA47824@devil.rrze.uni-erlangen.de> References: <20030519220145.GA98841@devil.rrze.uni-erlangen.de> <24710.1053395790@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <24710.1053395790@munnari.OZ.AU> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, May 20, 2003 at 08:56:30AM +0700, Robert Elz wrote: > | Is it really that you generate a special mc group per node? > > The practical effect of this is that ND packets need only be processed > by the node for whom they're intended in most cases (multicast group > clashes are possible, but aren't very likely). Contrast this with ARP > where an ARP request wakens every node on the LAN, all but one of > which ignore it. I understand this now. I just was confused, since I didn't see this on my BSD boxes. But it seems to be implemented on USAGI and Solaris. (Even ethereal didn't reveal this ...) Another point of confusion is the fact, that switches have to be more complex so that this works efficient. In IPv4 I know the CGMP and the IGMP-snooping mechanisms. What will it be in ipv6, to make the switches L3 aware? Will it be called MLD-snooping or will there be another mechanism with interaction of a router? Yet another point that makes me wondering: when you have a L2 flat network without any router you can't use this efficient mechanism. Is there a concept of a 'stub' or 'one arm' router to make such a network more efficient? regards, Jochen Kaiser -- Dipl. Inf. Jochen Kaiser, GPG 0x3C93A870, phone +49 9131 85-28681 Network Administration mailto:jochen.kaiser@rrze.uni-erlangen.de Regionales Rechenzentrum Universitaet Erlangen-Nuernberg, Germany Homepage and PublicKey: http://ipv6.rrze.uni-erlangen.de/~unrz111 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 21 09:17:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4LGHShs001169; Wed, 21 May 2003 09:17:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4LGHSC7001168; Wed, 21 May 2003 09:17:28 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4LGHOhs001161 for ; Wed, 21 May 2003 09:17:24 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4LGFtuc018414 for ; Wed, 21 May 2003 09:15:55 -0700 (PDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4LGFoht023336 for ; Wed, 21 May 2003 10:15:50 -0600 (MDT) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h4LGFi6I020124 for ; Wed, 21 May 2003 09:15:44 -0700 (PDT) Received: from SIVAV.qualcomm.com ([10.50.68.30]) by sabrina.qualcomm.com (8.12.9/8.12.5/1.0) with ESMTP id h4LGFgBC009933 for ; Wed, 21 May 2003 09:15:43 -0700 (PDT) Message-Id: <4.3.2.7.2.20030521090030.01efd5e8@jittlov.qualcomm.com> X-Sender: sivav@jittlov.qualcomm.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 21 May 2003 09:15:42 -0700 To: ipng@sunroof.eng.sun.com From: Siva Veerepalli Subject: PPP - Address autoconfiguration question Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk If a RAS/NAS advertises a unique global prefix over the PPP interface with the Autonomous configuration flag set, I think it is pretty safe to assume that both ends of the PPP link could use the prefix to configure an address for their end of the PPP link, irrespective of the usefulness of such an address for say, the RAS end of the PPP link. Is this accurate? I would appreciate your comments. Thanks, Siva -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 21 12:19:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4LJJUhs002370; Wed, 21 May 2003 12:19:30 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4LJJUnD002369; Wed, 21 May 2003 12:19:30 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4LJJRhs002362 for ; Wed, 21 May 2003 12:19:27 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4LJHwuc028048 for ; Wed, 21 May 2003 12:17:58 -0700 (PDT) Received: from laposte.rennes.enst-bretagne.fr (laposte.rennes.enst-bretagne.fr [192.44.77.17]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4LJHq4Z009854 for ; Wed, 21 May 2003 12:17:52 -0700 (PDT) Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id h4LJHmK03538; Wed, 21 May 2003 21:17:48 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id h4LJHmof022152; Wed, 21 May 2003 21:17:48 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200305211917.h4LJHmof022152@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Siva Veerepalli cc: ipng@sunroof.eng.sun.com Subject: Re: PPP - Address autoconfiguration question In-reply-to: Your message of Wed, 21 May 2003 09:15:42 PDT. <4.3.2.7.2.20030521090030.01efd5e8@jittlov.qualcomm.com> Date: Wed, 21 May 2003 21:17:48 +0200 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: If a RAS/NAS advertises a unique global prefix over the PPP interface with the Autonomous configuration flag set, I think it is pretty safe to assume that both ends of the PPP link could use the prefix to configure an address for their end of the PPP link, irrespective of the usefulness of such an address for say, the RAS end of the PPP link. Is this accurate? I would appreciate your comments. => this problem (get by an easy way global address(es) of the RAS/NAS) is IMHO a good usage of the R bit of prefix infos defined for mobile IPv6 (but useful in some other environments). 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 May 21 16:14:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4LNEShs004132; Wed, 21 May 2003 16:14:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4LNESFW004131; Wed, 21 May 2003 16:14:28 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4LNEOhs004124 for ; Wed, 21 May 2003 16:14:24 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4LNCsuc024327 for ; Wed, 21 May 2003 16:12:54 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4LNClep000543 for ; Wed, 21 May 2003 17:12:48 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 0332092; Thu, 22 May 2003 08:12:45 +0900 (JST) To: Jochen Kaiser Cc: Robert Elz , ipng@sunroof.eng.sun.com In-reply-to: Jochen.Kaiser's message of Wed, 21 May 2003 09:41:49 +0200. <20030521074149.GA47824@devil.rrze.uni-erlangen.de> 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: solicited group multicast address; MLD in L2 only networks? From: itojun@iijlab.net Date: Thu, 22 May 2003 08:12:44 +0900 Message-Id: <20030521231245.0332092@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >> The practical effect of this is that ND packets need only be processed >> by the node for whom they're intended in most cases (multicast group >> clashes are possible, but aren't very likely). Contrast this with ARP >> where an ARP request wakens every node on the LAN, all but one of >> which ignore it. > > I understand this now. I just was confused, since I didn't >see this on my BSD boxes. But it seems to be implemented on >USAGI and Solaris. (Even ethereal didn't reveal this ...) to know which IPv4/v6 multicast groups your node is joining, use ifmcstat(8). it won't show in netstat. 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 May 21 20:00:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4M30Bhs004871; Wed, 21 May 2003 20:00:11 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4M30BD4004870; Wed, 21 May 2003 20:00:11 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4M307hs004863 for ; Wed, 21 May 2003 20:00:07 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4M2wbKw002138 for ; Wed, 21 May 2003 19:58:37 -0700 (PDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4M2wVht019218 for ; Wed, 21 May 2003 20:58:31 -0600 (MDT) Received: from ocean.jinmei.org (unknown [3ffe:501:4819:2000:8963:61cf:622e:2ba7]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 4332615248; Thu, 22 May 2003 11:58:29 +0900 (JST) Date: Thu, 22 May 2003 11:58:27 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: itojun@iijlab.net Cc: Jochen Kaiser , Robert Elz , ipng@sunroof.eng.sun.com Subject: Re: solicited group multicast address; MLD in L2 only networks? In-Reply-To: <20030521231245.0332092@coconut.itojun.org> User-Agent: Wanderlust/2.10.0 (Venus) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk >>>>> On Thu, 22 May 2003 08:12:44 +0900, >>>>> itojun@iijlab.net said: >>> The practical effect of this is that ND packets need only be >>> processed by the node for whom they're intended in most cases >>> (multicast group clashes are possible, but aren't very likely). >>> Contrast this with ARP where an ARP request wakens every node on >>> the LAN, all but one of which ignore it. >> I understand this now. I just was confused, since I didn't see >> this on my BSD boxes. But it seems to be implemented on USAGI and >> Solaris. (Even ethereal didn't reveal this ...) > to know which IPv4/v6 multicast groups your node is joining, > use ifmcstat(8). it won't show in netstat. It does, actually (at least on some *BSDs). Try netstat -ian. But in the first place, I don't really understand what "I didn't see this on my BSD boxes" means... JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 21 23:05:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4M657hs005537; Wed, 21 May 2003 23:05:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4M657w9005536; Wed, 21 May 2003 23:05:07 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4M653hs005529 for ; Wed, 21 May 2003 23:05:03 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4M63Yuc002987 for ; Wed, 21 May 2003 23:03:34 -0700 (PDT) Received: from svr.v6 ([202.28.2.200]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4M63Rep021291 for ; Thu, 22 May 2003 00:03:28 -0600 (MDT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4M5dn409664; Thu, 22 May 2003 12:39:49 +0700 (ICT) From: Robert Elz To: Jochen Kaiser cc: ipng@sunroof.eng.sun.com Subject: Re: solicited group multicast address; MLD in L2 only networks? In-Reply-To: <20030521074149.GA47824@devil.rrze.uni-erlangen.de> References: <20030521074149.GA47824@devil.rrze.uni-erlangen.de> <20030519220145.GA98841@devil.rrze.uni-erlangen.de> <24710.1053395790@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 May 2003 12:39:49 +0700 Message-ID: <9662.1053581989@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 21 May 2003 09:41:49 +0200 From: Jochen Kaiser Message-ID: <20030521074149.GA47824@devil.rrze.uni-erlangen.de> | I understand this now. I just was confused, since I didn't | see this on my BSD boxes. But it seems to be implemented on | USAGI and Solaris. (Even ethereal didn't reveal this ...) Itojun and Jinmei have explained how to make *BSD boxes reveal it. | Another point of confusion is the fact, that switches have to | be more complex so that this works efficient. In IPv4 I know | the CGMP and the IGMP-snooping mechanisms. What will it be | in ipv6, to make the switches L3 aware? Will it be called | MLD-snooping or will there be another mechanism with interaction | of a router? I have heard talk of MLD-snooping, yes - but someone else is going to need to answer this part of your question. | Yet another point that makes me wondering: when you have a L2 | flat network without any router you can't use this efficient | mechanism. Is there a concept of a 'stub' or 'one arm' router | to make such a network more efficient? I don't understand this at all? Link level multicast doesn't require routers at all. The node simply computes the MAC (multicast) address that corresponds to the protocol (IPv6 here of course) multicast, using the defined rules, and sends to that MAC level multicast address, the same as it would send to any other. Where did you see a problem? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 21 23:12:53 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4M6Crhs005661; Wed, 21 May 2003 23:12:53 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4M6CrMf005660; Wed, 21 May 2003 23:12:53 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4M6Cnhs005653 for ; Wed, 21 May 2003 23:12:49 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4M6BJKw022293 for ; Wed, 21 May 2003 23:11:19 -0700 (PDT) Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4M6BDht015917 for ; Thu, 22 May 2003 00:11:14 -0600 (MDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id E375292 for ; Thu, 22 May 2003 15:11:10 +0900 (JST) To: ipng@sunroof.eng.sun.com In-reply-to: kre's message of Thu, 22 May 2003 12:39:49 +0700. <9662.1053581989@munnari.OZ.AU> 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: solicited group multicast address; MLD in L2 only networks? From: itojun@iijlab.net Date: Thu, 22 May 2003 15:11:10 +0900 Message-Id: <20030522061110.E375292@coconut.itojun.org> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > | Another point of confusion is the fact, that switches have to > | be more complex so that this works efficient. In IPv4 I know > | the CGMP and the IGMP-snooping mechanisms. What will it be > | in ipv6, to make the switches L3 aware? Will it be called > | MLD-snooping or will there be another mechanism with interaction > | of a router? > >I have heard talk of MLD-snooping, yes - but someone else is going to >need to answer this part of your question. there are L2 switch product which does MLD snooping already, just like IGMP snooping. in terms of complexity they are the same. itojun -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 22 04:13:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4MBD4hs006718; Thu, 22 May 2003 04:13:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4MBD31u006717; Thu, 22 May 2003 04:13:03 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4MBD0hs006710 for ; Thu, 22 May 2003 04:13:00 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4MBBTKw028677 for ; Thu, 22 May 2003 04:11:29 -0700 (PDT) Received: from max6.rrze.uni-erlangen.de (max6.rrze.uni-erlangen.de [131.188.3.214]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4MBBNht022532 for ; Thu, 22 May 2003 05:11:24 -0600 (MDT) Received: from devil.rrze.uni-erlangen.de by max6.rrze.uni-erlangen.de with ESMTP; Thu, 22 May 2003 11:32:05 +0200 Received: from devil.rrze.uni-erlangen.de (devil [127.0.0.1]) by devil.rrze.uni-erlangen.de (8.12.9/8.12.9) with ESMTP id h4M9W4ab002186; Thu, 22 May 2003 11:32:04 +0200 (CEST) (envelope-from Jochen.Kaiser@rrze.uni-erlangen.de) Received: (from unrz111@localhost) by devil.rrze.uni-erlangen.de (8.12.9/8.12.9/Submit) id h4M9W4AI002185; Thu, 22 May 2003 11:32:04 +0200 (CEST) X-Authentication-Warning: devil.rrze.uni-erlangen.de: unrz111 set sender to Jochen.Kaiser@rrze.uni-erlangen.de using -f Date: Thu, 22 May 2003 11:32:04 +0200 From: Jochen Kaiser To: "JINMEI Tatuya / ?$B?@L@C#:H" Cc: ipng@sunroof.eng.sun.com Subject: Re: solicited group multicast address; MLD in L2 only networks? Message-Id: <20030522093204.GA1978@devil.rrze.uni-erlangen.de> References: <20030521231245.0332092@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Thu, May 22, 2003 at 11:58:27AM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: [...] > It does, actually (at least on some *BSDs). Try netstat -ian. > > But in the first place, I don't really understand what "I didn't see > this on my BSD boxes" means... I used an ethereal to sniff on the localhost and didn't see the usage of these multicast groups ... just did see the "all nodes group" ... I will give it a second try and look more briefly. regards and thx, Jochen Kaiser -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 22 10:50:44 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4MHoihs008195; Thu, 22 May 2003 10:50:44 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4MHohBn008194; Thu, 22 May 2003 10:50:43 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4MHoehs008187 for ; Thu, 22 May 2003 10:50:40 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4MHn8uc012055 for ; Thu, 22 May 2003 10:49:09 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4MHn34Z004672 for ; Thu, 22 May 2003 10:49:03 -0700 (PDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 22 May 2003 10:49:00 -0700 Reply-To: From: "Tony Hain" To: "'Margaret Wasserman'" , "'Robert Elz'" Cc: "'Eliot Lear'" , "'Bob Hinden'" , Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Thu, 22 May 2003 10:48:59 -0700 Message-ID: <041901c3208a$6ccc4d50$74164104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <5.1.0.14.2.20030519073316.040d4e20@mail.windriver.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4MHoehs008188 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Margaret Wasserman wrote: > ... > It hasn't been demonstrated (yet) that there is rough > consensus in the WG about this, and we probably won't be > able to demonstrate that until the WG comes to some agreement > on the requirements for local addressing (which we could > already have, although they aren't written down -- do they > need to be?) Again, I offer: http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-01.txt specifically documenting the requirements. Please stop saying they aren't written down. The WG has not produced a document, but that is not the only source of requirements. If people feel the list is inaccurate or incomplete, please let me know. > > This is a very complicated topic, and there are a lot of > trade-offs that need to be considered between pursuing > non-globally-routable local addressing mechanisms, pursuing > provider-independent routing mechanisms, pursuing automated > renumbering systems to obviate (one of the) need(s) for local > addressing, etc. > > The fact that I think that this chunk of work is something > that could reasonably be broken off into a separate, focused > WG doesn't mean that I think it should die. In fact, I > think it is less likely to die if it gets its own resources > (dedicated meeting time, dedicated chairs, etc.). However, > this isn't my decision -- the decision about how to organize > the work in the area belongs to the ADs. In this case, it is broad enough that it probably belongs in the General Area. There aspects that touch all of the other areas, so putting it in any one is likely to overlook something. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 22 12:04:04 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4MJ44hs008986; Thu, 22 May 2003 12:04:04 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4MJ43dk008985; Thu, 22 May 2003 12:04:03 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4MJ40hs008978 for ; Thu, 22 May 2003 12:04:00 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4MJ2TKw027143 for ; Thu, 22 May 2003 12:02:29 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4MJ2OLv012175 for ; Thu, 22 May 2003 12:02:24 -0700 (PDT) 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 MAA14731; Thu, 22 May 2003 12:02:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4MJ2LJ30267; Thu, 22 May 2003 12:02:21 -0700 X-mProtect: <200305221902> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdUuCfOa; Thu, 22 May 2003 12:02:19 PDT Message-ID: <3ECD200E.90009@iprg.nokia.com> Date: Thu, 22 May 2003 12:07:58 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'Margaret Wasserman'" , "'Robert Elz'" , "'Eliot Lear'" , "'Bob Hinden'" , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <041901c3208a$6ccc4d50$74164104@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, Tony Hain wrote: > Again, I offer: > http://www.ietf.org/internet-drafts/draft-hain-ipv6-sitelocal-01.txt I read the document, and it seems to me there needs to be a discussion of cases in which link-local addressing (fe80::) is insufficient. In my opinion, it comes down to identifying use cases in which flat vs. hierarchical local addressing schemes are most appropriate. I believe this is a very difficult subject to get one's arms around, but one that a local scope address requirements document needs to tackle. Fred ftemplin@iprg.nokia.com -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 22 13:41:09 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4MKf9hs009513; Thu, 22 May 2003 13:41:09 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4MKf8VK009512; Thu, 22 May 2003 13:41:08 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4MKf2hs009505 for ; Thu, 22 May 2003 13:41:02 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4MKdVuc015368 for ; Thu, 22 May 2003 13:39:31 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4MKdMLv003028 for ; Thu, 22 May 2003 13:39:26 -0700 (PDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Thu, 22 May 2003 13:39:20 -0700 Reply-To: From: "Tony Hain" To: "'Fred L. Templin'" Cc: "'Margaret Wasserman'" , "'Robert Elz'" , "'Eliot Lear'" , "'Bob Hinden'" , Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Thu, 22 May 2003 13:39:13 -0700 Message-ID: <043701c320a2$351b53c0$74164104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: <3ECD200E.90009@iprg.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4MKf2hs009506 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Fred L. Templin wrote: > I read the document, and it seems to me there needs to be a > discussion of cases in which link-local addressing (fe80::) > is insufficient. In my opinion, it comes down to identifying > use cases in which flat vs. hierarchical local addressing > schemes are most appropriate. I believe this is a very > difficult subject to get one's arms around, but one that a > local scope address requirements document needs to tackle. I guess I accept the premise that the document should deal with it, but it is not clear to me what form that would take beyond the direct evidence that people have deployed networks that are larger scope than a single link, and smaller scope than global. Their requirement for larger than a single L2 link is ??? Clearly compartmentalization and traffic isolation comes to mind, but how much of that requirement is based on anecdotal requirements from broken implementations of > 15 years ago. Routing convergence is another frequent reason, but again global flat L2 host routing is not the problem it once was. Is it sufficient to say that network managers insist on the protection offered by a scope less than global, but simply 'want' the organizational structure of an L3 hierarchy that is larger than a single L2 link? If not, what is the real requirement for hierarchy? Is this the philosophical argument about L2 vs. L3 being better, or are we really talking about something like the need for a network to be constructed out of differing L2 media types for cost reasons. If different media is the reason, the arguments are more about interconnecting dissimilar media than hierarchy. Which brings us back to the question of how large does a network need to be to 'require' hierarchy rather than simply 'want' it? Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 22 14:37:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4MLbghs010028; Thu, 22 May 2003 14:37:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4MLbgHB010027; Thu, 22 May 2003 14:37:42 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4MLbchs010020 for ; Thu, 22 May 2003 14:37:38 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4MLa7uc005477 for ; Thu, 22 May 2003 14:36:07 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4MLa1Lv001873 for ; Thu, 22 May 2003 14:36:02 -0700 (PDT) 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 OAA22757; Thu, 22 May 2003 14:36:00 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4MLZw408248; Thu, 22 May 2003 14:35:58 -0700 X-mProtect: <200305222135> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.67, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdpeTCfu; Thu, 22 May 2003 14:35:57 PDT Message-ID: <3ECD440E.8040706@iprg.nokia.com> Date: Thu, 22 May 2003 14:41:34 -0700 From: "Fred L. Templin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: alh-ietf@tndh.net CC: "'Margaret Wasserman'" , "'Robert Elz'" , "'Eliot Lear'" , "'Bob Hinden'" , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <043701c320a2$351b53c0$74164104@eagleswings> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Tony, You are hitting exactly on the points that concern me, and I believe some implications for a local-use addressing scheme become evident from what you've said. I think this is approx. 90% about the phiolosophical argument about L2 vs. L3; issues with constructing networks out of differing L2 media types can be overcome. Your final question on how large does a network need to be to 'require' rather than 'want' hierarchy is very poignant. Seems like it might warrant some examination in the document. Fred ftemplin@iprg.nokia.com Tony Hain wrote: > Fred L. Templin wrote: > >>I read the document, and it seems to me there needs to be a >>discussion of cases in which link-local addressing (fe80::) >>is insufficient. In my opinion, it comes down to identifying >>use cases in which flat vs. hierarchical local addressing >>schemes are most appropriate. I believe this is a very >>difficult subject to get one's arms around, but one that a >>local scope address requirements document needs to tackle. > > > I guess I accept the premise that the document should deal with it, but > it is not clear to me what form that would take beyond the direct > evidence that people have deployed networks that are larger scope than a > single link, and smaller scope than global. Their requirement for larger > than a single L2 link is ??? > > Clearly compartmentalization and traffic isolation comes to mind, but > how much of that requirement is based on anecdotal requirements from > broken implementations of > 15 years ago. Routing convergence is another > frequent reason, but again global flat L2 host routing is not the > problem it once was. > > Is it sufficient to say that network managers insist on the protection > offered by a scope less than global, but simply 'want' the > organizational structure of an L3 hierarchy that is larger than a single > L2 link? If not, what is the real requirement for hierarchy? Is this the > philosophical argument about L2 vs. L3 being better, or are we really > talking about something like the need for a network to be constructed > out of differing L2 media types for cost reasons. If different media is > the reason, the arguments are more about interconnecting dissimilar > media than hierarchy. Which brings us back to the question of how large > does a network need to be to 'require' hierarchy rather than simply > 'want' it? > > > Tony > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 23 05:31:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4NCVbhs012645; Fri, 23 May 2003 05:31:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4NCVb3Z012644; Fri, 23 May 2003 05:31:37 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4NCVYhs012637 for ; Fri, 23 May 2003 05:31:34 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4NCU2uc023839 for ; Fri, 23 May 2003 05:30:02 -0700 (PDT) Received: from d12lmsgate-4.de.ibm.com (d12lmsgate-4.de.ibm.com [194.196.100.237]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4NCToYU025308 for ; Fri, 23 May 2003 06:29:55 -0600 (MDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-4.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4NCT8DI108184 for ; Fri, 23 May 2003 14:29:34 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4NCStNh059148 for ; Fri, 23 May 2003 14:29:07 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA55062 from ; Fri, 23 May 2003 14:28:53 +0200 Message-Id: <3ECE1421.1B157C4D@hursley.ibm.com> Date: Fri, 23 May 2003 14:29:21 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Limited-scope unambiguous addresses [Re: Draft on Globally Unique IPv6 Local Unicast Addresses] References: <043701c320a2$351b53c0$74164104@eagleswings> <3ECD440E.8040706@iprg.nokia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk "Fred L. Templin" wrote: > > Tony, > > You are hitting exactly on the points that concern me, and I > believe some implications for a local-use addressing scheme > become evident from what you've said. I think this is approx. > 90% about the phiolosophical argument about L2 vs. L3; issues > with constructing networks out of differing L2 media types > can be overcome. > > Your final question on how large does a network need to be > to 'require' rather than 'want' hierarchy is very poignant. > Seems like it might warrant some examination in the document. If the network manager *wants* hierarchy, then it's a customer requirement, and the discussion's over. Even in a penny-ante network like the one I used to run at CERN, with a few hundred LANs and a few thousand hosts, there is no doubt that internal hierarchy was desirable, for simplicity of administration and operations. With serious sized networks of a few thousand LANs, there is no doubt whatever. But the managers of those LANs in many cases are exactly the people who want some form of "local" addressing, for the reasons Tony's draft gives. So I don't think the case really needs to be made any more strongly than Tony makes it. While we're on Tony's draft, it doesn't IMHO give enough attention to four reasons why non-ambiguity is essential: - VPNs between enterprises both of which use "local" space - hosting by service providers of hosts that reside in their customers' "local" space - formation of virtual organizations (Grids) among enterprises using "local" space - mergers and acquisitions of enterprises using "local" space So, why I am putting "local" in quotes? Because I think it's now clear that it's poor terminology. These addresses (as my four cases above show) are not local. They are not global either. They have what we might call "limited scope," but there is no simple rule that tells you what the scope is. My conclusion: what we need is a family of "limited-scope unambiguous addresses" and Tony's draft should express the requirements for those. (They will also serve very nicely as identifiers for multi6.) Brian > > Fred > ftemplin@iprg.nokia.com > > Tony Hain wrote: > > Fred L. Templin wrote: > > > >>I read the document, and it seems to me there needs to be a > >>discussion of cases in which link-local addressing (fe80::) > >>is insufficient. In my opinion, it comes down to identifying > >>use cases in which flat vs. hierarchical local addressing > >>schemes are most appropriate. I believe this is a very > >>difficult subject to get one's arms around, but one that a > >>local scope address requirements document needs to tackle. > > > > > > I guess I accept the premise that the document should deal with it, but > > it is not clear to me what form that would take beyond the direct > > evidence that people have deployed networks that are larger scope than a > > single link, and smaller scope than global. Their requirement for larger > > than a single L2 link is ??? > > > > Clearly compartmentalization and traffic isolation comes to mind, but > > how much of that requirement is based on anecdotal requirements from > > broken implementations of > 15 years ago. Routing convergence is another > > frequent reason, but again global flat L2 host routing is not the > > problem it once was. > > > > Is it sufficient to say that network managers insist on the protection > > offered by a scope less than global, but simply 'want' the > > organizational structure of an L3 hierarchy that is larger than a single > > L2 link? If not, what is the real requirement for hierarchy? Is this the > > philosophical argument about L2 vs. L3 being better, or are we really > > talking about something like the need for a network to be constructed > > out of differing L2 media types for cost reasons. If different media is > > the reason, the arguments are more about interconnecting dissimilar > > media than hierarchy. Which brings us back to the question of how large > > does a network need to be to 'require' hierarchy rather than simply > > 'want' it? > > > > > > Tony > > > > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Fri May 23 10:06:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4NH6jhs014429; Fri, 23 May 2003 10:06:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4NH6jaG014428; Fri, 23 May 2003 10:06:45 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4NH6ghs014421 for ; Fri, 23 May 2003 10:06:42 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4NH59Kw000134 for ; Fri, 23 May 2003 10:05:09 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4NH543K023979 for ; Fri, 23 May 2003 11:05:04 -0600 (MDT) 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 KAA11885; Fri, 23 May 2003 10:05:03 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4NH52A16838; Fri, 23 May 2003 10:05:02 -0700 X-mProtect: <200305231705> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.159, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd61JqEW; Fri, 23 May 2003 10:05:00 PDT Message-Id: <4.3.2.7.2.20030523094050.0365edd8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 23 May 2003 10:04:07 -0700 To: Brian E Carpenter From: Bob Hinden Subject: Re: Limited-scope unambiguous addresses [Re: Draft on Globally Unique IPv6 Local Unicast Addresses] Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3ECE1421.1B157C4D@hursley.ibm.com> References: <043701c320a2$351b53c0$74164104@eagleswings> <3ECD440E.8040706@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 Brian, >While we're on Tony's draft, it doesn't IMHO give enough attention >to four reasons why non-ambiguity is essential: > >- VPNs between enterprises both of which use "local" space >- hosting by service providers of hosts that reside in their customers' >"local" space >- formation of virtual organizations (Grids) among enterprises using >"local" space >- mergers and acquisitions of enterprises using "local" space It would be good to capture these in a requirements draft. >So, why I am putting "local" in quotes? Because I think it's now >clear that it's poor terminology. These addresses (as my four cases >above show) are not local. They are not global either. They have what >we might call "limited scope," but there is no simple rule that tells >you what the scope is. I agree that "local" isn't a good description as the addresses can be used beyond a site and as you point out above this is a feature. It is different notion of scope than the way that local, site, global scope are used. It is more related to a set of routing configurations. I think we need a better way to capture the idea here. One thought is the scope is "virtual" in the way VPN is used. Virtual scope? Virtual unicast addresses? >My conclusion: what we need is a family of "limited-scope unambiguous >addresses" >and Tony's draft should express the requirements for those. (They will >also serve >very nicely as identifiers for multi6.)\ Sounds like a plan to me :-) 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 Fri May 23 15:41:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4NMfLhs016212; Fri, 23 May 2003 15:41:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4NMfLx6016211; Fri, 23 May 2003 15:41:21 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4NMfIhs016204 for ; Fri, 23 May 2003 15:41:18 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4NMdjKw013508 for ; Fri, 23 May 2003 15:39:45 -0700 (PDT) Received: from defiant.dfw.nostrum.com (adsl-65-67-187-82.dsl.rcsntx.swbell.net [65.67.187.82]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4NMddep004984 for ; Fri, 23 May 2003 16:39:39 -0600 (MDT) Received: (from sprunk@localhost) by defiant.dfw.nostrum.com (8.11.3/8.11.3) id h4NMdV225709; Fri, 23 May 2003 17:39:31 -0500 Date: Fri, 23 May 2003 17:39:31 -0500 From: Stephen Sprunk To: Eliot Lear Cc: alh-ietf@tndh.net, "'Bob Hinden'" , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Message-ID: <20030523173931.F2841@defiant.dfw.nostrum.com> References: <135301c31c8e$766cee50$261e4104@eagleswings> <3EC76F0F.4080009@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.16i In-Reply-To: <3EC76F0F.4080009@cisco.com>; from lear@cisco.com on Sun, May 18, 2003 at 04:31:27AM -0700 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Thus spake Eliot Lear: > > After all if it is good for the edge it must be > > even better and simpler for the core. > > Funny you should mention this- much of the edge renumbers all the time. > That's what DHCP and PPP have given us. Our problem space in only > this regard has narrowed significantly since IPng began. In other ways, > it's grown. > > > Forced renumbering is a fantasy, > > Except for most of the edge. If you define the edge as individual hosts, sure. I think, for the purposes of this debate, the "edge" is supposed to mean all non- transit networks. > > so the WG needs to get over it. > > No. The IP version 6 development team made a grave error by not > properly dealing with administrative concerns in the beginning, so > please let's deal with it now. IMHO, we face a serious challenge since edge (by my definition) network managers rarely participate in the IETF process. Many companies actually prohibit employees from participating in public fora, and even those of us who can are often forced to discuss hypothetical networks or situations to avoid breaching NDAs, which then get ripped apart by the technical purists. > > Any attempt to force network managers to > > change addresses will simply ensure they install a nat to isolate > > themselves from that insanity. > > Were this the root cause of the problem I would agree. But it is not, > and so I don't. Make renumbering easier, so network managers needn't > object to it. Neither IPv4 nor IPv6 has any semblance of multi-router renumbering tools or protocols. Either we modify IPv6 to have wire protocols for distributing prefix information to routers, requiring scrapping much of vendors' control plane code, or we create some external tools to automate the renumbering process on today's code. Do you have any other general strategies for solving the problem? > It's clearly possible, since it has been done on the edge > once before. If you can manage such a transition in the end points you > can manage it in the core. The hard remains the interaction with DNS, > as far as I tell. Renumbering residential or SOHO customers' hosts and even CPE is doable today, but that's only the tip of the iceberg. > I am by far not the first to identify the problem. The solution space > cannot be rocket science, but my suspicion is that it does require > enrollment of some sort in order to really scale. Enrollment? S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 24 02:13:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4O9DOhs017919; Sat, 24 May 2003 02:13:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4O9DOrZ017918; Sat, 24 May 2003 02:13:24 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4O9DLhs017911 for ; Sat, 24 May 2003 02:13:21 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4O9Beuc005037 for ; Sat, 24 May 2003 02:11:40 -0700 (PDT) Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4O9Bbht007919 for ; Sat, 24 May 2003 03:11:37 -0600 (MDT) Received: from edison.cisco.com (edison.cisco.com [171.70.144.164]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h4O9BPFW001940; Sat, 24 May 2003 02:11:25 -0700 (PDT) Received: from cisco.com (llon1187-equant-dhcp95.cisco.com [10.49.249.95]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id CAA23582; Sat, 24 May 2003 02:11:22 -0700 (PDT) Message-ID: <3ECF3737.2000108@cisco.com> Date: Sat, 24 May 2003 02:11:19 -0700 From: Eliot Lear User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030507 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Sprunk CC: alh-ietf@tndh.net, "'Bob Hinden'" , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <135301c31c8e$766cee50$261e4104@eagleswings> <3EC76F0F.4080009@cisco.com> <20030523173931.F2841@defiant.dfw.nostrum.com> In-Reply-To: <20030523173931.F2841@defiant.dfw.nostrum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Stephen Sprunk wrote: > Neither IPv4 nor IPv6 has any semblance of multi-router renumbering > tools or protocols. Either we modify IPv6 to have wire protocols for > distributing prefix information to routers, requiring scrapping much > of vendors' control plane code, or we create some external tools to > automate the renumbering process on today's code. Do you have any > other general strategies for solving the problem? Yes (although I certainly didn't code it or think of it), and it's in Cisco's code as well- it's called prefix delegation. I believe the key problem is around how DNS gets updated. Eliot -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 26 01:15:37 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4Q8Fbhs023019; Mon, 26 May 2003 01:15:37 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4Q8FbCn023018; Mon, 26 May 2003 01:15:37 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4Q8FXhs023011 for ; Mon, 26 May 2003 01:15:33 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4Q8DxKw017570 for ; Mon, 26 May 2003 01:13:59 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4Q8Do3K009890 for ; Mon, 26 May 2003 02:13:54 -0600 (MDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h4Q8Dnv05303; Mon, 26 May 2003 04:13:49 -0400 (EDT) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h4Q8Dm246576; Mon, 26 May 2003 04:13:49 -0400 (EDT) Received: from newcastle.torrentnet.com (localhost [127.0.0.1]) by newcastle.torrentnet.com (8.12.6/8.11.6) with ESMTP id h4Q8DmXR029276; Mon, 26 May 2003 04:13:48 -0400 (EDT) (envelope-from slblake@newcastle.torrentnet.com) Received: (from slblake@localhost) by newcastle.torrentnet.com (8.12.6/8.12.6/Submit) id h4Q8Dl7O029275; Mon, 26 May 2003 04:13:47 -0400 (EDT) Date: Mon, 26 May 2003 04:13:47 -0400 From: Steven Blake To: Christian Huitema Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Message-ID: <20030526081347.GA28743@newcastle.torrentnet.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Fri, May 09, 2003 at 03:12:41PM -0700, Christian Huitema wrote: > Bob, > > I believe your draft is a step in the right direction, but I regret that > it does not support the "informal networking" scenario, in which unique > numbers are assigned to network segments without intervention of an > assignment authority. That scenario requires "self allocation". The > obvious constraint in any self-allocation scheme is that it must either > use a random number, or an reuse an already available identifier. > > We have been through this a couple of times, and we know that the random > number route is fraught with perils. The birthday paradox dictates that > the number of bits in the random number be at least twice the base 2 log > of the number of objects in the system. If we aim for 10 billion > networks, we would need at least 66 bits, and that does not sound very > practical. > > This leaves us with the obvious alternative, i.e. to reuse an existing > identifier. Two of those come to mind: IPv4 addresses, and IEEE 802 > identifiers. Sites who have an IPv4 address could use it to build a 6to4 > prefix, so we can leave that aside. But we could combine a unique IPv6 > prefix (e.g. FEC0::/16) and a 48 bit IEEE 802 number to build a unique > 64 bit link prefix. > > Such 64 bit prefixes would have many of the advantages of your global > site identifiers, except they would identify links, not sites. Most > important, they would not require an assignment authority. Out of those 10 billion networks, fewer than 0.4% will need more than 8 bits of internal subnetting (see [1]). So they can operate happily with a 56-bit globally unique local address prefix (and they can treat their /48 provider assignment as a /56 by appending eight zeros). The 56-bit prefix can be formed by appending an IEEE 802 address to a /8 format prefix (someone already proposed something similar to this). Networks needing more than 8 bits of internal subnetting will be able and willing to pay a registry. [1] A population of 10 billion can support at most ~40 million organizations with at least 256 members (assuming no overlap). 8 bits of internal subnetting would allow a subnet per individual. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 26 03:20:18 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4QAKHhs023532; Mon, 26 May 2003 03:20:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4QAKHTk023531; Mon, 26 May 2003 03:20:17 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4QAKEhs023524 for ; Mon, 26 May 2003 03:20:14 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4QAIdKw008924 for ; Mon, 26 May 2003 03:18:39 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4QAIVYU026451 for ; Mon, 26 May 2003 04:18:32 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4QAI6E24192; Mon, 26 May 2003 17:18:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4QA67q02873; Mon, 26 May 2003 17:06:08 +0700 (ICT) From: Robert Elz To: Steven Blake cc: Christian Huitema , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <20030526081347.GA28743@newcastle.torrentnet.com> References: <20030526081347.GA28743@newcastle.torrentnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 May 2003 17:06:07 +0700 Message-ID: <2871.1053943567@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 26 May 2003 04:13:47 -0400 From: Steven Blake Message-ID: <20030526081347.GA28743@newcastle.torrentnet.com> | Out of those 10 billion networks, fewer than 0.4% will need more than | 8 bits of internal subnetting (see [1]). I don't believe this for a second, but even assuming it were true: | So they can operate happily | with a 56-bit globally unique local address prefix (and they can | treat their /48 provider assignment as a /56 by appending eight zeros). This means you're constraining the way they number their internal subnets, and (effectively) meaning that instead of the /48 that everyone is promised (to allow movement from one topology dependent address prefix to another without needing to produce an entire new internal address plan) what will be available is just /56's. | The 56-bit prefix can be formed by appending an IEEE 802 address to a | /8 format prefix (someone already proposed something similar to this). Yes, it is not a good idea. First, it assumes that an IEEE MAC-48 (or EUI-48 - which are you intending be used?) is a stable identifier which each organisation owns for eternity - which it isn't, it is a transient thing which lasts as long as one owns the equipment to which that address was assigned. Otherwise, when someone else takes over the equipment (perhaps "rescues" it from a dumpster) they have the same 48 bit address as your organisation used for its numbering, which they may also choose to use as well. Attempting to take a number designed for one purpose and bend it into use in ways its design was never intended to meet is almost always a bad idea. Further, why would anyone assume that for the lifetime of IPv6, MAC addresses will necessarily continue to be in use? Network technologies change. Right now (for compatibility) everyone wants 48 bit addresses from the same space - but eventually someone will decide that the benefit isn't worth the cost, and simply abandon that - after which others will follow. The IEEE has already created its EUI-64's - one must certainly allow for the possibility that some future technology might use them. | Networks needing more than 8 bits of internal subnetting will be able Most likely, yes. | and willing to pay a registry. But why would anyone assume that? What is to be assigned here is a number. I can make one up easily. My number isn't visible to any of you, it is for my use alone (or for those with whom I make private arrangements). Why would anyone want to bother dealing with some bureaucracy for that? Some might, for the warm fuzzies it gives, others will see that there's nothing at all the registries can do to prevent anyone from using any number they want - hence the fuzzies aren't really all that warm. kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 26 04:26:14 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4QBQEhs023843; Mon, 26 May 2003 04:26:14 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4QBQES6023842; Mon, 26 May 2003 04:26:14 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4QBQAhs023835 for ; Mon, 26 May 2003 04:26:11 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4QBOaKw017734 for ; Mon, 26 May 2003 04:24:36 -0700 (PDT) Received: from d12lmsgate-2.de.ibm.com (d12lmsgate-2.de.ibm.com [194.196.100.235]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4QBOTYU020573 for ; Mon, 26 May 2003 05:24:30 -0600 (MDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate-2.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4QBOFUm044374 for ; Mon, 26 May 2003 13:24:19 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4QBNpHk243076 for ; Mon, 26 May 2003 13:23:54 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47060 from ; Mon, 26 May 2003 13:23:50 +0200 Message-Id: <3ED1F960.98BE6367@hursley.ibm.com> Date: Mon, 26 May 2003 13:24:16 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <20030526081347.GA28743@newcastle.torrentnet.com> <2871.1053943567@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk below... Robert Elz wrote: > > Date: Mon, 26 May 2003 04:13:47 -0400 > From: Steven Blake > Message-ID: <20030526081347.GA28743@newcastle.torrentnet.com> > > | Out of those 10 billion networks, fewer than 0.4% will need more than > | 8 bits of internal subnetting (see [1]). > > I don't believe this for a second, but even assuming it were true: > > | So they can operate happily > | with a 56-bit globally unique local address prefix (and they can > | treat their /48 provider assignment as a /56 by appending eight zeros). > > This means you're constraining the way they number their internal subnets, > and (effectively) meaning that instead of the /48 that everyone is promised > (to allow movement from one topology dependent address prefix to another > without needing to produce an entire new internal address plan) what > will be available is just /56's. > > | The 56-bit prefix can be formed by appending an IEEE 802 address to a > | /8 format prefix (someone already proposed something similar to this). > > Yes, it is not a good idea. First, it assumes that an IEEE MAC-48 > (or EUI-48 - which are you intending be used?) is a stable identifier > which each organisation owns for eternity - which it isn't, it is a transient > thing which lasts as long as one owns the equipment to which that address > was assigned. Otherwise, when someone else takes over the equipment > (perhaps "rescues" it from a dumpster) they have the same 48 bit address > as your organisation used for its numbering, which they may also choose to > use as well. > > Attempting to take a number designed for one purpose and bend it into use > in ways its design was never intended to meet is almost always a bad idea. > > Further, why would anyone assume that for the lifetime of IPv6, MAC addresses > will necessarily continue to be in use? Network technologies change. > Right now (for compatibility) everyone wants 48 bit addresses from the > same space - but eventually someone will decide that the benefit isn't > worth the cost, and simply abandon that - after which others will follow. > The IEEE has already created its EUI-64's - one must certainly allow for the > possibility that some future technology might use them. > > | Networks needing more than 8 bits of internal subnetting will be able > > Most likely, yes. > > | and willing to pay a registry. > > But why would anyone assume that? What is to be assigned here is > a number. I can make one up easily. My number isn't visible to any of > you, it is for my use alone (or for those with whom I make private > arrangements). Why would anyone want to bother dealing with some > bureaucracy for that? Some might, for the warm fuzzies it gives, others > will see that there's nothing at all the registries can do to prevent > anyone from using any number they want - hence the fuzzies aren't really > all that warm. I agree with kre completely up to this last point. It's more than warm fuzzies. It is correct that if I pay 10 Euros for a copy of the number "181:8008:7134", there is nothing to stop someone else using it. But in fact, if I get my copy of "181:8008:7134" from a registry that promises never to give anyone else a copy of it, then it's easy to decide who wins if I ever encounter a clash with another copy of "181:8008:7134". I wouldn't have a problem with a variant of Bob's proposal in which (for example) FC00::/8 is followed by a 40 bit ID allocated as Bob suggests, and FD00::/8 is followed by a user-assigned 40 bit ID. Then FC00::/7 would be the prefix for all limited-scope addresses. (The arguments why we should only cater for /48s are given in RFC 3177, and are a done deal as far as I'm concerned.) 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 Mon May 26 04:50:02 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4QBo1hs024096; Mon, 26 May 2003 04:50:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4QBo102024095; Mon, 26 May 2003 04:50:01 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4QBnwhs024088 for ; Mon, 26 May 2003 04:49:58 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4QBmNuc000990 for ; Mon, 26 May 2003 04:48:23 -0700 (PDT) Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4QBmG3K012614 for ; Mon, 26 May 2003 05:48:17 -0600 (MDT) Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h4QBmGD26603 for ; Mon, 26 May 2003 14:48:16 +0300 (EET DST) Received: from esebh004.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 26 May 2003 14:48:15 +0300 Received: from esebe004.NOE.Nokia.com ([172.21.138.44]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 26 May 2003 14:48:15 +0300 Received: from esebe023.NOE.Nokia.com ([172.21.138.115]) by esebe004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 26 May 2003 14:48:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Mon, 26 May 2003 14:48:14 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMjeeJK6zFz3JdqRcmkXll00LoiiAAAovwQ From: To: , X-OriginalArrivalTime: 26 May 2003 11:48:15.0251 (UTC) FILETIME=[B135B630:01C3237C] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4QBnwhs024089 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Brian, One small question: > I agree with kre completely up to this last point. It's more than > warm fuzzies. It is correct that if I pay 10 Euros for a copy of > the number "181:8008:7134", there is nothing to stop someone else using > it. But in fact, if I get my copy of "181:8008:7134" from a registry that > promises never to give anyone else a copy of it, then it's easy to decide > who wins if I ever encounter a clash with another copy of > "181:8008:7134". What is the decision making process, though? How do you 'prove' ownership of "181:8008:7134"? 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 May 26 05:44:38 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4QCichs024707; Mon, 26 May 2003 05:44:38 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4QCibcc024706; Mon, 26 May 2003 05:44:37 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4QCiYhs024699 for ; Mon, 26 May 2003 05:44:34 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4QCgxuc009687 for ; Mon, 26 May 2003 05:42:59 -0700 (PDT) Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4QCgr3K002598 for ; Mon, 26 May 2003 06:42:53 -0600 (MDT) Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h4QCgqT06778; Mon, 26 May 2003 08:42:52 -0400 (EDT) Received: from newcastle.torrentnet.com (newcastle.torrentnet.com [4.18.161.67]) by imperial.torrentnet.com (8.11.6p2/8.11.2) with ESMTP id h4QCgqo64054; Mon, 26 May 2003 08:42:52 -0400 (EDT) Received: from newcastle.torrentnet.com (localhost [127.0.0.1]) by newcastle.torrentnet.com (8.12.6/8.11.6) with ESMTP id h4QCgpXR029589; Mon, 26 May 2003 08:42:51 -0400 (EDT) (envelope-from slblake@newcastle.torrentnet.com) Received: (from slblake@localhost) by newcastle.torrentnet.com (8.12.6/8.12.6/Submit) id h4QCgpxa029588; Mon, 26 May 2003 08:42:51 -0400 (EDT) Date: Mon, 26 May 2003 08:42:50 -0400 From: Steven Blake To: Brian E Carpenter Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Message-ID: <20030526124250.GA29542@newcastle.torrentnet.com> References: <20030526081347.GA28743@newcastle.torrentnet.com> <2871.1053943567@munnari.OZ.AU> <3ED1F960.98BE6367@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ED1F960.98BE6367@hursley.ibm.com> User-Agent: Mutt/1.4i Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Mon, May 26, 2003 at 01:24:16PM +0200, Brian E Carpenter wrote: > Robert Elz wrote: > > > > Date: Mon, 26 May 2003 04:13:47 -0400 > > From: Steven Blake > > Message-ID: <20030526081347.GA28743@newcastle.torrentnet.com> > > > > | Out of those 10 billion networks, fewer than 0.4% will need more than > > | 8 bits of internal subnetting (see [1]). > > > > I don't believe this for a second, but even assuming it were true: > > > > | So they can operate happily > > | with a 56-bit globally unique local address prefix (and they can > > | treat their /48 provider assignment as a /56 by appending eight zeros). I should have said "the rest can ..." (note to Steve: don't send future e-mails at 4am as a cure for insomnia). > > This means you're constraining the way they number their internal subnets, > > and (effectively) meaning that instead of the /48 that everyone is promised > > (to allow movement from one topology dependent address prefix to another > > without needing to produce an entire new internal address plan) what > > will be available is just /56's. This doesn't follow. Do you think that if you numbered your SOHO network out of bits 48-55 instead of 56-63, that it would somehow stop your provider from only allocating you a /56, if they could get away with it? > > | The 56-bit prefix can be formed by appending an IEEE 802 address to a > > | /8 format prefix (someone already proposed something similar to this). > > > > Yes, it is not a good idea. First, it assumes that an IEEE MAC-48 > > (or EUI-48 - which are you intending be used?) is a stable identifier > > which each organisation owns for eternity - which it isn't, it is a transient > > thing which lasts as long as one owns the equipment to which that address > > was assigned. Otherwise, when someone else takes over the equipment > > (perhaps "rescues" it from a dumpster) they have the same 48 bit address > > as your organisation used for its numbering, which they may also choose to > > use as well. Please. 10/100 NICs are less that 10 euros now (I got one for free with my cable modem). I would just as happily copy the MAC address from one and grind it into dust with my heel as pay some registry. > > Attempting to take a number designed for one purpose and bend it into use > > in ways its design was never intended to meet is almost always a bad idea. > > > > Further, why would anyone assume that for the lifetime of IPv6, MAC addresses > > will necessarily continue to be in use? Network technologies change. > > Right now (for compatibility) everyone wants 48 bit addresses from the > > same space - but eventually someone will decide that the benefit isn't > > worth the cost, and simply abandon that - after which others will follow. > > The IEEE has already created its EUI-64's - one must certainly allow for the > > possibility that some future technology might use them. This assumes that IPv6 will outlive Ethernet. Big assumption ... A contemporary solution utilizing a contemporary, pre-established registry, doesn't preclude future solutions. > > | Networks needing more than 8 bits of internal subnetting will be able > > > > Most likely, yes. > > > > | and willing to pay a registry. > > > > But why would anyone assume that? What is to be assigned here is > > a number. I can make one up easily. My number isn't visible to any of > > you, it is for my use alone (or for those with whom I make private > > arrangements). Why would anyone want to bother dealing with some > > bureaucracy for that? Some might, for the warm fuzzies it gives, others > > will see that there's nothing at all the registries can do to prevent > > anyone from using any number they want - hence the fuzzies aren't really > > all that warm. Because these addresses are certain to wind up in the DNS. > I agree with kre completely up to this last point. It's more than > warm fuzzies. It is correct that if I pay 10 Euros for a copy of > the number "181:8008:7134", there is nothing to stop someone else using > it. But in fact, if I get my copy of "181:8008:7134" from a registry that > promises never to give anyone else a copy of it, then it's easy to decide > who wins if I ever encounter a clash with another copy of "181:8008:7134". > > I wouldn't have a problem with a variant of Bob's proposal in which > (for example) FC00::/8 is followed by a 40 bit ID allocated as Bob > suggests, and FD00::/8 is followed by a user-assigned 40 bit ID. > Then FC00::/7 would be the prefix for all limited-scope addresses. > > (The arguments why we should only cater for /48s are given in > RFC 3177, and are a done deal as far as I'm concerned.) The perfect is the enemy of the good (enough). Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Steven L. Blake Ericsson IP Infrastructure +1 919-472-9913 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 26 07:07:17 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4QE7Hhs026300; Mon, 26 May 2003 07:07:17 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4QE7Hte026299; Mon, 26 May 2003 07:07:17 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4QE7Dhs026292 for ; Mon, 26 May 2003 07:07:13 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4QE5cuc022553 for ; Mon, 26 May 2003 07:05:38 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4QE5VYU003136 for ; Mon, 26 May 2003 08:05:32 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4QE5EE16987; Mon, 26 May 2003 21:05:15 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4QDneq04163; Mon, 26 May 2003 20:49:41 +0700 (ICT) From: Robert Elz To: Steven Blake cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <20030526124250.GA29542@newcastle.torrentnet.com> References: <20030526124250.GA29542@newcastle.torrentnet.com> <20030526081347.GA28743@newcastle.torrentnet.com> <2871.1053943567@munnari.OZ.AU> <3ED1F960.98BE6367@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 26 May 2003 20:49:40 +0700 Message-ID: <4161.1053956980@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 26 May 2003 08:42:50 -0400 From: Steven Blake Message-ID: <20030526124250.GA29542@newcastle.torrentnet.com> | I should have said "the rest can ..." (note to Steve: don't send future | e-mails at 4am as a cure for insomnia). That was kind of obvious, certainly it was how I read your first message. | This doesn't follow. Do you think that if you numbered your SOHO network | out of bits 48-55 instead of 56-63, that it would somehow stop your provider | from only allocating you a /56, if they could get away with it? No. The question is whether we allow them to get away with it. If we have a numbering standard that (essentially) forces most sites (all but 0.4%...) to use what is effectively a /56, that's what people will start allocating, for all uses. Not a good idea. | Please. 10/100 NICs are less that 10 euros now (I got one for free with | my cable modem). I would just as happily copy the MAC address from one | and grind it into dust with my heel as pay some registry. Yes, so would I. But, in practice, I don't grind the things into dust, instead they get shoved in a drawer, and eventually someone says "I see you have 30 unused cards in that drawer, can I have one (or two)" and the one they pull out just happens to be the one that matters... | This assumes that IPv6 will outlive Ethernet. Big assumption ... No, it assumes that something else may exist during the lifetime of IPv6 - ethernet may still exist as well (probably will). The question is whether you can assume that everyone will necessarily have a MAC address (or be willing to go and buy one). | A contemporary solution utilizing a contemporary, pre-established registry, | doesn't preclude future solutions. It doesn't, unless it consumes the address space. | Because these addresses are certain to wind up in the DNS. Of course, but that's irrelevant. 1918 addresses end up in the DNS now. Yet (somehow) the net manages to keep on working. Those addresses don't work (for most people) - nor will any kind of unroutable IPv6 address we invent, when it gets found in the DNS, unique, or not. The only thing that unique prefixes achieve, is to prevent a packet ending up at the wrong node (someone else's version of the address). Given EUI-64's in the low 64 bits of most addresses, the chances of that are essentially 0 regardless of how ambiguous the prefix is. It simply isn't worth inventing lots of mechanism which pretends to fix this, it isn't a big enough problem to worry about (if a fix were very likely to work, and very cheap - in all senses - to implement, then sure, but for all suggestions seen here, neither is true). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Mon May 26 07:09:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4QE9Vhs026326; Mon, 26 May 2003 07:09:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4QE9ViY026325; Mon, 26 May 2003 07:09:31 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4QE9Shs026318 for ; Mon, 26 May 2003 07:09:28 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4QE7rKw017111 for ; Mon, 26 May 2003 07:07:53 -0700 (PDT) Received: from d12lmsgate.de.ibm.com (d12lmsgate.de.ibm.com [194.196.100.234]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4QE7l3K000835 for ; Mon, 26 May 2003 08:07:47 -0600 (MDT) Received: from d12relay02.de.ibm.com (d12relay02.de.ibm.com [9.165.215.23]) by d12lmsgate.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4QE7Wu9088730; Mon, 26 May 2003 16:07:36 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4QE75Hk075424; Mon, 26 May 2003 16:07:12 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA36202 from ; Mon, 26 May 2003 16:06:58 +0200 Message-Id: <3ED21F9D.BC0A3162@hursley.ibm.com> Date: Mon, 26 May 2003 16:07:25 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: john.loughney@nokia.com Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk john.loughney@nokia.com wrote: > > Hi Brian, > > One small question: > > > I agree with kre completely up to this last point. It's more than > > warm fuzzies. It is correct that if I pay 10 Euros for a copy of > > the number "181:8008:7134", there is nothing to stop someone else using > > it. But in fact, if I get my copy of "181:8008:7134" from a registry that > > promises never to give anyone else a copy of it, then it's easy to decide > > who wins if I ever encounter a clash with another copy of > > "181:8008:7134". > > What is the decision making process, though? How do you 'prove' ownership > of "181:8008:7134"? > That is indeed the argument for escrowing the identity of the "purchaser" of each number, as suggested in Bob's draft. But maybe it would cost more than 10 Euros to extract an entry from the escrow archive. 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 Mon May 26 23:56:42 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4R6ughs029148; Mon, 26 May 2003 23:56:42 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4R6ugSe029147; Mon, 26 May 2003 23:56:42 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4R6udhs029140 for ; Mon, 26 May 2003 23:56:39 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4R6t3uc000349 for ; Mon, 26 May 2003 23:55:04 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4R6sqYU013056 for ; Tue, 27 May 2003 00:54:56 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4R6sIE27546; Tue, 27 May 2003 13:54:25 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4R6gKM06552; Tue, 27 May 2003 13:42:24 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <3ED21F9D.BC0A3162@hursley.ibm.com> References: <3ED21F9D.BC0A3162@hursley.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 May 2003 13:42:19 +0700 Message-ID: <6550.1054017739@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Mon, 26 May 2003 16:07:25 +0200 From: Brian E Carpenter Message-ID: <3ED21F9D.BC0A3162@hursley.ibm.com> | > > it. But in fact, if I get my copy of "181:8008:7134" from a registry that | > > promises never to give anyone else a copy of it, then it's easy to decide | > > who wins if I ever encounter a clash with another copy of | > > "181:8008:7134". I should have asked this when you first said that, but how? You (quite correctly) said "a registry". If you go spend your 10 Euros on the number from one registry, and I go spend my 10 Euros from another registry, and they both issue us the same number, who wins, and why? How/why is one registry to be preferred over another? By what legal fiction would one organisation's right to sell numbers for money be able to be judged better than anothers? Note that this is quite different from "routable" numbers, where what is really being obtained (sold, leased, loaned, whatever) is the right to have the number installed in one particular instance of the global routing table - with most people preferring the one that everyone else is also using (which does nothing to prevent someone else selling the same right wrt some other routing table - that's just not likely to get very many customers). The same is true of domain names, where what is really being "sold" isn't the name, but the slot in the DNS zone file. But with numbers that are just numbers and no more than that? 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 May 27 00:27:57 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4R7Rvhs029451; Tue, 27 May 2003 00:27:57 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4R7RuH0029450; Tue, 27 May 2003 00:27:56 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4R7Rrhs029443 for ; Tue, 27 May 2003 00:27:53 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4R7QIKw016923 for ; Tue, 27 May 2003 00:26:18 -0700 (PDT) Received: from garlic.apnic.net (garlic.apnic.net [202.12.29.224]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4R7QCep015804 for ; Tue, 27 May 2003 01:26:13 -0600 (MDT) Received: from garlic.apnic.net (localhost [127.0.0.1]) by garlic.apnic.net (8.12.8p1/8.12.8) with ESMTP id h4R7Ppve006579; Tue, 27 May 2003 17:25:51 +1000 (EST) Received: (from ggm@localhost) by garlic.apnic.net (8.12.8p1/8.12.8) id h4R7PnwJ021308; Tue, 27 May 2003 17:25:49 +1000 (EST) Date: Tue, 27 May 2003 17:25:49 +1000 From: George Michaelson To: Robert Elz Cc: Brian E Carpenter , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Message-Id: <20030527172549.296d8379.ggm@apnic.net> In-Reply-To: <6550.1054017739@munnari.OZ.AU> References: <3ED21F9D.BC0A3162@hursley.ibm.com> <6550.1054017739@munnari.OZ.AU> Organization: APNIC Pty Ltd X-Mailer: Sylpheed version 0.9.0claws1 (GTK+ 1.2.10; i386-pc-netbsdelf1.6T) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 27 May 2003 13:42:19 +0700 Robert Elz wrote: > Date: Mon, 26 May 2003 16:07:25 +0200 > From: Brian E Carpenter > Message-ID: <3ED21F9D.BC0A3162@hursley.ibm.com> > > | > > it. But in fact, if I get my copy of "181:8008:7134" from a registry > that| > > promises never to give anyone else a copy of it, then it's easy to > decide| > > who wins if I ever encounter a clash with another copy of > | > > "181:8008:7134". > > I should have asked this when you first said that, but how? > > You (quite correctly) said "a registry". If you go spend your 10 Euros > on the number from one registry, and I go spend my 10 Euros from another > registry, and they both issue us the same number, who wins, and why? Nobody wins. If the registrys reflect current RIR, then this is not supposed to happen, the freedom to choose one or another should not permit them to both allocate the same space, and if they can, the system has a bug. Of course, for a non-RIR registry, I can't say. But, then, you maybe got a telephone number and not an Internet address. What did you ask for? > > How/why is one registry to be preferred over another? By what legal > fiction would one organisation's right to sell numbers for money be > able to be judged better than anothers? In the current legal fiction, there is some top-level co-ordination that guarantees the field of [0 .. 2**(129-1)] is divided up into non-overlapping unique spaces (albeit as a sparce matrix, but none-the-less semi-enforced) To all intents and purposes, ignoring policy differences, 'legally' routable 'integers' cannot overlap. Of course, there is no (binding) definition of 'legally' here, but by common convention, the ones coming down from IANA are disjoint spaces. They do not overlap, and even under flat /32 allocation, they will not overlap unless there is a BUG in common registry, which will be fixed on being detected. Now, if you posit some registry outside that agreement (eg, to hypothicate, lets imagine RF ID tags, or ENUM E.164 mappings), and by some awful stuffup that becomes an overlapping number space in the integer field, which has other behaviour, your question becomes more important. But, if we stick to "one IANA to bind them" then under current policy, and predictable grandfather clause "thats not allowed" is a valid answer. > > Note that this is quite different from "routable" numbers, where what > is really being obtained (sold, leased, loaned, whatever) is the right > to have the number installed in one particular instance of the global > routing table - with most people preferring the one that everyone else > is also using (which does nothing to prevent someone else selling the > same right wrt some other routing table - that's just not likely to get > very many customers). Yes. But one of the things here, is that current number registries go out of their way NOT to guarantee routability, but do go out of their way to guarantee uniqueness in the common space. And a non-trivial number of complaints to registry reflect peoples concerns to keep that true. (eg when ROUTING registries collide in routing assertions) > > The same is true of domain names, where what is really being "sold" isn't > the name, but the slot in the DNS zone file. No, that is different. It *looks* the same in this measure, but you must not collapse the side effects of a zonefile structured tree, with the integer space. They aren't the same for all purposes. > > But with numbers that are just numbers and no more than that? These are not 'just' numbers: we polish the inside arc of the zeroes by hand. There are numbers, there are unique numbers, and there are uniquely allocated numbers. The last kind is what you want I think. I try to tell my son there really is only one number "three" -If I call it into use to enumerate three pieces of fruit in the bowl, then some poor sod over in russia has to forget he has three bottles of vodka, and I don't know how many lumps of yellow sphere I have once an Icelander needs to count herring in triplicate. Not suprisingly, he thinks this is potty. But in Internet addressing space, there really is only one ::3 I think. And, this is a good thing. Or, its not the Internet. -George > > 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 > -------------------------------------------------------------------- -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 27 00:46:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4R7kuhs029689; Tue, 27 May 2003 00:46:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4R7ku0C029688; Tue, 27 May 2003 00:46:56 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4R7kqhs029678 for ; Tue, 27 May 2003 00:46:52 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4R7jIuc009407 for ; Tue, 27 May 2003 00:45:18 -0700 (PDT) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4R7jC4Z001335 for ; Tue, 27 May 2003 00:45:12 -0700 (PDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4R7iZlr058694 for ; Tue, 27 May 2003 09:45:03 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4R7eRCp056460 for ; Tue, 27 May 2003 09:40:27 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA47538 from ; Tue, 27 May 2003 09:40:26 +0200 Message-Id: <3ED31685.DAD1937B@hursley.ibm.com> Date: Tue, 27 May 2003 09:40:53 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 Cc: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <3ED21F9D.BC0A3162@hursley.ibm.com> <6550.1054017739@munnari.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: > > Date: Mon, 26 May 2003 16:07:25 +0200 > From: Brian E Carpenter > Message-ID: <3ED21F9D.BC0A3162@hursley.ibm.com> > > | > > it. But in fact, if I get my copy of "181:8008:7134" from a registry that > | > > promises never to give anyone else a copy of it, then it's easy to decide > | > > who wins if I ever encounter a clash with another copy of > | > > "181:8008:7134". > > I should have asked this when you first said that, but how? > > You (quite correctly) said "a registry". If you go spend your 10 Euros > on the number from one registry, and I go spend my 10 Euros from another > registry, and they both issue us the same number, who wins, and why? > > How/why is one registry to be preferred over another? By what legal > fiction would one organisation's right to sell numbers for money be > able to be judged better than anothers? Let's not restart the ICANN wars here over a trivium. Like any other registry, we make it unique and its authority would come from IANA. As Bob's draft says, safeguards are needed to ensure that if it makes a profit, it would be used for the public good. > > Note that this is quite different from "routable" numbers, where what > is really being obtained (sold, leased, loaned, whatever) is the right > to have the number installed in one particular instance of the global > routing table - with most people preferring the one that everyone else > is also using (which does nothing to prevent someone else selling the > same right wrt some other routing table - that's just not likely to get > very many customers). > > The same is true of domain names, where what is really being "sold" isn't > the name, but the slot in the DNS zone file. Well, I think we also have running code to prove that people value hanging off the unique root, since despite dire predictions we still seem to have a single namespace. > But with numbers that are just numbers and no more than that? What you get for 10 Euros is *only* the assurance that the same number hasn't been given to anyone else. If you think that isn't worth paying for, don't use the service (that's why I believe there should be a non-registry alternative). Another way to look at it is (using my example prefix) that IANA has delegated FC00::/8 to a particular registry, and that registry has chosen to sell non-aggregatable /48 prefixes for 10 Euros each. If they stay in business, fine; if they go bust, that's fine too. Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 01:33:58 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4R8Xwhs000070; Tue, 27 May 2003 01:33:58 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4R8XwxW000069; Tue, 27 May 2003 01:33:58 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4R8Xths000062 for ; Tue, 27 May 2003 01:33:55 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4R8WKKw028169 for ; Tue, 27 May 2003 01:32:20 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4R8W83K028310 for ; Tue, 27 May 2003 02:32:13 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4R8VQE05238; Tue, 27 May 2003 15:31:27 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4R8I1M08825; Tue, 27 May 2003 15:18:08 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <3ED31685.DAD1937B@hursley.ibm.com> References: <3ED31685.DAD1937B@hursley.ibm.com> <3ED21F9D.BC0A3162@hursley.ibm.com> <6550.1054017739@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 May 2003 15:18:01 +0700 Message-ID: <8823.1054023481@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 27 May 2003 09:40:53 +0200 From: Brian E Carpenter Message-ID: <3ED31685.DAD1937B@hursley.ibm.com> | Let's not restart the ICANN wars here over a trivium. I don't want to, but someone sure will. This is exactly why the WG declined to go down this path way way back when it was first being discussed (you may remember that it was me who proposed this, a long long time ago). | Like any other | registry, we make it unique and its authority would come from IANA. Sure, we can do that, as we do for the root zones for the DNS. But, we know that has competitors - they exist, even though the names they sell are useless for most practical purposes. The numbers we're talking about would be just as useful as any others, as they have no function beyond being numbers. Anyone can compete. What's more, with a number space between 38 and 45 bits (depending upon what eventually happens) lots of people would have lots of opportunity to get very rich, before anyone even notices that there are any duplications occurring. | As Bob's draft says, safeguards are needed to ensure that if it makes | a profit, it would be used for the public good. It has to make a (BIG) profit - as the price has to be set artificially high to prevent speculators simply claiming the entire number space, and then reselling it all later, once it is exhausted. Even with a 45 bit number space, that's entirely possible, if the numbers were sold at anything even approaching the real cost of doing so. This is exactly what will encourage others to shove in their oar. | Well, I think we also have running code to prove that people value | hanging off the unique root, since despite dire predictions we still | seem to have a single namespace. What running code? All the obvious examples are where the uniqueness is useful for something. | What you get for 10 Euros is *only* the assurance that the same | number hasn't been given to anyone else. But how could anyone offer that assurance, when someone else could be giving out the same number? Someone with just as much right as the IANA to allocate meaningless numbers... The only assurance that anyone could really offer is that they won't allocate the same number to anyone else. Is that worth the 10 Euros when someone else will offer the same thing for 5 ? | Another way to look at it is (using my example prefix) that IANA | has delegated FC00::/8 to a particular registry, and that | registry has chosen to sell non-aggregatable /48 prefixes | for 10 Euros each. If they stay in business, fine; if they go | bust, that's fine too. But why does Mr X care what IANA has allocated, he can sell /48's in FC00::/8 just as easily as the "particular registry" can, and most likely can sell them a lot cheaper, as he doesn't care if speculators buy out his whole supply (in fact, X would probably love that, and even offer a discount, at even 0.01 Euro's per number, 2^40 numbers adds up to a tidy sum!) As I said in an earlier message, if we want to pretend that the numbers are going to be unique, we have to have something that only works if they are in fact unique. Here there's nothing. 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 May 27 01:42:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4R8gOhs000264; Tue, 27 May 2003 01:42:24 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4R8gOUJ000263; Tue, 27 May 2003 01:42:24 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4R8gKhs000256 for ; Tue, 27 May 2003 01:42:21 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4R8ejKw029693 for ; Tue, 27 May 2003 01:40:45 -0700 (PDT) Received: from ratree.psu.ac.th ([202.12.73.3]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4R8eP3K000905 for ; Tue, 27 May 2003 02:40:27 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4R8dpE10782; Tue, 27 May 2003 15:39:51 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4R8QJM08849; Tue, 27 May 2003 15:26:24 +0700 (ICT) From: Robert Elz To: George Michaelson cc: Brian E Carpenter , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <20030527172549.296d8379.ggm@apnic.net> References: <20030527172549.296d8379.ggm@apnic.net> <3ED21F9D.BC0A3162@hursley.ibm.com> <6550.1054017739@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 27 May 2003 15:26:19 +0700 Message-ID: <8847.1054023979@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 27 May 2003 17:25:49 +1000 From: George Michaelson Message-ID: <20030527172549.296d8379.ggm@apnic.net> George, I suspect that you haven't been following the whole discussion... (aside from anything else, it certainly isn't the RIRs that it is currently expected will allocate these things - though, as in my reply to Brian, anyone could, and the RIRs might just as well, along with everyone else, and their dogs, cats, and other miscellaneous pets). | What did you ask for? A number. It isn't useful as an Internet address (by design), it is just a number. | Yes. But one of the things here, is that current number registries go out of | their way NOT to guarantee routability, OK, I was using shorthand terminology - with regular 'routable' addresses, the registries make known to whom the addresses are assigned, and then those who run the routing systems make use of this data (guaranteed or not by the registries, they do) to determine who gets to advertise routes to where. That's fine, and all very useful, and the same will continue for IPv6 as it has for IPv4 (hopefully with better aggregation). But that's not what we're talking about here - the issue is numbers that are deliberately not made available to the routing system, the identities of the registrants is (as proposed) not generally available to anyone. | No, that is different. It *looks* the same in this measure, but you must not | collapse the side effects of a zonefile structured tree, with the integer | space. They aren't the same for all purposes. Of course not - but for this example, they're both cases where the uniqueness of the number is useful for some purpose, other than being a unique number. In the current proposal, there's no other purpose. | There are numbers, there are unique numbers, and there are uniquely | allocated numbers. The last kind is what you want I think. The question is why does anyone want that? What's it useful for? 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 May 27 04:26:01 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4RBQ1hs000941; Tue, 27 May 2003 04:26:01 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4RBQ0Ku000940; Tue, 27 May 2003 04:26:00 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4RBPvhs000933 for ; Tue, 27 May 2003 04:25:57 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4RBOMuc013564 for ; Tue, 27 May 2003 04:24:22 -0700 (PDT) Received: from d12lmsgate-5.de.ibm.com (d12lmsgate-5.de.ibm.com [194.196.100.238]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4RBOFep027799 for ; Tue, 27 May 2003 05:24:16 -0600 (MDT) Received: from d12relay01.de.ibm.com (d12relay01.de.ibm.com [9.165.215.22]) by d12lmsgate-5.de.ibm.com (8.12.9/8.12.8) with ESMTP id h4RBO1lr060270 for ; Tue, 27 May 2003 13:24:03 +0200 Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay01.de.ibm.com (8.12.9/NCO/VER6.5) with SMTP id h4RBLwCp072562 for ; Tue, 27 May 2003 13:22:01 +0200 Received: from dhcp22-66.zurich.ibm.com by ochsehorn.zurich.ibm.com (AIX 4.3/UCB 5.64/4.03) id AA20048 from ; Tue, 27 May 2003 13:21:56 +0200 Message-Id: <3ED34A6F.161477F8@hursley.ibm.com> Date: Tue, 27 May 2003 13:22:23 +0200 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en,fr,de Mime-Version: 1.0 To: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <3ED31685.DAD1937B@hursley.ibm.com> <3ED21F9D.BC0A3162@hursley.ibm.com> <6550.1054017739@munnari.OZ.AU> <8823.1054023481@munnari.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: ... (deleted lots of agree-to-differ stuff) ... > As I said in an earlier message, if we want to pretend that the numbers > are going to be unique, we have to have something that only works if > they are in fact unique. Here there's nothing. Yes there is. As Bob Moskowitz discovered ages ago on ANX, and others have discovered since, you can't operate VPNs among a set of users of Net 10 in any reasonable way, and of course the same applies to a set of users of FEC0::/10. The problem goes away with unique /48s under FC00::/8. Now, as a pragmatist, I would probably settle for a pseudo-random and probably-unique /48, but not everybody will. I can just imagine a phone call in which I recommend to IBM's chief network architect to use address space that *probably* nobody else is using. Do other people think we need a guaranteed-unique mechanism for limited-scope addresses, or is probably-unique enough? Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 04:58:28 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4RBwShs001188; Tue, 27 May 2003 04:58:28 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4RBwS8B001187; Tue, 27 May 2003 04:58:28 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4RBwOhs001180 for ; Tue, 27 May 2003 04:58:24 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4RBunuc018287 for ; Tue, 27 May 2003 04:56:49 -0700 (PDT) Received: from garlic.apnic.net (c18652.rochd1.qld.optusnet.com.au [211.28.236.247]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4RBugLv005655 for ; Tue, 27 May 2003 04:56:43 -0700 (PDT) Received: from garlic.apnic.net (localhost [127.0.0.1]) by garlic.apnic.net (8.12.8p1/8.12.8) with ESMTP id h4RBuAEQ000780; Tue, 27 May 2003 21:56:10 +1000 (EST) Received: (from ggm@localhost) by garlic.apnic.net (8.12.8p1/8.12.8) id h4RBu3IV000683; Tue, 27 May 2003 21:56:03 +1000 (EST) Date: Tue, 27 May 2003 21:56:02 +1000 From: George Michaelson To: Robert Elz Cc: Brian E Carpenter , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Message-Id: <20030527215602.7adf2cfb.ggm@apnic.net> In-Reply-To: <8847.1054023979@munnari.OZ.AU> References: <20030527172549.296d8379.ggm@apnic.net> <3ED21F9D.BC0A3162@hursley.ibm.com> <6550.1054017739@munnari.OZ.AU> <8847.1054023979@munnari.OZ.AU> Organization: APNIC Pty Ltd X-Mailer: Sylpheed version 0.9.0claws1 (GTK+ 1.2.10; i386-pc-netbsdelf1.6T) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Tue, 27 May 2003 15:26:19 +0700 Robert Elz wrote: > Date: Tue, 27 May 2003 17:25:49 +1000 > From: George Michaelson > Message-ID: <20030527172549.296d8379.ggm@apnic.net> > > George, I suspect that you haven't been following the whole discussion... fair call. I do have ipng archives here in front of me, but I dived in. > (aside from anything else, it certainly isn't the RIRs that it is > currently expected will allocate these things - though, as in my reply > to Brian, anyone could, and the RIRs might just as well, along with > everyone else, and their dogs, cats, and other miscellaneous pets). But like I said, the current experience shows that excluding routability we KNOW we can use a unitary-rooted process to divide the number field into disjoint pools to allocate from. We know this works, and although its a self-supporting circular logic, we mutually trust it and exclude private allocations into the same space precicely because uniqueness appears to be good, and maintainable. (and one suspects things like so-bgp or s-bgp, if they happen, will only tend to increase enforced/trust state in routing but thats another issue...) I didn't say 'we will do it' but I did try to say the RIR do stand as an existence proof. Man-and-his-dog selling snake oil leads to more bad scenarios than requirement to follow known working practices here surely? > > | What did you ask for? > > A number. It isn't useful as an Internet address (by design), it > is just a number. numbers have properties. exclude ordering, or any properties on the bitmask and apart from uniqueness, there isn't much left. are there enough prime numbers in the space we can all have one to seed our own crypto? I'd say not in the 'relatively large' end of the spectrum. I really think either we do value uniqueness, and so perpetuate it, or not. Hmm. I'll go with perpetuating it for now if thats ok. > > | Yes. But one of the things here, is that current number registries go out > of| their way NOT to guarantee routability, > > OK, I was using shorthand terminology - with regular 'routable' addresses, > the registries make known to whom the addresses are assigned, and then > those who run the routing systems make use of this data (guaranteed or > not by the registries, they do) to determine who gets to advertise routes > to where. That's fine, and all very useful, and the same will continue > for IPv6 as it has for IPv4 (hopefully with better aggregation). > > But that's not what we're talking about here - the issue is numbers that > are deliberately not made available to the routing system, the identities > of the registrants is (as proposed) not generally available to anyone. But the property of uniqueness is preserved, if the processes followed in allocation preserve the same behaviours, of making RIR look like one functional body, in as much as a shared pool is allocated with (at least) one useful condition: ie uniqueness. > > | No, that is different. It *looks* the same in this measure, but you must > not| collapse the side effects of a zonefile structured tree, with the > integer| space. They aren't the same for all purposes. > > Of course not - but for this example, they're both cases where the > uniqueness of the number is useful for some purpose, other than being > a unique number. In the current proposal, there's no other purpose. Come on. We all know technology has failings. routers are going to have to be configured here. If I heard the sense of the room right at the last two sessions of IPNG-like discussions at IETF right, people want to be able to know that their non-routed addresses aren't masking somebody elses routables, if non-routables are going to exist. They want to be able to apply sane, simple logic to the decision on what to do. > > | There are numbers, there are unique numbers, and there are uniquely > | allocated numbers. The last kind is what you want I think. > > The question is why does anyone want that? What's it useful for? Peace of mind. At a lowish cost of adopting processes broadly in line with what we already know we can do. Plus, the ability to defer a decision to change ones mind later on. -George > > kre -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 27 12:01:52 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4RJ1qhs002231; Tue, 27 May 2003 12:01:52 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4RJ1qHE002230; Tue, 27 May 2003 12:01:52 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4RJ1nhs002223 for ; Tue, 27 May 2003 12:01:49 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4RJ0DKw008896 for ; Tue, 27 May 2003 12:00:13 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4RJ07ep006912 for ; Tue, 27 May 2003 13:00:08 -0600 (MDT) 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 MAA01629; Tue, 27 May 2003 12:00:07 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4RJ05o27686; Tue, 27 May 2003 12:00:05 -0700 X-mProtect: <200305271900> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpd7sJ8He; Tue, 27 May 2003 12:00:03 PDT Message-Id: <4.3.2.7.2.20030527112512.0389cc98@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 27 May 2003 11:59:05 -0700 To: Brian E Carpenter From: Bob Hinden Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Cc: ipng@sunroof.eng.sun.com In-Reply-To: <3ED34A6F.161477F8@hursley.ibm.com> References: <3ED31685.DAD1937B@hursley.ibm.com> <3ED21F9D.BC0A3162@hursley.ibm.com> <6550.1054017739@munnari.OZ.AU> <8823.1054023481@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Brian, At 04:22 AM 5/27/2003, Brian E Carpenter wrote: >Now, as a pragmatist, I would probably settle for a pseudo-random >and probably-unique /48, but not everybody will. I can just imagine a >phone call in which I recommend to IBM's chief network architect to use >address space that *probably* nobody else is using. > >Do other people think we need a guaranteed-unique mechanism >for limited-scope addresses, or is probably-unique enough? My take on the discussion is that we need both. There are organizations who prefer to go to a registry to get some guarantee of uniqueness and others who prefer to generate a prefix themselves. Your earlier suggestion of >I wouldn't have a problem with a variant of Bob's proposal in which >(for example) FC00::/8 is followed by a 40 bit ID allocated as Bob >suggests, and FD00::/8 is followed by a user-assigned 40 bit ID. >Then FC00::/7 would be the prefix for all limited-scope addresses. appears to be a reasonable approach where the 40 bit ID under FD00:/8 would be selected by running an algorithm that would have to be specified. There is a clear tradeoff between a longer ID (to allow for better random numbers or MAC addresses) and the size of the subnet field. Before revising the draft, I would prefer to hear from more people on these tradeoffs. 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 Tue May 27 12:35:50 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4RJZohs002482; Tue, 27 May 2003 12:35:50 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4RJZoB3002481; Tue, 27 May 2003 12:35:50 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4RJZkhs002474 for ; Tue, 27 May 2003 12:35:46 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4RJYBKw026392 for ; Tue, 27 May 2003 12:34:11 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4RJY5Lv017560 for ; Tue, 27 May 2003 12:34:05 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) by uillean.fuaim.com (8.11.6/8.11.6) with ESMTP id h4RJY5N30314; Tue, 27 May 2003 12:34:05 -0700 Received: from innovationslab.net ([63.109.132.2]) (authenticated bits=0) by clairseach.fuaim.com (8.12.8/8.12.8) with ESMTP id h4RK2Yp0017423 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 27 May 2003 13:02:36 -0700 Message-ID: <3ED3BDAA.5070105@innovationslab.net> Date: Tue, 27 May 2003 15:34:02 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bob Hinden CC: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses References: <3ED31685.DAD1937B@hursley.ibm.com> <3ED21F9D.BC0A3162@hursley.ibm.com> <6550.1054017739@munnari.OZ.AU> <8823.1054023481@munnari.OZ.AU> <4.3.2.7.2.20030527112512.0389cc98@mailhost.iprg.nokia.com> In-Reply-To: <4.3.2.7.2.20030527112512.0389cc98@mailhost.iprg.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Hinden wrote: > Brian, > > At 04:22 AM 5/27/2003, Brian E Carpenter wrote: > >> Now, as a pragmatist, I would probably settle for a pseudo-random >> and probably-unique /48, but not everybody will. I can just imagine a >> phone call in which I recommend to IBM's chief network architect to use >> address space that *probably* nobody else is using. >> >> Do other people think we need a guaranteed-unique mechanism >> for limited-scope addresses, or is probably-unique enough? > > > My take on the discussion is that we need both. There are organizations > who prefer to go to a registry to get some guarantee of uniqueness and > others who prefer to generate a prefix themselves. I agree. There are justifications for both approaches. > > Your earlier suggestion of > >> I wouldn't have a problem with a variant of Bob's proposal in which >> (for example) FC00::/8 is followed by a 40 bit ID allocated as Bob >> suggests, and FD00::/8 is followed by a user-assigned 40 bit ID. >> Then FC00::/7 would be the prefix for all limited-scope addresses. > > > appears to be a reasonable approach where the 40 bit ID under FD00:/8 > would be selected by running an algorithm that would have to be specified. Yes. Not a hard algorithm to come up with either. > > There is a clear tradeoff between a longer ID (to allow for better > random numbers or MAC addresses) and the size of the subnet field. > > Before revising the draft, I would prefer to hear from more people on > these tradeoffs. I like Brian C.'s alternative suggestion. Regards, Brian -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Tue May 27 12:40:12 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4RJeChs002515; Tue, 27 May 2003 12:40:12 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4RJeBcP002514; Tue, 27 May 2003 12:40:11 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4RJe8hs002507 for ; Tue, 27 May 2003 12:40:08 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4RJcWuc002697 for ; Tue, 27 May 2003 12:38:32 -0700 (PDT) Received: from bowl.fysh.org ([195.167.170.152]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4RJcRht011822 for ; Tue, 27 May 2003 13:38:27 -0600 (MDT) Received: from zefram by bowl.fysh.org with local (Exim 3.35 #1 (Debian)) id 19KkH6-00027P-00; Tue, 27 May 2003 20:38:20 +0100 Date: Tue, 27 May 2003 20:38:20 +0100 To: Bob Hinden Cc: Brian E Carpenter , ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Message-ID: <20030527193820.GA6652@fysh.org> References: <3ED31685.DAD1937B@hursley.ibm.com> <3ED21F9D.BC0A3162@hursley.ibm.com> <6550.1054017739@munnari.OZ.AU> <8823.1054023481@munnari.OZ.AU> <4.3.2.7.2.20030527112512.0389cc98@mailhost.iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20030527112512.0389cc98@mailhost.iprg.nokia.com> User-Agent: Mutt/1.3.28i From: Zefram Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Bob Hinden wrote: >There is a clear tradeoff between a longer ID (to allow for better random >numbers or MAC addresses) and the size of the subnet field. > >Before revising the draft, I would prefer to hear from more people on these >tradeoffs. Although I was one of those that suggested a technique that would generate /56 prefixes, I see great value in arranging for /48 prefixes where possible, for uniformity with RFC3177. For randomly-generated addresses (both centrally allocated and individually allocated), an 8-bit format prefix and 40 bits of randomness seems like a good tradeoff. 40 bits seems to be about the amount of entropy we're aiming at, and a handful of bits either way makes no difference. An 8-bit format prefix is not too wasteful of address space. The case for which I suggested /56 prefixes was generating a prefix from a MAC-48. In that case, with 46 effective bits of identifier to fit into the prefix, we clearly can't get a /48. It seems like a valuable technique, but would have to be an exception to the /48 rule. Of course, any site needing more than eight bits of subnet ID is likely to have many MAC-48s to play with if they have any at all. -zefram -- Andrew Main (Zefram) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 28 05:06:05 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4SC65hs006669; Wed, 28 May 2003 05:06:05 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4SC64l3006668; Wed, 28 May 2003 05:06:04 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4SC61hs006661 for ; Wed, 28 May 2003 05:06:01 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4SC4Ouc028305 for ; Wed, 28 May 2003 05:04:24 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4SC44Lv001575 for ; Wed, 28 May 2003 05:04:05 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4SC3wP04334; Wed, 28 May 2003 19:03:58 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4SBoEV16150; Wed, 28 May 2003 18:50:16 +0700 (ICT) From: Robert Elz To: Brian E Carpenter cc: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <3ED34A6F.161477F8@hursley.ibm.com> References: <3ED34A6F.161477F8@hursley.ibm.com> <3ED31685.DAD1937B@hursley.ibm.com> <3ED21F9D.BC0A3162@hursley.ibm.com> <6550.1054017739@munnari.OZ.AU> <8823.1054023481@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 May 2003 18:50:14 +0700 Message-ID: <16148.1054122614@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 27 May 2003 13:22:23 +0200 From: Brian E Carpenter Message-ID: <3ED34A6F.161477F8@hursley.ibm.com> | Yes there is. As Bob Moskowitz discovered ages ago on ANX, and others have | discovered since, you can't operate VPNs among a set of users of Net 10 | in any reasonable way, Of course not. | and of course the same applies to a set of users of FEC0::/10. It applies to a set of users under FEC0::/48, yes, certainly. Whether it applies to FEC0::/10 or not depends upon what the users have done with the other 38 bits. | The problem goes away with unique /48s under FC00::/8. It would, if they were unique. | Now, as a pragmatist, I would probably settle for a pseudo-random | and probably-unique /48, but not everybody will. Anyone who doesn't is deluding themselves, as that's all they're going to get, without some method of verifying the uniqueness (some that everyone must use for the number to be useful). | I can just imagine a phone call in which I recommend to IBM's chief | network architect to use address space that *probably* nobody else is using. How are you ever going to be able to do better. Or rather, if you like, once IBM gets such a number, you leak it to me, and then I'll guarantee that someone else is using it... What you're getting here is really just some kind of belief that if there is a conflict, you have some justification for claiming that my version of 3 is the one true 3, and everyone else is a fraudulent copy (and in the case above with IBM, mine would be, obviously, but not necessarily all others). | Do other people think we need a guaranteed-unique mechanism | for limited-scope addresses, or is probably-unique enough? What people want is nice. How you actually get a a guaranteed-unique number is another question, and one I am still looking for an answer to. That is, without some means of ensuring the number is unique, which to me, means making use of the uniqueness in some way (ie: non-unique numbers don't work usefully) I can't see any method at all of actually guaranteeing uniqueness, as anyone can, maliciously or not, simply make up any number they like, and use it. And the number they make up might be the same number as the number you paid for. And really, their right to make up numbers is no less than anyone else's (including IANA, ICANN, ...). kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 28 05:19:00 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4SCJ0hs006868; Wed, 28 May 2003 05:19:00 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4SCJ0xT006867; Wed, 28 May 2003 05:19:00 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4SCIvhs006860 for ; Wed, 28 May 2003 05:18:57 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4SCHJKw010391 for ; Wed, 28 May 2003 05:17:19 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4SCH8Lv007858 for ; Wed, 28 May 2003 05:17:13 -0700 (PDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4SCH6P04921; Wed, 28 May 2003 19:17:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4SC3EV16172; Wed, 28 May 2003 19:03:16 +0700 (ICT) From: Robert Elz To: George Michaelson cc: Brian E Carpenter , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <20030527215602.7adf2cfb.ggm@apnic.net> References: <20030527215602.7adf2cfb.ggm@apnic.net> <20030527172549.296d8379.ggm@apnic.net> <3ED21F9D.BC0A3162@hursley.ibm.com> <6550.1054017739@munnari.OZ.AU> <8847.1054023979@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 May 2003 19:03:14 +0700 Message-ID: <16170.1054123394@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Tue, 27 May 2003 21:56:02 +1000 From: George Michaelson Message-ID: <20030527215602.7adf2cfb.ggm@apnic.net> | But like I said, the current experience shows that excluding routability | we KNOW we can use a unitary-rooted process to divide the number field | into disjoint pools to allocate from. Of course we can, that we can do that isn't the question. The question here is why I, as a customer, would go pay you 10 Euros for a number allocated this way, when "Joe's cheap numbers" is selling them at 1000 for 1 Euro ? What is special about a number allocated by the "blessed agency" in the case we're discussing? | numbers have properties. exclude ordering, or any properties on the | bitmask and apart from uniqueness, there isn't much left. The only property that actually matters to the numbers in question, the only one that the vast majority of people will ever care about, is that it is N bits (for some N not yet fully decided, nor does it matter much what N it is). Nothing else really matters for most organisations. Uniqueness is irrelevant for all but a few, and even those few only really need the number to be unique among their peers (and perhaps their peers) that is, perhaps a few thousand sites, maybe 100K, which a random number in a large enough N bits will almost certainly provide. Don't misunderstand me, I'd like and prefer unique numbers. But I won't be a party to telling people that's what we're providing, unless we really are providing numbers that are unique (with at least a very high degree of confidence). For a "central allocation" method of making them unique, that means we need a high degree of confidence that the one central authority is the only one that can ever exist (there needs to be a reason for that). | But the property of uniqueness is preserved, if the processes followed in | allocation preserve the same behaviours, of making RIR look like one | functional body, in as much as a shared pool is allocated with (at least) | one useful condition: ie uniqueness. George, I know it can be done. The question is why anyone would bother to do it - or more correctly, why *everyone* would bother to do it. All it takes is one exception, and uniqueness is gone. | If I heard the sense of the room right at the last two sessions | of IPNG-like discussions at IETF right, people want to be able to know that | their non-routed addresses aren't masking somebody elses routables, Yes, of course, that's important. But all that takes (and what these various slightly different proposals all provide) is a common prefix that says "no routable addresses in this block". So, you can take that as a given. My non-routable address doesn't need to differ from your non-routable address for this to work, unless we happen to want to use them to communicate. | > The question is why does anyone want that? What's it useful for? | Peace of mind. But from where does that come, when you know that anyuone else who likes can simply use the same number you are using, accidentally, or maliciously, and not suffer at all because of that (nor for that matter, do you suffer). | Plus, the ability to defer a decision to change ones mind later on. Change one's mind about what? kre -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 28 05:45:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4SCjjhs007158; Wed, 28 May 2003 05:45:46 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4SCjjlq007157; Wed, 28 May 2003 05:45:45 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4SCjghs007150 for ; Wed, 28 May 2003 05:45:42 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Central.Sun.COM [129.147.5.36]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4SCi4Kw014352 for ; Wed, 28 May 2003 05:44:04 -0700 (PDT) Received: from garlic.apnic.net (c18652.rochd1.qld.optusnet.com.au [211.28.236.247]) by brmea-mail-4.sun.com (8.12.9/8.12.9) with ESMTP id h4SChvht001255 for ; Wed, 28 May 2003 06:43:58 -0600 (MDT) Received: from garlic.apnic.net (localhost [127.0.0.1]) by garlic.apnic.net (8.12.8p1/8.12.8) with ESMTP id h4SChJxJ019985; Wed, 28 May 2003 22:43:19 +1000 (EST) Received: (from ggm@localhost) by garlic.apnic.net (8.12.8p1/8.12.8) id h4SCgqW9002410; Wed, 28 May 2003 22:42:52 +1000 (EST) Date: Wed, 28 May 2003 22:42:52 +1000 From: George Michaelson To: Robert Elz Cc: Brian E Carpenter , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Message-Id: <20030528224252.471dc24f.ggm@apnic.net> In-Reply-To: <16170.1054123394@munnari.OZ.AU> References: <20030527215602.7adf2cfb.ggm@apnic.net> <20030527172549.296d8379.ggm@apnic.net> <3ED21F9D.BC0A3162@hursley.ibm.com> <6550.1054017739@munnari.OZ.AU> <8847.1054023979@munnari.OZ.AU> <16170.1054123394@munnari.OZ.AU> Organization: APNIC Pty Ltd X-Mailer: Sylpheed version 0.9.0claws1 (GTK+ 1.2.10; i386-pc-netbsdelf1.6T) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 28 May 2003 19:03:14 +0700 Robert Elz wrote: > Date: Tue, 27 May 2003 21:56:02 +1000 > From: George Michaelson > Message-ID: <20030527215602.7adf2cfb.ggm@apnic.net> > > | But like I said, the current experience shows that excluding routability > | we KNOW we can use a unitary-rooted process to divide the number field > | into disjoint pools to allocate from. > > Of course we can, that we can do that isn't the question. The question > here is why I, as a customer, would go pay you 10 Euros for a number > allocated this way, when "Joe's cheap numbers" is selling them at 1000 > for 1 Euro ? What is special about a number allocated by the "blessed > agency" in the case we're discussing? Strong admission checks into routing are going to make Joe's numbers less useful. Rhetorical questions aside, minor flaws don't stop people using systems which are 'modelled' as being perfect. Whats special is that the agency is seen to operate in a public policy/governance space, to not do what Joe does. Whats special is that for a larger space of routing, the behaviours work 'well enough'. If you want to deliberately go and break the global routing cloud you can do that. Sooner or later, you wil be caught. People even went and showed they could run alternate roots in DNS. But your punters, people who bought a thousand from Joe for $10 instead of leasing one from an RIR for $100, only do that once, if they fall into a hole fast enough. In this matter, there are no bargains. If you seek to avoid or buck the system, you will pay a cost, in some measure. > > Nothing else really matters for most organisations. Uniqueness is > irrelevant for all but a few, and even those few only really need > the number to be unique among their peers (and perhaps their peers) > that is, perhaps a few thousand sites, maybe 100K, which a random > number in a large enough N bits will almost certainly provide. Yes. And, if you select a suitable prefix, I don't see any reason not to say "this prefix is for sites to use random selection methods to get 'nearly unique' addresses, if you want that. People who don't want to see this can filter it! > > Don't misunderstand me, I'd like and prefer unique numbers. But I > won't be a party to telling people that's what we're providing, unless > we really are providing numbers that are unique (with at least a very > high degree of confidence). For a "central allocation" method of making > them unique, that means we need a high degree of confidence that the > one central authority is the only one that can ever exist (there needs > to be a reason for that). We appear to have reasonably high confidence in that process already. We appear to have an administrative process for complaints when it breaks down, as well. I think claiming the percentage of bad against good can only get worse would be true, but is that enough to decide to do something else? depends on the slope of the line... > > | But the property of uniqueness is preserved, if the processes followed in > | allocation preserve the same behaviours, of making RIR look like one > | functional body, in as much as a shared pool is allocated with (at least) > | one useful condition: ie uniqueness. > > George, I know it can be done. The question is why anyone would bother > to do it - or more correctly, why *everyone* would bother to do it. > All it takes is one exception, and uniqueness is gone. No. this is like 'relatively prime' -if you are *reductionist* then you can't run an Internet anyway. one exception doesn't break 'practical' uniqueness. Nothing can stop somebody sniffing the wire, seeing an address, and deciding to try and add routes against it. even secured BGP won't be 'total' in that respect. We've been living with 'good enough' for a long time, in a lot of different fields, not just Internet/Networking. How many more than one does it take to make uniqueness practically useless? I think a HELL of a lot more. > > | If I heard the sense of the room right at the last two sessions > | of IPNG-like discussions at IETF right, people want to be able to know > that| their non-routed addresses aren't masking somebody elses routables, > > Yes, of course, that's important. But all that takes (and what these > various slightly different proposals all provide) is a common prefix > that says "no routable addresses in this block". So, you can take > that as a given. My non-routable address doesn't need to differ from > your non-routable address for this to work, > unless we happen to want to use them to communicate. Big unless. Very big unless. Now add back VPNs. one block+NAT is less useful than globally unique. its not about single point decisions. If 2 reasons exist making it useful isn't that enough? When you argue against one, does the other disappear? > > | > The question is why does anyone want that? What's it useful for? > | Peace of mind. > > But from where does that come, when you know that anyuone else who likes > can simply use the same number you are using, accidentally, or maliciously, > and not suffer at all because of that (nor for that matter, do you suffer). Well increasing trust in the routing cloud is a bigger problem. You need an identity check on the address, out of band, or some other mechanism like strong admission control to the routing cloud. Both of which either exist, or are in planning. I think a significant number of people continue(d) to use Sun's address space precisely because there is huge locality of reference in most of the network, and when there isn't the access path is mediated (proxies, caches, indirect access methods, name-to-address shifts) anyway. People re-using other address would see local service fine, and have a small percentage of problem in the wider net which was inexplicable unreachables (for them) and find ways round them (like proxies) or else debug it, and then fix their addressing model. > > | Plus, the ability to defer a decision to change ones mind later on. > > Change one's mind about what? About needing uniqueness. You can leave the egg whole and break it later, but its harder to glue it back together if you break it first and change your mind... -George > > kre -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 28 09:31:56 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4SGVuhs008040; Wed, 28 May 2003 09:31:56 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4SGVuLu008039; Wed, 28 May 2003 09:31:56 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4SGVqhs008032 for ; Wed, 28 May 2003 09:31:52 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4SGUFuc000244 for ; Wed, 28 May 2003 09:30:15 -0700 (PDT) Received: from tndh.net (evrtwa1-ar8-4-65-019-240.evrtwa1.dsl-verizon.net [4.65.19.240]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4SGU9YU008811 for ; Wed, 28 May 2003 10:30:09 -0600 (MDT) Received: from eagleswings (127.0.0.1) by library with [XMail 1.10 (Win32/Ix86) ESMTP Server] id for from ; Wed, 28 May 2003 09:30:03 -0700 Reply-To: From: "Tony Hain" To: Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses Date: Wed, 28 May 2003 09:29:59 -0700 Message-ID: <011101c32536$61cccfa0$56144104@eagleswings> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20030528224252.471dc24f.ggm@apnic.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4SGVrhs008033 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk George Michaelson wrote: > ... > > What is special about a number allocated by > the "blessed > > agency" in the case we're discussing? > > Strong admission checks into routing are going to make Joe's > numbers less useful. Admission checks by which authority? Remember we are talking about prefixes which are defined to not exist in the global public routing system. That makes them completely useful between private routing peers, until there is a duplication. > Rhetorical questions aside, minor flaws > don't stop people using systems which are 'modelled' as being > perfect. Whats special is that the agency is seen to operate > in a public policy/governance space, to not do what Joe does. The IETF does not have a good track record in the policy space. The numerical registry space is better, but not perfect (how many port numbers were assigned after the fact???). I believe the root of kre's concern is that we don't approach the governance space with the appropriate attitude. We need to admit up front that numbers will never be absolutely unique, and that some people will want to make up their own for completely random reasons. All we can do is define a single rooted registry with a to-be-defined conflict resolution process, and a space for those who want to do their own thing. We must not define the business aspects of the registry. Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Wed May 28 12:45:32 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4SJjWhs008763; Wed, 28 May 2003 12:45:32 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9/Submit) id h4SJjVj4008762; Wed, 28 May 2003 12:45:31 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.9+Sun/8.12.9) with ESMTP id h4SJjShs008755 for ; Wed, 28 May 2003 12:45:28 -0700 (PDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4SJhUuc012011 for ; Wed, 28 May 2003 12:43:30 -0700 (PDT) Received: from garlic.apnic.net (c18652.rochd1.qld.optusnet.com.au [211.28.236.247]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4SJhOLv022451 for ; Wed, 28 May 2003 12:43:25 -0700 (PDT) Received: from garlic.apnic.net (localhost [127.0.0.1]) by garlic.apnic.net (8.12.8p1/8.12.8) with ESMTP id h4SJh9xJ020091; Thu, 29 May 2003 05:43:09 +1000 (EST) Received: (from ggm@localhost) by garlic.apnic.net (8.12.8p1/8.12.8) id h4SJguRE015459; Thu, 29 May 2003 05:42:56 +1000 (EST) Date: Thu, 29 May 2003 05:42:55 +1000 From: George Michaelson To: Cc: Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Message-Id: <20030529054255.5a51044e.ggm@apnic.net> In-Reply-To: <011101c32536$61cccfa0$56144104@eagleswings> References: <20030528224252.471dc24f.ggm@apnic.net> <011101c32536$61cccfa0$56144104@eagleswings> Organization: APNIC Pty Ltd X-Mailer: Sylpheed version 0.9.0claws1 (GTK+ 1.2.10; i386-pc-netbsdelf1.6T) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On Wed, 28 May 2003 09:29:59 -0700 "Tony Hain" wrote: > George Michaelson wrote: > > ... > > > What is special about a number allocated by > > the "blessed > > > agency" in the case we're discussing? > > > > Strong admission checks into routing are going to make Joe's > > numbers less useful. > > Admission checks by which authority? Remember we are talking about > prefixes which are defined to not exist in the global public routing > system. That makes them completely useful between private routing peers, > until there is a duplication. No, we're talking about a complete system. The strong admission checks are on the other side, in the global routing cloud, excluding these things. The win for the private routing cloud is a much lower chance of address collision for arbitrary non-global connectivity, which for the large corporate sector getting into trade federations outside of the Internet (banks, manufacturing) would seem to me to be worth trying to achieve. > > > Rhetorical questions aside, minor flaws > > don't stop people using systems which are 'modelled' as being > > perfect. Whats special is that the agency is seen to operate > > in a public policy/governance space, to not do what Joe does. > > The IETF does not have a good track record in the policy space. The > numerical registry space is better, but not perfect (how many port > numbers were assigned after the fact???). I believe the root of kre's > concern is that we don't approach the governance space with the > appropriate attitude. We need to admit up front that numbers will never > be absolutely unique, and that some people will want to make up their > own for completely random reasons. All we can do is define a single > rooted registry with a to-be-defined conflict resolution process, and a > space for those who want to do their own thing. We must not define the > business aspects of the registry. I can live with that. I think thats a good position to take on this. Remind me: why isn't this done outside of routing space via flag-bits or something like multicast ttl scope? I would have thought that was always going to be faster to process in router/switch/host firmware or close-to-port logic. If the localization of the address has to be a property of the address, but all addresses are otherwise flat in routing ACLs then I really don't see what the advantage is in explicitly adding non-rooted allocation processes. But I can see why people want the claimed uniqueness to be qualified. As to 'business aspects' I think thats outside IETF, but some bodies *do* want to define that. I think preserving the routing cloud as a commons demands it. cheers -George > > Tony > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- -- George Michaelson | APNIC Email: ggm@apnic.net | PO Box 2131 Milton QLD 4064 Phone: +61 7 3367 0490 | Australia Fax: +61 7 3367 0482 | http://www.apnic.net -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 29 07:01:25 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4TE1PTX012465; Thu, 29 May 2003 07:01:25 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h4TE1OsM012464; Thu, 29 May 2003 07:01:24 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4TE1LTX012457 for ; Thu, 29 May 2003 07:01:21 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4TDxhuc022271 for ; Thu, 29 May 2003 06:59:44 -0700 (PDT) Received: from fuchsia.home (ip26.coe.tnet.co.th [203.146.155.26]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4TDxXep010576 for ; Thu, 29 May 2003 07:59:35 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h4TDvfwW015917; Thu, 29 May 2003 20:57:43 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4TDYji29290; Thu, 29 May 2003 20:34:45 +0700 (ICT) From: Robert Elz To: George Michaelson cc: Brian E Carpenter , john.loughney@nokia.com, ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses In-Reply-To: <20030528224252.471dc24f.ggm@apnic.net> References: <20030528224252.471dc24f.ggm@apnic.net> <20030527215602.7adf2cfb.ggm@apnic.net> <20030527172549.296d8379.ggm@apnic.net> <3ED21F9D.BC0A3162@hursley.ibm.com> <6550.1054017739@munnari.OZ.AU> <8847.1054023979@munnari.OZ.AU> <16170.1054123394@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 29 May 2003 20:34:45 +0700 Message-ID: <29288.1054215285@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Wed, 28 May 2003 22:42:52 +1000 From: George Michaelson Message-ID: <20030528224252.471dc24f.ggm@apnic.net> | Strong admission checks into routing are going to make Joe's numbers | less useful. Huh? My numbers are never going anywhere near anyone's admission checks, except mine. If I want to communicate with the world, I will have, and need, regular global (routable) addresses. The issue here is not that my numbers aren't unique, as I expressly don't care, but that someone else thought they were getting a unique number, and paid for that, and it turns out that their number is just the same as the one I'm using - that is, they didn't get what they paid for at all. If you're promising to sell duck eggs, duck eggs better be what you're providing, just hoping that the eggs you supply never hatch, and so no-one ever finds out they were emu eggs isn't good enough. | If you want to deliberately go and break the global routing cloud you | can do that. Sooner or later, you wil be caught. People even went and showed | they could run alternate roots in DNS. But your punters, people who bought a | thousand from Joe for $10 instead of leasing one from an RIR for $100, | only do that once, if they fall into a hole fast enough. Yes, that's fine - provided that there is something that doesn't work for the "bogus" number. Here, for almost everyone, there's nothing at all that doesn't work for any number they simply invent. Maybe major corporations will want numbers that don't conflict with those of other major corporations, just in case they ever do want to use the things for direct communication. They'll probably pay whatever fee is involved. That's fine. Just don't try and tell them that the numbers allocated are "unique", because they're not - except with the domain of end users who obtained their numbers from the same base source. For us, as protocol designers, what this means is that no matter what we do, nothing, anywhere in this space, can ever be assumed to be a unique number. In some operational environments the number is likely to be unique (no-one else who matters is using the same one), which is fine. But the protocols can *never* assume that. | In this matter, there are no bargains. If you seek to avoid or buck | the system, you will pay a cost, in some measure. How? Exactly what cost am I (on my private network at home) ever going to suffer because of making up my own number instead of paying for one ? | Yes. And, if you select a suitable prefix, I don't see any reason not | to say "this prefix is for sites to use random selection methods to | get 'nearly unique' addresses, if you want that. People who don't want | to see this can filter it! I expect all of this to be filtered just about everywhere. Explicit VPN type setups perhaps excepted (though even there, there's no requirement to use these non-routable addresses - the sites will also have their global addresses that they can use, a VPN after all is really just more trusted, or less filtered, traffic that is known to come from a particular source, it doesn't have to be using private addressing, and can be simpler if it isn't). | No. this is like 'relatively prime' -if you are *reductionist* then you | can't run an Internet anyway. one exception doesn't break 'practical' | uniqueness. If it is the right exception it most certainly does. | We've been living with 'good enough' for a long time, in a lot of different | fields, not just Internet/Networking. How many more than one does it take to | make uniqueness practically useless? I think a HELL of a lot more. George, the problem is that if we claim that the things are unique, people are going to start relying upon that. That is, building protocols that only work if the numbers are unique. Or, in other words, one of the problems with site-local addresses as we have them now is that they're not unique. This proposal is supposedly fixing that. Except it isn't, and we must not fool ourselves into believing that it is. Nothing that had problems because SL addresses weren't guaranteed unique will lave less problems with this proposal. That's fine as far as I'm concerned. | its not about single point decisions. If 2 reasons exist making it useful | isn't that enough? When you argue against one, does the other disappear? Once again, it isn't that unique numbers aren't useful, it is that we have no way to make such things. | > | Plus, the ability to defer a decision to change ones mind later on. | > | > Change one's mind about what? | | About needing uniqueness. You can leave the egg whole and break it later, | but its harder to glue it back together if you break it first and change | your mind... That's fine, provided uniqueness exists to begin with. Here we have it only if everyone agrees to play by the rules, and do the right thing. Everyone. Do you really believe that can possibly happen? Remember the proposal here is to have some entity selling up (up to) 2^40 numbers at 10 Eur each. That's 10,995,116,277,760 Euros (11 US style trillion) available. And the cost of obtaining the raw materials - 0 Euros. The only costs are the distribution costs (the cost of receiving and sending a packet per number, and a system upon which to run it all), and the billing costs. We've already seen people in the name space attempting to (and to a small degree, succeeding) sell names that patently obviously couldn't possibly work - do you really believe that there won't be similar people selling numbers, that patently obviously work just fine (all that's needed is that me and all my friends get our numbers from the same group if we plan on using them between us)? Tony Hain said: | I believe the root of kre's concern is that we don't approach the governance | space with the appropriate attitude. We need to admit up front that numbers | will never be absolutely unique, and that some people will want to make up | their own for completely random reasons. Yes. "We need to admit up front that numbers will never be absolutely unique" Exactly. But ... | All we can do is define a single rooted registry with a to-be-defined | conflict resolution process I'm not sure this is possible (I don't mean technically possible, I mean politically possible). From where to we get the power to decide who is the ultimate authority for numbers ? As George pointed out, even for the current (IPv4) routable numbers, the registries don't attempt to promise that they're useful - it just happens by common consensus that they are, but if one of the registries allocates you a number, and for whatever reason it doesn't work, there's nothing really that you can do about it (if you're really lucky you may get them to refund the fee). Here, there's nothing requiring uniqueness for the numbers to be useful (except for those few organisations that want VPNs between them, for which the only requirement anyway is that none of the organisations involved are using, or seeing, the same numbers). I can imagine a VPN with a few thousand members, much bigger than that, and I suspect that what you have is just a public internet (that is, with all the same problems, of wanting to be using topological addressing to make the routing scale sensibly, and hence not wanting to distribute around "non-routable" numbers anyway). Brian said that he wanted to avoid another ICANN nightmare (my words, not his). He didn't say how he planned on doing that. With 11 trillion Euros available for someone (over time) there's sure going to be a lot of pressure, both from organisations that want to get their finger in, and even from governments who want all of that foreign exchange flowing into their country, rather that flowing out to some other. Is the intent here to just slip this through and hope that no-one notices? 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 May 29 17:52:21 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4U0qLTX014914; Thu, 29 May 2003 17:52:21 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h4U0qL7t014913; Thu, 29 May 2003 17:52:21 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4U0qHTX014906 for ; Thu, 29 May 2003 17:52:17 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4U0oeKw008726 for ; Thu, 29 May 2003 17:50:40 -0700 (PDT) Received: from oak1a.cats.ohiou.edu (oak.cats.ohiou.edu [132.235.8.44]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4U0oU3K012551 for ; Thu, 29 May 2003 18:50:35 -0600 (MDT) Received: from hkruse.csm.ohiou.edu (hkruse.csm.ohiou.edu [132.235.75.144]) (authenticated bits=0) by oak1a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id h4U0j2AP534315 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Thu, 29 May 2003 20:45:03 -0400 (EDT) Date: Thu, 29 May 2003 20:45:58 -0400 From: Hans Kruse To: ipng@sunroof.eng.sun.com Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses Message-ID: <2377861193.1054241155@hkruse.csm.ohiou.edu> In-Reply-To: <20030527193820.GA6652@fysh.org> References: <20030527193820.GA6652@fysh.org> X-Mailer: Mulberry/2.2.1 (Win32) 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 I actually see a lot of value in the /56 proposal; I really like the simplicity of creating the /56 from any MAC-48 in the network. It accomplishes the uniqueness property without requiring central registration, and should serve organizations up to considerable size very well. And it readily discourages the notion of "make up a prefix" for temporary or (temporarily) disconnected networks. In the applications I can envision, a /56 should work fine, and an organization can "make more" based on additional MAC-48s. The draft might contain some language like "An organization using this method for creating unique network prefixes SHOULD (or MUST?) retain physical custody of the network device contain the MAC-48 used to define the prefix, for as long the prefix is in use". The way globally unique /48s based on a central registry are really only needed for very large organizations. --On Tuesday, May 27, 2003 20:38 +0100 Zefram wrote: > Bob Hinden wrote: >> There is a clear tradeoff between a longer ID (to allow for better >> random numbers or MAC addresses) and the size of the subnet field. >> >> Before revising the draft, I would prefer to hear from more people on >> these tradeoffs. > > Although I was one of those that suggested a technique that would generate > /56 prefixes, I see great value in arranging for /48 prefixes where > possible, for uniformity with RFC3177. For randomly-generated addresses > (both centrally allocated and individually allocated), an 8-bit format > prefix and 40 bits of randomness seems like a good tradeoff. 40 bits > seems to be about the amount of entropy we're aiming at, and a handful > of bits either way makes no difference. An 8-bit format prefix is not > too wasteful of address space. > > The case for which I suggested /56 prefixes was generating a prefix > from a MAC-48. In that case, with 46 effective bits of identifier > to fit into the prefix, we clearly can't get a /48. It seems like a > valuable technique, but would have to be an exception to the /48 rule. > Of course, any site needing more than eight bits of subnet ID is likely > to have many MAC-48s to play with if they have any at all. > > -zefram > -- > Andrew Main (Zefram) > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to majordomo@sunroof.eng.sun.com > -------------------------------------------------------------------- Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 29 20:42:36 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4U3gaTX015385; Thu, 29 May 2003 20:42:36 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h4U3gaBS015384; Thu, 29 May 2003 20:42:36 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4U3gXTX015377 for ; Thu, 29 May 2003 20:42:33 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4U3euuc026952 for ; Thu, 29 May 2003 20:40:56 -0700 (PDT) Received: from SERVER2000.arneill-py.sacramento.ca.us (adsl-209-233-126-65.dsl.scrm01.pacbell.net [209.233.126.65]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4U3ep4Z023026 for ; Thu, 29 May 2003 20:40:51 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: Draft on Globally Unique IPv6 Local Unicast Addresses MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Thu, 29 May 2003 20:41:13 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0 Message-ID: <963621801C6D3E4A9CF454A1972AE8F506717B@server2000.arneill-py.sacramento.ca.us> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft on Globally Unique IPv6 Local Unicast Addresses Thread-Index: AcMmRjYC4zMKPnrLQj+bKapS7tT07gAFqJ0Q From: "Michel Py" To: "Hans Kruse" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by sunroof.eng.sun.com id h4U3gXTX015378 Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk > Hans Kruse wrote: > I actually see a lot of value in the /56 proposal I will side with Brian Carpenter on this one: we have RFC3177 and I do not see enough reasons to re-visit it at this time. Michel. -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Thu May 29 22:25:31 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4U5PVTX015747; Thu, 29 May 2003 22:25:31 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h4U5PVGr015746; Thu, 29 May 2003 22:25:31 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4U5PSTX015739 for ; Thu, 29 May 2003 22:25:28 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4U5Npuc021083 for ; Thu, 29 May 2003 22:23:51 -0700 (PDT) Received: from ursa.amorsen.dk (x1-6-00-e0-28-13-bf-45.k32.webspeed.dk [195.41.138.12]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4U5Nj4Z000158 for ; Thu, 29 May 2003 22:23:46 -0700 (PDT) Received: from vega.amorsen.dk (unknown [172.31.4.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ursa.amorsen.dk (Postfix) with ESMTP id C395F1C174; Fri, 30 May 2003 07:23:43 +0200 (CEST) Subject: Re: Draft on Globally Unique IPv6 Local Unicast Addresses From: Benny Amorsen To: Hans Kruse Cc: ipng@sunroof.eng.sun.com In-Reply-To: <2377861193.1054241155@hkruse.csm.ohiou.edu> References: <20030527193820.GA6652@fysh.org> <2377861193.1054241155@hkruse.csm.ohiou.edu> Content-Type: text/plain Message-Id: <1054272212.1703.15.camel@vega.amorsen.dk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (1.3.92-1) (Preview Release) Date: 30 May 2003 07:23:32 +0200 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On fre, 2003-05-30 at 02:45, Hans Kruse wrote: > I actually see a lot of value in the /56 proposal; I really like the > simplicity of creating the /56 from any MAC-48 in the network. It > accomplishes the uniqueness property without requiring central > registration, and should serve organizations up to considerable size very > well. And it readily discourages the notion of "make up a prefix" for > temporary or (temporarily) disconnected networks. I have been lurking in this discussion by reading it as a newsgroup over at gmane.org. (I tried to post too, but even though gmane.org said it was posted, I do not think it reached the mailing list.) It seems to me that things would be easier by letting people invent their own numbers by whatever method they prefer. Then, if they care whether the numbers are unique, they can register the numbers they picked in one or more registries. This way they can be assured that other well-behaved people will not use the same numbers, and at the same time it is clear to everyone that the numbers are not /guaranteed/ to be unique. Later when two organisations need to connect to each other directly and the numbers conflict, I bet the organisation that registered its numbers has a good chance of being the one not having to renumber... By the way, I am not very fond of the MAC-address method. If we are into misusing other registries, we could turn a phone number into hexadecimal (including the international prefix.) 12 digits can be stored in 40 bit... /Benny -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 29 23:15:46 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4U6FjTX015965; Thu, 29 May 2003 23:15:45 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h4U6Fjea015964; Thu, 29 May 2003 23:15:45 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4U6FgTX015957 for ; Thu, 29 May 2003 23:15:42 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4U6E5uc003041 for ; Thu, 29 May 2003 23:14:05 -0700 (PDT) Received: from ALPHA9.ITS.MONASH.EDU.AU (alpha9.its.monash.edu.au [130.194.1.9]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4U6Dx3K023093 for ; Fri, 30 May 2003 00:13:59 -0600 (MDT) Received: from blammo.its.monash.edu.au ([130.194.1.74]) by vaxh.its.monash.edu.au (PMDF V5.2-31 #39306) with ESMTP id <01KWIBA1IOO69B3VS6@vaxh.its.monash.edu.au> for ipng@sunroof.eng.sun.com; Fri, 30 May 2003 16:01:25 +1000 Received: from blammo.its.monash.edu.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 1BF3912C018; Fri, 30 May 2003 16:01:25 +1000 (EST) Received: from eng.monash.edu.au (knuth.eng.monash.edu.au [130.194.252.110]) by blammo.its.monash.edu.au (Postfix) with ESMTP id 82E1E12C009; Fri, 30 May 2003 16:01:15 +1000 (EST) Date: Fri, 30 May 2003 16:01:15 +1000 From: Greg Daley Subject: Misusing registries for uniqueness (was Re: Draft on Globally Unique IPv6 Local Unicast Addresses) To: Benny Amorsen Cc: ipng@sunroof.eng.sun.com Reply-to: greg.daley@eng.monash.edu.au Message-id: <3ED6F3AB.6050003@eng.monash.edu.au> Organization: Monash University MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529 X-Accept-Language: en, en-us References: <20030527193820.GA6652@fysh.org> <2377861193.1054241155@hkruse.csm.ohiou.edu> <1054272212.1703.15.camel@vega.amorsen.dk> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Hi Benny, Benny Amorsen wrote: [part snipped] > By the way, I am not very fond of the MAC-address method. If we are into > misusing other registries, we could turn a phone number into hexadecimal > (including the international prefix.) 12 digits can be stored in 40 > bit... It's not that dumb an idea, it reminds me of base-85 (RFC-1924) IPv6 addressing notation. It certainly does solve the uniqueness issue for any given instant. What happens if you 're-number' your telephone? Greg :) -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 30 02:26:07 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4U9Q7TX016728; Fri, 30 May 2003 02:26:07 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h4U9Q7RM016727; Fri, 30 May 2003 02:26:07 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4U9Q3TX016720 for ; Fri, 30 May 2003 02:26:03 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Central.Sun.COM [129.147.5.43]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4U9OQuc012343 for ; Fri, 30 May 2003 02:24:26 -0700 (PDT) Received: from ratree.psu.ac.th (ratree.psu.ac.th [202.12.73.3]) by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4U9OIYU007835 for ; Fri, 30 May 2003 03:24:19 -0600 (MDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h4U9OAP09997; Fri, 30 May 2003 16:24:11 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h4U990E09766; Fri, 30 May 2003 16:09:00 +0700 (ICT) From: Robert Elz To: greg.daley@eng.monash.edu.au cc: ipng@sunroof.eng.sun.com Subject: Re: Misusing registries for uniqueness (was Re: Draft on Globally Unique IPv6 Local Unicast Addresses) In-Reply-To: <3ED6F3AB.6050003@eng.monash.edu.au> References: <3ED6F3AB.6050003@eng.monash.edu.au> <20030527193820.GA6652@fysh.org> <2377861193.1054241155@hkruse.csm.ohiou.edu> <1054272212.1703.15.camel@vega.amorsen.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 May 2003 16:09:00 +0700 Message-ID: <9764.1054285740@munnari.OZ.AU> Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk Date: Fri, 30 May 2003 16:01:15 +1000 From: Greg Daley Message-ID: <3ED6F3AB.6050003@eng.monash.edu.au> | It's not that dumb an idea, it reminds me of | base-85 (RFC-1924) IPv6 addressing notation. Which is a joke, not an idea (dumb or otherwise)... | It certainly does solve the uniqueness issue | for any given instant. What happens if you | 're-number' your telephone? This has the same problem as MAC addresses - it isn't stable (someone else can quite validly end up with the number that used to be yours). But, if abusing number spaces to try and gain easier uniqueness is an aim, then a (less automatic but perhaps still reasonable) method would be to abuse the IEEE OUI space (instead of the MAC address space). That is, any organisation with an OUI (22 real bits big) has 18 bits (256K) of numbers they can allocate however they see fit. And of course, organisations that the IEEE allows can go get new numbers. (The IETF is one such organisation of course, so IANA would have numbers to allocate). (This re-use of numbers would not conflict with other uses of the OUI, it would be in parallel, just as MAC48 and EUI-48 are - it would be xxx-40 of course, or -45 or something, depending upon prefix length). Of course, IEEE would probably need to agree to their number space being abused this way before we could suggest it as a method. Doing this still doesn't guarantee any kind of uniqueness, all it does is provide a ready made answer to the "one monopoly organisation" problem, while similtaneously making it effectively impossible for anyone to snarf any large fraction of the address space (no need to prescribe huge fees - like Eur 10). Even adding in registries, as Benny Amorsen proposed, doesn't really solve the problems. To be unique, there'd need to be one overall registry (perhaps sub-dividing the space to others) - which again means one monopoly, with no real justification for anyone to be the owner of that. Further, it only helps if people actually register (otherwise there are the same issues as with trade marks, where they can be held, unregistered, for a very long time, etc - except we have no legislation or case law to help with consistent reasonable answers to who wins). Multiple registries just means more places to register, and would create more confusion if A registers in registry 1, and B registers the same number in registry 2 (perhaps at about the same time, perhaps not). To actually get any kind of uniqueness, we need something that fails to work if the numbers are duplicated anywhere - and as these numbers are addresses, that really means that addressing has to fail. I can't see how that can possibly happen for numbers intended to be used only locally. 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 Fri May 30 14:38:33 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4ULcXTX019856; Fri, 30 May 2003 14:38:33 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h4ULcXEM019855; Fri, 30 May 2003 14:38:33 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4ULcTTX019848 for ; Fri, 30 May 2003 14:38:29 -0700 (PDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4ULaquc005132 for ; Fri, 30 May 2003 14:36:52 -0700 (PDT) Received: from ursa.amorsen.dk (x1-6-00-e0-28-13-bf-45.k32.webspeed.dk [195.41.138.12]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4ULak4Z012441 for ; Fri, 30 May 2003 14:36:47 -0700 (PDT) Received: from vega.amorsen.dk (unknown [172.31.4.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ursa.amorsen.dk (Postfix) with ESMTP id 62B991C174 for ; Fri, 30 May 2003 23:36:41 +0200 (CEST) Subject: Re: Misusing registries for uniqueness From: Benny Amorsen To: ipng@sunroof.eng.sun.com In-Reply-To: <9764.1054285740@munnari.OZ.AU> References: <3ED6F3AB.6050003@eng.monash.edu.au> <20030527193820.GA6652@fysh.org> <2377861193.1054241155@hkruse.csm.ohiou.edu> <1054272212.1703.15.camel@vega.amorsen.dk> <9764.1054285740@munnari.OZ.AU> Content-Type: text/plain Message-Id: <1054330599.1855.1.camel@vega.amorsen.dk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.92 (1.3.92-1) (Preview Release) Date: 30 May 2003 23:36:40 +0200 Content-Transfer-Encoding: 7bit Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk On 2003-05-30 at 11:09, Robert Elz wrote: > Even adding in registries, as Benny Amorsen proposed, doesn't really > solve the problems. To be unique, there'd need to be one overall > registry (perhaps sub-dividing the space to others) - which again means > one monopoly, with no real justification for anyone to be the owner of > that. The advantage of using multiple registries is that the problems are obvious to everyone. No one ends up thinking that their number is guaranteed to be unique. As you point out later, the addresses /cannot/ be enforced to be unique. There were organisations which used 9/8 or 192/8 (not 192.168/16) addresses for site local addressing in IPv4. An Internet Standard cannot force people to comply. I do not think there should be one top-level registry that subdivides space to other registries. Rather I think each registry should pick whatever bit of address space they feel like, within a single global allocation for site-local addresses. If two registries pick the same address space, too bad. Either they figure out a way to reconcile, or customers will avoid them. If a registry takes too much space, the other registries will ignore them. Either way, anyone can set up their own registry of site-local IPv6 numbers. I think the working group should try to stay out of the fray, except for setting aside a reasonably large space for it. A /16 would seem appropriate. Should site-local addresses end up not being standardised, there is always 10/8 mapped with 6to4... /Benny -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP 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 May 30 15:28:59 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4UMSxTX020351; Fri, 30 May 2003 15:28:59 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h4UMSx10020350; Fri, 30 May 2003 15:28:59 -0700 (PDT) Received: from engmail2sun.Eng.Sun.COM (engmail2sun [129.144.134.19]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4UMStTX020343 for ; Fri, 30 May 2003 15:28:55 -0700 (PDT) Received: from brmea-mail-3.sun.com (brmea-mail-3.Central.Sun.COM [129.147.5.34]) by engmail2sun.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4UMRIuc021462 for ; Fri, 30 May 2003 15:27:18 -0700 (PDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4UMRBep012035 for ; Fri, 30 May 2003 16:27:12 -0600 (MDT) 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 PAA24335; Fri, 30 May 2003 15:27:10 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id h4UMR9r19437; Fri, 30 May 2003 15:27:09 -0700 X-mProtect: <200305302227> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.9.150, claiming to be "spruce.iprg.nokia.com") by darkstar.iprg.nokia.com smtpdk3C5Wb; Fri, 30 May 2003 15:27:08 PDT Message-Id: <4.3.2.7.2.20030530151751.02bbafd8@mailhost.iprg.nokia.com> X-Sender: hinden@mailhost.iprg.nokia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 May 2003 15:26:00 -0700 To: Benny Amorsen From: Bob Hinden Subject: Re: Misusing registries for uniqueness Cc: ipng@sunroof.eng.sun.com In-Reply-To: <1054330599.1855.1.camel@vega.amorsen.dk> References: <9764.1054285740@munnari.OZ.AU> <3ED6F3AB.6050003@eng.monash.edu.au> <20030527193820.GA6652@fysh.org> <2377861193.1054241155@hkruse.csm.ohiou.edu> <1054272212.1703.15.camel@vega.amorsen.dk> <9764.1054285740@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipng@sunroof.eng.sun.com Precedence: bulk I don't follow this. It seems to me that there are two points on the allocation spectrum that are useful. At one end there is a central registry for organizations that are willing to pay something and want some higher assurance of uniqueness (and a way to reconcile disputes). At the other end is local generation of pseudo-random identifiers. If people want to set up web sites that generate the pseudo-random numbers for this purpose, that is fine too. I don't see any need for something in between the two approaches. The value of a registry is to have a higher guarantee of uniqueness. Other than that they should be generated locally. Bob At 02:36 PM 5/30/2003, Benny Amorsen wrote: >On 2003-05-30 at 11:09, Robert Elz wrote: > > > Even adding in registries, as Benny Amorsen proposed, doesn't really > > solve the problems. To be unique, there'd need to be one overall > > registry (perhaps sub-dividing the space to others) - which again means > > one monopoly, with no real justification for anyone to be the owner of > > that. > >The advantage of using multiple registries is that the problems are >obvious to everyone. No one ends up thinking that their number is >guaranteed to be unique. >As you point out later, the addresses /cannot/ be enforced to be unique. >There were organisations which used 9/8 or 192/8 (not 192.168/16) >addresses for site local addressing in IPv4. An Internet Standard cannot >force people to comply. > >I do not think there should be one top-level registry that subdivides >space to other registries. Rather I think each registry should pick >whatever bit of address space they feel like, within a single global >allocation for site-local addresses. If two registries pick the same >address space, too bad. Either they figure out a way to reconcile, or >customers will avoid them. If a registry takes too much space, the other >registries will ignore them. > >Either way, anyone can set up their own registry of site-local IPv6 >numbers. I think the working group should try to stay out of the fray, >except for setting aside a reasonably large space for it. A /16 would >seem appropriate. > >Should site-local addresses end up not being standardised, there is >always 10/8 mapped with 6to4... > > >/Benny > > > >-------------------------------------------------------------------- >IETF IPng Working Group Mailing List >IPng Home Page: http://playground.sun.com/ipng >FTP archive: ftp://playground.sun.com/pub/ipng >Direct all administrative requests to majordomo@sunroof.eng.sun.com >-------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- From owner-ipng@sunroof.eng.sun.com Sat May 31 13:52:15 2003 Received: from sunroof.eng.sun.com (localhost [127.0.0.1]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4VKqETX022819; Sat, 31 May 2003 13:52:15 -0700 (PDT) Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0/Submit) id h4VKqEMO022818; Sat, 31 May 2003 13:52:14 -0700 (PDT) Received: from engmail1mpk.Eng.Sun.COM (engmail1mpk [129.146.1.45]) by sunroof.eng.sun.com (8.12.10.Beta0+Sun/8.12.10.Beta0) with ESMTP id h4VKqBTX022811 for ; Sat, 31 May 2003 13:52:11 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Central.Sun.COM [129.147.5.31]) by engmail1mpk.Eng.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4VKoWNh015904 for ; Sat, 31 May 2003 13:50:32 -0700 (PDT) Received: from oak1a.cats.ohiou.edu (oak.cats.ohiou.edu [132.235.8.44]) by brmea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h4VKoQ3K026231 for ; Sat, 31 May 2003 14:50:27 -0600 (MDT) Received: from hkruse.csm.ohiou.edu (hkruse.csm.ohiou.edu [132.235.75.144]) (authenticated bits=0) by oak1a.cats.ohiou.edu (8.12.8-OU/8.12.8-OU) with ESMTP id h4VKlpAP1047807 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Sat, 31 May 2003 16:47:51 -0400 (EDT) Date: Sat, 31 May 2003 16:48:51 -0400 From: Hans Kruse To: ipng@sunroof.eng.sun.com Subject: Re: Misusing registries for uniqueness Message-ID: <2536437283.1054399731@hkruse.csm.ohiou.edu> In-Reply-To: <4.3.2.7.2.20030530151751.02bbafd8@mailhost.iprg.nokia.com> References: <4.3.2.7.2.20030530151751.02bbafd8@mailhost.iprg.nokia.com> X-Mailer: Mulberry/2.2.1 (Win32) 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 I agree. --On Friday, May 30, 2003 15:26 -0700 Bob Hinden wrote: > I don't follow this. It seems to me that there are two points on the > allocation spectrum that are useful. At one end there is a central > registry for organizations that are willing to pay something and want > some higher assurance of uniqueness (and a way to reconcile disputes). > At the other end is local generation of pseudo-random identifiers. If > people want to set up web sites that generate the pseudo-random numbers > for this purpose, that is fine too. I don't see any need for something > in between the two approaches. The value of a registry is to have a > higher guarantee of uniqueness. Other than that they should be generated > locally. Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com --------------------------------------------------------------------